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

Re: Remaining missing glphs


Matthias Clasen wrote:

>>> regarding: \varbeta

> I have not seen this one either, so I don't know how it is supposed
> to look like, but I have picked up the following information in a posting
> to comp.text.tex some time ago:

> :I would like to write a short citation of a greek word, without
> :using a babel package. The TeX Book advises to use math mode.
> :
> :Actually, that's fine, except for the beta, when it's used inside
> :a word ($\beta$ is only correct for initial letters).
> :The correct beta (a \varbeta ?) should look like a mirrored $\partial$

Have a look at

  http://www.unicode.org/Unicode.charts/normal/U+0370.html 

for a Greek font table.  The \varbeta is in slot U+03D0 and seems to
look like a normal \beta without a stem descending below the baseline
and the upper bowl being perhaps a little more curly than usual.  

If this character is only needed for Greek text, it is questionable
whether this justifies allocating two slots in a new math encoding.
On the other hand, the IUPAP standard on symbols in physics states
that if there are two variants of a Greek letter, either one may be
used, so it wouldn't be wrong to use it in math mode if available.

>>> regarding: \skewchar

> Since we're counting slots here, let me mention another idea of mine
> which would buy us 1 slot per encoding:
> Since we have decided to have a space in slot 32 in every encoding,
> is it really necessary to reserve slot 0 as skewchar ? Is there any
> reason against using slot 32 as the skewchar ? No glyph will ever have to
> be kerned against the space, or am I wrong here ? And the dumb drivers
> which rely on the space in slot 32 (are there any ?) will never see the
> kerning, if they ever see a space glyph at all.

Personally, I would welcome this idea if there aren't any technical
reasons speaking against it.  From TeX's point of view, there should
be no need for a space character in math mode, especially not for a
visible space.  If a space glyph is retained as an empty glyph purely
for technical reasons, this would be ideal for use as a \skewchar,
especially since the \skewchar would never appear in the output.  

Now, the question remains whether there are any technical reasons
against using character 0 for visible symbols.  I seem to recall that
the 8r-encoding of PostScript fonts avoided the use of characters 
0, 10, 13 (i.e. NUL, LFD, RET) ``in case we meet dump software''.
Since we did not worry about slots 10 and 13 before, I really don't
seem why we should treat slot 0 any different.

Cheers, Ulrik.