Re: [Groff] Some thoughts on glyphs

[Werner LEMBERG]

> >   .composite ho u0328
> >   .composite ah u030C
> >   .composite aa u0301
> >   ...
> 
> Should we strive to have all the Unicode ranges mapped in
> glyph.tmac, or just the Latin-A, Latin-B and extensions (perhaps
> Cyrillic too) plus the needed ranges for European/Slavic languages
> typesetting (math symbols, dingbats, etc.) and leave the CJKV ranges
> as optional files to be loaded on demand (you already said that
> complex in-context typesetting such as in Arabic and most Hindi
> scripts is out of scope)? Perhaps make the actual Unicode ranges
> loaded by default a runtime configuration flag with a sensible
> default that can be changed with a "configure" variable before
> compilation, like paper size and the postscript spooler flags?

The number of `.composite' calls is very limited (less than 10); the
number of groff glyph names is fixed also (about 400).  All other
glyph names will be derived algorithmically, so the problem you
describe actually doesn't exist.

Having many glyphs in font files is a completely different thing.
Here we have to extend the format in a sensible way to handle CJKV
glyphs.  I haven't investigated this problem yet, so don't expect a
detailed answer.

> What I like with your proposal, and the input encoding mapping
> mechanism you propose, is that someone with enough determination
> could create input encoding mappings as big as Big-5 to UTF-8 or a
> Shift-JIS to UTF-8 encoding (would UTF-8 be the internal encoding?).

Again, this is a completely different problem.  The one and only
encoding groff 2.0 will understand is UTF8 (besides latin1 and EBCDIC
for backwards compatibility).  Everything else will be handled by the
libiconv, Bruno Haible's excellent library for converting input
encodings.

I was only talking about glyph names, nothing else.  Please be
careful and do a clear distinction between input characters and
output glyphs.

> And talking about the input encoding to Unicode mappings... I think
> they should be configurable at runtime with a default determined at
> compilation time too. I see this as advantageous to people who
> actually use an input encoding different to Latin-1 (I can think of
> most other ISO-8859 encodings, Windows code pages, KOI-8, MacOS
> encodings under OSX, CJKV encodings, and non standardized encodings
> such as Georgian and Armenian).

libiconv can handle *a lot* of input encodings :-)


    Werner