tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
* \w'blah'u issues (really: 'u' scaling width)
@ 2014-08-09 17:01 Kristaps Dzonsons
  2014-08-09 20:41 ` Ingo Schwarze
  0 siblings, 1 reply; 4+ messages in thread
From: Kristaps Dzonsons @ 2014-08-09 17:01 UTC (permalink / raw)
  To: tech

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

Hello,

Earlier I mentioned, as an aside, that OpenGL manuals look bad.  Try 
rendering gluPerspective to see what I mean.  (Attached.)

I tracked this down to the following:

.SH PARAMETERS
.TP \w'\fIaspect\fP\ \ 'u
\f2fovy\fP
Specifies the field of view angle, in degrees, in the \f2y\fP direction.
.TP
\f2aspect\fP

Note that the width of the TP head is being set to the contents of 
\w'xxx'.  So this should be interpreted as

.Tp <width of "aspect  ">u

which should amount to 8 character widths.

However, in roff.c:630, we multiply this width by 24.  As a result, 
everything's wonky.  (8 * 24 = a long line)

At first I thought that we should just yank the 24.  But in running a 
little test, it seems that the \w'' doesn't calculate the string width 
in characters, but in magic internal units.  So it's not that we 
shouldn't multiply by 24, but instead that the "u" scaling unit should 
*divide* by 24.

The test was:

.TH FOO 1
.TP \w'h'u
hello
world
.TP 24u
hello
world
.TP 48u
hello
world

These now display similarly between mandoc and nroff with the enclosed 
patch, though I haven't tested it exhaustively.  Thoughts?

Best,

Kristaps

[-- Attachment #2: gluPerspective.3 --]
[-- Type: text/plain, Size: 2653 bytes --]

'\" e  
'\"macro stdmacro
.ds Vn Version 1.2
.ds Dt 6 March 1997
.ds Re Release 1.2.0
.ds Dp May 22 14:54
.ds Dm 0 May 22 14:
.ds Xs 14699     5
.TH GLUPERSPECTIVE 3G
.SH NAME
.B "gluPerspective
\- set up a perspective projection matrix

.SH C SPECIFICATION
void \f3gluPerspective\fP(
GLdouble \fIfovy\fP,
.nf
.ta \w'\f3void \fPgluPerspective( 'u
	GLdouble \fIaspect\fP,
	GLdouble \fIzNear\fP,
	GLdouble \fIzFar\fP )
.fi

.SH PARAMETERS
.TP \w'\fIaspect\fP\ \ 'u 
\f2fovy\fP
Specifies the field of view angle, in degrees, in the \f2y\fP direction.
.TP
\f2aspect\fP
Specifies the aspect ratio that determines
the field of view in the \f2x\fP direction.
The aspect ratio is the ratio of \f2x\fP (width) to \f2y\fP (height).
.TP
\f2zNear\fP
Specifies the distance from the viewer to the near clipping plane
(always positive).
.TP
\f2zFar\fP
Specifies the distance from the viewer to the far clipping plane
(always positive).
.SH DESCRIPTION
\%\f3gluPerspective\fP specifies a viewing frustum into the world coordinate system.
In general, the aspect ratio in \%\f3gluPerspective\fP should match the aspect ratio
of the associated viewport. For example, aspect = 2.0 means 
the viewer's
angle of view is twice as wide in \f2x\fP as it is in \f2y\fP.
If the viewport is
twice as wide as it is tall, it displays the image without distortion.
.P
The matrix generated by \%\f3gluPerspective\fP is multipled by the current matrix,
just as if \f3glMultMatrix\fP were called with the generated matrix.
To load the perspective matrix onto the current matrix stack instead,
precede the call to \%\f3gluPerspective\fP with a call to \f3glLoadIdentity\fP.
.P
Given \f2f\fP defined as follows:
.sp
.ce
f  = cotangent(fovy/2)

The generated matrix is
.Bd -literal
      f
 ------------       0              0              0
    aspect

                 
     0              f              0              0

                               zFar+zNear    2*zFar*zNear
     0              0          ----------    ------------
                               zNear-zFar     zNear-zFar

     0              0              -1             0

.Ed

.SH NOTES
Depth buffer precision is affected by the values specified for
\f2zNear\fP and \f2zFar\fP.
The greater the ratio of \f2zFar\fP to \f2zNear\fP is,
the less effective the depth buffer will be at distinguishing between
surfaces that are near each other.
If 

.ce
r = zFar/zNear

.P
roughly log2(r) bits of depth buffer precision are lost.
Because r approaches infinity as \f2zNear\fP approaches 0,
\f2zNear\fP must never be set to 0.
.SH SEE ALSO
\f3glFrustum\fP, \f3glLoadIdentity\fP,
\f3glMultMatrix\fP, \%\f3gluOrtho2D\fP

[-- Attachment #3: scale.diff --]
[-- Type: text/plain, Size: 2010 bytes --]

Index: term_ps.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ps.c,v
retrieving revision 1.62
diff -u -p -r1.62 term_ps.c
--- term_ps.c	1 Aug 2014 19:25:52 -0000	1.62
+++ term_ps.c	9 Aug 2014 16:59:03 -0000
@@ -1145,6 +1145,9 @@ ps_hspan(const struct termp *p, const st
 	case SCALE_VS:
 		r = su->scale * p->ps->lineheight;
 		break;
+	case SCALE_BU:
+		r = PNT2AFM(p, su->scale / 3.0);
+		break;
 	default:
 		r = su->scale;
 		break;
Index: term_ascii.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ascii.c,v
retrieving revision 1.27
diff -u -p -r1.27 term_ascii.c
--- term_ascii.c	1 Aug 2014 19:25:52 -0000	1.27
+++ term_ascii.c	9 Aug 2014 16:59:04 -0000
@@ -255,6 +255,9 @@ ascii_hspan(const struct termp *p, const
 	case SCALE_VS:
 		r = su->scale * 2.0 - 1.0;
 		break;
+	case SCALE_BU:
+		r = su->scale / 24.0;
+		break;
 	default:
 		r = su->scale;
 		break;
Index: term.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term.c,v
retrieving revision 1.226
diff -u -p -r1.226 term.c
--- term.c	1 Aug 2014 19:38:29 -0000	1.226
+++ term.c	9 Aug 2014 16:59:04 -0000
@@ -786,6 +786,9 @@ term_vspan(const struct termp *p, const 
 	case SCALE_VS:
 		r = su->scale;
 		break;
+	case SCALE_BU:
+		r = su->scale / 24.0;
+		break;
 	default:
 		r = su->scale - 1.0;
 		break;
Index: html.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/html.c,v
retrieving revision 1.159
diff -u -p -r1.159 html.c
--- html.c	23 Jul 2014 15:00:08 -0000	1.159
+++ html.c	9 Aug 2014 16:59:04 -0000
@@ -761,6 +761,8 @@ bufcat_su(struct html *h, const char *p,
 	v = su->scale;
 	if (SCALE_MM == su->unit && 0.0 == (v /= 100.0))
 		v = 1.0;
+	if (SCALE_BU == su->unit)
+		v /= 24.0;
 
 	bufcat_fmt(h, "%s: %.2f%s;", p, v, roffscales[su->unit]);
 }

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: \w'blah'u issues (really: 'u' scaling width)
  2014-08-09 17:01 \w'blah'u issues (really: 'u' scaling width) Kristaps Dzonsons
@ 2014-08-09 20:41 ` Ingo Schwarze
  2014-08-12  1:04   ` Kristaps Dzonsons
  0 siblings, 1 reply; 4+ messages in thread
From: Ingo Schwarze @ 2014-08-09 20:41 UTC (permalink / raw)
  To: Kristaps Dzonsons; +Cc: tech

Hi Kristaps,

my suspicion is that some cleanup is required with respect to scaling
units.  So far, i never looked closely at that part.

Kristaps Dzonsons wrote on Sat, Aug 09, 2014 at 07:01:40PM +0200:

> Earlier I mentioned, as an aside, that OpenGL manuals look bad.  Try
> rendering gluPerspective to see what I mean.  (Attached.)
> 
> I tracked this down to the following:
> 
> .SH PARAMETERS
> .TP \w'\fIaspect\fP\ \ 'u
> \f2fovy\fP
> Specifies the field of view angle, in degrees, in the \f2y\fP direction.
> .TP
> \f2aspect\fP
> 
> Note that the width of the TP head is being set to the contents of
> \w'xxx'.  So this should be interpreted as
> 
> .Tp <width of "aspect  ">u
> 
> which should amount to 8 character widths.
> 
> However, in roff.c:630, we multiply this width by 24.  As a result,
> everything's wonky.  (8 * 24 = a long line)
> 
> At first I thought that we should just yank the 24.  But in running
> a little test, it seems that the \w'' doesn't calculate the string
> width in characters, but in magic internal units.

The terminus technicus is "basic unit", see the Heirloom manual for
details.  It is device-specific, defined by the "res" entry in the
DESC file.  For all terminal devices, including -Tascii, -Tlatin,
-Tutf8, -Tlocale, -Thtml, -Txhtml, 240 basic units = 1 inch.
For -Tps and -Tpdf, 72000 basic units = 1 inch.

> So it's not that we shouldn't multiply by 24,

With the current architecture, roff.c cannot do the right thing
since it doesn't know about the output device and mustn't care.
On the other hand, it cannot defer expansion to the formatters
because \w can be used in numerical expressions, register
assignments and .if conditionals, which the formatters do not
have access to.

So the best thing roff.c can do is assume terminal output.
In that case, 10n = 1in hence 1n = 24u, yes.

> but instead that the "u" scaling unit should *divide* by 24.

Looking at ascii_hspan() in term_ascii.c, i must say the comment
about eyeballing is scary.  We want to convert from various units
to "n".  Why not just put the exact numbers?  That would be:

  /* inch-based */
  SCALE_IN:  * 10.0        /* ok */
  SCALE_PC:  * 10.0/6.0    /* ok */
  SCALE_PT:  * 10.0/72.0   /* ok */
  SCALE_BU:  * 10.0/240.0  /* missing indeed */
  SCALE_CM:  * 10.0/2.54   /* slightly off */

  /* character-based */
  SCALE_EN:  * 1.0         /* ok */
  SCALE_EM:  * 1.0         /* ok */
  SCALE_MM:  * 1.0/100.0   /* completely wrong */

The function ps_hspan() wants to convert various units to points.
The exact values are:

  SCALE_IN:  * 72.0        /* ok */
  SCALE_PC:  * 12.0        /* ok */
  SCALE_PT:  * 1.0         /* completely wrong */
  SCALE_BU:  * 72.0/240.0  /* missing; *0.3, not /3.0 as you suggest */
  SCALE_CM:  * 72.0/2.54   /* approximately right */

The case SCALE_MM must be the same as SCALE_EM, but with an
additional factor of * 100.0.  MM is *not* millimeter!

Summarizing in-line:

> Index: term_ps.c
> ===================================================================
> RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ps.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 term_ps.c
> --- term_ps.c	1 Aug 2014 19:25:52 -0000	1.62
> +++ term_ps.c	9 Aug 2014 16:59:03 -0000
> @@ -1145,6 +1145,9 @@ ps_hspan(const struct termp *p, const st
>  	case SCALE_VS:
>  		r = su->scale * p->ps->lineheight;
>  		break;
> +	case SCALE_BU:
> +		r = PNT2AFM(p, su->scale / 3.0);

                r = PNT2AFM(p, su->scale * 0.3);

would seem right, and PT and CM should also be corrected.

> +		break;
>  	default:
>  		r = su->scale;
>  		break;
> Index: term_ascii.c
> ===================================================================
> RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ascii.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 term_ascii.c
> --- term_ascii.c	1 Aug 2014 19:25:52 -0000	1.27
> +++ term_ascii.c	9 Aug 2014 16:59:04 -0000
> @@ -255,6 +255,9 @@ ascii_hspan(const struct termp *p, const
>  	case SCALE_VS:
>  		r = su->scale * 2.0 - 1.0;
>  		break;
> +	case SCALE_BU:
> +		r = su->scale / 24.0;
> +		break;

Yes, and MM and CM should also be corrected.

>  	default:
>  		r = su->scale;
>  		break;
> Index: term.c
> ===================================================================
> RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term.c,v
> retrieving revision 1.226
> diff -u -p -r1.226 term.c
> --- term.c	1 Aug 2014 19:38:29 -0000	1.226
> +++ term.c	9 Aug 2014 16:59:04 -0000
> @@ -786,6 +786,9 @@ term_vspan(const struct termp *p, const 
>  	case SCALE_VS:
>  		r = su->scale;
>  		break;
> +	case SCALE_BU:
> +		r = su->scale / 24.0;
> +		break;
>  	default:
>  		r = su->scale - 1.0;
>  		break;

No, here you want to convert to pica (1/6 inch, 12 points, 40u).
So that should be:

  /* inch-based */
  SCALE_IN:  * 6.0         /* ok */
  SCALE_PC:  * 1.0         /* ok */
  SCALE_PT:  / 12.0        /* wrong */
  SCALE_BU:  * 6.0/240.0   /* missing; /40.0, not /24.0 */
  SCALE_CM:  * 6.0/2.54    /* slightly off */

  /* character-based */
  SCALE_EN:  * 6.0/10.0    /* wrong */
  SCALE_EM:  * 6.0/10.0    /* wrong */
  SCALE_MM:  * 6.0/1000.0  /* completely wrong */

> Index: html.c
> ===================================================================
> RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/html.c,v
> retrieving revision 1.159
> diff -u -p -r1.159 html.c
> --- html.c	23 Jul 2014 15:00:08 -0000	1.159
> +++ html.c	9 Aug 2014 16:59:04 -0000
> @@ -761,6 +761,8 @@ bufcat_su(struct html *h, const char *p,
>  	v = su->scale;
>  	if (SCALE_MM == su->unit && 0.0 == (v /= 100.0))
>  		v = 1.0;
> +	if (SCALE_BU == su->unit)
> +		v /= 24.0;
>  
>  	bufcat_fmt(h, "%s: %.2f%s;", p, v, roffscales[su->unit]);
>  }

Yes.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: \w'blah'u issues (really: 'u' scaling width)
  2014-08-09 20:41 ` Ingo Schwarze
@ 2014-08-12  1:04   ` Kristaps Dzonsons
  2014-08-12  2:43     ` Ingo Schwarze
  0 siblings, 1 reply; 4+ messages in thread
From: Kristaps Dzonsons @ 2014-08-12  1:04 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: tech

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

Ingo,

Enclosed are the horizontal adjustments as per your suggestions.  (NOT 
the vertical ones yet.)  To test this, I simply ran mandoc and groff 
side-by-side with both -Tascii and -Tps with each test unit having a 
resulting non-zero length.  They're more-or-less similar, but if we want 
to be precisely the same, there's more work to be done.

Best,

Kristaps

[-- Attachment #2: hspaces.diff --]
[-- Type: text/plain, Size: 3326 bytes --]

Index: html.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/html.c,v
retrieving revision 1.160
diff -u -p -r1.160 html.c
--- html.c	10 Aug 2014 23:54:41 -0000	1.160
+++ html.c	12 Aug 2014 01:02:16 -0000
@@ -759,6 +759,8 @@ bufcat_su(struct html *h, const char *p,
 	v = su->scale;
 	if (SCALE_MM == su->unit && 0.0 == (v /= 100.0))
 		v = 1.0;
+	else if (SCALE_BU == su->unit)
+		v /= 24.0;
 
 	bufcat_fmt(h, "%s: %.2f%s;", p, v, roffscales[su->unit]);
 }
Index: term_ascii.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ascii.c,v
retrieving revision 1.28
diff -u -p -r1.28 term_ascii.c
--- term_ascii.c	10 Aug 2014 23:54:41 -0000	1.28
+++ term_ascii.c	12 Aug 2014 01:02:16 -0000
@@ -230,31 +230,41 @@ ascii_hspan(const struct termp *p, const
 	double		 r;
 
 	/*
-	 * Approximate based on character width.  These are generated
-	 * entirely by eyeballing the screen, but appear to be correct.
+	 * Approximate based on character width.
+	 * None of these will be actually correct given that an inch on
+	 * the screen depends on character size, terminal, etc., etc.
 	 */
-
 	switch (su->unit) {
+	case SCALE_BU:
+		r = su->scale * 10.0 / 240.0;
+		break;
 	case SCALE_CM:
-		r = su->scale * 4.0;
+		r = su->scale * 10.0 / 2.54;
+		break;
+	case SCALE_FS:
+		r = su->scale * 2750.0;
 		break;
 	case SCALE_IN:
 		r = su->scale * 10.0;
 		break;
+	case SCALE_MM:
+		r = su->scale / 100.0;
+		break;
 	case SCALE_PC:
-		r = (su->scale * 10.0) / 6.0;
+		r = su->scale * 10.0 / 6.0;
 		break;
 	case SCALE_PT:
-		r = (su->scale * 10.0) / 72.0;
-		break;
-	case SCALE_MM:
-		r = su->scale / 1000.0;
+		r = su->scale * 10.0 / 72.0;
 		break;
 	case SCALE_VS:
 		r = su->scale * 2.0 - 1.0;
 		break;
-	default:
+	case SCALE_EN:
+	case SCALE_EM:
 		r = su->scale;
+		break;
+	case SCALE_MAX:
+		abort();
 		break;
 	}
 
Index: term_ps.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ps.c,v
retrieving revision 1.63
diff -u -p -r1.63 term_ps.c
--- term_ps.c	10 Aug 2014 23:54:41 -0000	1.63
+++ term_ps.c	12 Aug 2014 01:02:17 -0000
@@ -1117,28 +1117,32 @@ ps_hspan(const struct termp *p, const st
 	 */
 
 	switch (su->unit) {
-	case SCALE_CM:
-		r = PNT2AFM(p, su->scale * 28.34);
-		break;
-	case SCALE_IN:
-		r = PNT2AFM(p, su->scale * 72.0);
+	case SCALE_BU:
+		r = PNT2AFM(p, su->scale * 6.0 / 240.0);
 		break;
-	case SCALE_PC:
-		r = PNT2AFM(p, su->scale * 12.0);
-		break;
-	case SCALE_PT:
-		r = PNT2AFM(p, su->scale * 100.0);
+	case SCALE_CM:
+		r = PNT2AFM(p, su->scale * 72.0 / 2.54);
 		break;
 	case SCALE_EM:
 		r = su->scale *
 		    fonts[(int)TERMFONT_NONE].gly[109 - 32].wx;
 		break;
-	case SCALE_MM:
-		r = PNT2AFM(p, su->scale * 2.834);
-		break;
 	case SCALE_EN:
 		r = su->scale *
 		    fonts[(int)TERMFONT_NONE].gly[110 - 32].wx;
+		break;
+	case SCALE_IN:
+		r = PNT2AFM(p, su->scale * 72.0);
+		break;
+	case SCALE_MM:
+		r = su->scale *
+		    fonts[(int)TERMFONT_NONE].gly[109 - 32].wx / 100.0;
+		break;
+	case SCALE_PC:
+		r = PNT2AFM(p, su->scale * 12.0);
+		break;
+	case SCALE_PT:
+		r = PNT2AFM(p, su->scale * 1.0);
 		break;
 	case SCALE_VS:
 		r = su->scale * p->ps->lineheight;

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: \w'blah'u issues (really: 'u' scaling width)
  2014-08-12  1:04   ` Kristaps Dzonsons
@ 2014-08-12  2:43     ` Ingo Schwarze
  0 siblings, 0 replies; 4+ messages in thread
From: Ingo Schwarze @ 2014-08-12  2:43 UTC (permalink / raw)
  To: Kristaps Dzonsons; +Cc: tech

Hi Kristaps,

Kristaps Dzonsons wrote on Tue, Aug 12, 2014 at 03:04:12AM +0200:

> Enclosed are the horizontal adjustments as per your suggestions.
> (NOT the vertical ones yet.)  To test this, I simply ran mandoc and
> groff side-by-side with both -Tascii and -Tps with each test unit
> having a resulting non-zero length.  They're more-or-less similar,
> but if we want to be precisely the same, there's more work to be
> done.

That is ok schwarze@ with the exception of two numbers,
see below inline.

If you agree with the two modifications, please commit to HEAD,
and i'll merge to VERSION_1_12 and OpenBSD.

Yours,
  Ingo


> Index: html.c
> ===================================================================
> RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/html.c,v
> retrieving revision 1.160
> diff -u -p -r1.160 html.c
> --- html.c	10 Aug 2014 23:54:41 -0000	1.160
> +++ html.c	12 Aug 2014 01:02:16 -0000
> @@ -759,6 +759,8 @@ bufcat_su(struct html *h, const char *p,
>  	v = su->scale;
>  	if (SCALE_MM == su->unit && 0.0 == (v /= 100.0))
>  		v = 1.0;
> +	else if (SCALE_BU == su->unit)
> +		v /= 24.0;
>  
>  	bufcat_fmt(h, "%s: %.2f%s;", p, v, roffscales[su->unit]);
>  }
> Index: term_ascii.c
> ===================================================================
> RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ascii.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 term_ascii.c
> --- term_ascii.c	10 Aug 2014 23:54:41 -0000	1.28
> +++ term_ascii.c	12 Aug 2014 01:02:16 -0000
> @@ -230,31 +230,41 @@ ascii_hspan(const struct termp *p, const
>  	double		 r;
>  
>  	/*
> -	 * Approximate based on character width.  These are generated
> -	 * entirely by eyeballing the screen, but appear to be correct.
> +	 * Approximate based on character width.
> +	 * None of these will be actually correct given that an inch on
> +	 * the screen depends on character size, terminal, etc., etc.
>  	 */
> -
>  	switch (su->unit) {
> +	case SCALE_BU:
> +		r = su->scale * 10.0 / 240.0;
> +		break;
>  	case SCALE_CM:
> -		r = su->scale * 4.0;
> +		r = su->scale * 10.0 / 2.54;
> +		break;
> +	case SCALE_FS:
> +		r = su->scale * 2750.0;

Here the correct value is

		r = su->scale * 65536.0 * 10.0 / 240.0;

That's 2730.666..., not 2750.0.

>  		break;
>  	case SCALE_IN:
>  		r = su->scale * 10.0;
>  		break;
> +	case SCALE_MM:
> +		r = su->scale / 100.0;
> +		break;
>  	case SCALE_PC:
> -		r = (su->scale * 10.0) / 6.0;
> +		r = su->scale * 10.0 / 6.0;
>  		break;
>  	case SCALE_PT:
> -		r = (su->scale * 10.0) / 72.0;
> -		break;
> -	case SCALE_MM:
> -		r = su->scale / 1000.0;
> +		r = su->scale * 10.0 / 72.0;
>  		break;
>  	case SCALE_VS:
>  		r = su->scale * 2.0 - 1.0;
>  		break;
> -	default:
> +	case SCALE_EN:
> +	case SCALE_EM:
>  		r = su->scale;
> +		break;
> +	case SCALE_MAX:
> +		abort();
>  		break;
>  	}
>  
> Index: term_ps.c
> ===================================================================
> RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term_ps.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 term_ps.c
> --- term_ps.c	10 Aug 2014 23:54:41 -0000	1.63
> +++ term_ps.c	12 Aug 2014 01:02:17 -0000
> @@ -1117,28 +1117,32 @@ ps_hspan(const struct termp *p, const st
>  	 */
>  
>  	switch (su->unit) {
> -	case SCALE_CM:
> -		r = PNT2AFM(p, su->scale * 28.34);
> -		break;
> -	case SCALE_IN:
> -		r = PNT2AFM(p, su->scale * 72.0);
> +	case SCALE_BU:
> +		r = PNT2AFM(p, su->scale * 6.0 / 240.0);

Well, here we are in a fix.

Were are converting from basic units to points.
So the correct thing to do would be / 72000.0 to go to inches
then * 72.0 to go to points, that is, / 1000.0 all told.

However, that only makes sense for documents explicitly
specifying widths in basic units and targetting PostScript/PDF
output only - explicit width specifications in basic units
are inherently non-potarble across devices: 1000u is half
across the page on the terminal (about 40n) while it is
almost nothing in PostScript (1 point, see above).

So we can safely assume few people will do that, and certainly
not in manual pages.  So where can basic units come from, if
not from explicit specifications?  The only thing i see is \w.
But, as we discussed, what \w expands to is by necessessity *wrong*
for PostScript output.

Or let's put it the other way round.  No matter what device
we are formatting for, we should always assume that basic units
are *terminal* basic units because that's what \w delivers.

So, the right thing to do here is:
Go from *terminal* basic units to inches: / 240.0
Go from inches to points: * 72.0   (not 6.0)
Hence:

		r = PNT2AFM(p, su->scale * 72.0 / 240.0);

>  		break;
> -	case SCALE_PC:
> -		r = PNT2AFM(p, su->scale * 12.0);
> -		break;
> -	case SCALE_PT:
> -		r = PNT2AFM(p, su->scale * 100.0);
> +	case SCALE_CM:
> +		r = PNT2AFM(p, su->scale * 72.0 / 2.54);
>  		break;
>  	case SCALE_EM:
>  		r = su->scale *
>  		    fonts[(int)TERMFONT_NONE].gly[109 - 32].wx;
>  		break;
> -	case SCALE_MM:
> -		r = PNT2AFM(p, su->scale * 2.834);
> -		break;
>  	case SCALE_EN:
>  		r = su->scale *
>  		    fonts[(int)TERMFONT_NONE].gly[110 - 32].wx;
> +		break;
> +	case SCALE_IN:
> +		r = PNT2AFM(p, su->scale * 72.0);
> +		break;
> +	case SCALE_MM:
> +		r = su->scale *
> +		    fonts[(int)TERMFONT_NONE].gly[109 - 32].wx / 100.0;
> +		break;
> +	case SCALE_PC:
> +		r = PNT2AFM(p, su->scale * 12.0);
> +		break;
> +	case SCALE_PT:
> +		r = PNT2AFM(p, su->scale * 1.0);
>  		break;
>  	case SCALE_VS:
>  		r = su->scale * p->ps->lineheight;
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-08-12  2:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-09 17:01 \w'blah'u issues (really: 'u' scaling width) Kristaps Dzonsons
2014-08-09 20:41 ` Ingo Schwarze
2014-08-12  1:04   ` Kristaps Dzonsons
2014-08-12  2:43     ` Ingo Schwarze

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).