[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 14:32:46 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1

On 02.11.22 23:45, Deri wrote:
On Wednesday, 2 November 2022 18:19:37 GMT joerg van den hoff wrote:
I believe the reason is because the glyph for the sqrtex/radicalex which
groff delivers in the Symbol font actually overlines the following glyph,
and it is the definition in ps.tmac which "corrects" this so that it
works for eqn. Other fonts which have their own sqrtex glyph actually
overline themselves (rather than what follows), so they don't need the
same correction.

What happens if you include the command

.rchar radicalex

to remove this correction?

nothing, AFAICS: same result as before. I admit I do not (yet or
forever...?) quite understand the the whole thing. but as said, in my case
there is definitely no own (font-defined/provided) sqrtex glyph involved.
those fonts (e.g. DejavuSansMono) don't have that. so I guess they should
behave like the standard fonts and just used the groff mechanism (replace
sqrtex by radicalex and whatever adjustments are in place to make it work
with eqn). but as the example shows, there is a visible-to-massive
misalignment (mostly horizontally but also vertically), depending on font.

Command should be:-

.rchar \[radicalx]

sorry. My expectation is that any font which does not contain sqrtex/radicalex
itself which then uses the glyph from Symbol font, will have a space after the
sqrt, but if the font has its own sqrtex/radicalex (like Garamond) all will be
good. The .rchar command does not make the glyph "unknown" to groff, it
removes a pseudo definition of the glyph which has been defined by the .char
command, so it will then use the actual glyph of the same name.

ah, ok then. mission report: this (.rchar \[radicalex]) infact makes output sane
for the Garamond font (which does have it's own glyph for that). BUT: doing the 
thing for, e.g., Palatino (or any other font which does *not* have a radicalex 
messes up previously sane output: know there the root renders as

i.e. large gap between sqrt and the extensionbar. is this to be expected?

and if .rchar radicalex is supposed to make that glyph unknown to groff, I
do not understand, why my pdf does not change and groff does not complain?
it seems the sqrtex->radicalex substitution is performed irrespective of
the attempt to rm radicalex with the `.rchar' directive?

also, regarding my example pdf from last mail, to be clear: I did not use
eqn there, rather those square roots are specified as a string:

.ds longroot \\[sqrt]\\[sqrtex]\\[sqrtex]\\[sqrtex]\\[sqrtex]

and then interpolated in the examples for different fonts.

another detail I just have noted: as, said, in my example file, out of the 3
external fonts (Garamond, Optima, DejavuSansMono) none does define a sqrtex
glyph, but Garamond actually *does* have its own radicalex glyph and that
one is in fact used, it seems, as indicated by the differing line thickness
of the extension bar for that font in the example pdf. and this
font-internal radicalex seems to be defined (for Garamond, anyway) such
that it overlines the _preceding_ glyph (which happens to be the square
root glyph here...) but repetitions of the glyph do not do that but
properly extent the bar. or so it seems.

Also, in ps.tmac, \[sqrtex] is made a synonym for \[radicalex], which is why
groff is using \[radicalex] from the Garamond font. The .rchar command above
should fix the problem of the misplaced over line.

it does for Garamond but at the same time deteriorates/corrupts output from 
not having the radicalex glyph to start with...

The other fonts which define their own sqrt but not a sqrtex it would be an
accident if the glyph in the symbol font exactly matched the sqrt in the text

yes, that much at least I've understood already :).

what I do not understand is:

when consistently removing any radicalex and sqrt glyphs (none of the considered fonts as a sqrtex glyph at all, anyway) from all font definition files, should this not lead to exactly identical
behaviour regarding square root drawing with all those fonts since, I presume, 
in this case the
same machinery will be invoked as for the standard fonts (all of which do not have those glyphs at all, too)? or is there some hardcoded tweak involved that explicitly checks the font name and does
something peculiar in case it is one of the standard fonts?

in any case, doing the above (removing radicalex and sqrt glyphs from the font 
definition files
of the external fonts does not achieve exactly identical rendering. attached a q&d demo (I reiterate: all font-internal definition of sqrt and radicalex are removed from the external font definition files):

there are immediately visible problems with DejavuSansMono and PTSans. but if you pixel-peep at 1600% or so you can see that actually only Palatino, Optima and PTSerif look "perfect". Garamond has a small "kink" between sqrt and start of radicalex which is not there in the Palatino "reference" rendering.

so in this sample 3 fonts "good", 3 fonts "bad".

what could cause this discrepant rendering, presuming that in this setup in each case the Symbol font glyphs are used?

the minimal example, it seems is a source file (with adjusted font name, of 
course: DMR is my
private choice for "DejavuSansMono-italic") like


this renders the sqrt plus extension bar in general differently depending on the selected font although the resulting pdf only uses the Sybmols font (for the conisdered case where font does
not contain either sqrt or sqrtex/radicalex).

question: how can the font switch effect the (relative) positioning of the two 
subsequent glyphs
from the Symbols font?




so there seem to be several distinct (but somehow related) issues:

* the case discussed in the bug reports #62923 and #63179 where the font
defines its own sqrtex

* the case I have now observed with Garamond where the font defines its own
radicalex. and this glyph seems then to be found by the fallback
substitution sqrtex -> radicalex (rather than the radicalex from the S

* the case where the external font does not have either sqrtex or radicalex
(like the standard fonts, I understand). here, the standard fallback
substitution happens, but the extension bar is not properly aligned
relative to preceding sqrt glyph. but what I *now* see is the following
which kinda explains the last issue (maybe the others as well?):

the tested fonts (Optima, Garamond, DejavuSansMono) do _all_ define there
own sqrt glyph in all styles R, I, B, BI and the standard fonts (Times,
Palatino etc) do *not* do that, only the symbols font does.

so my tentative explanation is: the mechanism implemented by groff
explicitly assumes that both sqrt and radicalex are the glyphs defined by
the symbols font and only for those sqrt and extension bar are properly
aligned. if either sqrt or/and radicalex are found in the font, those
glyphs are used, but seemingly using metric information or other implicit
assumptions that are only valid for the symobls font. -- does that make any

a workaround seems to be to enforce usage of sqrt and radicalex from S font
and to just ignore those glyphs' definition in the font files. indeed
removing the "offending" glyphs from the font file resolves the issue (as
is to be expected :)).


Attachment: sqrt2.pdf
Description: Adobe PDF document

reply via email to

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