[bug #58930] take baby steps toward Unicode

[Dave]

Follow-up Comment #26, bug #58930 (project groff):

[comment #24 comment #24:]
> > > +.fchar \[u2016] || \" double vertical line (matrix norm)
> > 
> > This one presents a kerning issue: if two U+2016s are set next to each
other, they should have a little space between them.
> 
> You've studied kerning a lot more than I have.

I don't know about that in general.  I happen to have in this instance, in
implementing a macro to support the CMOS sequence of footnote symbols for
tables (specified in section 3.79 in the 17th edition), which includes U+2016
fifth in the sequence of six symbols, and specifies doubling the symbols for
the seventh and beyond.  So in the unfortunate table with eleven or more
footnotes, two U+2016s will appear next to each other.  Arguably, for footnote
identification, it matters little whether the reader sees a solid block of
|||| rather than two groups of ||, but the latter I think has the aesthetic
edge, and might even turn out to be helpful in the truly unfortunate table
where three or four of them appear next to each other: "|| || ||" seems easier
to distinguish from "|| || || ||" than "||||||" from "||||||||" (though at
this point we're getting into absurdly unrealistic territory where there's no
room for any table on the page with all those footnotes, and maybe a table
isn't the best way to present this information after all).

> I'm not sure that kerns are even applied to fallback character definitions.

Not only aren't they, there's really no mechanism for them to be, since the
only place groff allows defining kernpairs is in the font description file,
which by definition cannot include fallback characters.  There's no user-level
way to add kernpairs (see bug #44244).

My aforementioned footnote macro defined an ersatz U+2016 character largely as
you do here, and included logic to add a thin space between adjacent ones,
which was the only way to handle this (probably only theoretical) scenario
because of this limitation.

> Or is that what you're proposing to work around?

At this stage I'm not proposing anything, just identifying potential
problems.

> I am proposing to punt on this issue and see if the users complain,
basically.

For an edge case like this, that's reasonable.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58930>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/