Automated Equation Processing and Rendering Workflows for Publishers

1,580 views

Published on

Typesetting mathematical equations for print/digital outputs is currently a serious pain point for many publishers. Two common workflow solutions are to either:

1. Use a specialized typesetting tool with rich mathematical rendering support (e.g., LaTeX)

2. Convert all equations to images for use in traditional desktop publishing tools (e.g., InDesign)

However, there are key downsides to both these approaches. For publishers that don’t focus exclusively on math and science titles, spinning up a LaTeX-based production program may require too much overhead in time/resources to justify the investment. And converting equations to images is not ideal either, as it decreases ease of maintainability and poses challenges for digital outputs in terms of both scalability for different form factors and accessibility for visually impaired readers.

As a tech publisher that produces many titles a year with mathematical content, O’Reilly Media was unsatisfied with the compromises entailed by the above workflow choices, and developed an alternative solution: a mathematics API called “STIX” that slots into its XML/
HTML-based single-source workflow.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,580
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Automated Equation Processing and Rendering Workflows for Publishers

  1. 1. Automated Workflows for Mathematical Equation Processing and Rendering EDUPUB 2013 October 29, 2013 Sanders Kleinfeld O’Reilly Media, Inc.
  2. 2. Or: b ! 4ac !b ± 2a 2 ≠
  3. 3. How should I produce books with complex mathematical content?
  4. 4. Publishers often go one of two routes for source files…
  5. 5. Typeset with AT L X! E section{Bayes's Theorem} At this point we have everything we need to derive Bayes's Theorem. We'll start with the observation that conjunction is commutative; that is % [ p{A AND B} = p{B AND A} ] % for any events $A$ and $B$. index{Bayes's Theorem derivation} index{conjunction} Next, we write the probability of a conjunction: % [ p{A AND B} = p{A}~p{B|A} ] % (Source From Think Bayes [O’Reilly Media]: http://code.google.com/p/thinkstats/source/browse/trunk/thinkbayes/ book.tex#634)
  6. 6. OR…
  7. 7. Just Embed Images! (From Head First Algebra [O’Reilly Media])
  8. 8. Downsides of LATEX approach: •  •  What if you don’t want to build a TEX toolchain? LATEX is great for PDF export, but what about output to EPUB/Mobi? Downsides of image approach: •  •  Maintenance is a pain! How to scale/optimize for different output formats?
  9. 9. O’Reilly’s Solution: Embed LATEX in Standard ASC or DB Source Instead, we start with a small congestion window and double it for every roundtrip--i.e., exponential growth. As a result, the time required to reach a specific throughput target is a function (<<SS_TIME>>) of both the roundtrip time between the client and server and the initial congestion window size. [[SS_TIME]] [latexmath] .Time to reach the cwnd size of size N ++++ begin{aligned} mathrm{Time} = mathrm{RTT} times leftlceil log_2 left ( frac{mathrm{N}}{mathrm{initial cwnd}} right) rightrceil end{aligned} ++++ (From High Performance Browser Networking [O’Reilly Media])
  10. 10. BUT…
  11. 11. How do I render AT X for embedded L E all my different (e)book outputs?
  12. 12. What about MathML? (http://www.w3.org/Math/)
  13. 13. MathML Rendered to PDF* * With AntennaHouse Formatter
  14. 14. MathML in EPUB (iBooks)
  15. 15. MathML in EPUB (NOOK)
  16. 16. MathML in Mobi (Kindle Fire)
  17. 17. OK, what about SVG? (http://www.w3.org/Graphics/SVG/)
  18. 18. SVG Rendered to PDF* * With AntennaHouse Formatter
  19. 19. SVG in EPUB (iBooks)
  20. 20. SVG in Mobi (Kindle Paperwhite)
  21. 21. SVG in Mobi (Kindle “classic”)
  22. 22. Gah, what’s left? JPEG or PNG?
  23. 23. Well, yes. Only standard bitmap image formats work reliably everywhere
  24. 24. BUT…
  25. 25. Why do we need a one-size-fits-all solution?
  26. 26. Can’t we optimize equation output separately for each format?
  27. 27. “Frustrated man at a desk” (by LaurMG; http://commons.wikimedia.org/wiki/File:Frustrated_man_at_a_desk_(cropped).jpg)
  28. 28. Don’t Worry!
  29. 29. Make an API!
  30. 30. O’Reilly Media’s Math Conversion API (a.k.a. STIX) EPUB Equation LATEX Source MathML Source STIX Mobi Equation PDF Equation Web Equation
  31. 31. STIX: Under the Hood LATE X tralics MathML (http://www-sop.inria.fr/marelle/tralics/) MathML SVGMath (http://sourceforge.net/projects/svgmath/) SVG rsvg PNG Source Format Conversion Tool Intermediate Format Output Format (https://developer.gnome.org/rsvg/stable/)
  32. 32. Equation Output Formats Per Ebook Format EBOOK Format Equation Output Format EPUB PNG Mobi PNG PDF MathML (rendered by AntennaHouse Formatter*) HTML (for Web) LATEX or MathML (with MathJax** for rendering) * http://www.antennahouse.com/ ** http://www.mathjax.org/
  33. 33. Future Improvements •  MathJax-based engine for STIX (à la svgtex) https://github.com/agrbin/svgtex •  Improved Accessibility! (alt text for PNG via ChromeVox) http://kefletcher.blogspot.com/2013/07/next-stepsfrom-accessibility-sprint.html
  34. 34. Contact Me! Email: sanders@oreilly.com Twitter: @sandersk

×