4

A major publisher recently requested my accepted pdf in an MSWord format. When I offered the LaTeX source, they demurred: “We’ll work with the pdf”. They were glad to receive the figure files, however.

Other papers I’ve published lately have been delayed by errors in converting LaTeX to XML.

Between a publisher's need for XML and a preponderance of MSWord submissions, much technical publishing has moved away from using LaTeX source code. So, I have two questions (Edited):

  1. What “best practices” will allow authors to streamline their LaTeX submissions to major technical publishers using an XML-first model?
  2. Are there packages or engines that authors can use with LaTeX to produce pdfs that will reliably convert to XML when sent for production?

Addendum: Looking further, and after michal.h21's useful answer, I have found several threads on direct conversion of LaTeX to XML or ePub (XML, ePub). I have also found a TUGBoat article about the Neptune system, which is used by publishers for managing the proofing of LaTeX-origin articles.

My inquiry is in a different direction: "What tools can help an author reduce production delays when submitting LaTeX papers (source or pdf output) to an XML-first journal?"

Improve this question

1 Answer 1

Reset to default
5

I am developer of TeX4ht, one of systems used for the LaTeX to XML conversion. The development is in progress, as can be seen from the ChangeLog. It is driven by user requests. I can say that we don't get many requests from publishers, so if they tell you about errors in the conversion, they probably don't think it is necessary to tell developers about issues they face. Errors obviously cannot be fixed without bug reports.

Other issue is that there is lot of different XML flavours, TEI, Docbook, ODT, JATS, etc. Some of them have quite strict requirements regarding document structure. I can say that it can be quite nightmare to debug interaction between LaTeX packages, TeX4ht and validation requirements of various XML formats. It is just too much time consuming to study various specifications that often don't contain examples, so it is hard to understand them often.

For example, I've recently tried to add the basic support for JATS, but it requires specific structure of the document, which doesn't correspond to the structure of usual LaTeX document. Some post-processing using XML transformation tools will be necessary. We have built-in support for such transformations in TeX4ht luckily. But it is not easy process unfortunately. Before I could complete it, I was overwhelmed by bug reports and feature requests from TeX4ht and my other projects, so I haven't found time and energy to progress in this field in the last few months.

So in conclusion:

  1. the best solution is to convert your document to HTML5 or ODT using

    make4ht filename.tex

or

make4ht -f odt filename.tex

Other formats have worse support, simply because there is lack of user requests for them.

  1. There is lot of people who want to convert their documents, but very few who actually work on tools that enable it. The problem is that the conversion is a bit difficult process.

    In TeX4ht there are several separate stages in the conversion process - first we inject some code in LaTeX commands. This code is then used to insert XML tags. We patch LaTeX core and hundreds of packages. This is the hard thing, as you must understand code of the package that you try to modify, and TeX4ht mechanisms.

    Easier part is the configuration of the output formats, because you don't need to be expert in TeX programming for that. Usually, you can just copy configuration for a specific command or environment from HTML configuration file and modify it to use correct XML tags.

Improve this answer
2
  • @michal.21 -- Thank you for this answer and for your work on text4ht. You've described some of the factors that make the conversion difficult to systematically implement (e.g., by the production vendor). My question (1) comes the perspective of an author submitting a paper (not the person converting it) -- what steps can I take in writing my LaTeX source that would reduce the number of problems for the person converting?
    – John
    Jun 24, 2020 at 12:28
  • @John I guess from the author perspective, there is not much you can do, as each producer has unique workflow and you cannot know what they do with your file. So one thing you can do is to test your document with make4ht from the beginning, to see if it can be compiled at all. The odt file can be converted to DOCX, so if they really want Word file, you can at least produce it from your document. It is always better to try to produce the XML document from the beginning, as you may find some issues that are easier to fix at that moment than when you already have full text.
    – michal.h21
    Jun 24, 2020 at 12:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .