[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: Thu, 3 Nov 2022 21:47:33 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1

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

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

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


reply via email to

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