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

[joerg van den hoff]

On 02.11.22 23:45, Deri wrote:
> 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.

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
   _
√

i.e. large gap between sqrt and the extensionbar. is this to be expected?

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

it does for Garamond but at the same time deteriorates/corrupts output from 
fonts
not having the radicalex glyph to start with...

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

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):

there are immediately visible problems with DejavuSansMono and PTSans. but if you pixel-peep at 
1600% or so you can see that actually only Palatino, Optima and PTSerif look "perfect". Garamond
has a small "kink" between sqrt and start of radicalex which is not there in the Palatino 
"reference" rendering.

so in this sample 3 fonts "good", 3 fonts "bad".

what could cause this discrepant rendering, presuming that in this setup in each case the Symbol 
font glyphs are used?

the minimal example, it seems is a source file (with adjusted font name, of 
course: DMR is my
private choice for "DejavuSansMono-italic") like

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


this renders the sqrt plus extension bar in general differently depending on the selected font 
although the resulting pdf only uses the Sybmols font (for the conisdered case where font does
not contain either sqrt or sqrtex/radicalex).

question: how can the font switch effect the (relative) positioning of the two 
subsequent glyphs
from the Symbols font?

thx,
joerg

> 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

sqrt2.pdf
Description: Adobe PDF document