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.

Latest articles

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?

But do they? I don't have access to any samples.

> 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"

________________________________



Two comments:

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."

I admit this makes me somewhat sad :-(
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?

But do they? I don't have access to any samples.

> 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 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
  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> 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"





        Two comments:

        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,
              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."

              I admit this makes me somewhat sad :-(
              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?

But do they? I don't have access to any samples.

> 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"
________________________________



Two comments:

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."

I admit this makes me somewhat sad :-(
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
*dreadful* experience.

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
modalities. Hopefully, this can be integrated into Readium. Screen Reader
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

- http://idpf.org/news/ibm_adopts_epub


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
            Masinter <masinter@adobe.com>, Peter Krautzberger
            <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
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> 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"





      Two comments:

      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,
            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."

            I admit this makes me somewhat sad :-(
            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?

But do they? I don't have access to any samples.

> 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> 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> 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"
>
> ------------------------------
>
>
>
> Two comments:
>
> 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*
> <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* <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,
>    *https://twitter.com/fakebaldur/status/614794685559742464*
>    <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."
>
>    I admit this makes me somewhat sad :-(
>    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/ 

If you would like to learn more about MathFlow, please visit: http://www.dessci.com/en/products/mathflow/

Topics in this post: 

Re: [dpub] CSS Priorities Spreadsheet

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
comments/questions :-(

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

    See also: [3]IRC log

       [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

    <dauwhe> google doc:
    [16]https://docs.google.com/spreadsheets/d/15IsDMPwSXx197Iqe4I9
    xh7K8anmJ5c0-OFEG7w0LHYM/edit?usp=sharing

      [16] 
https://docs.google.com/spreadsheets/d/15IsDMPwSXx197Iqe4I9xh7K8anmJ5c0-OFEG7w0LHYM/edit?usp=sharing

    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.

    Tzviya: "Any other comments?"

    <laudrain> +q

    Luc: "I was just wondering why footnotes is #3? Is it because
    it's already processed/specified?"

    <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.'

    Brady: "The user-stylesheet is misnamed. It's broader - the
    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
    an early document, please comment."
    ... "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
    browsers/reading systems"

    <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/02 21:32:07 $
      __________________________________________________________

      [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./

Re: [dpub] CSS Priorities Spreadsheet

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 use 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 includes a link to a 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 (slide #12). Design Science has been an integral part of both the design and dissemination of MathML since the very start. I hope you'll excuse us if we give each other a little pat on the back as we watch our baby grow and mature – it feels good to be part of such a useful and successful standard!

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

Re: update to xml entities draft

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

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.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet