Hello Werner, Thanks for all the answers.
> > economic both in space in the font file format and in memory, rather > > than a representation that enumerates character after character. > > This is what I mean with `classes', something like this in a font > description file, using two new sections: > > classes > <Alike> = A :A 'A `A ... ; > <CJKpunct> = U+3000 - U+303F; > <Hiragana> = U+3040 - U+309F; > ... > > <CJK> = <CJKpunct> <Hiragana> ... ; > > properties > <CJK> width 24 > ... > <Alike> kern V -3 I see. I had imagined the same thing with just the properties and no classes, like the POSIX locale files. The classes make it easier to write small font files. On the other hand, the classes are arbitrary: two font files can describe exactly the same properties with very different class definitions. Not sure whether that's good or bad. > I've no idea how to store such information efficiently within memory. The three-level tables that are used in glibc's localedef program appear suitable here. They can store for example an complete width table for Unicode in ca. 12 KB, with an O(1) access (ca. 3 memory references). > > I assume, an element of a font - often called "index" - is a glyph. > > What is an "output character" then? > > Just sloppy wording by me :-) Well, TTY devices basically convert > troff glyphs back to output characters OK, good to hear that's it's not a major complication. Only the 'code' field in 'class glyph' in grotty/tty.cpp is of this type; it doesn't warrant a typedef. Bruno _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
