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

[joerg van den hoff]

On 04.11.22 01:00, Deri wrote:
> 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.

ok, I see. to be complete:

as said, I actually did not delete the (indeed immediately preceding) sqrt line 
but put a `#'
in front -- first ignorantly presuming it acts as comment char -- so I in fact 
just
"renamed" glyph `sqrt' to `#sqrt'. and sr thus ittoed to the glyph `#sqrt' 
which in turn
is the font specific sqrt. that in fact was the observed behaviour regarding 
the positioning
of the radicalex: still using metric of font specific sqrt :).

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

yes, thanks a lot.

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

no, I do not think that's the issue here, at least not for the most part. for one, all the used 
external fonts I had converted from fonts available on the Mac, so the system's viewer should simply 
find the exact same font if looking for it. more important, I checked with `pdffonts' and according 
to its report, *all* text fonts (even Palatino) _were_ embedded in the example pdfs so the 
font-specific glyphs are available in the pdf anyway. only Symbol (S) is not embedded. but the 
examples you refer to where using the font specific glyphs, (except in the palatino case).

so there quite probably _is_ an issue with the quartz pdf engine (all other pdf viewers (those not 
using the quartz pdf renderer) agree on how to render the document) but that's totally not a groff 
problem :).

> 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

yes, that's obviously true. it would be most welcome if groff could validly use
font-specific sqrt. but it currently is not able to validly do that as all the 
misalignment
issues demonstrate.

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

of all the additional fonts I have so far considered with groff, _all_ do have
sqrt but only a single one (Garamond) does have its own radicalex as well. so 
the common case
(if my font sample is representative ;)) seems sqrt: yes, radicalex: no.

but for Garamond the `rchar' intervention you proposed indeed fixed the issue 
so maybe
the above (which seems to boil down to the same thing) would help elsewhere, 
too.

> 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

see above: I think that is the regular situation.

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

dejavu does have the overline glyph but unfortunately: no, it does not fit. 
this input:

.nf
\s36\f[DMI]\[#sqrt]\[sqrtex]

\s36\f[DMI]\[#sqrt]\[u0305]

\s36\f[DMI]\[sqrt]\[sqrtex]

(where, remember, \[#sqrt], is the actual sqrt from the font due to my edits of the DMI file) does 
produce the result in attached screenshot.

first line: sqrt glyph from font, radicalex (via sqrtex) from S since not 
available in font

second line:  sqrt glyph and overline glyph from font: both, position and width are not matching the 
sqrt

third line: sqrt and radicalex from S (since DMI edited etc.)


so this (overline replacing radicalex) seems not to be generally useful.


bottom line: I do of course agree with you that it principally is desirable to use all glyphs 
available in the used font if possible and not to silently replace some of them. but as far as
I understand the situation there is no easy way to achieve a clean display of 
sqrt plus sqrtex
in a "font-agnostic" way for all possible cases?

it would of course help if a fix could be found so that at least the case "font contains both sqrt 
and radicalex" could be made to work.

but the seemingly much more frequent case "font only contains sqrt but no matching extension glyph 
(radicalex)" should also be somehow addressed. and in my view it then is of course preferable if
groff just bypasses the sqrt glyph and falls back to S rather than ending up with a broken 
misaligned rendering, no?

last observation: as far as the standard fonts are concerned, groff always uses S for sqrt and 
radicalex, simply because both are missing from the standard fonts anyway. so, despite the fact
that there are rather massive typographical differences between those fonts, 
square roots are always
typeset identically -- actually without doing any harm aesthetically in my 
view. so the case could
be made for doing the same thing even for external fonts: this would be an easy 
fix and would lead
to "square roots are always typeset (correctly) in the same way".  compared to 
the present situation
I would consider this an advantage :).

OTOH: if a real solution could be found (working for all fonts using the available font-specific 
glyphs) that would be nicer. but this would seemingly imply that the font does have _both_ of sqrt
and a matching radicalex or overline or similar, that groff would be able to 
identify the matching
glyph pairs (which might be font specific and thus opening a can of worms?) and to patch them 
together correctly.

naively I would have presumed that if a font does have a sqrt it must have a provision/glyph to 
extent those sqrt glyphs but seemingly that is not really the case. I really wonder how this (sqrt 
extension) is _supposed_ to be done, canonically, for fonts providing sqrt but no (it seems) obvious
candidate for the extension bar?

best,
joerg

> Cheers
>
> Deri
>
> > thx,
> > joerg

Screen Shot 2022-11-04 at 10.39.19.png
Description: PNG image