At 2026-11-12T12:58:17+0100, Morten Bo Johansen wrote: > Long subject, but I wonder if it would be possible to use the more > descriptive of the two names that glyphs have in the afmtodit file in > the generated URW fonts?
I don't know. Maybe? > For instance, the glyph, 'ะค', which in the unicode database is called > "CYRILLIC CAPITAL LETTER EF" and which has the hex code 0424, is > referred to as "afii10038" in the URW fontfiles, but afmtodit also > registers this glyph by its more descriptive name, "Efcyrillic". The name "afii10038" is the one the Adobe Glyph List (AGL) uses. If I remember correctly, Deri has advocated moving away from the AGL as an authoritative source of information, at least in part because it's no longer maintained. EDIT: Hmm, it seems that the name _does_ come from the AGL. $ sed -n '2088,2092p;2244p' src/utils/afmtodit/afmtodit.tables # This table was algorithmically derived from the Adobe Glyph List (AGL) # file 'glyphlist.txt' from the GitHub Adobe Type Tools agl-aglfn # project, on 2026-10-13. # # See "groff:" comments for altered mappings. "Efcyrillic", "0424", This could be an example of the "aliasing problem" that is producing conflict and confusion in Savannah #59402. https://savannah.gnu.org/bugs/?59402 > It would be much better if the latter name were used in the fontfiles. > To illustrate, I have a function in my editor where I can search for > glyphs in the groff fontfiles and then insert them into the buffer in > groff notation, but how would I search for this glyph? If I search > for "cyrillic", nothing turns up. I hope to address a related issue in the near future, maybe even in the 1.26 development cycle, with improvements to the `pchar` request (new to 1.24.0) that pursue glyph information all the way to the font description file (when that character is not user-defined). That wouldn't help to _search_ for how the _font file_ identifies a glyph, but it would least expose the name (if any) that a font file uses for a specified _groff_ character. The idea is analogous to the report issued by the `pfp` request, also new to groff 1.24.0. $ echo .pfp | groff 2>&1 | head 1 R 2 I 3 B 4 BI 5 TR TR Times-Roman 6 CR CR Courier 7 CI CI Courier-Oblique 8 CB CB Courier-Bold 9 CBI CBI Courier-BoldOblique 10 SS SS Symbol-Slanted $ printf '.fp 50 TBold TB\n.pfp\n' | groff 2>&1 | grep 50 50 TBold TB Times-Bold (It occurs to me now that `pfp` could accept non-negative integers as arguments, and report only on the requested mounting positions.) > To spell it out: The line in e.g. the fontfile, U-CR, that looks like > this > > u0424 600,563 2 424 afii10038 -- 0424 > > should rather look like this > > u0424 600,563 2 424 Efcyrillic -- 0424 > > Would such a change be feasible? I think this probably _could_ be done; the question is whether we give up anything of value by abandoning the AGL as a sole source of truth, and if so, what those valuable things might be. Doing so might also create a problem for ourselves in maintaining our own glyph identifier database. We already sort of do that with the list of special character identifiers in _groff_char_(7). When Werner Lemberg was maintainer he declared a moratorium on any further expansion of that identifier name space (as preconfigured by groff). I see the advantages in that policy. I don't think we have the resources to keep up with Unicode's ever-growing repertoire. It might be worthwhile to investigate how other typesetting systems cope with this problem. > If I included the afmtodit file in my search function that wouldn't > tell me which of the fontfiles that actually has this glyph, so that's > not a solution. ...but grepping _afmtodit.tables_ might help. I admit that that might be feeble advice. Regards, Branden
signature.asc
Description: PGP signature
