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

[Deri]

On Wednesday, 2 November 2022 18:19:37 GMT joerg van den hoff wrote:
> > 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.

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.

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

Also, in ps.tmac, \[sqrtex] is made a synonym for \[radicalex], which is why 
groff is using \[radicalex] from the Garamond font. The .rchar command above 
should fix the problem of the misplaced over line.

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.

Cheers 

Deri


> 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