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
