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 > 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. 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? 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. 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. 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.)
signature.asc
Description: PGP signature
