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

"G. Branden Robinson" <[email protected]> Wed, 11 Feb 2026 19:17:49 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260212011749.ji4z3szwys4l2yys@illithid>
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 (application/pgp-signature, 833 B)