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

[Deri]

On Thursday, 3 November 2022 20:47:33 GMT joerg van den hoff wrote:
> as a follow up to previous mail:
> 
> without understanding the full details, I know see that the DMI font
> definition (for DejavuSansMono-Oblique as the orignal font name is (rather
> than *-italic as previously claimed ;)) not only
> contains
> 
> \[sqrt]
> 
> but also a line reading verbatim:
> 
> \[sr] "
> 
> and this glyph \[sr], according to groff_char is also denoting the square
> root glyph. and I have not looked at ps.tmac and see that it contains
> 
> .char \[radicalex] \h'-\w'\[sr]'u'\[radicalex]\h'\w'\[sr]'u'
> 
> which sure is the "magic" you have alluded to previously.
> 
> but, obviously, this uses the width of the \[sr] glyph *from currently
> active font* and this seems then to explain the misalignment between sqrt
> and extension bar with DMI since so far I only had removed sqrt but not
> \[sr] as well. doing that now, the pdf output indeed looks good :).
> 
> as far as I understand, what is happening here is that with \[sr] still
> present, the ps.tmac entry uses the width of the font specific sqrt glyph
> (even if that entry has been removed, while \[sr] being kept). how this
> happens I do not understand since the `sr' entry seems empty and does not
> just duplicate the info from the `sqrt' line.
> 
> but by trial+error this, then, seems a working solution: remove all three of
> 
> \[radicalex]
> \[sqrt]
> \[sr]
> 
> from the font description file in which case consistent usage of glyphs from
> S font is ensured (even in the radicalex magic in ps.tmac). (what I
> actually did, was prepend those glyph definitions by a shell comment
> character `#': I guess this actually does achieve a renaming from `sqrt' to
> `#sqrt' as the glyph's name :), right?)
> 
> is this approximately correct?
> 
> lingering questions:
> 
> 1.
> what's up with `sqrt' vs. `sr'?
According to some new wording in the groff_char man page:-

============================================================================

In groff , you can instead use \[radicalex] to continue the radical sign
\[sr]; these special characters are intended for use with text fonts. \[sqrt] 
and \[sqrtex] are their counter-parts with mathematical spacing.

============================================================================

Hinting at different spacing depending whether it comes from a text or a 
mathematical font. All fonts I have seen which contain sqrt have a following 
line:-

sr  "

Which, in this case, the double quote has the meaning "ditto", so sr has the 
exact same spacing as sqrt. This also explains the strange spacing after you 
removed sqrt, sr would have dittoed whichever was the previous glyph! So I 
don't think there is ever any real difference.

> 2.
> why is the `sr' entry in the font description just '\sr "', what does that
> mean?

See explanation above.

> 3.
> what would be the correct (TM) solution for the whole problem? the above,
> namely enforcing that the glyphs are taken from S? if so, could this not be
> done by groff, when reading the font description (i.e. ignoring those
> glyphs, if present)?

Probably not desirable. Your pngs showed that there are different styles of 
glyph for the square root, i.e. MacOS (s2.png). The reason it can be different 
is because you have not requested ghostscript to embed the fonts within the 
pdf, so then it is to the particular viewer to select a suitable font which is 
available to it. I'm sure if you always force ghostscript to embed all fonts, 
then groff produced pdfs will always be correct on MacOS (and everywhere 
else).

A user may prefer the glyph style of sqrt in a completely different font. So 
we should not force them to always use the glyphs from Symbol font. An example 
is the font XITSMath-Regular.pfa which contains all the maths symbols and 
regular text glyphs in a matching style. There are a number of improvements 
which could be made:-

A) The .char magic in ps.tmac should only be applied to the radicalex glyph in 
the Symbol font (because it is weird), not if the glyph comes from a different 
font. I believe .fschar rather than .char may be of use here.

B) There may be problems if the current text font contains a square root glyph 
(sr or sqrt) but not a bar extension (radicalex or sqrtex) since that glyph in 
the Symbol font may not "match" the glyph in the text font. This may be 
further complicated because the font designer may intend the square root 
extender to be the combining overline glyph U+0305, so this would be better to 
use than the radicalex in the symbol font. Whether afmtodit can be amended to 
handle this I am not sure. It would be helpful if you could check if one of 
your fonts which has a sqrt glyph but no radicalex actual contains a glyph for 
U0305, and if so, does it "fit" with the sqrt.

Cheers

Deri

> thx,
> joerg