Update of bug #67244 (group groff):
Assigned to: gbranden => deri
_______________________________________________________
Follow-up Comment #14:
Hi Deri,
Unfortunately your reply didn't make it past Savannah's paranoid email filter.
But no worries, I'm replying here.
(Ah, I see you've since re-replied in a form Savannah accepted.)
On Tuesday, 1 July 2025 06:19:34 BST you wrote:
>> 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.
I'm not yet convinced I've done so. I think _groff_'s support for
"third-party" fonts may be too underspecified to support such a claim.
For example, I've abandoned my idea of adding an `-M` option to _afmtodit_ and
no longer requiring specification of a map file (using _groff_'s "text.map" as
a default). The wisdom of the existing approach is becoming clearer to me:
Unicode is a big place and we can expect third-party fonts to _frequently_
supply glyphs for which we don't already define special character identifiers.
Or, no such identifiers will be needed because the input documents using such
fonts will go straight to `\[uXXXX]`-style escape sequences.
Like with Greek, for example.
If I'm right, we didn't properly support the Tinos fonts in the first place.
Even in old _groff_. Our lack of support might have recently changed its
shape a bit, but arguably that's not a regression.
That said, what matters more than whether something "technically" regressed or
not is whether we have happy users. Like you, I want _groff_ users to be able
to install the Tinos fonts and carry on with minimal effort beyond that.
But, in order to support them, we might have to start offering guidance about
what sort of "map" file they're going to need to craft to feed to _afmtodit_.
(I have an inkling that if a font doesn't offer coverage of _any_ of _groff_'s
predefined special character names--if everything maps from `uniXXXX` to
`uXXXX`--then a map file is unnecessary.
So maybe `-M` is a good idea after all. Hmmm.)
The main reason my reply to you wasn't as responsive as you wanted was not, in
this case, because I missed the point (I think) but because my thoughts around
these issues haven't settled down, and I have at least two pieces of homework
to do before they can.
> Very happy.
Good news! It was your idea as well, I think. :)
> 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.
Only if you don't buy my argument that it isn't a regression. But even if it
isn't, we need to have a credible story for Tinos font users and others
similarly situated, so that they can get what they want. Yet another
documentation task.
> 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.
I don't understand the problem yet.
echo "Στα Ελληνικά"|test-groff -Tps -ms -F
/usr/share/groff/site-font/ -f TINO -k | okular -
file #57348
I can see that this looks wrong. There should be a lowercase iota where the
isolated diacritical mark is hanging below the baseline beneath an empty
glyph.
I'm afraid what you said about the key collisions arising from _libgroff_'s
use of a Unicode Normalization Form (NFD?) went a bit over my head. I thought
I understood the gross concept of it, but it seems like what's going on with
this Greek font is something terribly bizarre. In the Latin script, the
analogy that comes to my mind is an input document that uses U+0101 LATIN
SMALL LETTER A WITH MACRON and somehow, thanks to _libgroff_, this gets
remapped to U+005E CIRCUMFLEX ACCENT. Huh?!?! Something weirder than
decomposition appears to be going on.
So one item of homework for me is to brush up on Unicode normalization forms.
Another is to find out if combining accents in Greek radically change their
shapes from isolated to combined forms.
And a third is to, uh, actually install the Tinos fonts and get them working
with _groff_ locally so I can experiment.
Does Greek have "iotated" letters, where a base glyph can do double duty as a
combining glyph? If so, yikes! That doesn't happen in the Latin script!
Arrgh!
But maybe the problem is simply that the "text.map" file is inappropriate for
the Tinos fonts, and those fonts need a map file that is correct. I hope so.
But I fear not, given your point about how the problem arises due to the
mappings of Unicode characters without _groff_ special character names.
I could be misstating some things. My understanding is fragmentary. That's
why my previous reply was partially unresponsive.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67244>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
