[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More questions on low slots




> It would seem rather a mistake, however, to reduce further from 256 to
> 223 per math fam *at the TeX end* of the interface, when TeX only needs
> to deal with a .tfm file and virtual font mechanisms are readily
> available. I don't know if this is really what Matthias and Ulrik were
> speaking of, probably I didn't completely understand.

But if we do not keep the restrictions of other systems in mind while
designing the encodings, we will end up with two sets of encodings,
one for TeX and one for more restricted systems, with a defined mapping
between them. Anyway, our implementation is not restricted to 223 slots
per encoding, MC and MSP are nearly full 256-slot tables, but I have
tried to avoid kerning relations between 0--31 and 32--256. The other
encodings have fewer slots and after my recent reshuffling, MS1 and MS2
have nothing in the area 0--31 except \i and \j (since these have to live at
their T1 positions). 

> Pragmatically speaking it may be necessary for the moment to have .pfb
> files that leave slots 0-31 open, and put a hard space in slot 32, but
> in the discussion of \skewchar etc this issue seems in danger of being
> being mixed up with the TeX interface issue: I think it would be silly
> for TeX to see in the .tfm file for a math symbol font that there is a
> space in slot 32 when it is never going to be used as a math symbol; and
> in the absence of other criteria the natural place for a skewchar would
> seem to be position 0 or 255 (which is why I suggested 0 in the first
> place).

 [...] 

> However, let me hastily contradict myself and
> say that it might be rather useful in a math symbol font to have a
> phantom 0 and phantom minus sign character, for tables of numbers. And
> one of those could naturally go into slot 32 :-) Maybe those are in the
> proposal already, in fact---I don't recall offhand.

I don't think this has been proposed. If we do that, then the union of
\skewchar and space will lose its attractiveness, since the space will then
be used in the dvi-file and we would have to fear that the skewchar kerning
would appear in the document. If we decide to do this and move the skewchar
away from slot 32 again, I would vote for slot 255 instead of 0, since the
MSP encoding has an accent in slot 0 which has to live there. 255 could be
reserved in all encodings.

Regards, Matthias