[bug #62923] [gropdf] glyph aliases in in font description files not parsed correctly

[G. Branden Robinson]

Follow-up Comment #12, bug #62923 (project groff):

[comment #10 comment #10:]
> eqn has a hardcoded name for the bar glyph of radicalex.

This turns out not to be true.  GNU eqn _always_ puts out the special
characters \[sqrt] and \[sqrtex] (which are "special" even among special
characters, i.e., they are intended for non-text fonts), and has no provision
for writing out the text glyphs \[sr] and \[radicalex].

https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/sqrt.cpp#n42

So where in blazes do those "Cradicalex" commands come from in the "grout"
output, then?

_ps.tmac_ has done us a...favor.
 

.char \[radicalex] \h'-\w'\[sr]'u'\[radicalex]\h'\w'\[sr]'u'
.fchar \[sqrtex] \[radicalex]


https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/ps.tmac#n34

On the *ps* device, \[radicalex] is _unconditionally_ rewritten at formatting
time to move left by the width of the text glyph \[sr], written, and then move
right by the same amount.  (Because "radicalex" is a special character, it is
always written out using the 'C' output command, which does not imply motion
by the width of the written glyph.  That is, an uninterrupted series of C
commands will overstrike at the same position.)

(You will also observe that the re-definition appears to be circular.  The
groff Texinfo manual documents a "special anti-recursion feature" of the
`char` family of requests that prevents this.)

Since this redefinition of \[radicalex] seems to work all right, I have no
complaint about it _per se_.  I do wonder if it shouldn't be _eqn_'s job to do
this, though...

But the PostScript font descriptions we supply with _groff_ don't actually
define any glyphs for "sqrtex".  They aren't even aliased to "radicalex" in
the font description files.

That means that as far as the formatter is concerned, when these fonts are
mounted (and only these, not any third-party fonts installed by the user), the
"sqrtex" special character _never_ exists in any font; '.if c \[sqrtex]' would
always fail.  So the `fchar` line we see above, defining a "fallback"
character, is always interpreted.

That, I believe, is why the "C radicalex" command stubbornly appears in GNU
troff output.

I haven't installed XITS Math myself yet, but I'll work on that.  In the
meantime I tried the following patch.


diff --git a/font/devps/S b/font/devps/S
index ae8b3a902..ed2cf3a8c 100644
--- a/font/devps/S
+++ b/font/devps/S
@@ -90,6 +90,7 @@ rB    "
 pp     658,674 3       94      perpendicular
 _      500,0,125,2,2   3       95      underscore
 radicalex      500,917,0,590   3       96      radicalex
+sqrtex "
 *a     631,500,18      3       97      alpha
 *b     549,741,223     3       98      beta
 *x     549,499,231     3       99      chi
diff --git a/tmac/ps.tmac b/tmac/ps.tmac
index 8b796e376..dbb251683 100644
--- a/tmac/ps.tmac
+++ b/tmac/ps.tmac
@@ -32,7 +32,7 @@
 .fchar \[u2011] -
 .
 .char \[radicalex] \h'-\w'\[sr]'u'\[radicalex]\h'\w'\[sr]'u'
-.fchar \[sqrtex] \[radicalex]
+.char \[sqrtex] \h'-\w'\[sqrt]'u'\[sqrtex]\h'\w'\[sqrt]'u'
 .char \[mo] \h'.08m'\[mo]\h'-.08m'
 .char \[nm] \h'.08m'\[nm]\h'-.08m'
 .char \[parenlefttp] \[parenlefttp]\h'.016m'


You can see there is a potentially important distinction here, not between
"radicalex" and "sqrtex", but in the horizontal motions that bracket them. 
"sr" is a "text" special character, meaning it's normally drawn from a text
font.[1]  "sqrt" is a "special" special character, meaning that it is drawn
from a font that is expected to lack text glyphs (i.e., to lack glyphs that
vary in the four traditional styles of roman, italic, bold, and bold-italic). 
So we can imagine that glyph registration might be off if the XITS Math font's
"sqrtex" is used with the _groff_ PostScript Symbol font's "sqrt".

The foregoing changes made the (GNU troff) output less surprising, without
PostScript output looking worse.  Here is my test file.


$ cat EXPERIMENTS/sqrtex.roff 
.sp
.EQ
sqrt x
.EN
.sp 4v
.EQ
gsize 48
sqrt x
.EN
.sp
.EQ
gsize 8
sqrt x
.EN


> the XITSMR font has a glyph sqrtex

My hypothesis is therefore as above: glyph registration is incorrect because
"sqrtex" is being used with the spacing of _groff_ PostScript Symbol font's
"sr" instead of the XITS Math font's "sqrt".

At this point I think what I need to do is look more closely at the
particulars of XITS Math.

> I have done my analysis of the problem and confirmed that it affects grops
as well as gropdf with identical (wrong) output. Since this has nothing to do
with a bug in gropdf, I have removed myself from the assignation.
> 
> Hopefully you can check the analysis I have already done and do your own
analysis.

Okay.  The product of that analysis so far is given above.

[1] Nevertheless, in groff's PostScript font descriptions, "sqrt" appears only
in the "special font", "S" (with "sr" aliased to it).  I believe it is Werner
Lemberg who created the distinction between "text" radicals and extensions
(\[sr], \[radicalex]) and "math" radicals and extensions (\[sqrt], \[sqrtex]),
about 20 years ago.  The reasons are not entirely clear to me, though if
somebody is making fonts with bold, italic, and bold-italic radical signs
grouped with their basic Latin alphabetical neighbors, their proper semantics
in _groff_ are indeed "text".


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62923>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/