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

[joerg van den hoff]

as a follow up to last mail:

I have now patched all my font definition files, converting all sqrt and radicalex glyph definitions 
to comments (i..e. prepending #).

this makes square root and extension bar perfectly aligned for _most_ fonts but surprisingly still 
not for all:, e.g. for DejavuSansMono there still is a slight horizontal misalignment (extension bar 
starting a bit early thus protruding slightly to left, overlapping the sqrt glyph) while
for PTSans the bar starts a bit late, leaving a small gap to preceding sqrt 
glyph.

this also happens outside of eqn context, i.e when explicitly inserting

\[sqrt]\[sqrtex]

in the text.

again, I do not get the reason: I would have thought that by enforcing usage of sqrt and radicalex 
from symbol font (by removing those from the used font's font definition file) should produce
identical output of `\[sqrt]\[sqrtex]' irrespective of selected font?

thx,
joerg

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?
>
> Cheers
>
> Deri