Follow-up Comment #29, bug #64155 (group groff):
> Well, when you're prepared to discuss it, it would be good to know if/how Dave's original report in comment #0 was invalid I think I can answer this - it is certainly not invalid, it just has nothing to do with ZD not being a "proper" family (in your eyes). If you do -fZD, which has no alphabetic glyphs, any start up macros which contain conditional statements of the form:- .if '\*[.T]'html' \" etc.. Will produce character not found errors, since, as we know, both sides are formatted in separate environments and compared. The give away in Dave's initial report is that the "character undefined" errors spell out the words "ps/pdf/html" at least can be seen. I'm sure this "feature" has come up before. Even with Branden's code which stopped -fZD from working did not address the real problem because if you have four fonts with R, I, B, and BI extension but don't contain alphabetic characters, -f works for the "family" but you will see exactly the same errors as Dave reported. One way for a proper fix, is to create a copy of TR as TRSKEL, add the "special" parameter, and change the name parameter to TRSKEL, remove all kernpairs, delete all glyph definitions above 127, and finally alter the DESC file by incrementing the number and adding TRSKEL on the end. This will solve the error occurring if you use -f on fonts which don't contain ascii glyphs, such as some CJK fonts. This can all be done in the devpdf directory (I have done it for testing), but a very similar change can be made to devps as well. An alternative fix would be to consider including the GNU UnifontMedium font in groff and using it as a special instead of TRSKEL, this has the advantage of solving any undefined glyphs as well, but there are other issues. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64155> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/