Re: Maths in ebooks

[Paulo Ney de Souza <pauloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 5106 bytes --]

Well... it is not so simple ....

The first problem that arises is -- what is the "target ePub" -- specially
since you are talking about displaying it in a device, and in a way that is
better than PDF.

The kind of ePub produced by Pandoc is a sort of a "pure ePub" -- it
generates both ePub2 and ePub3 that passes validation with flying colors
but displays very poorly on the devices (iPad, Kobo, Nook, Google Play,
ADE, browser ePub display, converted to Kindle, etc ...). The main reasons
for that can be broken in two classes:

First is a CSS problem: Pandoc offers you a plain ePub and does not play
much with the CSS, while a LOT of what makes a good ePub relies on CSS.
This problem is resolvable, you just have to spend the time finding out
what is  the look you find the best and the target machine you want it for.

The second class of problems is much harder: Not all ePub elements are
supported by all manufacturers and programs and even then -- they make
their own choice on HOW to support it and their OWN interpretation on how
it should look like.

Ultimately every one of these ePub rendering engines use an HTML rendering
engine underneath, but manufacturers are not very open and forthcoming with
what rendering engine they are using for their reader -- very few release
that information and they change it all the time (now that rendering
engines are becoming a standard and a commodity). There are even reports
that a reader (Kobo) uses one rendering engine in one platform and another
elsewhere.

And up to now we have not even touched SVG ... and here the problem
iterates again... SVG is a standard (as MathML is) and as such manufactures
pick and choose which parts to use and support. It is fairly easy to make
an SVG for a circle that will not display on one or another rendering
engine.

For a look at the ePub3 Support Grid you can check:
http://epubtest.org/results/ and on http://epubtest.org/compare/ you can
see what pieces of the SVG standard are supported by each reader.

The problem is very similar to the one tackled by MathJax and KaTeX --
these are programs that stick their tongue out, feel the environment in the
user machine (browser, rendering engine, installed fonts, etc ...) and
prepare from sources the kind of HTML/MathML/CSS/Fonts it should be sent to
that reader.

We literally need to do the same for ePub, and start delivering the ePub
that is appropriate for one or another device...that will take some work!

Paulo Ney

PS.Just a remark - SVGLaTeX is a defunct project right now.







On Thu, Jan 15, 2015 at 2:59 AM, Thomas Arildsen <thomasarildsen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:

> I have been experimenting with including maths in ebooks (ultimately
> because I would like to be able to publish my research as ebooks instead of
> PDF which I think is suboptimal for tablets etc.) One approach that sort of
> works for me is converting from Markdown with LaTeX maths to ePub where I
> can make Pandoc turn the maths into MathML. My problem is just that the
> MathML looks quite horrible in comparison to what LaTeX can usually produce
> in PDF etc.
> A fall-back solution for me could be to render the maths bitmapped and
> then include the images in the document. However, I recently figured out
> that ePub seems to support SVG as well and it is actually possible to turn
> LaTeX into SVG output (see e.g. http://dvisvg.sourceforge.net/ and
> http://svgkit.sourceforge.net/SVGLaTeX.html). So far I have succeeded in
> doing this quite manually, but I was wondering if it would be possible to
> make Pandoc able to automate this conversion of math formulae into SVG with
> subsequent inclusion of the SVG into the ePub? I have no experience in
> hacking Pandoc.
> Best regards,
>
> Thomas Arildsen
>
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/dfcf2e4b-b377-4d48-be9f-de82088e7832%40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/dfcf2e4b-b377-4d48-be9f-de82088e7832%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAFVhNZPeDbtt%2BTt3%3D8BYVX42XfFb%3D4RtaLGt29Ho-ik%3DQzeTSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 6717 bytes --]