Follow-up Comment #14, bug #63076 (project groff):
[comment #13 comment #13:] > > I guess the main things I'm curious about are how you solved the problem of KOI8-R having code points in the same space as C1 controls (which groff uses for internal purposes). > I did not handle that case in any special way. The resulting document looks as it is supposed to (including the Cyrillic "a" characters (_а_), which C1 translates to). Or this problem can manifest itself in some unobvious way? Ah, I see--the answer is pretty obvious if I just look at a KOI8-R code chart instead of going by memory. https://en.wikipedia.org/wiki/KOI8-R All of the problematic code points (0x80-0x9F) are _not alphabetic_ in KOI8-R. In fact they're the sorts of things you wouldn't normally have in *roff input documents, or even most word-processed documents no matter what the formatter. While I think it would be in order to caution the user that not every valid graphical code point in KOI8-R is acceptable groff input, for inputting _text_ there will be no problem. And preconv(1) can be used anyway. There are established groff mechanisms for obtaining the symbols in KOI8-R 0x80-0x9F. Several have groff special character names, some are best obtained using the eqn(1) preprocessor, and things like boxes are best done with tbl(1) tables or drawing commands (\D escape sequences). This simplifies things a lot. Again, finding the right place(s) to document the restriction on 0x80-0x9F will be important--but it looks like there are no serious technical challenges here. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?63076> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
