On Tuesday, 3 March 2026 02:02:40 GMT onf wrote: > 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
Hi onf, A further wrinkle is that since Adobe dropped support for postscript, some fonts have switched to using version 3 of the 'post' table:- ============================================================================ Version 3.0 This version makes it possible to create a font that is not burdened with a large set of glyph names. A version 3.0 'post' table can be used by OpenType fonts with TrueType or CFF (version 1 or 2) data. This version specifies that no PostScript name information is provided for the glyphs in this font file. The printing behavior of this version on PostScript printers is unspecified, except that it should not result in a fatal or unrecoverable error. Some drivers may print nothing; other drivers may attempt to print using a default naming scheme. ============================================================================ You can see this in Adobe's own SourceCodePro otf fonts. So, a reliance on postscript glyph names may become difficult. Cheers Deri
