From: Andrew R. <aro...@ya...> - 2004-05-18 12:05:15
|
At 08:43 AM 18/05/2004 +0200, you wrote: >* Alan W. Irwin <ir...@be...> [2004-05-17 22:14]: > > > The real ordering problem is for symbols. We just have an embarrassment of > > riches for freely accessible type 1 postscript fonts and truetype > fonts, and > > I expect the symbols for the various fonts don't come in any standard > order. In *theory* they should. Practice is another thing naturally... > > We likely will just have to live with that situation, and use some variant > > of x07c.c to find out what position corresponds to what symbol for a given > > font. Currently my variant of x07c.c uses "#g\xNN" (where NN is > hexadecimal) > > syntax to explore the first 156 symbols of any font. Once the current 156 > > limit is overcome the #g method will only work up to the first 256 symbols > > in the font. Thus, eventually, I want to make sure the "#(NNNN)" method > > (where NNNN is decimal) will work as well. Currently the "#(NNNN)" method > > of producing symbols corresponding to arbitrary positions in the font table > > only works for Hershey fonts. > >Let us try to not reinvent the wheel. The way to go here is to use Unicode >UTF-8 (see http://www.unicode.org) for the encoding of the characters. So, >we should make the API accept also Unicode strings as an alternative to the >#-escaped strings. UTF-8 strings are easily detectable (use for instance >libunicode, available everywhere) and the Freetype library is Unicode-aware. > >I am sure that almost all characters of the Hershey fonts have UTF-8 >corresponding glyph numbers (see the glyph tables at >http://www.unicode.org/charts/). I agree with Rafael, and believe unicode is the way to go long term - it's only an accident of 1980s 8 bit architecture we are stuck with ASCII's 256 characters. Translating between the Hershey fonts, unicode, then finding freetype compatible fonts with the symbols would be the interesting part of the exercise. -Andrew |