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

## GNOME 3.17.4

Source: Ask.com News Search for "mathml" • July 24, 2015 • Permalink

 Linux Today - Found Jul. 24, 2015 ... you can find improved Wayland hi-dpi support in mutter, IP addresses for vms in gnome-boxes, MathML support in orca, performance improvements... Gnome Workshop Announces Grand Opening Sale For Lightning Cable - Minyanville Explore All

## MathML 3.0 is now an ISO standard | The Aperiodical

Source: mathml - Google Blog Search • Christian Perfect • July 10, 2015 • Permalink

After a lengthy lull in which MathML was deeply unpopular, mainly due to browser makers not supporting it but mainly due to it being extremely hard for the average mathematician to work with, the format which aimed to be ...

## Re: Use of \catcode command for character letters ^ and _ in pmml-new.sty file restricts the normal use of these characters for superscripts and subscripts.

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

On 07/07/2015 20:46, saf sied wrote:
> At some places in my text document I am using Dr. Carlisle’s XSLT

"David" is fine:-)

> <https://github.com/davidcarlisle/web-xslt/tree/master/pmml2tex> to
> convert MathML to LaTeX; whereas, at other places I am using standard
> ams-LaTeX.
> In MikTeX, the following properly displays “a squared” and “a sub 2”
> \documentclass{article}
> \begin{document}
> $a^2$
> $a_2$
> \end{document}
> But when including the \usepackage{pmml-new} in the preamble the above
> displays as simple text a^2 and a_2.
> If I remove the last two lines (shown at the end below) from the
> pmml-new.sty file the “^” and “_” work fine for superscripts and
> subscripts respectively. Moreover, msup and msub defined in the above
> file continue to work for superscript and subscript, as well. I would
> like to use both the LaTeX generated from MathML and the standard LaTeX
> in a same document. For example I would like to be able to use the
> following quadratic formula generated from MathML or a simple LaTeX
>   $$a^2$$ on the same tex document:
> $$\let\par\empty > x={\frac{{-b\unicode{177}\sqrt{{\msup{{b}}{{{2}}}}-{4}ac}}}{{{2}a}}} >$$
> Would removing the following last two lines from the pmml-new.sty file
> cause any other issues? If yes, are there any other changes we can make
> to the .sty file to make both ams-LaTeX and LaTeX generated by Dr.
> Carlisle’s files work together on a same document
> \catcode\_=12
> \catcode\^=12
>

Yes you could remove that from a local copy or just set them back to

The original use case for the style was converting XML (such as the XML
source of the MathML spec) where ^ (and especially) _ may occur just as
normal text and rather than have to trap and escape those I just made
all _ normal text and never generated _ for subscripts, always used
\msub etc.

As your fragments show it doesn't really to to make "clean" tex to put
into an existing document, it was used to convert the entire document to
tex for pdf generation as a "black box" process, so the tex it generates
is rather ugly.

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.

________________________________


## Use of \catcode command for character letters ^ and _ in pmml-new.sty file restricts the normal use of these characters for superscripts and subscripts.

Source: www-math@w3.org Mail Archives • saf sied (saf_itpro@yahoo.com) • July 07, 2015 • Permalink

At some places in my text document I am using Dr. Carlisle’s XSLT to convert MathML to LaTeX; whereas, at other places I am using standard ams-LaTeX.In MikTeX, the following properly displays “a squared” and “a sub 2”\documentclass{article}\begin{document}$a^2$$a_2$\end{document}But when including the \usepackage{pmml-new} in the preamble the above displays as simple text a^2 and a_2.If I remove the last two lines (shown at the end below) from the pmml-new.sty file the “^” and “_” work fine for superscripts and subscripts respectively. Moreover, msup and msub defined in the above file continue to work for superscript and subscript, as well. I would like to use both the LaTeX generated from MathML and the standard LaTeX in a same document. For example I would like to be able to use the following quadratic formula generated from MathML or a simple LaTeX  $$a^2$$ on the same tex document:$$\let\par\emptyx={\frac{{-b\unicode{177}\sqrt{{\msup{{b}}{{{2}}}}-{4}ac}}}{{{2}a}}}$$ Would removing the following last two lines from the pmml-new.sty file cause any other issues? If yes, are there any other changes we can make to the .sty file to make both ams-LaTeX and LaTeX generated by Dr. Carlisle’s files work together on a same document\catcode\_=12\catcode\^=12
Thanks..Saf


## [Minutes] 2015-07-06 Digital Publishing Interest Group Teleconference

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

Hi all,

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

http://www.w3.org/2015/07/06-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

06 Jul 2015

[2]Agenda

[2]
http://www.w3.org/mid/b9986cf719ea4f3bafc2669f4a3ab2d0@CAR-WNMBP-006.wiley.com

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

Attendees

Present
Dave Cramer, Tzviya Siegman, Bill Kasdorf, Chris Lilley,
Toru Kawakubo, Ivan Herman, Tim Cole, Brady Duga, Deborah
Kaplan, Ben De Meester, Peter Kreutzberger, Thierry Michel,
David Stroup, Alan Stearns, Vladimir Levantovsky,  NickRuffilo.

Regrets
Luc Audrain, Phil Madans, Heather Flanagan, Julie Morris ,
Zheng Xu.
Chair
Tzviya Siegman

Scribe
Nick Ruffilo

Contents

* [4]Topics
1. [5]describedAt
* [6]Summary of Action Items
__________________________________________________________

<trackbot> Date: 06 July 2015

<scribe> scribenick: NickRuffilo

<tzviya> agenda:
[7]https://lists.w3.org/Archives/Public/public-digipub-ig/2015J
ul/0007.html

[7]
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jul/0007.html

<Bill_Kasdorf> I think Dave added a seventh agenda item, right?

huh ui'm not getting audio hold

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

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

<pkra> I got that.

<ChrisL> webex says michael miller

<pkra> webex is such a snitch

tzviya: "We have some new people and unidentified people..."

<ChrisL> can ppl hear me?

<astearns> no

No chris - still muted

<ChrisL> well, odd

<astearns> there we go

OK - we hear you

Chris: "Hello! I'm Chris Lilly technical director of
Interaction Domain - involved in CSS, web-fonts, SVG. In
particular, I'm here because I want a closer liason with CSS
working group and Houdini. And what DPUB wants. I was invited
for this call - and expect to participate regularly."

Tzviya: "Anyone else new on the call? There are some new
joiners of DPUB. Not sure if you're on the call or in IRC"

<ChrisL> congrats Alan!

Tzviya: "Adding a comment about DPUB and CSS -> the CSS Working
group as identified new chairs - and Alan Sterns is one of the
new chairs. Congratulations!"

<Karen> +1 Alan as new co-chair in October

Alan: "I will not be chair until october"

<Bill_Kasdorf> +1

<pkra> +1

<ivan> +1

Tzviya: "I believe there is only 1 thing on the agenda -
discussing CSS with Chris. I've posted a bunch of links to CSS,
priorities. Just the morning he added stuff to that. I'll turn
this over to dave and chris"

<dauwhe>
[9]https://www.w3.org/dpub/IG/wiki/Functional_Requirements_for_
Pagination

[9]
https://www.w3.org/dpub/IG/wiki/Functional_Requirements_for_Pagination

<dauwhe>
xh7K8anmJ5c0-OFEG7w0LHYM/edit#gid=2138850308

[10]

<dauwhe>
[11]http://w3c.github.io/dpub-pagination/priorities.html

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

Dave: "We have been working on a couple of things - first was
the wiki page that has functional requirements - based on early
work by Brady - interacting with pages stuff. We're trying to
collect our requirements there. The 2nd piece that we started
working on is an explicit CSS priorities document which has

...: "We will start to move it to a different format once it's
more final and written up in a better format. There are tons of
information and it's a challenge to figure out the best way to
show it. But, it sort of feels useful to start collecting all
these things 'in one place' that is really multiple places"

Chris: "Dave is on the CSS group - I've poked him about Latin
Requirements. But then there are all these other things that
have new things."

davE: "One of the core issues is - what is the reason for being
for LatinReq... It didn't have anything to say about
implementations and priorities."

Chris: "I wasn't suggesting that it need be the only doc, just
the only place I was looking."

Dave: "Yes, LatinReq isn't enough - we need a W3C document that

Tzviya: "We're hoping to get a bit of clarification of what is
going on with houdini and how this fits it in."

Chris: "A feature of the web is using polyfills - so people
don't have to wait for features to be added. This sort-of works
but tends not to work if you use a bunch of them together. It
ends up doing lots of re-implementation, which is pointless as
the browser already knows how to do it. Also there are some
things that are really hard to extend as it happens under the
hood. The idea of houdini

(and it's named after a magician) because it's trying to remove
some of the hand-waving."
...: "It's a sub-group of CSS and the tag, but it's more API
based. I think this is a new focus on new APIs and new
extensibility points. To make it less abstract - we plan on
exposing the box tree - it's largely assumed that the boxes
that are made follow the element tree (there are a bunch of
differences - and many over time) especially when you go across
a fragment. You also might want to

have things like Pages in there as well - which belong in a box
tree and not the DOM tree. That is how I see houdini fitting
in."

<dauwhe> [12]http://dev.w3.org/csswg/css-display/#intro

[12] http://dev.w3.org/csswg/css-display/#intro

Dave: "In the CSS display spec there is a note about what it
means to be in the box tree and DOM tree. This may end up being
where we use these things - the display tree."

<Bill_Kasdorf> +1 to Karen

Karen: "That was one of the more articulate descriptions of
houdini! Thank you! We really need to go to the next level of
explaining 'what is this and how does it work together' so not
only our members, but people interested have a clue. The next
step would be to prepare a more plain-english 'for resources,
for publishers, ...' think about how do we best communicate
some of the work that we

are doing to our community right now."

Chris: "I agree that it is needed - and many W3C working groups
need to work on. For houdini it is still up in the air, but in
the upcoming Paris meeting, I believe we will be tackling this,
and in October that would be a good time to address this
issue."

Karen: "I'll sync up with Nick on this."

Ivan: "What you describe is one end of the spectrum. The other
end is the poor technical people who have to do something with
the NY meetup - we discussed having 'these and these' features
that should be in the CSS declarative style. We noted what is
missing and what we were trying to get. The reader should be
able to handle

pagination through a declaration."
...: "Now there is another side saying that some super-magic
should be doing this through houdini. Something that publishers
& authors should be using. We ended up by saying we are unsure
what line we need to be prepared for - and possibly both."

Chris: "I hear what you say let me try to address. Declarative
is the way it's going and where it will continue to go. Most
poly-fills use declarative syntax that isn't used them
implement. From authoring - no need to touch that stuff. you
should be able to get far without scripting. For an implementer
POV - which is extends a browser, there will be a need - as you
won't want each individual

item bringing in the polyfills - you want the browser to be a
'browser ++'"

Brady: "I think that is where we left it - that's the
conclusion in my head. Publishers should be using these CSS
specs in a declarative way - the reading system NEEDS to be
able to use these polyfills. As an implementer, I have to
struggle with adding the polyfills in a cross-browser way."
...: "Pagination is the most horrible thing that has ever
happened - there is multi-column that gets panned around. You
can do it by breaking up the DOM - as you have no idea where
things end, so you have to figure out where text ends... People
have done it with scrolling and putting a gap between pages.
None of them quite work - and you cannot do things on a
page-level. You can't do widows

and orphans well either with many of these concepts."

Tzviya: "Widow and orphan control and hyphenation are simple
things that are very important - and difficult without the
concept of a page."

ivan: "if this is the way it goes, then we as a group need to
accept that Houdini is there, and the implementors do the
polyfills. Then the question is - do we have everything in CSS
that the publishers need to make the declaratives?"
...: "Then we need to go back to the CSS working group to ask
for certain things to be declared."

Tzviya: "Alot of scholarly publishing uses PDF is because of
MATH - even though we have MathML and other things, it's either
difficult or NOT supported at all, and that's keeping the STEM
world away."

<pkra> same for education.

Ivan: "What is it that the CSS working group needs from us? To
have pagination on the priority list?"

<tzviya>
[13]http://w3c.github.io/dpub-pagination/priorities.html

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

Chris: "There is a GAP analysis between what is specified and
what browsers ACTUALLY do. What is the level of implementation?
Also why - is there missing information?"
... "What is currently in use, what are the needs, and what
isn't yet specified. having clear requirements and adequate
detail - how it will be extended - how does it actually work -
because CSS has suffered from multiple inconsistent
implementations - we're trying to avoid doing that. Having
multiple pagination requirements will be an issue.
Demonstrating need with clarity and how it is

additive and not breaking the model would be a high priority."

Ivan: "Ok that makes sense"

<ChrisL> yes, one way forward is to triage the existing specs
and get agreements on which are the bad bits

Dave: "I agree with Chris. I think one thing we need to do is
that - there are alot of page related stuff in CSS specs. It's
widely varying quality and in some cases there are things that
have been that are described by the PDF formatters a long time
ago and don't represent the modern concesus of how CSS should
be designed. Even the CSS page-spec itself - and the margin
boxes. At some point

everyone needs to decide, do we go ahead with the older things
and try to patch them up. Do we burn the village and rebuild
with more modern concepts?"

Chris: "Figuring out what isn't implemented - because it's
rubbish - and removing that will help us see where we are
going."

Tzviya: "There are concerns & belief that this is used for
print... This is - in some pockets - used for print, but all of
our interests are beyond print. "

Chris: "The reason I raised that is that the CSS working group
looks at it as 'well, who prints web pages anyways' and the
common use cases - such as tabbed viewing, and apps that are
using slideshows - those tend to get brushed off."

Ivan: "This pretty much relates to the other issue - the
browser vendors - I see pagination as potentially pretty
interesting from a user-interface point of view on the web.
It's very long - then pagination as a find of user interface
structure is something I would really love to have. And I must
say that some of our own documents would benefit from such a
use-case. Is this discussed at all

by browsers? Do they see any argument about that at all?"

Chris: "They do tend to brush it away. This is a problem that
is also faced by accessibility - we want these for blind, color
blind. In the early days, they did the research and found that
the market was low - so browsers wouldn't implement. But, as
new information comes out, they realize that there are more
people who would benefit from such features - such as
accessibility. We want to have

cross-references so you can say 'page 28' but equally we want
to say 'section 5.3.2' if we solve one, we can solve the other
one. Then, what we need gets implemented."

Ivan: "In a sense - would it also help if the publishing
community put these kinds of arguments more explicilty the user
interface for pagination."

Chris: "yes. To some extent. Some needs to be explicit, and
some is a battle plan you don't tell them until they fall for
it."

<pkra> sliders?

Tzviya: "In the documents we're calling for - we should
declaritively state that it works for slides, flashcards,
cards, tiles."
...: "We should spell that out - so pagination isn't just for
'books'"

Tzviya: "Chris - do we need to clarify between CSS and Houdini
when writing this document?"

Chris: "I suggest not - see it as a continuum. Some things are
implemented, some are IN CSS but not implemented. Some can be
easily polyfilled, and some are hard/impossible to polyfill
without houdini."

<tzviya>
[14]http://w3c.github.io/dpub-pagination/priorities.html

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

Chris: "to clarify - the document is the wiki pages?"

Tzviya: "Nope - this is the text version of the CSS worksheet"

DavE: "this is evolving. I'm still fumbling a bit."

Tzviya: "Dave should get more help and input from others in the
group. "

<ChrisL> yes, I commit to helping with this

Tzviya: "We could use help determining implementation. We know
what we want, but we're not sure where things would happen.
There are a list of where specs exist. We could use help in
that section."

<ivan> ChrisL++

Chris: "I already committed to some GAP analysis on pagination
- so i'm already working on that. So I'll commit here, because
this will make the research a bit more public."

Tzviya: "OK."
... "Other comments? We have next-steps but I'll leave dave and
chris."
...: "Everyone clear on next steps?"
... "Deborah - I see you're here. We need to get note to PF

describedAt

Deborah: "Ok - Should we call what I have 'final'? George sent
some comments and I incorporated what he suggested."

Tzviya: "Just send the final version around."

Deborah: "I'll do that this morning. This in particular is PF -
feels - uncomfortable - about the ARIA describedAT ARIA role in
that they don't think there is alot of buyin yet from
publishers to implement. Our note is an explanation of 'why we
think it is INCREDIBLY useful"

<ChrisL> (discussion of aria described-at and aria 1.1 vs 2.0
staging)

Tzviya: "The reason they are considering deprecating it is
because there is a new version. Deborah and Charles concluded -
with lots of input - that now is not a good time to deprecate
describedAT. They put together alot of examples of how it would
be useful. So, we have this draft of the note. If any publisher
in particular has strong feeling, they might as us as
publishers to come to a PF

meeting."
...: "If anyone wants to see the text get in touch wtih
deborah, charles, or I."

Deborah: "you can always conect me if you have suggestions or
questions"

Tzviya: "Anything else before we close it for today?"

Ivan: "Worth noting as a heads-up that the document that Tzviya
and Markus made with PF - the DPUB-ARIA document has gone
through all the necessary hurdles - it will be published
tomorrow! It has been accepted by Judy and michael is taking
care of it.

<Karen> +1 interpretation for publishing community

Summary of Action Items

[End of minutes]
__________________________________________________________

Minutes formatted by David Booth's [15]scribe.perl version
1.140 ([16]CVS log)
$Date: 2015/08/02 23:01:45$
__________________________________________________________

[15] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[16] 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 [17]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/persent+/present+/
Found ScribeNick: NickRuffilo
Inferring Scribes: NickRuffilo
Present: Dave_Cramer Tzviya_Siegman Bill_Kasdorf Chris_Lilley Toru_Kawak
ubo Ivan_Herman Tim_Cole duga Deborah_Kaplan Ben_De_Meester Peter Krautz
berger thierry david_stroup astearns Vlad Bert
Agenda: [18]http://www.w3.org/mid/b9986cf719ea4f3bafc2669f4a3ab2d0@CAR-W
NMBP-006.wiley.com
Found Date: 06 Jul 2015
Guessing minutes URL: [19]http://www.w3.org/2015/07/06-dpub-minutes.html
People with action items:

[18]
http://www.w3.org/mid/b9986cf719ea4f3bafc2669f4a3ab2d0@CAR-WNMBP-006.wiley.com
[19] http://www.w3.org/2015/07/06-dpub-minutes.html

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

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

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


## CICM 2015: Final Call for Participation, Deadline July 6th, 2015

Source: www-math@w3.org Mail Archives • Serge Autexier (serge.autexier@dfki.de) • July 06, 2015 • Permalink

                     Final Call for Participation

Conference on Intelligent Computer Mathematics
CICM 2015

13-17 July 2015
Washington DC, USA

The programme for this year's CICM in Washington can be found as

The accepted papers as

In addition we solicit for posters which will not be peer reviewed, but we
will just do a screen review for relevance to the conference. A poster
presentation will consist of a 5 minute teaser talk and the presentation of
the poster on Tuesday morning (together with the other presentations in the
Systems/Data/Projects track).

You can submit a brief abstract on a poster by 22 June 2015 via EasyChair:
https://www.easychair.org/conferences/?conf=cicm2015

Registration to the conference will open shortly.

For details on the conference, registration, accommodation, etc. see
http://www.cicm-conference.org/2015/cicm.php

**********************************************************************
Invited Speakers:
**********************************************************************

*  Leonardo de Moura, https://leodemoura.github.io/
"Formalizing mathematics using the Lean Theorem Prover"
(http://leanprover.github.io/)
*  Tobias Nipkow, http://www21.in.tum.de/~nipkow/
"Analyzing the Archive of Formal Proofs"
*  Jim Pitman, http://www.stat.berkeley.edu/~pitman/
"Towards a Global Digital Mathematics Library"
*  Richard Zanibbi, http://www.cs.rit.edu/~rlaz/
"Math Search for the Masses: Multimodal Search
Interfaces and Appearance-Based Retrieval"

**********************************************************************
The principal tracks of the conference will be:
**********************************************************************

* Calculemus (Symbolic Computation and Mechanised Reasoning)
Chair: Jacques Carette
* DML (Digital Mathematical Libraries)
Chair: Volker Sorge
* MKM (Mathematical Knowledge Management)
Chair: Cezary Kaliszyk
* Systems and Data
Chair: Florian Rabe
* Doctoral Programme
Chair: Umair Siddique

Publicity chair is Serge Autexier. The local arrangements are
coordinated by the Local Arrangements Chairs, Bruce R. Miller
(National Institute of Standards and Technology, USA) and Abdou
Youssef (The George Washington University, Washington, D.C.), and the
overall programme is organized by the General Programme Chair,
Manfred Kerber (U. Birmingham, UK).

As in previous years, we have co-located workshops:

*  Formal Mathematics for Mathematicians
*  Theorem proving components for Educational software (ThEdu'15)
*  MathUI

Furthermore we have a doctoral programme to mentor doctoral
students giving presentations and a tutorial on the generic proof
assistant Isabelle.
--------------------------------------------------------------------------------


## MathML 3.0, ¿un estándar internacional al que nadie le hace caso ...

Source: mathml - Google Blog Search • Manuel López Michelone • July 05, 2015 • Permalink

La historia de MathML no ha sido una de las más felices. Ha sido una buena idea crear un lenguaje de marcas (como podría ser XML) para las ecuaciones matemáticas, pero por alguna razón la gente no parece respaldarlo.

## 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:

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


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


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