Hi Deri, On Mon Mar 2, 2026 at 6:43 PM CET, Deri wrote: > On Monday, 2 March 2026 15:45:03 GMT onf wrote: > > It's also worth remembering the context in which they were writing it, > > though. The printers of the time were fairly limited in all sorts of > > ways including the number of glyphs they could work with. In today's > > conditions, however, their advice would be fairly stupid. The proper > > -- and technologically absolutely feasible -- solution is to make eqn > > capable of setting typographically correct large square roots, not > > insisting users change their equations. The logic is hardly different > > from adding support for longer identifiers rather than insisting that > > users find a way to name their macros and registers using only two > > characters. > > As far as I know unicode allocates a single code for SQUARE ROOT (U+221A) and > another for RADICAL SYMBOL BOTTOM (U+23B7). Fonts such as "DejaVuMathTeXGyre" > go much further offering different pre-composed sizes of the square root sign > and also a glyph for the tip and one for the extension line. So yes it > possible to "build" a square root of an arbitrary height using the 3 glyphs. > The problem is that the extender and the tip are not in unicode, their > postscript names are not "official" (in the AGL), so the only way for groff > to > access them is via \N'nnn', which is only guaranteed to work for that > particular version of that particular font. > > If someone were to create a font with the 3 glyphs and we gave them groff > names, sqbt, sqex and sqtp, then the changes to eqn would be doable. The > alternative is to lobby unicode to allocate codes for the extender and the > tip, i.e. the same as U+239B/C/D which are the top/middle/bottom of a left > parenthesis.
Fair points, you are right on all accounts. In neatroff, \N takes the glyph name as defined by the font rather than its numeric ID (e.g. \N'radicalbt') which makes using \N for this portable across all fonts with the same naming scheme (at the cost of being incompatible with other troff implementations). There is also request `fmap` to map troff name to given font glyph name as if it was defined by a `char` entry in the font, e.g. .fmap CMEX10 sqbt radicalbt \[sqbt] \" resolves to glyph with ID `radicalbt` when font is CMEX10 fmap would be a worthy addition to groff, IMO. But even creating a specialized font or two for square roots, as you suggest, would be better (i.e. create more acceptable output) than merely scaling the small square root as groff is doing now. There are many math fonts around under free licenses, so assembling a specialized square root font shouldn't be difficult if this path is chosen. Cheers, onf
