Michael Everson writes: > At 15:14 -0800 2003-12-02, Patrick Andries wrote: > > > > Actually, if you look at the Last Resort Glyphs (at a large enough > >> size) you will see that the block name and range numbers are part of > >> the image. See http://developer.apple.com/fonts/LastResortFont/ > > > >I believe the name is in English. > > That's correct. I tried to get Apple to put all the block names in > Irish, of course.... ;-)
Using the official Unicode script name in English is not a problem. But a OS vendor could as well choose to translate these names in localized versions of this font if the OS itself is translated. The other good thing could be to include also the script name in a typical language using that script natively (for example the "lastresorthebrew" glyph usezd for the hebrew block should not only display "HEBREW" with ASCII letters on the top, but also the Hebrew term for "HEBREW")... Such a font seems easy to create automatically by using the basic glyphs of a base font containing the ASCII letters and digits, and a source text file giving the name and range of Unicode code point blocks, as well as a representative character or string. Hinting the generated LastResort font it is not really necessary, but some automatic hinting could be used in the generated glyphs to hide (at PPM values below 64), the border text that displays the block name and range of hex code points. I just wonder if it would then not be simpler to have a way to define algorithmic fonts implemented as native compiled code in a DLL or shared library for the OS using it, instead of needing it to be installed as a regular TTF font. I don't know for example if Windows or MacOSX can reference a DLL using some known and documented COM interface as if it was a font: It would allow, possibly, an easier development for advanced hinting, or kerning or ligature, or glyph processing by native code rather than with tables in TTF/OTF/AAT fonts. Of course the same question comes to Java: can a Java class be used to implement a font for use in Swing or Java2D or AWT? It seems that it is possible, as Java handles fonts selection by using a Font object instanced by the resource loader but that may be subclassed, and instanciated as another font. As Java is a de-facto common standard for cross-platform compatibility of binary code, this could be a very interesting alternative to TTF encoded fonts which are complex to develop and test. At least, this could be used to develop complex fonts before they are finalized in a OTF/AAT format. __________________________________________________________________ << ella for Spam Control >> has removed Spam messages and set aside Newsletters for me You can use it too - and it's FREE! http://www.ellaforspam.com
<<attachment: winmail.dat>>
