[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
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'?
2.
why is the `sr' entry in the font description just '\sr "', what does that mean?
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)?
thx,
joerg
- \[sqrtex] woes (related to bugs bug #62923 and #63179), joerg van den hoff, 2022/11/02
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), Deri, 2022/11/02
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), joerg van den hoff, 2022/11/02
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), Deri, 2022/11/02
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), joerg van den hoff, 2022/11/03
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), Deri, 2022/11/03
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), joerg van den hoff, 2022/11/03
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179),
joerg van den hoff <=
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), Deri, 2022/11/03
- Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), joerg van den hoff, 2022/11/04
Re: \[sqrtex] woes (related to bugs bug #62923 and #63179), joerg van den hoff, 2022/11/02