2013/5/24 Henri Sivonen <hsivo...@hsivonen.fi>
> On Mon, May 6, 2013 at 1:52 AM, Benoit Jacob <jacob.benoi...@gmail.com
> >wrote:
>
> > 2013/5/5 Robert O'Callahan <rob...@ocallahan.org>> One other thing: EPUB
> > publishers are screaming for good math support for
> > > textbooks (and currently that means they want MathML). They're mostly
> > > Webkit-based, and maybe we don't care about them, but there you are.
> > >
> >
> > Given that TeX is already the standard in scientific publishing, I would
> > find it very surprising if they complained about a TeX-based or TeX-like
> > format !
> >
> >
> TeX is a programming language
I never talked of putting TeX itself on the Web, only a small subset that,
contrary to TeX, would be purely a markup language.
Other people before in this thread have made this misreading of my
proposition, so I suppose that I was unclear.
> and, in practice, running the program results
> in a rigid PDF.
I also thought that it was obvious that a suitably chosen subset of TeX
could be free of such unwanted characteristics.
In fact, "Ascii MathML" is, by looking at their examples, heavily inspired
by TeX syntax,
http://www1.chapman.edu/~jipsen/mathml/asciimath.html
and so is a good approximation of what I meant to suggest (except that I
meant to stay even closer to TeX syntax, than they do on some examples).
Again, most people have similarly misunderstood my proposal, so I suppose
that it was unclearly expressed.
I just thought that it would go without saying that I wouldn't be walking
in on dev-platform proposing an imperative, fixed-layout language to do
math typography, and that "a suitable subset of TeX" would implicitly mean
pure-markup, no-fixed-layout.
> For the Web, we need something that can dynamically reflow
> to different viewports and integrate with CSS layout.
Of course.
Benoit
> MathJax or Web
> Components involve the publisher sending a program along with a supposedly
> declarative representation, so as a whole, it's again like sending a
> program, because you have to run the program to be sure about what the
> declarative input really results.
>
> EPUB publishers want something that is declarative and reflows to viewport
> width. Presentation MathML is that and it doesn't make sense to start over.
>
> These days, it's fashionable to rely on JavaScript and to treat
> downloadable EPUB files as an anachronism in an always-online world, but
> there's still value in being able to represent content in a way that can be
> reflown, edited, copied and pasted instead of only being rendered by a
> program supplied by the publisher. After all, we have all this CSS stuff
> for non-mathematical text instead of each site sending over an
> emscripten-compiled typesetter that paints the image of text onto canvas.
>
> Although math doesn't have the same mass-market appeal as text in general,
> math is pretty important for humanity, so I think it makes sense to keep
> the way to handle mathematical text in a way that's analogous with other
> text in browsers (declarative, reflowable, has a DOM) and endeavor to get
> Wikipedia to actually use it by default so that Chrome and IE would have
> compatibility pressure from a ridiculously mainstream site even if not from
> its most mainstream articles.
>
> (Compared to music and flowcharts, math has a greater need to integrate
> with line layout instead of working as an image-like region, so it makes
> less sense to use SVG. As for chemistry, presentation MathML probably
> serves chemistry pretty well, too.)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
