Re: Not predefined Extended Latin character needed, interesting solution found

[G. Branden Robinson]

At 2021-05-18T18:19:52-0500, Dave Kemper wrote:
> On 5/18/21, Oliver Corff <oliver.corff@email.de> wrote:
> > I am a bit confused because ./configure warns me that I do not have URW
> > fonts, but /usr/share/fonts/urw-base35/ is definitely not empty.
> > ./configure does not respond well when I run it with the urw font
> > directory option, and asks me to get the necessary fonts from
> > http://downloads.ghostscript.com/public/fonts/urw-base35-v1.10.zip
> >
> > However, that URL just returns a 404 error.
> 
> A very recent change to the groff code (commits 39de1019 and d6b6183a,
> from 4 days ago) addressed the above issues, in response to another
> bug report about this (http://savannah.gnu.org/bugs/?60604).

Thanks, Dave.  I encourage readers of this list to also subscribe to
bug-groff@ and groff-commit@.  Dave does yeoman's work creating links
between our bug tracker and the mailing lists, but more eyes means more
discussion potential, and ultimately wiser development decisions.

> If you're willing to give it another try, you could grab the latest
> code from git (http://savannah.gnu.org/git/?group=groff) and see if
> that solves the problem for you.

Earlier this month I encountered a similar problem in our gpinyin(1) man
page and irritably added a workaround for it[1].

Consider the following input file:

.nf
.lf 1
1 \z\[u0304]a
2 \z\[a-]a
3 \[a a-]
4 \[u0101]
5 \[u0061_0304]
6 \N'257' \" 0x101

This works nicely--mostly--on a UTF-8 terminal.  The exception is that
there's no word space on the first line.  I cannot fathom why.  Bug?

Rendering this with -Tps or -Tpdf is a significantly less happy
experience.

Only lines 1 and 2 print any glyphs at all after the numbers (but at
least there's a word space on line 1).

troff: EXPERIMENTS/amacron.groff:1: warning: can't find special character 
'u0304'
troff: EXPERIMENTS/amacron.groff:3: warning: can't find special character 
'u0061_0304'
troff: EXPERIMENTS/amacron.groff:6: warning: can't find numbered character 257

If you look closely, you will see that line 2's output, while
comprehensible, isn't perfect--the macron isn't centered over the base
glyph 'a'.  I assume that this is because Combining Characters Are Hard;
there's more to them than blind overstriking if you want good results.

This does seem to reveal the underlying problem; either the Times roman
equivalent font on my system doesn't have a combining macron glyph
U+0304 or groff doesn't know about it because afmtodit(1) didn't find
out or didn't communicate that information in the TR font file it
generated.  I tried to get a precomposed "a with macron above" by going
for its Unicode code point directly in line 6.  That was a Hail Mary
pass because, as I understand it:

(A) A PostScript font isn't guaranteed to have its glyphs arranged in
    Unicode code point order, and historically they in fact weren't.
(B) Line 4 is the right way to ask for that code point; our "afmtodit
    tables" force that to be decomposed to the form in line 5
    automatically, so for -Tps and -Tpdf lines 4 and 5 wind up being
    transformed to the same thing.  I think.  I haven't actually checked
    device-independent output for this yet.

Most concerning is that lines 4 and 5 render no glyph and also produce
no warning.  We're not on the terminal; grops(1) and gropdf(1) should be
given accurate font coverage information for the fonts they're using.

I also wonder if that diagnostic shouldn't be worded differently, like

  "font '%1' has no glyph for special character '%2'"

Can someone point me in the right direction to look for the bug(s) here?

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff-commit/2021-05/msg00062.html

signature.asc
Description: PGP signature