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

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
catcode 8 and 7 after loading the package.

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

    See also: [3]IRC log

       [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,
    our requirements, houdini. Dave has added many links to our
    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>
    [10]https://docs.google.com/spreadsheets/d/15IsDMPwSXx197Iqe4I9
    xh7K8anmJ5c0-OFEG7w0LHYM/edit#gid=2138850308

      [10] 
https://docs.google.com/spreadsheets/d/15IsDMPwSXx197Iqe4I9xh7K8anmJ5c0-OFEG7w0LHYM/edit#gid=2138850308

    <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
    been a google spreadsheet."

    <ChrisL> oh, I hadn't seen that spreadsheet before
    ...: "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
    notes more information."

    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
    pagination in the reading system. When we had a discussion at
    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
    about ARIA Describe dat?"

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/07/28 18:31:46 $
      __________________________________________________________

      [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+/
Succeeded: s/addative/additive/
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

                 Registration Deadline July 6th, 2015


The programme for this year's CICM in Washington can be found as
http://www.cicm-conference.org/2015/cicm.php?event=&menu=detailed-programme

The accepted papers as
http://www.cicm-conference.org/2015/cicm.php?event=&menu=talks

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
You will be informed about acceptance shortly after your submission.

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

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: 

New DIAGRAM Webinar: Accessible Math for Ebooks Using MathML ...

Source: mathml - Google Blog Search • jnoblitt • June 29, 2015 • Permalink

Registration is now open for the next DIAGRAM webinar: Title: Accessible Math for Ebooks Using MathML Cloud Date: Wednesday, July 15, 2015. Time: 11:00 a.m. Pacific (2:00 p.m. Eastern; 20:00 GMT) Presenters: Sanders ...

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.

(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