You are right: we have a print journal's interest in math typesetting. However, we also have a 25-year archive to curate. And we want it online.
We have wondered whether recent improvements to browsers and search engines have by now eroded our long-standing objections to serving articles in PDF instead of HTML. Our terse and unusual programming languages use Unicode points far outside ASCII; cut/paste from articles is particularly valuable. Encouragingly, the PDFs we've produced from DocBook seem to do this correctly. (Adrian, take note.) Thus our interest in DocBook as a source format from which to produce camera-ready PDF and web-ready HTML.
We do appreciate that DocBook is designed for technical documentation and rightly contents itself with a lower standard of typesetting than TeX's. So that's an open question for us: are the XML-FO formatters up to it? We wonder about the XEP line-break algorithm that put some truly awful hyphenation in Vector 23:4
. We have yet to tackle any serious CMN (common math notation) typesetting using MathML. All the CMN in the current issue was kluged, but eventually we have to set some real CMN.
In choosing to try DocBook before LaTeX, I noticed the existence of a LaTeX=>HTML process
, but paid it little attention as the site looked neglected. That might have been a mistake. Knuth considers typesetting a finite problem completely addressed by TeX, and since TeX version 3, the version numbers have converged on π. So perhaps there aren't any loose ends to work on.
Did you consider storing the LaTeX source and using the LaTeX and latex2html processes to generate other formats from it? Or does your CMS somehow preclude that?
Or perhaps you took the view that any kind of XML was a better medium than TeX for an archive?
has slender production resources, so we want our usually tech-savvy contributors to submit articles in a format that minimises our work. A subset of XHTML might be a better markup for contributors: authors can get immediate visual feedback with a browser and stylesheet. We already know we can get camera-ready PDF by importing XHTML into Word (a fall-back), and imagine we can write XSL to convert that XHTML subset into DocBook and whatever HTML the site design-de-jour calls for.
We might produce an issue using LaTeX before drawing a conclusion.
Any views on our production and archiving strategy most welcome.
2008/10/18 Albretch Mueller <email@example.com>
On Fri, Oct 17, 2008 at 9:50 PM, Stephen Taylor <firstname.lastname@example.org> wrote:
> So I'm interested to hear that you're going the other way ...
I see why we are looking at the same thing from different perspectives
Your main interest as a (print) journal editor is
typesetting/formatting/lay out, while I am trying to use docbook as a
CMS repository, also the actual text I got was in latex format
At least docbook's xml is good at reformatting to many other formats
including text (html and rtf) and image-based formats such as pdf and
I am curious about the specific problems you are having because I
have always heard complaints of people going the other way around,
from latex to, say, html, because latex features are a superset not
well represented in the html format