[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `low slots'
- To: math-font-discuss@cogs.susx.ac.uk
- Subject: Re: `low slots'
- From: Hans Aberg <haberg@matematik.su.se>
- Date: Sat, 4 Oct 1997 13:52:01 +0200
>> TrueType comes to mind when you think about restrictions below 32
>
>(1) Actually, there is nothing in the TrueType spec about this and I have
>many TrueType fonts that work just fine with characters in 0 - 32.
>However, the Macintosh and Windows 3.1 and Windows 95
>implementations (and most font generation software) do not implement
>the spec - only Windows NT does.
>
>(2) More importantly, the problem with 0 - 32 is not restricted to TrueType
>fonts, but to arbitrary scalable fonts, since most applications have
>some problem with this. On Mac, 13 is hardwired to return and not
>a glyph, many applications treat strings as null terminated so 0 is
>problematic. Acrobat has troubles with 0, 9, 10, 13, 32, and 127. etc.
I think this these are restrictions of how people write software, and not
of the computer OS: For example, there is nothing in the C standard
demanding strings to be null terminated, but if you find that convenient,
you may do it that way; more modern software will not use null terminated
strings in critical situtaions. The Macs do not have return hardwired to
return; if you write a simple editor, then you get a struct from the
keyboard where the `return' in the event is just a 8-bit number (plus other
data, describing the keyboard event), and you can remap it as you please.
The Mac files (= data fork) are actually binary, with no restrictions on
its contents. The MacOS comes with a toolbox which software writers can use
if they find it convenient, and it is in that the problems are to be found.
-- But when the MacOS improves, those problems go away. I gather it is the
same thing on the MSOS side.
So if people really want use TeX fonts, they could probably write the
software to do it.
>I don't think you have to worry too much about math fonts being used in
>other applications. They are essentially useless when prepared for TeX.
>This is because the advance width is not the advance width, but where to
>put the subscript, the `true' advance width is the advance width of the
>character plus the italic correction, etc. You know the story.
So it sounds like that to me, too. :-)
Hans Aberg
* AMS member: Listing <http://www.ams.org/cml/>
* Email: Hans Aberg <haberg@member.ams.org>