missing alphabet in unicode
Will Robertson
Any of you happen to know why there is no sans serif Greek alphabet
defined in unicode when there *is* sans serif BOLD Greek? (both
upright and italic)
sf bold greek starts at U+1D756
sf bold italic greek at U+1D790
Unless I'm missing something, this seems like a strange omission.
Will
Chris Rowley
chris
Will Robertson
> Why not ask Barbara to tell us the history of this accident?
She's not entirely sure about this one either. They filled up
alphabets based on symbols they found in use, so maybe no-one's ever
used sans serif greek before. Even still, it would be logical to
include it given that the bold shapes are there.
Will
Barbara Beeton
Why not ask Barbara to tell us the history of this accident?
sadly, barbara does not remember exactly why
there is no lightface sans serif greek, only
bold. at this remove, my best guess is that
it was felt that the bold was more likely to
be used (for vectors, and probably more in
physics than math) than the lightface, which
is known to be recommended for dimensions of
SI base quantities (nist guide, p.23) and no
recommendations have been found for anything
else in particular. the "nist guide" is nist
publication 811, guide for the use of the
international system of units, link at
http://physics.nist.gov/Pubs/pdf.html
one of the goals of the unicode exercise was
to fill an integral number of blocks; both
bold and lightface wouldn't fit, so the one
that was felt to be more probable by the utc
members working on the task was what was
included.
if anyone can find published instances of
lightface sans greek, please send them to me
and they will be submitted for consideration.
(the utc is prepared to consider these if
real examples can be found.)
[i guess i'd better start reading this newsgroup.]
-- bb
--------------------
Will Robertson
Thanks for your information and time. I'm not sure what you mean by
"an integral number of blocks" but I do understand that space was
limited.
I'll ask around about examples of lightface greek, but I suspect that
if *you're* not aware of it, it doesn't exist :)
> [i guess i'd better start reading this newsgroup.]
:)
As Chris belatedly discovered, there's a mailing list setting so you
can avoid the web interface. After you sign in here:
<http://groups-beta.google.com/group/unimath?hl=en>
you can set the email settings in "Edit my membership" on the right.
Will
Ross Moore
Surely the basic idea is that math symbols should appear to be
easily distinguishable from ordinary letters.
It makes sense that only bold sans-serif greeks have been used
in practice --- especially if capitals are needed.
Let's call this alphabet "sans-Greek".
Remember that with these, and most other math-families, the
special style is used only with isolated symbols, not with
long expressions.
(operators, relations, arrows don't have serifs anyway !)
In LaTeX terms, as I understand it, we are talking about
a "math-alphabet", not a "math-version".
Now suppose we have a set of math-families and alphabets,
defined for the "normal" math-version, and there is a need
to switch to a "bold" math-version --- for use in a poster,
say, or within a special figure or diagram.
Well, the easiest way to implement this would be to use
a bold-face version of the same STIX font, if such were
available. But even so, would there be bolder bold characters?
These would look pretty ugly.
More likely, the "bold" version of "sans-Greek" would use exactly
the same characters as the "normal" version (in a similar way to
large operators being the same; p.352 LaTeX Companion 2nd ed).
After all, a change of math-version is not normally associated with
a different meaning for the mathematics, just with a different style
of presentation.
>
> Will
Cheers,
Ross
------------------------------------------------------------------------
Ross Moore ro...@maths.mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 +2 9850 8955
Sydney, Australia 2109 fax: +61 +2 9850 8114
------------------------------------------------------------------------
Will Robertson
>
> Surely the basic idea is that math symbols should appear to be
> easily distinguishable from ordinary letters.
Hmm, I guess I hadn't considered that Greek and sans Greek would be
fairly similar.
But then you'd still have trouble with bold Greek and sans bold Greek.
The reason I bring this up is because it's not going to be very
intuitive to have people writing things like
\mathbf{\alpha}% works
\mathsf{\alpha}% doesn't work
\mathbf{\mathsf{\alpha}}% does work!
(or \mathbfsf...are there any opinions about whether such nested maths
font commands should be allowed?)
It's going to be confusing getting all the uprights/italics sorted out
too.
Classically, \mathbf implies an upright shape. But people are used to
getting italic Greek letters.
I think there are going to have to be a few packages options
enumerating the different choices.
Will
Ross Moore
On 16/01/2007, at 2:22 PM, Will Robertson wrote:
>
> Ross Moore wrote:
>>
>> Surely the basic idea is that math symbols should appear to be
>> easily distinguishable from ordinary letters.
>
> Hmm, I guess I hadn't considered that Greek and sans Greek would be
> fairly similar.
It's not just similarity among Greek variants that's the problem, it's
also
similarity of some letters to roman letters; e.g.
\nu and v is the classic example;
\epsilon and e (in some typefaces);
\varsigma and s
\iota and i (esp. when dotless)
> But then you'd still have trouble with bold Greek and sans bold Greek.
But people aren't likely to be mixing those; at least not deliberately.
Typically an author or editor might choose one of these, to give
an increased supply of symbols foe his/her special area of study.
There's unlikely to be a need for both together --- though that's not to
say it's impossible. In the context of an encyclopaedia, that covers
many
areas and tries to faithfully reproduce the symbols that are commonly
used in all of them, then you may need all variants.
But even there, it's unlikely to need them within related articles.
>
> The reason I bring this up is because it's not going to be very
> intuitive to have people writing things like
> \mathbf{\alpha}% works
> \mathsf{\alpha}% doesn't work
Why not ?
Just \DeclareMathAlphabet to use the bold-sans Greek characters.
> \mathbf{\mathsf{\alpha}}% does work!
With current implementations of math-alphabets, only the inner-most
would have effect. That's because it is its font that would be in effect
(at least for the normal roman alphabet) when the argument is added
to the math-list.
So I'd expect that the same should apply to the Greek letters, if you
were to add styling of these to the effect of \mathbf and \mathsf .
> (or \mathbfsf...are there any opinions about whether such nested maths
> font commands should be allowed?)
You cannot stop people from using them -- rightly or wrongly.
The issue is to decide what should be the result.
I'd say that inner-most dominates.
>
> It's going to be confusing getting all the uprights/italics sorted out
> too.
> Classically, \mathbf implies an upright shape. But people are used to
> getting italic Greek letters.
With \mathversion{bold} the greeks are slanted surely ?
(from fontmath.ltx)
\DeclareSymbolFont{operators} {OT1}{cmr} {m}{n}
\DeclareSymbolFont{letters} {OML}{cmm} {m}{it}
\DeclareSymbolFont{symbols} {OMS}{cmsy}{m}{n}
\DeclareSymbolFont{largesymbols}{OMX}{cmex}{m}{n}
\DeclareMathAlphabet {\mathbf}{OT1}{cmr}{bx}{n}
\DeclareMathAlphabet {\mathsf}{OT1}{cmss}{m}{n}
\DeclareMathAlphabet {\mathit}{OT1}{cmr}{m}{it}
\DeclareMathAlphabet {\mathtt}{OT1}{cmtt}{m}{n}
\SetSymbolFont{operators}{bold}{OT1}{cmr} {bx}{n}
\SetSymbolFont{letters} {bold}{OML}{cmm} {b}{it}
\SetSymbolFont{symbols} {bold}{OMS}{cmsy}{b}{n}
\SetMathAlphabet\mathsf{bold}{OT1}{cmss}{bx}{n}
\SetMathAlphabet\mathit{bold}{OT1}{cmr}{bx}{it}
That is, always the same font family and shape, just bold versions.
Note also that \mathbf within \mathversion{bold} is the same as
in \mathversion{normal} , and similarly for \mathtt .
The {largesymbols} don't change either, as I mentioned in a
previous email.
> I think there are going to have to be a few packages options
> enumerating the different choices.
Sure. If we implement as a package to be loaded.
>
> Will
>
Hope this helps,
Ross