Re: [Groff] eqn: sqrt problems

[Deri James]

On Wednesday 07 Sep 2011 15:19:49 Denis M. Wilson wrote:
> 
> Deri,
> 
> Am I right in thinking your font U-TI is the URW Nimbus Roman No9 L
> Regular Italic?  If so then its sqrt matches that from the Symbol font
> S (if also URW), so a redefinition of sqrt is not necessary.

Denis,

Yes, I was using that font, but what I was checking was the "-Z" output from 
groff, so I could see which fonts groff was telling the backend driver to use. 
Without .char I saw:-

x font 41 U-HBI
f41
s11000
H73200
v16327
Csqrt
x font 11 S
f11
Cradicalex
h520
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
f41
s10000
H79162
V38397
tax

where you can see the sqrt and radicalex being specified in different fonts. 
And 
with .char I saw:-

x font 11 S
f11
s11000
H73200
v16327
Csqrt
h77
Cradicalex
h520
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
h5500
Cradicalex
x font 41 U-HBI
f41
s10000
H79239
V26386
tax

where both characters are selected from the same font (S).

NB I've switched to using U-HBI whose sqrt does not match the radicalex in the 
symbol font.

> Different families from the URW set and others, however, show various
> degrees of misalignment.  Using your clever trick. which I would modify
> to
> 
>     .char \[sqrt] \f[S]\[sqrt]\f[]
> 
> the misalignment was *reduced* but not removed.  If I added
> 
>     .char \[sr] \f[S]\[sr]\f[]
> 
> Then everything comes out perfectly, which is very mysterious, as gnu
> eqn does *not* use \[sr].  But it also comes out correctly to use
> 
>     .char \[sqrt] \f[S]\[sr]\f[]
>

In the fonts I have, glyph sr is just a synonym for sqrt.

One slight complication when testing this output is that if you are viewing 
the output using something which uses ghostscript to convert to PDF before 
viewing, then ghostscript, by default, does not embed all fonts (you can force 
it to) so the viewing application has to "guess" which system font to use (not 
always correctly). 

A bonus in investigating this is it prompted me to fix gropdf to correctly 
handle glyphs above 255, so it now handles sqrt from eqn using the full URW 
fonts.

> I've come round to thinking this is a weakness in eqn, and that my
> solution (c) may be the proper one, as there may be other maths symbols
> in some text fonts that are also in Symbol, causing unexpected errors
> (proof needed).

The problem only occurs if two glyphs are meant to be matched (like radical 
and radicalex) and the loaded font only contains one of the pair. Placing two 
.char definitions for these 2 characters in file eqnrc should force groff to 
always use the symbol font for this pair of characters. 

> Denis

Deri