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

[Deri]

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

> 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 
groff, please can you do the same as your original sqrt.pdf (without the 
.rchar) using your patched fonts with sqrt removed.

Cheers 

Deri