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

[joerg van den hoff]

On 02.11.22 17:23, Deri wrote:
> On Wednesday, 2 November 2022 13:08:45 GMT joerg van den hoff wrote:
> > as far as I have understood the discussions in those threads, the problem
> > seems to have been attributed to a naming collision (or rather the presence
> > of a sqrtex glyph in the font)?
>
> I believe the reason is because the glyph for the sqrtex/radicalex which groff
> delivers in the Symbol font actually overlines the following glyph, and it is
> the definition in ps.tmac which "corrects" this so that it works for eqn.
> Other fonts which have their own sqrtex glyph actually overline themselves
> (rather than what follows), so they don't need the same correction.
>
> What happens if you include the command
>
> .rchar radicalex
>
> to remove this correction?

nothing, AFAICS: same result as before. I admit I do not (yet or forever...?) 
quite understand the
the whole thing. but as said, in my case there is definitely no own (font-defined/provided) sqrtex 
glyph involved. those fonts (e.g. DejavuSansMono) don't have that. so I guess they should behave 
like the standard fonts and just used the groff mechanism (replace sqrtex by radicalex and whatever
adjustments are in place to make it work with eqn). but as the example shows, there is a 
visible-to-massive misalignment (mostly horizontally but also vertically), depending on font.

and if .rchar radicalex is supposed to make that glyph unknown to groff, I do 
not understand, why
my pdf does not change and groff does not complain? it seems the 
sqrtex->radicalex substitution
is performed irrespective of the attempt to rm radicalex with the `.rchar' 
directive?

also, regarding my example pdf from last mail, to be clear: I did not use eqn 
there, rather those
square roots are specified as a string:

.ds longroot \\[sqrt]\\[sqrtex]\\[sqrtex]\\[sqrtex]\\[sqrtex]

and then interpolated in the examples for different fonts.

another detail I just have noted: as, said, in my example file, out of the 3 external fonts 
(Garamond, Optima, DejavuSansMono) none does define a sqrtex glyph, but Garamond actually *does*
have its own radicalex glyph and that one is in fact used, it seems, as 
indicated by the differing
line thickness of the extension bar for that font in the example pdf. and this font-internal 
radicalex seems to be defined (for Garamond, anyway) such that it overlines the _preceding_ glyph
(which happens to be the square root glyph here...) but repetitions of the 
glyph do not do that
but properly extent the bar. or so it seems.

so there seem to be several distinct (but somehow related) issues:

* the case discussed in the bug reports #62923 and #63179 where the font 
defines its own sqrtex

* the case I have now observed with Garamond where the font defines its own 
radicalex. and this
glyph seems then to be found by the fallback substitution sqrtex -> radicalex 
(rather than the
radicalex from the S font)

* the case where the external font does not have either sqrtex or radicalex (like the standard 
fonts, I understand). here, the standard fallback substitution happens, but the extension bar
is not properly aligned relative to preceding sqrt glyph. but what I *now* see is the following 
which kinda explains the last issue (maybe the others as well?):

the tested fonts (Optima, Garamond, DejavuSansMono) do _all_ define there own 
sqrt glyph in all
styles R, I, B, BI and the standard fonts (Times, Palatino etc) do *not* do 
that, only the symbols
font does.

so my tentative explanation is: the mechanism implemented by groff explicitly 
assumes that both
sqrt and radicalex are the glyphs defined by the symbols font and only for 
those sqrt and extension
bar are properly aligned. if either sqrt or/and radicalex are found in the 
font, those glyphs
are used, but seemingly using metric information or other implicit assumptions 
that are only valid
for the symobls font. -- does that make any sense??

a workaround seems to be to enforce usage of sqrt and radicalex from S font and 
to just
ignore those glyphs' definition in the font files. indeed removing the 
"offending" glyphs from the
font file resolves the issue (as is to be expected :)).

best,
joerg

> Cheers
>
> Deri