Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

MathML 3.0 Is An International Standard - I Programmer

Source: mathml - Google Blog Search • unknown • July 03, 2015 • Permalink

The story of MathML is not a happy one. It is a good idea - create a markup language for mathematical equations - but for some reason people just don't seem to want to get behind it. Will the new official status of MathML 3.0 ...

Re: update to xml entities draft

Source: www-math@w3.org Mail Archives • William F Hammond (hammond@csc.albany.edu) • July 02, 2015 • Permalink

On 20150627 at 143534-0700 "Asmus Freytag (t)" writes:

> Unicode generally does not encode characters by usage. For
> example there's no distinction between period, decimal
> point, abbreviation point etc.. This reflects the underlying
> situation, to wit, that this is a case of the *same* symbol
> being used in different conventions.
>
> The downside is that it is thus not possible to use plain
> text to capture which convention is intended (but nothing
> prevents anyone from providing rich-text markup). The upside
> is that data can't exhibit "random alternation" between
> identical looking symbols; experience has shown that this is
> a most likely outcome if "the same" item is encoded several
> times, based merely on convention.

Period, decimal point, abbreviation point: three different
names and three different concepts commonly sharing the same
symbol though not necessarily the same left and right
spacing.

As a point of argument (but not a request) they *should* be
three different characters.

Absent that, the typesetter with a proportional font must
use various conventions, not completely reliable, to guess
the spacing.  Of course, commonly the user will be oblivious
of these differences and the user's keyboard will have only
one of these.  But the astute user may want to be able to
make distinctions.  The distinctions can be made available,
for example, in rich text, as you observe, in SGML, or in
LaTeX.

With a given oblivious user and a given typesetting suite
random alternation will not occur.

Other than for searching I fail to see why random
alternation should be a problem.  Are there other problems
associated with random alternation?

As to mathematical searching, searching for mathematical
symbols is an order of magnitude more complicated than
searching for text, e.g., multi-character math symbols,
things like phi vs varphi, ..., so the small number of
possible alternations (at most 256, the size of the U+21xx
block, actually quite a few less than that) should not add
much complexity to code for mathematical symbol searching.

-- Bill


RE: report: iOS9 adds "print to PDF"

Source: public-digipub-ig@w3.org Mail Archives • Bill Kasdorf (bkasdorf@apexcovantage.com) • July 01, 2015 • Permalink

Tons of readers support EPUB 3. See epubtest.org.

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Wednesday, July 01, 2015 3:15 PM
To: Peter Krautzberger
Cc: Bill Kasdorf; Ivan Herman; Larry Masinter; Olaf Drümmer; W3C Digital Publishing IG
Subject: Re: report: iOS9 adds "print to PDF"

Android's book reader supports EPUB3. I have not run an exhaustive analysis  of it compared to Apple's but iBooks does a phenomenal job. My hat is off to Apple. Also Google books are published in EPUB format.

Rich Schwerdtfeger

[Inactive hide details for Peter Krautzberger ---07/01/2015 02:00:56 PM---> Maybe it's a problem that PDF works essentially ever]Peter Krautzberger ---07/01/2015 02:00:56 PM---> Maybe it's a problem that PDF works essentially everywhere, whereas EPUB hardly does?

From: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>
To: Olaf Drümmer <olaf@druemmer.com<mailto:olaf@druemmer.com>>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>>, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Date: 07/01/2015 02:00 PM
Subject: Re: report: iOS9 adds "print to PDF"

________________________________

> Maybe it's a problem that PDF works essentially everywhere, whereas EPUB hardly does?

Well, iOS and OSX ship with a pretty good epub2&3 viewer, iBooks.

> And that PDF could be made to work for people with special needs?

> And how many websites are out there that really use MathML (as opposed to images of formulas with some Alt attached to them).

Many. Anybody who's serious about math and science, really. From STEM publishers like IEEE to platforms like StackExchange, from individual researchers to MOOCs, from educational publishers like Pearson to blogging teachers, from computational software like iPython Notebooks and MatLab to encyclopedias like, well, Wikipedia (thought arguably not yet the default).

> [...] why it's not good enough for 'mobile'.

Because it throws away most of the information; imho, that's fine for printing but not much beyond that.

>  How realistic is it that a sizeable number of users will actually use EPUB3 (including having access to 'real' EPUB3 reading systems, availability publications in EPUB3, and so forth)?

Apple ships a good epub viewer on all products. They also don't seem to care about other platforms, cf. the iBooks Author format.

> why is there no decent, readily available web page to EPUB3 converter at all?

A google search<https://duckduckgo.com/?q=!g+html+to+epub&t=canonical> turns up a few options. Sure they are not perfect, but neither are PDF generators (though arguably those they'll screw up different things). I would say Calibre has comparable (yet different) quality to print-to-pdf from browsers. Perhaps all it takes is an epub equivalent of print stylesheets to improve the situation quickly (though print stylesheets are probably a good start for epub generation, too).

Anyway, I don't have any issue with having a PDF generator around; it just doesn't knock me off my feet.
Peter.

On Wed, Jul 1, 2015 at 8:18 PM, Olaf Drümmer <olaf@druemmer.com<mailto:olaf@druemmer.com>> wrote:
Maybe it's a problem that PDF works essentially everywhere, whereas EPUB hardly does? And that PDF could be made to work for people with special needs? And how many websites are out there that really use MathML (as opposed to images of formulas with some Alt attached to them). If PDF is used on let's say an iPad and the PDF is captured at the same 'form factor' as when it is being displayed on the iPad, I have difficulty seeing why it's not good enough for 'mobile'.

Maybe there should be more considerations of the combination of  relevance AND feasibility? How realistic is it that a sizeable number of users will actually use EPUB3 (including having access to 'real' EPUB3 reading systems, availability publications in EPUB3, and so forth)? PDF does have the advantage of being relatively widely available, serving over 95% of users well enough for all practical purposes. It took PDF over 20 years to get there. Currently EPUB3 is where PDF was ca. 2 or 3 years into its existence. How do we deal with the other 17 years it might need to establish EPUB3 in the same manner?

And: There is one question that really keeps me thinking - and I have yet to find a good / satisfactory answer: why is there no decent, readily available web page to EPUB3 converter at all? Especially if/as EPUB3 could be described as a packaged web page/site… Or am I missing something?  Or is it too early in the game/am I being too impatient?

Olaf

On 1 Jul 2015, at 19:49, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:

They should have done save to EPUB3 as it is packaged. As you point out, PDF is not the best format for mobile. Also IBook author can import EPUB3. From an accessibility perspective it is more than just tagged PDF that is important. It is also access to digital math to allow for alternative renderings for blind, low vision, attention deficit, situational impairments, and dyslexic users.

Print fidelity is nice but, today, it is about supporting a broader range of users and also due to the uptake of mobile devices in education inclusive access is much more important.

Rich Schwerdtfeger

<graycol.gif>Bill Kasdorf ---07/01/2015 12:13:27 PM---Two comments: Yes, it's the structure that's the main issue—and the structure expressed in a standar

From: Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>>
To: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Cc: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: 07/01/2015 12:13 PM
Subject: RE: report: iOS9 adds "print to PDF"

________________________________

Yes, it's the structure that's the main issue—and the structure expressed in a standard way (i.e., HTML5). That's also fundamentally important for accessibility. So "Save as HTML + CSS" is way better than an alternative "save as X" imo, unless the "X" is EPUB 3, which would be optimal.

The other point is that unless I'm not up-to-date on this (and I may not be), I would be cautious about Apple's iBooks Author format because at least wrt the use of Author itself, I believe there are restrictions on how those files can be distributed and sold (e.g., limited to iBooks). I would love to be informed that that's no longer the case.

--Bill K

From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
Sent: Tuesday, June 30, 2015 2:59 AM
To: Larry Masinter; W3C Digital Publishing IG
Cc: Ivan Herman
Subject: Re: report: iOS9 adds "print to PDF"

> Serious question: if it was “Save as HTML + CSS” or “save as X” for
> any other X, would you be less sad, and why?

Top of my list would be epub3,  but Apple's iBooks Author format would make sense.

Given the quality of the website-to-epub generators I've encountered, that seems like a much harder problem. But even a non-optimal solution might provide a better experience than a page-sized PDF on small screen. In combination with something like readability/pocket/etc or "save selection", the content could even shine.

> What data would you have in other formats that you don’t have for PDF?

I suppose that comes down to the quality of the files, i.e., whether they are "plain old" PDFs (glyphs on a canvas) or pdf/a or even using Flash/JS/etc to represent more complex content. Assuming it's just glyphs with positions, then it seems to me almost all markup is lost whereas HTML/CSS-based formats like epub and iBA can retain parts of the original structure.

Don't get me wrong, I understand why one would ship a PDF generator (i.e., for all the usual reasons); but it doesn't stop me from wondering if whoever decided that this is a good feature for mobile devices also thought: "but really, we need a better way".

Peter.

On Tue, Jun 30, 2015 at 12:42 AM, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>> wrote:
Serious question: if it was “Save as HTML + CSS” or “save as X” for
any other X, would you be less sad, and why?

What data would you have in other formats that you don’t have for PDF?

Seriously. It’s really hard to get down to requirements.

On 6/27/15, 8:48 AM, "Ivan Herman" <ivan@w3.org<mailto:ivan@w3.org>> wrote:

Me too...

Ivan

---
Ivan Herman
Tel:+31 641044153<tel:%2B31%20641044153>
http://www.ivan-herman.net<http://www.ivan-herman.net/>

(Written on mobile, sorry for brevity and misspellings...)

On 27 Jun 2015, at 16:15, Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>> wrote:
Just something I came across, https://twitter.com/fakebaldur/status/614794685559742464

Quote: "It’s particularly useful for webpages, since it keeps all the text, and makes it searchable and copyable unlike, say, taking a screenshot."

Peter.



Re: report: iOS9 adds "print to PDF"

Source: public-digipub-ig@w3.org Mail Archives • Richard Schwerdtfeger (schwer@us.ibm.com) • July 01, 2015 • Permalink

Android's book reader supports EPUB3. I have not run an exhaustive analysis
of it compared to Apple's but iBooks does a phenomenal job. My hat is off
to Apple. Also Google books are published in EPUB format.

Rich Schwerdtfeger

From:   Peter Krautzberger <peter.krautzberger@mathjax.org>
To:     Olaf Drümmer <olaf@druemmer.com>
Cc:     Richard Schwerdtfeger/Austin/IBM@IBMUS, Bill Kasdorf
<bkasdorf@apexcovantage.com>, Ivan Herman <ivan@w3.org>, Larry
Masinter <masinter@adobe.com>, W3C Digital Publishing IG
<public-digipub-ig@w3.org>
Date:   07/01/2015 02:00 PM
Subject:        Re: report: iOS9 adds "print to PDF"

> Maybe it's a problem that PDF works essentially everywhere, whereas EPUB
hardly does?

Well, iOS and OSX ship with a pretty good epub2&3 viewer, iBooks.

> And that PDF could be made to work for people with special needs?

> And how many websites are out there that really use MathML (as opposed to
images of formulas with some Alt attached to them).

Many. Anybody who's serious about math and science, really. From STEM
publishers like IEEE to platforms like StackExchange, from individual
researchers to MOOCs, from educational publishers like Pearson to blogging
teachers, from computational software like iPython Notebooks and MatLab to
encyclopedias like, well, Wikipedia (thought arguably not yet the default).

> [...] why it's not good enough for 'mobile'.

Because it throws away most of the information; imho, that's fine for
printing but not much beyond that.

>  How realistic is it that a sizeable number of users will actually use
availability publications in EPUB3, and so forth)?

Apple ships a good epub viewer on all products. They also don't seem to
care about other platforms, cf. the iBooks Author format.

> why is there no decent, readily available web page to EPUB3 converter at
all?

A google search turns up a few options. Sure they are not perfect, but
neither are PDF generators (though arguably those they'll screw up
different things). I would say Calibre has comparable (yet different)
quality to print-to-pdf from browsers. Perhaps all it takes is an epub
equivalent of print stylesheets to improve the situation quickly (though
print stylesheets are probably a good start for epub generation, too).

Anyway, I don't have any issue with having a PDF generator around; it just
doesn't knock me off my feet.
Peter.

On Wed, Jul 1, 2015 at 8:18 PM, Olaf Drümmer <olaf@druemmer.com> wrote:
Maybe it's a problem that PDF works essentially everywhere, whereas EPUB
hardly does? And that PDF could be made to work for people with special
needs? And how many websites are out there that really use MathML (as
opposed to images of formulas with some Alt attached to them). If PDF is
used on let's say an iPad and the PDF is captured at the same 'form
factor' as when it is being displayed on the iPad, I have difficulty
seeing why it's not good enough for 'mobile'.

Maybe there should be more considerations of the combination of
relevance AND feasibility? How realistic is it that a sizeable number of
reading systems, availability publications in EPUB3, and so forth)? PDF
does have the advantage of being relatively widely available, serving
over 95% of users well enough for all practical purposes. It took PDF
over 20 years to get there. Currently EPUB3 is where PDF was ca. 2 or 3
years into its existence. How do we deal with the other 17 years it might
need to establish EPUB3 in the same manner?

And: There is one question that really keeps me thinking - and I have yet
to find a good / satisfactory answer: why is there no decent, readily
available web page to EPUB3 converter at all? Especially if/as EPUB3
could be described as a packaged web page/site… Or am I missing
something?  Or is it too early in the game/am I being too impatient?

Olaf

On 1 Jul 2015, at 19:49, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

They should have done save to EPUB3 as it is packaged. As you point
out, PDF is not the best format for mobile. Also IBook author can
import EPUB3. From an accessibility perspective it is more than
just tagged PDF that is important. It is also access to digital
math to allow for alternative renderings for blind, low vision,
attention deficit, situational impairments, and dyslexic users.

Print fidelity is nice but, today, it is about supporting a broader
range of users and also due to the uptake of mobile devices in
education inclusive access is much more important.

Rich Schwerdtfeger

<graycol.gif>Bill Kasdorf ---07/01/2015 12:13:27 PM---Two comments:
Yes, it's the structure that's the main issue—and the structure
expressed in a standar

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
To: Peter Krautzberger <peter.krautzberger@mathjax.org>, Larry
Masinter <masinter@adobe.com>, W3C Digital Publishing IG <
public-digipub-ig@w3.org>
Cc: Ivan Herman <ivan@w3.org>
Date: 07/01/2015 12:13 PM
Subject: RE: report: iOS9 adds "print to PDF"

Yes, it's the structure that's the main issue—and the structure
expressed in a standard way (i.e., HTML5). That's also
fundamentally important for accessibility. So "Save as HTML + CSS"
is way better than an alternative "save as X" imo, unless the "X"
is EPUB 3, which would be optimal.

The other point is that unless I'm not up-to-date on this (and I
may not be), I would be cautious about Apple's iBooks Author format
because at least wrt the use of Author itself, I believe there are
restrictions on how those files can be distributed and sold (e.g.,
limited to iBooks). I would love to be informed that that's no
longer the case.

--Bill K

From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
Sent: Tuesday, June 30, 2015 2:59 AM
To: Larry Masinter; W3C Digital Publishing IG
Cc: Ivan Herman
Subject: Re: report: iOS9 adds "print to PDF"

> Serious question: if it was “Save as HTML + CSS” or “save as X”
for
> any other X, would you be less sad, and why?

Top of my list would be epub3,  but Apple's iBooks Author format
would make sense.

Given the quality of the website-to-epub generators I've
encountered, that seems like a much harder problem. But even a
non-optimal solution might provide a better experience than a
page-sized PDF on small screen. In combination with something like
readability/pocket/etc or "save selection", the content could even
shine.

> What data would you have in other formats that you don’t have for
PDF?

I suppose that comes down to the quality of the files, i.e.,
whether they are "plain old" PDFs (glyphs on a canvas) or pdf/a or
even using Flash/JS/etc to represent more complex content. Assuming
it's just glyphs with positions, then it seems to me almost all
markup is lost whereas HTML/CSS-based formats like epub and iBA can
retain parts of the original structure.

Don't get me wrong, I understand why one would ship a PDF generator
(i.e., for all the usual reasons); but it doesn't stop me from
wondering if whoever decided that this is a good feature for mobile
devices also thought: "but really, we need a better way".

Peter.

On Tue, Jun 30, 2015 at 12:42 AM, Larry Masinter <
Serious question: if it was “Save as HTML + CSS” or “save as X” for
any other X, would you be less sad, and why?

What data would you have in other formats that you don’t have for
PDF?

Seriously. It’s really hard to get down to requirements.

On 6/27/15, 8:48 AM, "Ivan Herman" <ivan@w3.org> wrote:

Me too...

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)

On 27 Jun 2015, at 16:15, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:
Just something I came across,

Quote: "It’s particularly useful for webpages, since it keeps
all the text, and makes it searchable and copyable unlike,
say, taking a screenshot."

Peter.



RE: report: iOS9 adds "print to PDF"

Source: public-digipub-ig@w3.org Mail Archives • Bill Kasdorf (bkasdorf@apexcovantage.com) • July 01, 2015 • Permalink

In addition to the more detailed comments from Peter (below):

The accessibility community is in general agreement that PDF, even when laboriously enhanced for accessibility (and only a minuscule proportion of PDFs are), does not meet their needs compared to well structured EPUB 3. EPUB 3 was designed in collaboration with that community to be inherently accessible and the DAISY Consortium has standardized on EPUB 3 as the format for the delivery of accessible content.

—Bill Kasdorf

From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
Sent: Wednesday, July 01, 2015 3:00 PM
To: Olaf Drümmer
Cc: Richard Schwerdtfeger; Bill Kasdorf; Ivan Herman; Larry Masinter; W3C Digital Publishing IG
Subject: Re: report: iOS9 adds "print to PDF"

> Maybe it's a problem that PDF works essentially everywhere, whereas EPUB hardly does?

Well, iOS and OSX ship with a pretty good epub2&3 viewer, iBooks.

> And that PDF could be made to work for people with special needs?

> And how many websites are out there that really use MathML (as opposed to images of formulas with some Alt attached to them).

Many. Anybody who's serious about math and science, really. From STEM publishers like IEEE to platforms like StackExchange, from individual researchers to MOOCs, from educational publishers like Pearson to blogging teachers, from computational software like iPython Notebooks and MatLab to encyclopedias like, well, Wikipedia (thought arguably not yet the default).

> [...] why it's not good enough for 'mobile'.

Because it throws away most of the information; imho, that's fine for printing but not much beyond that.

>  How realistic is it that a sizeable number of users will actually use EPUB3 (including having access to 'real' EPUB3 reading systems, availability publications in EPUB3, and so forth)?

Apple ships a good epub viewer on all products. They also don't seem to care about other platforms, cf. the iBooks Author format.

> why is there no decent, readily available web page to EPUB3 converter at all?

A google search<https://duckduckgo.com/?q=!g+html+to+epub&t=canonical> turns up a few options. Sure they are not perfect, but neither are PDF generators (though arguably those they'll screw up different things). I would say Calibre has comparable (yet different) quality to print-to-pdf from browsers. Perhaps all it takes is an epub equivalent of print stylesheets to improve the situation quickly (though print stylesheets are probably a good start for epub generation, too).

Anyway, I don't have any issue with having a PDF generator around; it just doesn't knock me off my feet.
Peter.

On Wed, Jul 1, 2015 at 8:18 PM, Olaf Drümmer <olaf@druemmer.com<mailto:olaf@druemmer.com>> wrote:
Maybe it's a problem that PDF works essentially everywhere, whereas EPUB hardly does? And that PDF could be made to work for people with special needs? And how many websites are out there that really use MathML (as opposed to images of formulas with some Alt attached to them). If PDF is used on let's say an iPad and the PDF is captured at the same 'form factor' as when it is being displayed on the iPad, I have difficulty seeing why it's not good enough for 'mobile'.

Maybe there should be more considerations of the combination of  relevance AND feasibility? How realistic is it that a sizeable number of users will actually use EPUB3 (including having access to 'real' EPUB3 reading systems, availability publications in EPUB3, and so forth)? PDF does have the advantage of being relatively widely available, serving over 95% of users well enough for all practical purposes. It took PDF over 20 years to get there. Currently EPUB3 is where PDF was ca. 2 or 3 years into its existence. How do we deal with the other 17 years it might need to establish EPUB3 in the same manner?

And: There is one question that really keeps me thinking - and I have yet to find a good / satisfactory answer: why is there no decent, readily available web page to EPUB3 converter at all? Especially if/as EPUB3 could be described as a packaged web page/site… Or am I missing something?  Or is it too early in the game/am I being too impatient?

Olaf

On 1 Jul 2015, at 19:49, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:

They should have done save to EPUB3 as it is packaged. As you point out, PDF is not the best format for mobile. Also IBook author can import EPUB3. From an accessibility perspective it is more than just tagged PDF that is important. It is also access to digital math to allow for alternative renderings for blind, low vision, attention deficit, situational impairments, and dyslexic users.

Print fidelity is nice but, today, it is about supporting a broader range of users and also due to the uptake of mobile devices in education inclusive access is much more important.

Rich Schwerdtfeger

<graycol.gif>Bill Kasdorf ---07/01/2015 12:13:27 PM---Two comments: Yes, it's the structure that's the main issue—and the structure expressed in a standar

From: Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>>
To: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Cc: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: 07/01/2015 12:13 PM
Subject: RE: report: iOS9 adds "print to PDF"
________________________________

Yes, it's the structure that's the main issue—and the structure expressed in a standard way (i.e., HTML5). That's also fundamentally important for accessibility. So "Save as HTML + CSS" is way better than an alternative "save as X" imo, unless the "X" is EPUB 3, which would be optimal.

The other point is that unless I'm not up-to-date on this (and I may not be), I would be cautious about Apple's iBooks Author format because at least wrt the use of Author itself, I believe there are restrictions on how those files can be distributed and sold (e.g., limited to iBooks). I would love to be informed that that's no longer the case.

--Bill K

From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
Sent: Tuesday, June 30, 2015 2:59 AM
To: Larry Masinter; W3C Digital Publishing IG
Cc: Ivan Herman
Subject: Re: report: iOS9 adds "print to PDF"

> Serious question: if it was “Save as HTML + CSS” or “save as X” for
> any other X, would you be less sad, and why?

Top of my list would be epub3,  but Apple's iBooks Author format would make sense.

Given the quality of the website-to-epub generators I've encountered, that seems like a much harder problem. But even a non-optimal solution might provide a better experience than a page-sized PDF on small screen. In combination with something like readability/pocket/etc or "save selection", the content could even shine.

> What data would you have in other formats that you don’t have for PDF?

I suppose that comes down to the quality of the files, i.e., whether they are "plain old" PDFs (glyphs on a canvas) or pdf/a or even using Flash/JS/etc to represent more complex content. Assuming it's just glyphs with positions, then it seems to me almost all markup is lost whereas HTML/CSS-based formats like epub and iBA can retain parts of the original structure.

Don't get me wrong, I understand why one would ship a PDF generator (i.e., for all the usual reasons); but it doesn't stop me from wondering if whoever decided that this is a good feature for mobile devices also thought: "but really, we need a better way".

Peter.

On Tue, Jun 30, 2015 at 12:42 AM, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>> wrote:
Serious question: if it was “Save as HTML + CSS” or “save as X” for
any other X, would you be less sad, and why?

What data would you have in other formats that you don’t have for PDF?

Seriously. It’s really hard to get down to requirements.

On 6/27/15, 8:48 AM, "Ivan Herman" <ivan@w3.org<mailto:ivan@w3.org>> wrote:

Me too...

Ivan

---
Ivan Herman
Tel:+31 641044153<tel:%2B31%20641044153>
http://www.ivan-herman.net<http://www.ivan-herman.net/>

(Written on mobile, sorry for brevity and misspellings...)

On 27 Jun 2015, at 16:15, Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>> wrote:
Just something I came across, https://twitter.com/fakebaldur/status/614794685559742464

Quote: "It’s particularly useful for webpages, since it keeps all the text, and makes it searchable and copyable unlike, say, taking a screenshot."

Peter.



Re: report: iOS9 adds "print to PDF"

Source: public-digipub-ig@w3.org Mail Archives • Richard Schwerdtfeger (schwer@us.ibm.com) • July 01, 2015 • Permalink

Well, here we go.

PDF - you need to pinch and squeeze your way through a document. It is a

The reason we have not seen taken off on the web is a chicken and egg
problem:

- No good integration of Math support in authoring tools
- Inconsistent browser support.
- Because of the two above people don't author in MathML they stick an
inaccessible bitmap out for people.

So,

Authoring tools are now starting to integrate MathML authoring support.
Namo Author is one. I am on their technical advisory board. This will make
it easier for teachers to produce digital math.

Many think that alternative text is adequate. It is not. Research has shown
that providing the ability to navigate a digital math equation, with the
keyboard while having the symbols, etc. highlighted and spoken, results in
math comprehension going up across the board by 10-15%. For Attention
deficit and dyslexia, for which the numbers far exceed blind access, this
is essential functionality.

Benetech is working now to create a cloud reader that will take a MathML
equation and allow you to navigate it and have it rendered with multiple
vendors on Windows, Linux, and Mac are adding more support for MathML.

Let's forget public web pages for a minute. Think about digital books and
online courses that you typically don't run through on the broader web. The
pieces are coming together now. Education would really benefit from a boost
in math comprehension.
All IBM documentation today can be published as EPUB3. Some links:
- http://asmarterplanet.com/blog/2014/02/epub-mobile.html

When you get to Asia Pacific EPUB is the book standard - there is no
Amazon. In South Korea all education material must be published in EPUB
format. The education space in the US is converging on EPUB as well.

On April 2nd I was speaking at Harvard on global accessibility trends and
spoke with the Harvard Vice Provos Bols. There was an ADA Title 3
settlement that day on edX that involved educational content delivered to
Harvard and MIT. Please take a look at section 18 and the reference to
EPUB3:
http://www.justice.gov/sites/default/files/opa/press-releases/attachments/2015/04/02/edx_settlement_agreement.pdf

This is not going to take 17 years and frankly things progress much faster
today than they did 17 years ago.

Rich

Rich Schwerdtfeger

From:   Olaf Drümmer <olaf@druemmer.com>
To:     Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:     Olaf Drümmer <olaf@druemmer.com>, Bill Kasdorf
<bkasdorf@apexcovantage.com>, Ivan Herman <ivan@w3.org>, Larry
<peter.krautzberger@mathjax.org>, W3C Digital Publishing IG
<public-digipub-ig@w3.org>
Date:   07/01/2015 01:18 PM
Subject:        Re: report: iOS9 adds "print to PDF"

Maybe it's a problem that PDF works essentially everywhere, whereas EPUB
hardly does? And that PDF could be made to work for people with special
needs? And how many websites are out there that really use MathML (as
opposed to images of formulas with some Alt attached to them). If PDF is
used on let's say an iPad and the PDF is captured at the same 'form factor'
as when it is being displayed on the iPad, I have difficulty seeing why
it's not good enough for 'mobile'.

Maybe there should be more considerations of the combination of  relevance
AND feasibility? How realistic is it that a sizeable number of users will
systems, availability publications in EPUB3, and so forth)? PDF does have
the advantage of being relatively widely available, serving over 95% of
users well enough for all practical purposes. It took PDF over 20 years to
get there. Currently EPUB3 is where PDF was ca. 2 or 3 years into its
existence. How do we deal with the other 17 years it might need to
establish EPUB3 in the same manner?

And: There is one question that really keeps me thinking - and I have yet
to find a good / satisfactory answer: why is there no decent, readily
available web page to EPUB3 converter at all? Especially if/as EPUB3 could
be described as a packaged web page/site… Or am I missing something?  Or is
it too early in the game/am I being too impatient?

Olaf

On 1 Jul 2015, at 19:49, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

They should have done save to EPUB3 as it is packaged. As you point
out, PDF is not the best format for mobile. Also IBook author can
import EPUB3. From an accessibility perspective it is more than just
tagged PDF that is important. It is also access to digital math to
allow for alternative renderings for blind, low vision, attention
deficit, situational impairments, and dyslexic users.

Print fidelity is nice but, today, it is about supporting a broader
range of users and also due to the uptake of mobile devices in
education inclusive access is much more important.

Rich Schwerdtfeger

<graycol.gif>Bill Kasdorf ---07/01/2015 12:13:27 PM---Two comments:
Yes, it's the structure that's the main issue—and the structure
expressed in a standar

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
To: Peter Krautzberger <peter.krautzberger@mathjax.org>, Larry
Masinter <masinter@adobe.com>, W3C Digital Publishing IG <
public-digipub-ig@w3.org>
Cc: Ivan Herman <ivan@w3.org>
Date: 07/01/2015 12:13 PM
Subject: RE: report: iOS9 adds "print to PDF"

Yes, it's the structure that's the main issue—and the structure
expressed in a standard way (i.e., HTML5). That's also fundamentally
important for accessibility. So "Save as HTML + CSS" is way better
than an alternative "save as X" imo, unless the "X" is EPUB 3, which
would be optimal.

The other point is that unless I'm not up-to-date on this (and I may
not be), I would be cautious about Apple's iBooks Author format
because at least wrt the use of Author itself, I believe there are
restrictions on how those files can be distributed and sold (e.g.,
limited to iBooks). I would love to be informed that that's no longer
the case.

--Bill K

From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
Sent: Tuesday, June 30, 2015 2:59 AM
To: Larry Masinter; W3C Digital Publishing IG
Cc: Ivan Herman
Subject: Re: report: iOS9 adds "print to PDF"

> Serious question: if it was “Save as HTML + CSS” or “save as X” for
> any other X, would you be less sad, and why?

Top of my list would be epub3,  but Apple's iBooks Author format
would make sense.

Given the quality of the website-to-epub generators I've encountered,
that seems like a much harder problem. But even a non-optimal
solution might provide a better experience than a page-sized PDF on
small screen. In combination with something like
readability/pocket/etc or "save selection", the content could even
shine.

> What data would you have in other formats that you don’t have for
PDF?

I suppose that comes down to the quality of the files, i.e., whether
they are "plain old" PDFs (glyphs on a canvas) or pdf/a or even using
Flash/JS/etc to represent more complex content. Assuming it's just
glyphs with positions, then it seems to me almost all markup is lost
whereas HTML/CSS-based formats like epub and iBA can retain parts of
the original structure.

Don't get me wrong, I understand why one would ship a PDF generator
(i.e., for all the usual reasons); but it doesn't stop me from
wondering if whoever decided that this is a good feature for mobile
devices also thought: "but really, we need a better way".

Peter.

On Tue, Jun 30, 2015 at 12:42 AM, Larry Masinter <masinter@adobe.com>
wrote:
Serious question: if it was “Save as HTML + CSS” or “save as X” for
any other X, would you be less sad, and why?

What data would you have in other formats that you don’t have for
PDF?

Seriously. It’s really hard to get down to requirements.

On 6/27/15, 8:48 AM, "Ivan Herman" <ivan@w3.org> wrote:

Me too...

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)

On 27 Jun 2015, at 16:15, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:
Just something I came across,

Quote: "It’s particularly useful for webpages, since it keeps
all the text, and makes it searchable and copyable unlike, say,
taking a screenshot."

Peter.



Re: report: iOS9 adds "print to PDF"

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • July 01, 2015 • Permalink

> Maybe it's a problem that PDF works essentially everywhere, whereas EPUB
hardly does?

Well, iOS and OSX ship with a pretty good epub2&3 viewer, iBooks.

> And that PDF could be made to work for people with special needs?

> And how many websites are out there that really use MathML (as opposed to
images of formulas with some Alt attached to them).

Many. Anybody who's serious about math and science, really. From STEM
publishers like IEEE to platforms like StackExchange, from individual
researchers to MOOCs, from educational publishers like Pearson to blogging
teachers, from computational software like iPython Notebooks and MatLab to
encyclopedias like, well, Wikipedia (thought arguably not yet the default).

> [...] why it's not good enough for 'mobile'.

Because it throws away most of the information; imho, that's fine for
printing but not much beyond that.

>  How realistic is it that a sizeable number of users will actually use
availability publications in EPUB3, and so forth)?

Apple ships a good epub viewer on all products. They also don't seem to
care about other platforms, cf. the iBooks Author format.

> why is there no decent, readily available web page to EPUB3 converter at
all?

up a few options. Sure they are not perfect, but neither are PDF generators
(though arguably those they'll screw up different things). I would say
Calibre has comparable (yet different) quality to print-to-pdf from
browsers. Perhaps all it takes is an epub equivalent of print stylesheets
to improve the situation quickly (though print stylesheets are probably a
good start for epub generation, too).

Anyway, I don't have any issue with having a PDF generator around; it just
doesn't knock me off my feet.
Peter.

On Wed, Jul 1, 2015 at 8:18 PM, Olaf Drümmer <olaf@druemmer.com> wrote:

> Maybe it's a problem that PDF works essentially everywhere, whereas EPUB
> hardly does? And that PDF could be made to work for people with special
> needs? And how many websites are out there that really use MathML (as
> opposed to images of formulas with some Alt attached to them). If PDF is
> used on let's say an iPad and the PDF is captured at the same 'form factor'
> as when it is being displayed on the iPad, I have difficulty seeing why
> it's not good enough for 'mobile'.
>
> Maybe there should be more considerations of the combination of  relevance
> AND feasibility? How realistic is it that a sizeable number of users will
> systems, availability publications in EPUB3, and so forth)? PDF does have
> the advantage of being relatively widely available, serving over 95% of
> users well enough for all practical purposes. It took PDF over 20 years to
> get there. Currently EPUB3 is where PDF was ca. 2 or 3 years into its
> existence. How do we deal with the other 17 years it might need to
> establish EPUB3 in the same manner?
>
> And: There is one question that really keeps me thinking - and I have yet
> to find a good / satisfactory answer: why is there no decent, readily
> available web page to EPUB3 converter at all? Especially if/as EPUB3 could
> be described as a packaged web page/site… Or am I missing something?  Or is
> it too early in the game/am I being too impatient?
>
> Olaf
>
>
> On 1 Jul 2015, at 19:49, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
>
> They should have done save to EPUB3 as it is packaged. As you point out,
> PDF is not the best format for mobile. Also IBook author can import EPUB3.
> From an accessibility perspective it is more than just tagged PDF that is
> important. It is also access to digital math to allow for alternative
> renderings for blind, low vision, attention deficit, situational
> impairments, and dyslexic users.
>
> Print fidelity is nice but, today, it is about supporting a broader range
> of users and also due to the uptake of mobile devices in education
> inclusive access is much more important.
>
>
> Rich Schwerdtfeger
>
> <graycol.gif>Bill Kasdorf ---07/01/2015 12:13:27 PM---Two comments: Yes,
> it's the structure that's the main issue—and the structure expressed in a
> standar
>
>
> From: Bill Kasdorf <bkasdorf@apexcovantage.com>
> To: Peter Krautzberger <peter.krautzberger@mathjax.org>, Larry Masinter <
> masinter@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
> Cc: Ivan Herman <ivan@w3.org>
> Date: 07/01/2015 12:13 PM
> Subject: RE: report: iOS9 adds "print to PDF"
>
> ------------------------------
>
>
>
>
> Yes, it's the structure that's the main issue—and the structure expressed
> in a standard way (i.e., HTML5). That's also fundamentally important for
> accessibility. So "Save as HTML + CSS" is way better than an alternative
> "save as X" imo, unless the "X" is EPUB 3, which would be optimal.
>
> The other point is that unless I'm not up-to-date on this (and I may not
> be), I would be cautious about Apple's iBooks Author format because at
> least wrt the use of Author itself, I believe there are restrictions on how
> those files can be distributed and sold (e.g., limited to iBooks). I would
> love to be informed that that's no longer the case.
>
> --Bill K
>
> *From:* Peter Krautzberger [mailto:peter.krautzberger@mathjax.org
> <peter.krautzberger@mathjax.org>]
> * Sent:* Tuesday, June 30, 2015 2:59 AM
> * To:* Larry Masinter; W3C Digital Publishing IG
> * Cc:* Ivan Herman
> * Subject:* Re: report: iOS9 adds "print to PDF"
>
> > Serious question: if it was “Save as HTML + CSS” or “save as X” for
> > any other X, would you be less sad, and why?
>
> Top of my list would be epub3,  but Apple's iBooks Author format would
> make sense.
>
> Given the quality of the website-to-epub generators I've encountered, that
> seems like a much harder problem. But even a non-optimal solution might
> provide a better experience than a page-sized PDF on small screen. In
> combination with something like readability/pocket/etc or "save selection",
> the content could even shine.
>
> > What data would you have in other formats that you don’t have for PDF?
>
> I suppose that comes down to the quality of the files, i.e., whether they
> are "plain old" PDFs (glyphs on a canvas) or pdf/a or even using
> Flash/JS/etc to represent more complex content. Assuming it's just glyphs
> with positions, then it seems to me almost all markup is lost whereas
> HTML/CSS-based formats like epub and iBA can retain parts of the original
> structure.
>
> Don't get me wrong, I understand why one would ship a PDF generator (i.e.,
> for all the usual reasons); but it doesn't stop me from wondering if
> whoever decided that this is a good feature for mobile devices also
> thought: "but really, we need a better way".
>
> Peter.
>
>
>
> On Tue, Jun 30, 2015 at 12:42 AM, Larry Masinter <*masinter@adobe.com*
> Serious question: if it was “Save as HTML + CSS” or “save as X” for
> any other X, would you be less sad, and why?
>
> What data would you have in other formats that you don’t have for PDF?
>
> Seriously. It’s really hard to get down to requirements.
>
>
> On 6/27/15, 8:48 AM, "Ivan Herman" <*ivan@w3.org* <ivan@w3.org>> wrote:
>
> Me too...
>
> Ivan
>
> ---
> Ivan Herman
> Tel:*+31 641044153* <%2B31%20641044153>
> *http://www.ivan-herman.net* <http://www.ivan-herman.net/>
>
> (Written on mobile, sorry for brevity and misspellings...)
>
>
>
> On 27 Jun 2015, at 16:15, Peter Krautzberger <
> *peter.krautzberger@mathjax.org* <peter.krautzberger@mathjax.org>> wrote:
>
>    Just something I came across,
>
>    Quote: "It’s particularly useful for webpages, since it keeps all the
>    text, and makes it searchable and copyable unlike, say, taking a
>    screenshot."
>
>    Peter.
>
>
>
>
>


American Physical Society continues as MathJax Supporter

Source: MathJax • July 01, 2015 • Permalink

The American Physical Society (APS) continues to support the MathJax project as a MathJax Supporter.

Founded in 1899, the American Physical Society (APS) is the world’s largest organization of physicists and involved in several activities to advance and diffuse the knowledge of physics, including a strong publication program with landmark titles such as Physical Review Letters, the Physical Review journals, and Reviews of Modern Physics. As an influential supporter of SGML-based math notation in the 1990s and an early adopter of MathML, the APS has long been furthering innovation in academic communication.

“This past year we were able to create a high-quality, HTML rendering of our journal articles, which are often math intensive. MathJax along with the web version of the STIX fonts created by the MathJax team are key pieces of the implementation.”, said Mark Doyle, Chief Information Officer, American Physical Society. “After many years of work, it is gratifying to see the MathJax, JATS XML, and STIX efforts come together so seamlessly. MathJax also works quite well with our website’s respocd cnsive design for a first rate mobile experience.”

“Thanks to the dedication of sponsors such as APS, MathJax continues to deliver a reliable, high-quality solution for math and science on the web.”, comments Peter Krautzberger, MathJax manager. “As one of the original MathJax sponsors, APS’s support and feedback keeps pushing our development at MathJax forward.”

We look forward to continuing the collaboration with APS, and welcome their ongoing support for the MathJax project.

W3C MathML 3.0 Gets Approval as ISO/IEC International Standard

Source: Ask.com News Search for "mathml" • June 30, 2015 • Permalink

 Individual.com - Found Jun. 30, 2015 ... approval of the MathML Version 3.0 2nd Edition as an ISO/IEC International Standard (ISO/IEC 40314:2015). According to a release, MathML is...

eWebEditor integrates MathFlow

Source: Design Science News • Aaron Guigar • June 29, 2015 • Permalink

Design Science has partnered with eWebSoft, the makers of eWebEditor. eWebEditor is a Chinese WYSIWYG HTML editor that can be added to web-based tools. Developers who choose eWebEditor will give their users a configurable HTML editor with the ability to author equations using MathFlow

eWebSoft's clients include online assessment systems and learning management systems that need to properly edit mathematical content in lessons and tests. The users of this software are familiar with copying equations from Design Science's MathType software, but this integration with MathFlow will make the addition of math to websites a more seamless experience.

Would you like to give it a try? You can demo MathFlow with the eWebEditor at http://www.ewebeditor.net/math/

Topics in this post:

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • June 29, 2015 • Permalink

FYI I worked in my comments, added two lines, and unfortunately added more

Peter

On Fri, Jun 26, 2015 at 8:55 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

> > I’ve responded to a few more of the comments in the google sheet.
>
> Thanks so much Dave!
>
> > I would encourage you to edit the math-related bits as you see fit, as
> your knowledge of this area is at least a billion times greater than my
> own.
>
> Mmm, not so sure ;-) I guess since it is a list of CSS issues pointing to
> MathML does not always seem right, e.g., pointing to element-based
> mlabeldtr seems off when I hear about future CSS counters work. Then again,
> MathML includes copious amounts of styling ability (but that's a different
> discussion).
>
> Peter.
>
> On Thu, Jun 25, 2015 at 3:59 PM, Dave Cramer <dauwhe@gmail.com> wrote:
>
>> On Thu, Jun 25, 2015 at 3:15 AM, Peter Krautzberger <
>> peter.krautzberger@mathjax.org> wrote:
>> >
>> > @Dave I'm not sure how best to incorporate the comments I've left in
>> the google sheet. Could I get some review before I edit the sheet itself?
>>
>> Hi Peter,
>>
>> I’ve responded to a few more of the comments in the google sheet. I would
>> encourage you to edit the math-related bits as you see fit, as your
>> knowledge of this area is at least a billion times greater than my own.
>>
>> It sounds like getting all the cross-reference stuff in GCPM [1] would be
>> helpful. And getting CSSWG to finally write a table spec ;)
>>
>> Thanks!
>>
>> Dave
>>
>> [1] http://dev.w3.org/csswg/css-gcpm/#cross-references
>>
>>
>>
>


[Minutes] 2015-06-29 Digital Publishing Interest Group Teleconference

Source: public-digipub-ig@w3.org Mail Archives • Thierry MICHEL (tmichel@w3.org) • June 29, 2015 • Permalink

Hi all,

The minutes of the Digital Publishing Interest Group Teleconference
dated 2015-06-29 are now available at

http://www.w3.org/2015/06/29-dpub-minutes.html

These public minutes are also linked from the dpub wiki
http://www.w3.org/dpub/IG/wiki/Meetings

Also find these minutes in a text version following, for your convenience.

Best,

Thierry Michel

___________________________________________________________

[1]W3C

[1] http://www.w3.org/

Digital Publishing Interest Group Teleconference

29 Jun 2015

[2]Agenda

[2]
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0138.html

[3] http://www.w3.org/2015/06/29-dpub-irc

Attendees

Present
Ivan Herman, Nick Ruffilo, Toru Kawakubo, Dave Cramer,
Tzviya Siegman, Peter Krautzberger, Charles Clapierre,
Luc Audrain, Brady Duga, Alan Stearns, Ben De Meester,
Deborah Kaplan, Heather Flanagan, Liam Quin, Bert Boss,
Thierry Michel.

Regrets
Bill Kasdorf, Julie Morris, Ayla Stein.

Chair
Tzviya

Scribe
NickRuffilo

Contents

* [4]Topics
1. [5]CSS Prioritization
2. [6]changes to white paper
* [7]Summary of Action Items
__________________________________________________________

<trackbot> Date: 29 June 2015

<scribe> scribenick: NickRuffilo

<laudrain> present_ Luc

<HeatherF> Mute early, mute often.

<tzviya> [8]http://www.w3.org/2015/06/22-dpub-minutes.html

[8] http://www.w3.org/2015/06/22-dpub-minutes.html

Tzviya: "any comments on minutes for last week?"

<pkra> +1

<HeatherF> Sorry I missed it

Tzviya: "Silence is golden - the minutes from last week
are..... APPROVED!"
... "Web Annotations Update"

topic Web Annonations Update

<tzviya> [9]http://www.w3.org/annotation/

[9] http://www.w3.org/annotation/

Ivan: "as you know the group was created after a workshop. We
have no quite a good mix of publishers and web-application
developers. That's a good things. part of the good is semantic
web - some are the more 'geeky' web developers. Contact is
going OK - but they think different (tm)"

<ivan> [10]http://w3c.github.io/web-annotation/model/wd/
...: "There are no issues, that's just the dynamics. As you may
know, the group started with a specific specification that
wasn't a W3C standard - but was created by a community group -
the open annotations community group. They had a pretty
complete specification. That was the main input for the work
there. That work is the annotation data model. The way
annotations are represented when

[10] http://w3c.github.io/web-annotation/model/wd/

moving to different systems. There was a first working draft
that was published."

ivan: "That document is mostly the same as the community draft.
Biggest difference is that this is based less on semantic web
and TTL (one of the usual languages used for semantic web) and
it has been translated into JSON - and it has both, so it lets
you choose how you'd like to read it. There were some minor
changes."

<ivan> [11]http://w3c.github.io/web-annotation/protocol/wd/
...: "There is a documentation called Web Annotations Protocol
(linked above). it's in a fairly good state and we hope to have
it out in the first working draft in 1-2 weeks. It's actually a
document that is based on a recommendation that was recently
published at W3C the LDP (linked data protocol) which looked at
how you transfer this types of data over HTTP and store them,
retrieve them, etc
. Fairly minor specification on top of the existing protocol."

[11] http://w3c.github.io/web-annotation/protocol/wd/

<ivan> [12]http://w3c.github.io/web-annotation/api/rangefinder/
...: " The 3rd document that is in prep that we hope will be a
draft within a few weeks is the Rangefinder API, which comes
closer and closer to the things we've discussed. The issues is
how do you define a range or a sequence of characters, or place
in a document to which you can attach some annotations - so you
can also change, so it's relatively stable to changes to the
document as a whole
. It's currently and API for Javascript - mainly for JS
applications that are running on the client. But it has issues
on JS level things on how you can get the text of a selection,
and find it in a document... If you look at the document itself
it's full of alot of issues. It needs a lot of work."
...: "Once this rangefinder is specified, there should be some
sort of URI or serialization of it, so I can define it in terms
of URI, or fragment ID."
... "There are lots of discussions on various use cases and
technical details. There are directions that have been raised
that we still don't know if we'll do more. Still not sure if we
want to define and API in Javascript. I don't know if this will
be defined. It is still something we have to look at. The other
thing that is regularly coming up - the annotation data model
is JSON or Turtle
. Implementation will be JSON, but there are discussions on
whether there is an HTML serialization of the model..."
...: "The way it could be used is that a client could add such
elements into the DOM tree. Since it's in terms of the DOM, it
can be styled easily in general - which is probably something
very useful. Whether this would be done using existing elements
or whether it would be done as an extension to HTML is unknown.
We haven't had any serious discussions on it yet."
... "We have some overlaps - which is good. Bill K is regularly
on the call. Rob Sanderson will hopefully come back soon..."

[12] http://w3c.github.io/web-annotation/api/rangefinder/

<HeatherF> I can hear folks just fine, ivan included

<pkra> me too.

<tzviya>
[13]https://www.w3.org/annotation/wiki/Use_Cases#Use_Cases_by_t
he_Web_Annotation_Working_Group

[13]
https://www.w3.org/annotation/wiki/Use_Cases#Use_Cases_by_the_Web_Annotation_Working_Group

Tzviya: "From my perspective - what is happening in my
day-to-day - my colleague is attending the annotation meetings.
There are topics we are both discussing. Issues liek fragment
identifier come up, and it may be helpful for everyone to
discuss the overlaps. The use-cases that the WG put together
would be useful. The copy-edit use-case for example."

<Zakim> liam, you wanted to discuss quick note on copy/edi use
case

Liam: "This relates to copy-edit use-case. There is a
change-markup working group. They implemented the open-office
using open markup - may be worth considering what they do."

<liam> [14]https://www.w3.org/community/change/

[14] https://www.w3.org/community/change/

Tzviya: "Idea is to keep the work we are doing in sync. make
sure we're aware of what everyone is working on."

CSS Prioritization

<liam> (I think that is right; DeltaXML has offered their
technology to W3C)

<tzviya>
[15]https://lists.w3.org/Archives/Public/public-digipub-ig/2015
Jun/0091.html

[15]
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0091.html

xh7K8anmJ5c0-OFEG7w0LHYM/edit?usp=sharing

[16]

Tzivya: "Dave has put together a list of CSS priorities."

<dauwhe> The start of a more expository version:
[17]http://w3c.github.io/dpub-pagination/priorities.html
...: "We can spend some time today work on the priorities
list."
... "Thank you dave - this is the thing we really need to send
to the CSS working group

[17] http://w3c.github.io/dpub-pagination/priorities.html

<pkra> I'm here.
...: "It's STARTING in google docs for easy and quick edits -
but we're doing an HTML doc in github as well"

<pkra> (not sure my mic works though)

Dave: "I think some of this may end up merging with latinReq so
i'm still figuring out the best way to collect and display this
information"

<pkra> mpf

<pkra> will dial-in again.

<laudrain> +q

Luc: "I was just wondering why footnotes is #3? Is it because

<pkra> liam I did "Present+ pkra"

<pkra> I'm doa;e

<pkra> (please pignore my single-handed typing)

Dave: "Right now it's mostly a print feature and I'm not sure
there is consensus that it works within digial publishing.
Within paged media I'm not sure there is a reason to display
footnotes as they do in print. It's a feature that's incredibly
difficult to spec. We are a long way from having interest for
implementations. It will have to be a lot of lower level
features - and it is a

problematic area."

Luc: "if we treat footnotes as we do in paper, it could be
complex, but if we treat it as a place where we treat it
differently in digital - it comes down to spec."

Tzviya: "That's an issue for semantics of HTML, not for CSS. "

Luc: "Do we really want footnotes to display at the bottom of
the page in digital?"

DavE: "people are doing tons of things in HTML. There are
popups, and all sorts of renderings. In open-web, we can do
many renderings, but the bottom of a page is not really
possible. Until there are some specific display-mode that
people agree on, it may be a bit pre-mature. i'm not sure what
we would do right now, besides saying "we want displays at the
bottom of the page." that would

need new CSS or markup."

Peter: "How far the MathML spec is a reasonable reference? I
suppose there is an open problem of MathML and CSS in general -
and the reality of it in implementations... How useful is the
MathML reference?"

<pkra> sry'

Dave: "Basically we're unsure how it will introduce it. For the
spreadsheet - this isn't what we'll do when we finally present
it. for each of the math issues - we have different points for
different sections of the spec. We know much exists in the
MathML spec. For the spreadsheet - spell out what items you
want and why (specifics). We'll get to the politics later on."

<Zakim> liam, you wanted to note a tablet sized reader with
visible footnotes could be a killer feature in education,
should be based onuser choice not on CSS and javascript

Liam: "The spreadsheet is great - another aspect is what should
be under USER control and what should be publisher control. You
may also want to say 'i want to see footnotes at the bottom of
the screen' If footnotes are marked up, the readers will have
the ability to let the users choose. We should bear that in
mind."
... 'User style sheets are a low-level thing. No user in the
planet is capable of writing it, so it becomes the job of the
user-agent. This is more global.'

ability for the user to do interesting things. User-stylesheet
is probably not the right word."

<liam> [e.g. "display footnotes at bottom of screen" depends on
footnotes being marked up in the text]

Peter: "I think actual work needs to happen between MathML and
HTML/CSS is equations. How far is it appropriate to link to the
mathML spec as a solution to the problem when they are supposed
to be CSS problems."

<pkra> thx

Dave: "Linking to MathML is perfectly appropriate. It is a spec
that has a solution to a particular problem - even if in a
different space.
...: "Going back to user-control over styling. I see that as a
huge issue, on the scale of being it's own task force, I don't
think it has been explored nearly enough. My sense is that that
is the model that CSS was built on and it's entirely inadequate
- and we need to think about that area."

+1

<tzviya> +1

<astearns> +1 to more discussion on user customization - the
discussion usually ends on "not user stylesheets" and needs to
progress past that

Tzviya: "we should not hesitate at ALL on commenting - this is
... "Think of it as a brainstorming thing - priority is hard to
assign and I think dave has done a good job so far with
priorities, if you have input, dave would appreciate it. If
things are missing, throw them in. We also need to figure out
what to do NEXT with the document. And how we bring it up to
our friends."

Dave: "If we have more priorities - more things we want but
don't have - after that it is alot of wordsmitthing and
information and such."
... "Input on priorities is greatly appreciated. I found some
recurring themes. And posted on twitter..."

Ivan: "Let's remember how we started with this current round.
It started because there was a disconnect between DPUB and CSS
WG - and CSS had a false impression that the DPUB community
doesn't have anything to ask for - we're all happy with
problems solved!"
...: "What this table shows is that this is not true. What we
want to show is to see what is the most helpful for the CSS
working group to influence the way the CSS working group
evolves so that everyone is equally happy. Not sure we should
go back into our corner for half a year. we should see this as
a continuous discussion."

Bert: "Hard to say what the BEST approach is, but probably good
to have some people meet at the fence. To get to the
prioirities - you'd need a champion who can talk to people -
alan, dave, myself. Try to get those people to speak up at the
CSS working group. People can read the documents, but you need
someone to explain them in a nice voice

Ivan: "We did have the idea - chris offered to come to this
call at some point - more interested in pagination that
houdini, etc. We could invite daniel glazman, etc. Would be
good to have regular contact"

Nick: "Might be worth a read-through of EPUB3 spec and Apple
Spec"

Dave: "Most of what we've discussed are in multiple specs - so
one of our big task is leaning on browser vendors to actually
implement these things."
... "The CSS working group might not be the only working group
to do that."

Not just browsers - also ereading platforms

Ivan: "We should separate features that land on CSS working
group and features that are just about implementation by

<laudrain> Sorry, have to quit

Dave: "Ways of structuring that are evolved - I've been trying
to have a category for 'things that need spec' 'things that
have been spec'd but need implementation' ..."

Tzviya: "We have a few tasks in front - items we're asking for,
and from whom we're making the request. Our immediate goal is
to list the items we're asking for. Then what to do next is a
little more complicated. Not alot of support for
implementation. We need it written up and fairly quickly."

<HeatherF> Yes
...: "Everyone get comments in by end of the week. Is that
enough time for the first draft?"

+1

<HeatherF> :-D
...: "In the following weeks we'll work towards documentation."

Liam: "When i get a chance, I'll add the properties in XSL-FO
that aren't yet in CSS"

Charles: "In reviewing the document - I see accessibility -
it's blank right now. Isn't that a big issue?"
... "With screen-readers and hyphenation - getting that
working..."

Dave: "That's also a question with initial letters, pseudo
elements - making sure ..."
...: "What sort of virtual elements..."

Tzviya: "We need to make sure WHAT we are working on is
accessible. We may not right it, but it may get passed to PF
for an accessibility review. Most of what we're asking for is
generated content - which is not accessibile."

<pkra> [18]http://bocoup.com/weblog/text-rendering/

[18] http://bocoup.com/weblog/text-rendering/

Peter: "I just was wondering what to do about the above issue.
Somebody analyzed that improving text rendering came with
significant performance. Even if we get issues into CSS, but
they aren't usable, that gives other issues..."

Dave: "On thing is we all have different use cases in different
environments. There are features that are not appropriate
because of context, etc. If readability is more important than
60FPS, we give authors tools so they can make tradeoffs
themselves."

Brady: "The performance issues are difficult to leave up to
publishers - a 2meg chapters, with optimized legibility and
pagination, it's hard to tell the publisher to worry about
that, or the reading system. Although not sure what CSS can
do."

changes to white paper

<tzviya>
[19]http://w3c.github.io/epubweb/draft/#general-architecture-fo
r-portable-offline-and-online-states

[19]
http://w3c.github.io/epubweb/draft/#general-architecture-for-portable-offline-and-online-states

<ivan> [20]http://w3c.github.io/epubweb/draft/

[20] http://w3c.github.io/epubweb/draft/

ivan: "I've made changes to the white-paper based on the
discussion on Cache - where some of us chimed in. I tried to
put the general ideas in there. Before I put that in the main
version, I'd like it to be reviewed."

<ivan>
[21]http://w3c.github.io/epubweb/draft/#general-architecture-fo
r-online-offline-publications
...: "Actually that URI should be the right one. Please have a
look today - because things need time to be read by others."

[21]
http://w3c.github.io/epubweb/draft/#general-architecture-for-online-offline-publications

<tzviya>
[22]http://www.w3.org/TR/2015/WD-service-workers-20150625/

[22] http://www.w3.org/TR/2015/WD-service-workers-20150625/

Tzviya: "Service workers is a first-public working draft."

+1

<HeatherF> +1

<pkra> +1

<tzviya> +1

<Karen> +1

<ivan> +1

<astearns> +1

<clapierre1> -1

<bjdmeest> +1

<Bert> +1

<dauwhe> +1 in some other time zone :)

tzviya: "Looking for comments on CSS prioritization and the
EPUB-WEB white paper - ASAP!!!!"

Summary of Action Items

[End of minutes]
__________________________________________________________

Minutes formatted by David Booth's [23]scribe.perl version
1.140 ([24]CVS log)
$Date: 2015/07/05 21:31:44$
__________________________________________________________

[23] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[24] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30
Check for newer version at [25]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

[25] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/disaply/display/
Succeeded: s/glassman/glazman/
Succeeded: s/danielle/daniel/
Found ScribeNick: NickRuffilo
Inferring Scribes: NickRuffilo
Present: Ivan_Herman Nick_Ruffilo Toru_Kawakubo Dave_Cramer Tzviya_Siegm
an pkra clapierre1 Luc duga astearns Ben_De_Meester Deborah_Kaplan Heath
er_Flanagan Liam_Quin Bert
Agenda: [26]https://lists.w3.org/Archives/Public/public-digipub-ig/2015J
un/0138.html

[26]
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0138.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 29 Jun 2015
Guessing minutes URL: [27]http://www.w3.org/2015/06/29-dpub-minutes.html
People with action items:

[27] http://www.w3.org/2015/06/29-dpub-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of [28]scribe.perl diagnostic output]

[28] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm


Re: update to xml entities draft

Source: www-math@w3.org Mail Archives • Asmus Freytag (t) (asmus-inc@ix.netcom.com) • June 26, 2015 • Permalink

On 6/23/2015 3:20 PM, Murray Sargent wrote:
> David Carlisle wrote that one could made definitions like
>
>> U+2102 DOUBLE-STRUCK CAPITAL C = Complex numbers
>>
>> Leaving U+1D53A free to be defined as a part of a generic alphabetic run as
>> MATHEMATICAL DOUBLE-STRUCK CAPITAL C
> One can't change the definitions of the math alphanumerics now since they are already encoded and Unicode has a stability guarantee. In addition they are widely used in technical documents as defined. We might have been able to get away with such definitions before the math alphanumerics were added to the Unicode Standard 3.1 back in March, 2001.  For Microsoft Office apps, I wrote routines to work around the separation of the math alphabetics into the LetterLike Symbols and math alphanumerics blocks and it's complicated and even error prone. So I really wish that we had done something along the lines David suggests. But it's clearly water over the dam at this point.
>
> +Asmus and Michel in case they want to defend Unicode's position of not duplicating characters.

Someone may have to forward this reply to the list.
> I'd argue that simplicity of implementation should play an important role in this regard. This isn't the only place where Unicode is over unified. But these complications do provide ways to keep programmers employed <grin>.

Unicode generally does not encode characters by usage. For example
there's no distinction between period, decimal point, abbreviation point
etc.. This reflects the underlying situation, to wit, that this is a
case of the *same* symbol being used in different conventions.

The downside is that it is thus not possible to use plain text to
capture which convention is intended (but nothing prevents anyone from
providing rich-text markup). The upside is that data can't exhibit
"random alternation" between identical looking symbols; experience has
shown that this is a most likely outcome if "the same" item is encoded
several times, based merely on convention.

In the existing case, when 2102 and friends were encoded in the
Letterlike Symbols block, they were clearly intended as a subset of the
double struck alphabet. The fact that some of the conventional meanings
for characters from this subset are annotated in the nameslist does not
detract from that.

It took a few versions of Unicode to better understand the best way to
encode symbols and alphabets used for math. The unfortunate side effect
of that is that the math alphabets are not sequential but have "holes".

In some cases, Unicode apparently does encode convention, for example
the micro vs. Greek mu, or Ohm vs. Greek Omega. These have complicated
histories. The desire to preserve the Latin-1 layout as an aid in
migration overrode the normal reluctance to code by convention. The
downside is that now users will use "random alternation" for the mu used
as micro sign. Greek users will most certainly not use the Latin-1 code
point for that purpose.

Some of the letterlike symbols should not have been coded in that block,
but in the Squared abbreviations block. That is because their origin was
fundamentally the special em-square set of units used in Asian
standards.  In the early versions of Unicode, there was this idea of
filtering out from such sets, any symbol that might be used
"generically", that is, outside an Asian typographic environment.

For most such usages, the standard Latin (or Greek, for Ohm) letters
would have been the correct characters, leaving Kelvin, Ohm, and
Angstrom as specifically "squared" characters.

So, while there are exceptions to what has by now become the principle
for new encodings, I would not call the treatment of math alphabets
"over unified". It is rather an attempt to not needlessly repeat the
"underunification" of micro, Kelvin, Ohm and Angstrom.

A./


Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • June 26, 2015 • Permalink

> I’ve responded to a few more of the comments in the google sheet.

Thanks so much Dave!

> I would encourage you to edit the math-related bits as you see fit, as
your knowledge of this area is at least a billion times greater than my
own.

Mmm, not so sure ;-) I guess since it is a list of CSS issues pointing to
MathML does not always seem right, e.g., pointing to element-based
mlabeldtr seems off when I hear about future CSS counters work. Then again,
MathML includes copious amounts of styling ability (but that's a different
discussion).

Peter.

On Thu, Jun 25, 2015 at 3:59 PM, Dave Cramer <dauwhe@gmail.com> wrote:

> On Thu, Jun 25, 2015 at 3:15 AM, Peter Krautzberger <
> peter.krautzberger@mathjax.org> wrote:
> >
> > @Dave I'm not sure how best to incorporate the comments I've left in the
> google sheet. Could I get some review before I edit the sheet itself?
>
> Hi Peter,
>
> I’ve responded to a few more of the comments in the google sheet. I would
> encourage you to edit the math-related bits as you see fit, as your
> knowledge of this area is at least a billion times greater than my own.
>
> It sounds like getting all the cross-reference stuff in GCPM [1] would be
> helpful. And getting CSSWG to finally write a table spec ;)
>
> Thanks!
>
> Dave
>
> [1] http://dev.w3.org/csswg/css-gcpm/#cross-references
>
>
>


W3C MathML 3.0 Approved as ISO/IEC International Standard ...

Source: mathml - Google Blog Search • A.R. Guess • June 26, 2015 • Permalink

MathML is the mark-up language used in software and development tools for statistical, engineering, scientific, computational, and academic expressions of math on the Web. The Mathematical Markup Language provides ...

Re: update to xml entities draft

Source: www-math@w3.org Mail Archives • William F Hammond (hammond@csc.albany.edu) • June 25, 2015 • Permalink

Murray Sargent <murrays@exchange.microsoft.com> writes:

> David Carlisle wrote that one could made definitions like
>
>>U+2102 DOUBLE-STRUCK CAPITAL C = Complex numbers
>>
>>Leaving U+1D53A free to be defined as a part of a generic
>> alphabetic run as
>>MATHEMATICAL DOUBLE-STRUCK CAPITAL C

I hope we're clear that just because at some point in
history the glyph that might have been used for U+1D53A had
been used for U+2102 does not mean that the *character*
named "DOUBLE-STRUCK CAPITAL C" would be the same as a
*character* in the alphabetic series "MATHEMATICAL
DOUBLE-STRUCK CAPITAL *".

Just to drive home this point, let me note that there are
annotations in my (slightly old) copy of the standard for the
characters in the U+21xx block corresponding to the vacant
slots indicating dedicated mathematical meanings.

The characters in the plane 1 mathematical alphabetic series
do not have annotations indicating dedicated meanings.

There is no need to change the names in U+21xx since already
they are different from what should be the mathematical
alphabetic series vacant slot names.

> One can't change the definitions of the math alphanumerics
> now since they are already encoded and Unicode has a
> stability guarantee.

Not necessary.

> In addition they are widely used in technical documents as
> defined. We might have been able to get away with such
> definitions before the math alphanumerics were added to
> the Unicode Standard 3.1 back in March, 2001.

My suggestion is simply that the vacant slots be filled.  That
won't break anything.  Of course, it might then take maybe a
decade before anyone could rely on them.

> For Microsoft Office apps, I wrote routines to work around
> the separation of the math alphabetics into the LetterLike
> Symbols and math alphanumerics blocks and it's complicated
> and even error prone. So I really wish that we had done
> something along the lines David suggests. But it's clearly
> water over the dam at this point.

Yes, *complicated and error prone*.

> ... +Asmus and Michel in case they want to defend Unicode's
> position of not duplicating characters. I'd argue that
> simplicity of implementation should play an important role
> in this regard. ...

Again, filling in the slots might generate redundant glyph
references, depending on glyph choices for the various
characters, but would not duplicate characters.

And all routes I can imagine for user-generated documents,
at least in most of Europe, Australia, North America, and
South America involve complicated code such as you describe.

-- Bill

#mathml #html5 #unicode #unigaps #xhtmlTooComplicated


MathML is now an ISO and IEC standard!

Source: Design Science News • Neil Soiffer • June 23, 2015 • Permalink

We've blogged about MathML lots of times, so I'm sure I don't need to tell you why MathML is the way math should be written on the Web or why it is so important for accessibility. Instead, let me take this space to write about its history as a standard.

MathML was the first XML-based W3C standard back in 1998. (OK, W3C only issues "recommendations", but most people consider them standards). It came at a time when most people thought the future of the web was going to be XHTML. XHTML (and more generally, XML) is used a lot by publishers and others who want to make sure what they write is "valid". But for the rest of us, HTML and its lazy "I'll make it work" attitude is the direction the web took. That was an unfortunate direction for math for many years because MathML wasn't part of HTML. Thankfully that changed in the last couple of years when MathML was included as part of the HTML5 spec; HTML5 became the official standard last year but had been widely implemented well before its standardization.

Firefox and our MathPlayer plug-in for IE have long supported display of MathML. Safari added support a few years back. Chrome briefly had support but in a very controversial move, removed it due to security concerns with the implementation and lack of an internal support person. Thankfully, the JavaScript-based MathJaX does a great job of supporting MathML in all browsers, so you can have MathML in all your pages. There's no need to use images that don't scale, can't line break, and are inaccessible.

MathML is now endorsed by ISO and IEC. This is a nice progression for MathML because several governments have laws that state that if there is an ISO standard available, it should be used where appropriate. This will definitely help cement MathML's place as a method to represent mathematical notation.

You can read the W3C's announcement here. It also includes a link to video that our own Bob Mathews made showing an iPad screen reading a Wikipedia page with MathML. If you want to see more examples of Math being spoken, you can see examples of JAWS, ChromeVox, and MathPlayer speaking the same Wikipedia page by taking a look at my CSUN talk.

Topics in this post:

RE: update to xml entities draft

Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • June 23, 2015 • Permalink

David Carlisle wrote that one could made definitions like

>U+2102 DOUBLE-STRUCK CAPITAL C = Complex numbers
>
>Leaving U+1D53A free to be defined as a part of a generic alphabetic run as
>MATHEMATICAL DOUBLE-STRUCK CAPITAL C

One can't change the definitions of the math alphanumerics now since they are already encoded and Unicode has a stability guarantee. In addition they are widely used in technical documents as defined. We might have been able to get away with such definitions before the math alphanumerics were added to the Unicode Standard 3.1 back in March, 2001.  For Microsoft Office apps, I wrote routines to work around the separation of the math alphabetics into the LetterLike Symbols and math alphanumerics blocks and it's complicated and even error prone. So I really wish that we had done something along the lines David suggests. But it's clearly water over the dam at this point.

+Asmus and Michel in case they want to defend Unicode's position of not duplicating characters. I'd argue that simplicity of implementation should play an important role in this regard. This isn't the only place where Unicode is over unified. But these complications do provide ways to keep programmers employed <grin>.

Murray


Re: update to xml entities draft

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • June 23, 2015 • Permalink

On 23/06/2015 19:58, Murray Sargent wrote:
> Yes the empty slots in the math alphanumerics are annoying and require
> extra code to navigate around, but as you know the corresponding
> characters already existed in the Unicode Standard when we encoded the
> math alphanumerics (see LetterLike Symbols) and it's Unicode's policy
> not to encode the same character twice (if possible). So at least it's
> relatively easy to calculate where the math alphanumerics are. Without
> the slots it'd be harder.

That's true but the existing ones could have been classified as specific
for their intended use eg

U+2102 DOUBLE-STRUCK CAPITAL C = Complex numbers

leaving
U+1D53A free to be defined as a part of a generic alphabetic run
MATHEMATICAL DOUBLE-STRUCK CAPITAL C

But it's only an annoying quirk, as you say it can be programmed around
so probably not worth changing now, as change introduces its own problems.

David

________________________________

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________


RE: update to xml entities draft

Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • June 23, 2015 • Permalink

Yes the empty slots in the math alphanumerics are annoying and require extra code to navigate around, but as you know the corresponding characters already existed in the Unicode Standard when we encoded the math alphanumerics (see LetterLike Symbols) and it's Unicode's policy not to encode the same character twice (if possible). So at least it's relatively easy to calculate where the math alphanumerics are. Without the slots it'd be harder.

Murray

Sent from my Windows Phone
________________________________
From: William F Hammond<mailto:hammond@csc.albany.edu>
Sent: ‎6/‎23/‎2015 15:12
To: David Carlisle<mailto:davidc@nag.co.uk>
Cc: www-math@w3.org<mailto:www-math@w3.org>
Subject: Re: update to xml entities draft

David Carlisle <davidc@nag.co.uk> writes:

> On 22/06/2015 20:30, William F Hammond wrote:
>> Was nothing done in unicode about the vacant slots in the
>> various math character series, e.g., bbf, cal, frak, nor
>
> If you mean the class="reserved" cells in for example
> http://www.w3.org/2003/entities/2007doc/1D5.html
> then I think Unicode sees those as a feature not a problem that
> needs to be solved.

Yes, that.

>> about cal vs. script ?
> No, I don't know what the prospects of getting anything
> done there are.  At least it seems that a convention for
> OpenType math fonts to have both styles, using the same
> Unicode slots but distinguished by OpenType stylistic
> features is developing.

Yes.

AIUI originally Knuth introduced calligraphic characters to
provide in TeX what mathematicians would write as script
characters.  As things are today, it's possible to use both
in LaTeX.  Given the growing number of levels of hierarchy
in mathematics, there is the tendency for mathematicians to
want ever more families of characters, and, so, for
example, a mathematical author might choose to use \mathcal
for sheaves while using \mathscr for complexes of sheaves.

In this way what was once a distinction between glyphs
becomes a distinction between characters.

Likewise the vacant ("reserved") slots arose, but with less
excuse, from a failure of the larger to community to
appreciate the difference between glyphs and characters, but
it is more egregious since the corresponding characters in
the U+21xx block were carefully chosen in a bygone age
for dedicated usage with particular meaning.

I suppose the "feature" is that the vacant slots exist at
all.

-- Bill


Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.