Fwd: unicode-math and mathrsfs
Will Robertson
>> When you use \mathscr, do you *also* use \mathcal in your documents?
>
> Yes, I do, even in the same formula:
>
> {\mathscr D}({\mathcal O}_X)
>
> (for the ring of differential operators on the algebra of functions on a
> scheme X).
Dear all,
I've had a report of a mathematician using both script and calligraphic letters in his work. (See above.)
This is a bit of a problem for unicode mathematics.
What are the chances of the addition of another maths alphabet into unicode? (I'm guessing "slim".)
I'll add some code to my package to support this sort of usage. Up until now I've been assuming (as per unicode) that \mathcal and \mathscr are the same.
-- Will
Ross Moore
On 27/05/2010, at 2:04 PM, Will Robertson wrote:
> Begin forwarded message:
>
>>> When you use \mathscr, do you *also* use \mathcal in your documents?
>>
>> Yes, I do, even in the same formula:
>>
>> {\mathscr D}({\mathcal O}_X)
>>
>> (for the ring of differential operators on the algebra of
>> functions on a
>> scheme X).
I suspect that if this has occurred in publications,
then it might be done as:
\mathfrak{D}(\mathcal{0}_X) 𝔒(𝒪_X)
I think you need to hear from Barbara about what the AMS
have done, or plans to do, with this kind of construction.
Another possibility is to use a bold-script D (U+1D4D3)
with a medium weight script O (U+1D4AA). 𝓓(𝒪_X)
I'd doubt that we need more math alphabets (touchwood!)
but maybe STIX has it already:
U+0E230 is an italic script D
U+0E24A is a bold-italic script D
>
>
> Dear all,
>
> I've had a report of a mathematician using both script and
> calligraphic letters in his work. (See above.)
>
> This is a bit of a problem for unicode mathematics.
>
> What are the chances of the addition of another maths alphabet into
> unicode? (I'm guessing "slim".)
>
> I'll add some code to my package to support this sort of usage. Up
> until now I've been assuming (as per unicode) that \mathcal and
> \mathscr are the same.
>
> -- Will
Cheers,
Ross
------------------------------------------------------------------------
Ross Moore ross....@mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 (0)2 9850 8955
Sydney, Australia 2109 fax: +61 (0)2 9850 8114
------------------------------------------------------------------------
Will Robertson
> I suspect that if this has occurred in publications,
> then it might be done as:
>
> \mathfrak{D}(\mathcal{0}_X) 𝔒(𝒪_X)
>
> I think you need to hear from Barbara about what the AMS
> have done, or plans to do, with this kind of construction.
>
>
> Another possibility is to use a bold-script D (U+1D4D3)
> with a medium weight script O (U+1D4AA). 𝓓(𝒪_X)
>
> I'd doubt that we need more math alphabets (touchwood!)
> but maybe STIX has it already:
> U+0E230 is an italic script D
> U+0E24A is a bold-italic script D
Okay, so in this case the "ring of differential operators" is a special symbol that looks like a curly script D, but the whole alphabet is probably not necessary?
The fact that STIX has such a symbol is a good sign already. (But I hope these extra symbols can be incorporated into unicode sooner rather than later.)
Will
Ross Moore
On 27/05/2010, at 5:08 PM, Will Robertson wrote:
>
> Okay, so in this case the "ring of differential operators" is a
> special symbol that looks like a curly script D, but the whole
> alphabet is probably not necessary?
>
> The fact that STIX has such a symbol is a good sign already. (But I
> hope these extra symbols can be incorporated into unicode sooner
> rather than later.)
STIX has whole alphabets in the Private Use area.
No doubt people will start to use these.
The question is whether or not MathML and TeX-based Unicode-Math
(and my Tagged-PDF support) should provide CMap or /ActualText
to map these to the nearest Unicode equivalent, though still
use the actual requested symbol when possible.
The best solution is for Unicode to add these alphabets;
but then we have STIX using them at different code-points.
The situation could get rather murky.
Will Robertson
> The best solution is for Unicode to add these alphabets;
> but then we have STIX using them at different code-points.
>
> The situation could get rather murky.
Depending on the lag time, quite.
Wait, are these glyphs in the "private use area" or are these simply unused slots near the other math glyphs in unicode? If they're pre-emptively filling up slots without using the PUA, then there's not really any problem.
Not sure how I'll address these private code point glyphs in unicode-math, either. I suppose if the glyphs are in STIX then Barbara will be able to supply me with control sequences for them, so not too much trouble perhaps (until people start wishing to change fonts).
Might have to restrict being able to switch fonts on those glyphs. (In fact, I probably need to add a way to map control sequences to specific glyphs of specific fonts for exactly this purpose.)
-- Will
Jonathan Kew
> On 27/05/2010, at 4:57 PM, Ross Moore wrote:
>
>> The best solution is for Unicode to add these alphabets;
>> but then we have STIX using them at different code-points.
>>
>> The situation could get rather murky.
>
> Depending on the lag time, quite.
>
> Wait, are these glyphs in the "private use area" or are these simply unused slots near the other math glyphs in unicode?
They're PUA codes.
> If they're pre-emptively filling up slots without using the PUA, then there's not really any problem.
Hold on a minute, Will! Wearing my "standardizer's hat", I have to disagree here, in the strongest terms :) .... if STIX (or anyone) starts "pre-emptively filling up slots", there would be a HUGE problem. Those slots are liable to be filled with some other character in a future standard. That's a mess that should be avoided at all costs. The point of standards is that they're STANDARD.
> Not sure how I'll address these private code point glyphs in unicode-math, either. I suppose if the glyphs are in STIX then Barbara will be able to supply me with control sequences for them, so not too much trouble perhaps (until people start wishing to change fonts).
Well, yes. That's the price people pay for using things that are not (yet) standardized; they become dependent on one specific implementation, and lose the interoperability that comes from everyone following a common standard. Unicode provides the PUA so that there is a clear line between what's standard and interoperable, and what's private to a particular implementation or system.
JK
Will Robertson
>> If they're pre-emptively filling up slots without using the PUA, then there's not really any problem.
>
> Hold on a minute, Will! Wearing my "standardizer's hat", I have to disagree here, in the strongest terms :) .... if STIX (or anyone) starts "pre-emptively filling up slots", there would be a HUGE problem.
Ah, yes, rather. Of course you're more right than right.
To try and dig myself out of this hole I've dug for myself, in my head what I was thinking was that the "unicode maths" area had some empty spaces that were as-yet unfilled but still earmarked for unicode maths.
Now that I think of it, though, I don't recall ever seeing any such empty-but-allocated space before. Must have been hallucinating.
See you soon :)
-- Will
Barbara Beeton
Begin forwarded message:
>> When you use \mathscr, do you *also* use \mathcal in your documents?
>
> Yes, I do, even in the same formula:
>
> {\mathscr D}({\mathcal O}_X)
>
> (for the ring of differential operators on the algebra of functions on a
> scheme X).
Dear all,
I've had a report of a mathematician using both script and calligraphic
letters in his work. (See above.)
and i can find an ams publication that uses
*five* *different* styles of lowercase p with
different meanings. (it was author prepared,
and the fonts were embedded in the pdf file
that was delivered for publication.
This is a bit of a problem for unicode mathematics.
What are the chances of the addition of another maths alphabet into
unicode? (I'm guessing "slim".)
correct. i submitted samples of the publication
in question as evidence, but they felt it was
simply too far out to consider. i tend to agree
with them. the editors here will accept two
styles of script (calligraphic and euler) with
no complaint, but if more are called for, they
will militate for another choice, e.g. fraktur.
of course i can try again, but "slim" is a good
estimate of the likelihood.
I'll add some code to my package to support this sort of usage. Up until
now I've been assuming (as per unicode) that \mathcal and \mathscr are
the same.
unicode has been blind on this. but i've got
a new contact there who might be willing to
take another look. i'll have to dig for
examples. if anyone can provide a published
reference where multiple letters in multiple
scripts -- the same letter meaning different
things in a structured manner -- are used,
that will give me the necessary ammunition.
-- bb
Aditya Mahajan
> if anyone can provide a published
> reference where multiple letters in multiple
> scripts -- the same letter meaning different
> things in a structured manner -- are used,
> that will give me the necessary ammunition.
In my thesis I used caligraphic, RSFS, and fraktur (and blackboard
bold also, if that matters). However, I am not sure if it is a good use
case. I could easily have used bold caligraphic script instead of RSFS.
Aditya
Aditya Mahajan
> the editors here will accept two
> styles of script (calligraphic and euler) with
> no complaint,
Doesn't euler + calligraphic have the same trouble as euler + RSFS:
unicode has only one script. How would you represent two scirpt families
using unicode.
Aditya
Will Robertson
Well, unicode isn't able to represent an entire mathematics document because you still need markup to deal with things like subscripts and superscripts.
So whether or not more maths alphabets get added to unicode I don't see a problem (pragmatically) using different fonts for the two different script alphabets.
-- Will
Ross Moore
For the purposes of printing, and the visual representation,
using different fonts is not a problem.
For the publishers, having extra alphabets in the Private Use area
is probably a good thing --- for them !!! --- since you can have
unique character codes for the letters from the different fonts.
Presumably it makes their *private* archival methods more robust.
However, where it *is* a problem is when you want to represent
the document in a *public* Archival format, or enrich it with
markup to get different visual renderings;
e.g. tagged PDF, for PDF/A or PDF/UA (= ISO32000 )
or conversion to MathML (any version).
Now you may not have fonts at all.
The sup/subscripts do not cause a problem, since there are
standard tags for these: <msup>,<msub>,<msubsup> .
For the same characters in different fonts then there is <mstyle>
but this is really for styles, and isn't meant to require specific
fonts. It cannot require fonts, for some devices won't be designed
to be able to handle them.
And how does one "Read Out Loud" different font faces?
Using Private Use codes resolves this, but creates a different
kind of ambiguity, as those points do not have standardised
meanings.
Thus my original question was whether, upon encountering
documents using these STIX-supported alphabets in the PU codes,
whether conversion software should map these to real Unicode
points. For example, tagged PDF can render a bold script letter,
but should it include /ActualText for a normal math-script one?
>
> -- Will
Hope this helps,
Will Robertson
> However, where it *is* a problem is when you want to represent
> the document in a *public* Archival format, or enrich it with
> markup to get different visual renderings;
> e.g. tagged PDF, for PDF/A or PDF/UA (= ISO32000 )
> or conversion to MathML (any version).
>
> Now you may not have fonts at all.
I agree completely.
It's not at all optimal if the extra glyphs in STIX start being widely used without also being added to unicode.
> Thus my original question was whether, upon encountering
> documents using these STIX-supported alphabets in the PU codes,
> whether conversion software should map these to real Unicode
> points. For example, tagged PDF can render a bold script letter,
> but should it include /ActualText for a normal math-script one?
I don't really feel like I'm qualified to answer this. I would be inclined to think that any PUA symbols fall outside the area of being able to interact with reliably with this sort of thing.
-- Will
Ross Moore
On 28/05/2010, at 3:42 PM, Will Robertson wrote:
> On 28/05/2010, at 2:38 PM, Ross Moore wrote:
>
>> However, where it *is* a problem is when you want to represent
>> the document in a *public* Archival format, or enrich it with
>> markup to get different visual renderings;
>> e.g. tagged PDF, for PDF/A or PDF/UA (= ISO32000 )
>> or conversion to MathML (any version).
>>
>> Now you may not have fonts at all.
>
> I agree completely.
> It's not at all optimal if the extra glyphs in STIX start being
> widely used without also being added to unicode.
>
>
>> Thus my original question was whether, upon encountering
>> documents using these STIX-supported alphabets in the PU codes,
>> whether conversion software should map these to real Unicode
>> points. For example, tagged PDF can render a bold script letter,
>> but should it include /ActualText for a normal math-script one?
>
> I don't really feel like I'm qualified to answer this.
It wasn't meant to be just for you, but the group
as a whole, and possibly beyond. :-)
> I would be inclined to think that any PUA symbols fall outside the
> area of being able to interact with reliably with this sort of thing.
Yes, that is consistent with the Unicode philosophy, as I
understand it. But it remains to be seen what the publishers
will actually produce and distribute.
If they produce PDFs *without* such CMap or /ActualText
replacements, then we could be in for a bad time.
Or maybe this will force the hand of the Unicode maintainers,
since there will be a large (well, decent-sized) and significant
community that will get into the habit of using those extra symbols.
I'd like to see it start off in a *right* way, rather than have
things go piecemeal for awhile, until the standard is extended.