Re: \w'blah'u issues (really: 'u' scaling width)

[Ingo Schwarze <schwarze@usta.de>]

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