From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout-webserver.scc.kit.edu (mailout-webmail.scc.kit.edu [129.13.185.232]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id s7C2iVXe000840 for ; Mon, 11 Aug 2014 22:44:31 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1XH24a-000780-Em; Tue, 12 Aug 2014 04:44:28 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1XH24a-0005WT-Ck; Tue, 12 Aug 2014 04:44:28 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1XH24Z-0003vN-83; Tue, 12 Aug 2014 04:44:27 +0200 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1XH23o-0001jv-LT; Tue, 12 Aug 2014 04:43:40 +0200 Date: Tue, 12 Aug 2014 04:43:40 +0200 From: Ingo Schwarze To: Kristaps Dzonsons Cc: tech@mdocml.bsd.lv Subject: Re: \w'blah'u issues (really: 'u' scaling width) Message-ID: <20140812024340.GA8674@iris.usta.de> References: <53E653F4.2030402@bsd.lv> <20140809204126.GG30999@iris.usta.de> <53E9680C.9050702@bsd.lv> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E9680C.9050702@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) 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