On Tuesday, 1 July 2025 06:19:34 BST you wrote: > Update of bug #67244 (group groff): > > Status: In Progress => Need Info > Assigned to: gbranden => deri > > _______________________________________________________ > > Follow-up Comment #10: > > [comment #9 comment #9:] > > > Sorry to be a pain but this commit has revealed a problem. > > Only 2 things pain me here. Well, 3, but the third pains you too. > > 1. You should have set the ticket's "open/closed" datum to "open" when > changing the status from "fixed" to "in progress". > Not a deal, I eventually found it. :)
Naughty, naughty me. > 2. I feel like you've expanded the scope of the ticket considerably. > > The objective of this ticket was only to fix the problems depicted > graphically in comment #1 and comment #2. I agree whole heartedly with the changes to symbol and text map files which you committed in this bug, so I thought my observations on a regression introduced by it, belonged here as well. > > The problem is linked to the design decision to use decomposed unicode as > > the primary key for looking up the font table, which is essentially what > > the groff fonts are. > > A redesign of _groff_'s character resolution processes, or mappings from > special character identifiers to Unicode code points (where applicable), > seem like a much bigger and longer-term project than contemplated in > comment #0. > > That said, maybe this bug *should* remain "in progress" (and should become > > "open" again) until, as you said in comment #2: > > all greek SYMBOLS should only appear in symbol.map and not in > > text.map. Similarly preconv and afmtodit (with text.map) should > > be using unicode uXXXX names. > > I've been giving some attention to bug #66876, and have grown increasingly > uneasy with the blanket dumping of all text font character names into > symbol.map, and the appearance of character names that historically are > unstyled (and therefore "special" in that sense) *also* showing up in > text.map. > > Except for the *m and mc confusion, it seems we've mostly gotten away from > this because the Adobe/URW font's character coverage is fairly static and > disjunctive. > > But I'm starting to think that our text.map and symbol.map files are > actually specific to the Adobe/URW fonts. Maybe I'm wrong, and glyph > naming is much more consistent among third party fonts. But that still > wouldn't make it incorrect to get text.map and symbol.map out of each > others business, making them disjunct lists of characters; any overlap > should be specifically motivated and documented. > > First, what do you think of this text.map/symbol.map reform? Very happy. > Secondly, are you willing to migrate the design issue of _libgroff_'s > Unicode<->glyph mapping to another ticket? > How you propose to mitigate the regression (in grops, I've put a sticking plaster on gropdf to try to avoid the problem) probably deserves to stay here. The longer term design problem which is the root of the issue can definitely be shunted to a new long term goal ticket, I'd appreciate your thoughts on the issue of grops now choosing the wrong glyph for iota (and others) since you have not addressed it in your reply. Sometimes you don't quite get the point of my posts, so I'll try a one liner:- +verbatim+ echo "Στα Ελληνικά"|test-groff -Tps -ms -F /usr/share/groff/site-font/ -f TINO -k | okular - -verbatim- This needs the google Tinos fonts installed as TINO[R/I/B/BI] in site-font for devps and devpdf, using the latest afmtodit and text.map (or the greek symbol names sedded away). You should then see:- [1] Which does not look correct. The reason it is wrong is explained in the previous post (along with a bunch of other, not so drastic, examples.
signature.asc
Description: This is a digitally signed message part.
