From: Michael Everson (everson@evertype.com)
Date: Wed Dec 03 2003 - 05:53:21 EST
At 01:44 +0100 2003-12-03, Philippe Verdy wrote:
>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.
At some expense. You are welcome to lobby Apple to commission a
localized French version of the Last Resort Font.
>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")...
You are welcome to draw up a list of all of the "native" names.
>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.
You don't know much about drawing fonts, evidently.
>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.
To what end?
>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.
Wonder away.
>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.
"Possibly"?
>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.
"Possible."
>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.
"Interesting."
I don't think so.
-- Michael Everson * * Everson Typography * * http://www.evertype.com
This archive was generated by hypermail 2.1.5 : Wed Dec 03 2003 - 06:44:41 EST