[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Remaining missing glphs
- To: email@example.com
- Subject: Re: Remaining missing glphs
- From: Ulrik Vieth <firstname.lastname@example.org>
- Date: Wed, 1 Oct 1997 14:12:51 +0200
- Cc: email@example.com
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
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.