Thanks. I had actually forgotten that I had filed a bug report. Inspired by the discussion I looked around in the tmac and font directories and found some odd definitions. If I add another of my own (in my document)
.char \[sr] \[u203E] then it seems as if the radical and the bar actually connect. The square root symbol is too bold, but otherwise OK. Sigfrid On Thu, 12 Feb 2026 at 02:17, G. Branden Robinson < [email protected]> 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 > > > 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.) > -- Sigfrid Lundberg, Ph.D., System developer Lund, Sweden https://sigfrid-lundberg.se/ <http://sigfrid-lundberg.se/>
squareroot-problem.pdf
Description: Adobe PDF document
