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

[joerg van den hoff]

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 
fault...)

>   
> > > The other fonts which define their own sqrt but not a sqrtex it would be
> > > an
> > > 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, 
yes.

> 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 
grops)
produced from this input:

.\"--------------------
.nf
\s36\f[DMI]\[sqrt]\[sqrtex]
\s36\f[PI]\[sqrt]\[sqrtex]
.\"--------------------

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 
preceded
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
p1
x font 11 S
f11
s36000
V12000
H72000
md
DFd
Csqrt
H70092
Cradicalex
h39672
n12000 0
V24000
H72000
Csqrt
Cradicalex
h37764
n12000 0
x trailer
V792000
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.

best,
joerg

> Cheers
>
> Deri

sqrt2.pdf
Description: Adobe PDF document

s2.png
Description: PNG image

s1.png
Description: PNG image

s3.png
Description: PNG image