[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)

From: joerg van den hoff
Subject: Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)
Date: Thu, 3 Nov 2022 19:42:17 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1

On 03.11.22 18:08, Deri wrote:
On Thursday, 3 November 2022 13:32:46 GMT joerg van den hoff wrote:
Command should be:-

.rchar \[radicalx]

sorry. My expectation is that any font which does not contain
sqrtex/radicalex itself which then uses the glyph from Symbol font, will
have a space after the sqrt, but if the font has its own sqrtex/radicalex
(like Garamond) all will be good. The .rchar command does not make the
glyph "unknown" to groff, it removes a pseudo definition of the glyph
which has been defined by the .char command, so it will then use the
actual glyph of the same name.

ah, ok then. mission report: this (.rchar \[radicalex]) infact makes output
sane for the Garamond font (which does have it's own glyph for that). BUT:
doing the same thing for, e.g., Palatino (or any other font which does
*not* have a radicalex glyph) messes up previously sane output: know there
the root renders as

Brilliant, exactly what I predicted above, good for Garamond (which has its
own radicalex), terrible for any other font which uses the glyph from Symbol.
The reason, as I have explained in https://savannah.gnu.org/bugs/?62923 is
because the radicalex in the symbol font is weird, see also https://
savannah.gnu.org/bugs/?63179. So the fix in ps.tmac which you .rchared should
only really be applied if the glyph is being sourced from the S font.

i.e. large gap between sqrt and the extensionbar. is this to be expected?


it does for Garamond but at the same time deteriorates/corrupts output from
fonts not having the radicalex glyph to start with...

Again, as predicted.

yes, you are right :). (and I actually overlooked that part of your mail. my 

The other fonts which define their own sqrt but not a sqrtex it would be
accident if the glyph in the symbol font exactly matched the sqrt in the
text font.

yes, that much at least I've understood already :).

Good, so you have found the answer. If the sqrt comes from the text font and
sqrtex comes from Symbol the glyphs are not designed to work together.

my question would be: what should groff do in such cases? naively, I would say
it would be better if groff would unconditionally use sqrt and radicalex from
the S font (even if one or both are provided by the used external font) to
circumvent this issue and to produce sane looking square roots all the time.
is this a bad idea?

what I do not understand is:

when consistently removing any radicalex and sqrt glyphs (none of the
considered fonts as a sqrtex glyph at all, anyway) from all font definition
files, should this not lead to exactly identical behaviour regarding square
root drawing with all those fonts since, I presume, in this case the same
machinery will be invoked as for the standard fonts (all of which do not
have those glyphs at all, too)? or is there some hardcoded tweak involved
that explicitly checks the font name and does something peculiar in case it
is one of the standard fonts?

in any case, doing the above (removing radicalex and sqrt glyphs from the
font definition files of the external fonts does not achieve exactly
identical rendering. attached a q&d demo (I reiterate: all font-internal
definition of sqrt and radicalex are removed from the external font
definition files):

I'm afraid the sqrt2.pdf is not helpful because it has not been produced by

but faithfully pasted together from that ;). it was just intended as a visual
head-to-head comparison between those example fonts. but otherwise not helpful, 

groff, please can you do the same as your original sqrt.pdf (without the
.rchar) using your patched fonts with sqrt removed.

to simplify(?) things, and pars pro toto, I've attached the pdf (always via 
produced from this input:


where DMI is my "private" font description for DejavuSansMono (edited to remove the sqrt glyph (no radicalex anyway)). maybe this "squeezed"
display facilitates the direct comparison of both square roots (the top one 
by font switch to DMI, the bottom one by font switch to PI (palatino italics).

with my "ghostscript" viewers under X11 (gv and mupdf) it displays like
in attached s1.png.

viewing the same pdf with the MacOS default viewer ("Preview") renders it like 
in s2.png.

as said, it seems a known issue that the MacOS quartz pdf engine has some 
quirks/bugs and
never has displayed groff-derived pdf output completely properly (especially equations, large brackest etc.). in the present case it is somewhat remarkable, that the misalignment between sqrt and radicalex is not visible here. but nevertheless the width of both extensionbars is obviously different. so there still *is* a discrepancy. NB: comparing s2.png to s1.png, one also can see that the sqrt is rendered rather differently per se: the slant of the upslope part is different in both cases.

in any case, s2.png is only attached to emphasize that under MacOS this different issue (pdf engine broken in that it interprets groff-produced pdf not quite right) might cause confusion. OTOH, acrobat viewer renders it (see. s3.png) identical to mupdf/gv. so this should be the "true" result.

for completeness, the dit output for the above troff input is:
x T ps
x res 72000 1 1
x init
x font 11 S
n12000 0
n12000 0
x trailer
x stop

which also seems to proof that the pdf output in fact only uses the S font. and although I am not that fluent in "reading dit" it also seems that the `H' and `h' commands indeed cause different position and length of the radicalex, no? question being: why?

it really mystifies me, why those "mute" font switches (PI and DMI never used for any glyphs in the document source) have an adverse influence on the formatting of the sqrt+radicalex (at least in the DMI case). why does this happen (and how to prevent it happen in the first place...)?

if you want/need more information, just let me know.




Attachment: sqrt2.pdf
Description: Adobe PDF document

Attachment: s2.png
Description: PNG image

Attachment: s1.png
Description: PNG image

Attachment: s3.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]