[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: joerg van den hoff
Subject: Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)
Date: Fri, 4 Nov 2022 11:19:12 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1

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


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


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:

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

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

why is the `sr' entry in the font description just '\sr "', what does that

See explanation above.

yes, thanks a lot.

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

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

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:




(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?





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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]