Re: There is a severe problem with EQN and square roots

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/>