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/