At 2021-01-13T04:34:50-0600, Dave Kemper wrote: > On 1/4/21, Denis M. Wilson <d...@oxytropis.plus.com> wrote: > > rfc1345 does not have a base-line ellipsis, a character frequently > > used in English writing. > > > It is available as \N'188' in the symbol font or as \[u2026]. > > Since commit aac5fd24 (2003), it has been available in the Symbol font > as \[u2026] as well, no longer requiring the \N syntax to access it -- > a good thing, since, like .char, \N inhibits kerning (though this is > moot for the ellipsis in the default groff fonts while > http://savannah.gnu.org/bugs/?58897 is unresolved).
I was looking at #58897 just the other day as I slowly grind my way though "[PATCH]"-annotated Savannah tickets. I reckon it can be applied as-is, but it brings to my mind a smelly can of worms that I keep finding under my nose when I research several different outstanding Savannah tickets, and that is the relationship between the PostScript core fonts[1] and the groff build process. Right now these are completely decoupled in the procedural sense, and this causes grief in multiple respects. Even if Adobe's fonts are stable (or moribund), GhostScript's aren't. This has caused issues with distributors seeing groff mysteriously break when GhostScript gets upgraded, forcing a rebuild of groff against the new ghostscript. As I understand it, it also led to the weird \[lh] (left hand) glyph problem that Werner recently analyzed[2]. To me, it seems like afmtodit should be run against Adobe or GhostScript PostScript Level 2 fonts as part of the groff build process, which means a build-dependency of some kind, and this further leads to the uncomfortable question of the non-freeness of the Adobe fonts and whether GhostScript's replacements are truly metrically identical. I'd answer this question for myself except I cannot figure out where to download Adobe's PS Level 2 font repertoire! Can someone tell me? I don't think the non-free build-dependency issue is a real challenge, it just moves the lump in the carpet. As I have argued before, the font metrics themselves should be uncopyrightable under U.S. law and they can be extracted and distributed as part of groff. Re-extracting them (or verifying their continued stasis) for each new groff release would then be a procedure for our recently-added FOR-RELEASE file. I'm not too concerned with the _esthetics_ of GhostScript fonts--if they look ugly, those are bugs in GhostScript and we can report them. If the metrics are truly incompatible, then either that's a GS bug or we really do need to add the foundry feature https://savannah.gnu.org/bugs/?58969 and distinguish URW from Adobe accordingly. This, too, should not be a big deal, as conscientious Free Software distributors and users should already have or prefer the URW fonts anyway. _If_ we can solve these build-time issues, then we can also solve some distributor problems, by encouraging them to use package triggers to regenerate relevant groff font files with afmtodit when the actual fonts on the system are updated. I suppose this would be done for devps and devpdf. These matters have been troubling me for some time, and I don't feel confident that I fully understand them, so I would appreciate corrections to any of the above. I do sense that addressing my concerns will involve some mild architectural work, and I am pessimistic that anything beyond Dave's patch in #58897 (which I've already applied to my local Git checkout, and which will appear in my next push after I verify that it does no harm to generated files) can be done in time for groff 1.23.0. Regards, Branden [1] https://en.wikipedia.org/wiki/PostScript_fonts [2] https://savannah.gnu.org/bugs/?59531
signature.asc
Description: PGP signature
