On Thursday, 12 February 2026 01:17:49 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2026-02-11T22:17:54+0000, Deri via GNU roff typesetting system discussion > wrote: > > I believe the problem might be because the 'sqrt' and 'radicalex' are > > not both coming fro the regular Symbol font, one or both are coming > > from different fonts. > > Yes, when I saw the wrongly overhanging radical extension, I thought > something like that might be going on. Thanks for confirming. > > > eqn expects both of the to come from the S font. > > I _think_ it might be more precise to say that eqn expects the radical > extension character to _not_ have the "weird as hell" placement relative > to the glyph bounding box that the PostScript and PDF standards expect. > > https://savannah.gnu.org/bugs/?63179 > I think the "weird" radicalex in S works because it has an equally weird entry in the groff font:-
radicalex 500,913,0,590 3 96 radicalex -- F8E5 That's a left italic correction larger than the given width of the glyph! The attached png illustrates the difference between the symbol font and another symbol font (Symbola) which shows the (equivalent) overline lying exactly within the glyph bounding box. Using symbola rather than symbol is possible, but you need these commands:- .char \[radicalex] \[rn] .char \[u203E] \[u203E] .special Symbola The attached pdf illustrates using CommicNeue with Symbola. Eqn has handled the combination just fine, although the square root and the extender are a bit heavy compared to ComicNeue. [derij@pip build]$ pdffonts eqn.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- CBOURJ+Symbola Type 1 Custom yes yes no 8 0 ADVOXW+ComicNeue-Bold Type 1 Custom yes yes no 12 0 ENOSDN+ComicNeue-Italic Type 1 Custom yes yes no 16 0 MPGYJN+ComicNeue-Regular Type 1 Custom yes yes no 20 0 > > It may be improved if you include '.special S' before the equation, > > this means that symbols (including sqrt and radicalex) be sourced from > > S (if available) otherwise from your STIX font. > > > > If STIX has the Overline glyph U+203E in the font it may work with:- > > > > .char \[radicalex] \[u203E] > > > > (CombiningOverline U+0305 will not work). > > At the same time I don't know that all fonts available for PostScript > and PDF scrupulously adhere to the aforementioned "weird as hell" > glyph-specific semantics. They don't need to. See above. The trick is that the sqrt and rn (overline) must both exist in the same (symbol type) font. several text fonts I have looked at include a sqrt glyph but not a matching overline (or vice versa), so it can be difficult to force groff to use matching glyphs from one font. > If that's true, then it's not going to be possible to program our way > around this problem in eqn,[1] because a conditional check for the 'ps' > and 'pdf' devices wouldn't be enough to decide the question, and even > the 'S' itself is, in principle, user-replaceable. (A groff font > description file for it would likely have to be regenerated, but that's > what we offer afmtodit(1) for.) > > Are the above half-informed conjectures consistent with your > understanding? Not quite. Symbola IS a replacement for our Symbol, and works with eqn if you can make groff use its glyphs even if the text font includes one of the glyphs. Something like:- .char \[radicalex] \[rn] .char \[sqrt] \f[Symbola]\[sqrt] .char \[rn] \f[Symbola]\[rn] Will force the Symbola glyphs to be used even if the text font includes one of the glyphs. > If so, maybe I can add a "caveat" to the eqn(1) man page about it. I > don't mind having another platform from which to point out, and complain > about, PS/PDF's lunatic radical extension. Radicalex is a URW bonkerism, its not even in Unicode so URW shoved it in the Private Use Area block, within Unicode it is U+203E OVERLINE. Not much to do with PS/PDF, they just use the fonts. > Regards, > Branden > > [1] That's probably an overstatement. We _could_ try harder to kludge > around the problem with dirty hacks, like having GNU eqn generate > *roff that formats a radical extension into a throwaway diversion > and then checks the `dl` or `.w` registers to see how wide the > result was, and if it's "too wide" according to some heuristic > (wider than 1n or 1m?), decides that it's of the "weird" kind and > sets a flag enabling some kind of compensating offset when the > equation is formatted. > > To me, this idea promises to be complex to implement, fragile in > implementation, and frustrating to users if the heuristic proves to > be imprecise, because it would constitute fiddling with the output > in a way that is deep, relatively hard to audit, and likely > extremely hard to find if you don't already know to look for it, > which almost no one who hasn't read this email would think to do. > > What I had in mind for Savannah #63179 was another approach > entirely, which is to not use a font to render the radical sign (and > its overbar) at all if the radical and extension have to be set at a > larger type size than the radicand to "fit over it". As people have > long noted (and as TeX fans have long loved to lord over us), this > approach is bad because the glyph line thickness scales up with the > type size, and it's not idiomatic in mathematical typography to have > the radical sign be this brutally heavy thing compared to the stroke > thickness of the glyphs in the radicand, which is the more important > information semantically. This will prove exceptionally difficult to achieve, matching the drawn line width to the variable width of the filled shape which form the lines in a glyph, which itself is dependent on the point size eqn chooses. The png shows the sqrt in two fonts, finding the correct point to attach a drawn line and getting the width correct for any font with a square root glyph would defeat me (using just the information in the groff font), of course it might be done by decomposing the actual glyph in the .pfb and a bit of trigonometry. My advice, it is not worth the effort. Better to document somewhere that both glyphs must come from the same font, and the 3 .chars above which will ensure it when a particular text font contains just one of them. Be aware that the device tmacs, i.e. ps.tmac, already convert \[rn] to a \D'l .5m 0', which looks awful when used with sqrt from Symbola, hence the need for the .char above which overides this conversion to line drawing. Cheers Deri > It's the same reason you wouldn't set a conventional fraction like > this (warning: UTF-8 follows). > > a+1 > ███ > b+2 > > Sure, that's a...horizontal bar...of sorts...between the numerator > and denominator. (Everyone looks around the room uncomfortably.)
eqn.pdf
Description: Adobe PDF document
