At 2021-05-18T18:19:52-0500, Dave Kemper wrote: > On 5/18/21, Oliver Corff <oliver.co...@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
