[texhax] automated document processing (was Re: tex vs latex)

William Adams will.adams at frycomm.com
Fri Oct 30 12:40:30 CET 2009

On Oct 28, 2009, at 6:57 PM, C.A.Rowley at open.ac.uk wrote:

> Why have the fundamental processes of automated document processing  
> at most levels progressed not at all during that same period?  (I  
> exclude font technologies from this indictment.)

It's a hard problem, and one which few companies are willing to invest  

Commercial software developers have to sell software which users are  
able to learn, and are willing to use, so one ends up w/ naïve users  
treating computers are glorified memory typewriters w/ advanced  
features ignored or mis-used.

Software is tested and evaluated in periodicals by journalists who  
find it easier to manage a long list of features and yes / no  
checkboxes than any sort of in-depth evaluation of how a system works  
and can be used most efficiently.

That said, the fundamentals of this are kind of invariant, aren't they?

Typography ultimately devolves to key-value pairs of text and markup  
and how one processes that.

The best markup scheme I've found is TEI: http://www.tei-c.org/ 
index.xml and there're some neat tools for converting that to LaTeX.  
(I hope that there will be some direct integration w/ LaTeX-3?)

An open-ended rant about difficulties in the industry:

  - no way to encode index entries in XML and have them set as such in  
  - no flexible space before heads in InDesign w/o resorting to  
scripts which often require manual intervention
  - no way to conditionally insert graphics in InDesign (actually, one  
can't get graphics in when using Adobe Tagged Text and if one uses  
XML, one can't get in index entries, so one has to resort to hybrid  
work-flows and proprietary tools like XTags)
  - tools which focus on allowing the user to do things like  
instantiate 45 different spot colours in a file w/ a single menu  
command rather than automating processing colours, &c. (Adobe  
Illustrator to name names)
  - no way to encode graphic sizes in html using relative sizes (ems)  
when using CSS or any other system I've found
  - RIPs which will not honour a request to provide a .pdf at a  
particular Adobe Acrobat compatibility level

(there, my week in a nutshell)

By contrast, TeX / LaTeX (and ConTeXt and other variants) work, are  
extensible and the only limits to what one can do w/ them are human  
ingenuity and available computer processing power and storage capacity.


William Adams
senior graphic designer
Fry Communications
Sphinx of black quartz, judge my vow.

More information about the texhax mailing list