[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More questions on low slots
- Subject: Re: More questions on low slots
- From: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
- Date: Thu, 2 Oct 1997 11:56:53 +0200
- Cc: math-font-discuss@cogs.susx.ac.uk
Matthias Clasen:
> Yesterday, I reread Justin Zieglers paper and found a constraint
> which I had overread so far: At the place where it is mandated that
> slot 32 be the space in all encodings, it is also stated that there
> should be no ligature/kerning relations between the regions 0-32 and
> 33-255 to make it easy to put the low region into a separate font
> for dumb software.
Well, I'm not a device driver expert, but I've noticed that several
PostScript fonts do indeed mess around with the region 0-31 (not 32).
For example, I've looked at the Bakoma cmsy10.afm which has metrics
for slots 0-127 while the corresponidng cmsy10.pfb has an encoding
vector for slots 32-126 and 160-196. Slot 160 is a space glyph,
slots 161-192 correspond to 0-31 and slot 196 to 127 (ASCII DEL).
Better don't ask how this fits together and works internally.
> This is not satisfied in our current implementation. I wonder if it
> is even satisfied in the original YAASP proposal, since it has the
> skewchar in slot 0 (and by definition there will be lot of kerning
> relations with the skewchar from all over the font).
> We could try to satisfy the constraint as well as possible
> in the original proposal (ie leave the skewchar in the low region,
> but avoid any kerning/ligature information between ordinary glyphs
> from the two regions), but it will not be easy in MC. At least the
> slash would have to move in the high region; there might be more.
As for skewchar kernings, moving it from 0 to 32 might solve the
problem already. As for slash, period, and comma kernings, the only
way I see to fulfil the requirement would be to reshuffle the table,
perhaps placing them in the usual ASCII positions?
> But is this worth the effort ?
I don't know. We'd really need some more background information about
where the technical requirements come from. Any experts listening here?
Cheers, Ulrik.