OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: The problem with typography (with or without flow objects)

[ Lists Home | Date Index | Thread Index ]
  • From: "Eve L. Maler" <Eve.Maler@east.sun.com>
  • To: xml-dev@xml.org
  • Date: Wed, 14 Jun 2000 10:41:01 -0400

At 09:23 AM 6/14/00 +0100, Sebastian Rahtz wrote:
>Eve L. Maler writes:
>  > In my days as a technical editor, we were forced, over and over, to make
>  > decisions that increased the accuracy and quality of information to the
>  > detriment of their beauty.
>Sounds good to me. Not sure how it relates to FO?

FOs aren't a page description language; they just provide rules.  Any one 
back end will produce slightly (or wildly) different results.  So a 
production system that uses FOs to increase efficiency and interoperability 
will probably continue in the direction of worrying about turnaround while 
giving shorter shrift to page beauty.  This isn't guaranteed, of course, 
but can you imagine pumping RTF out of your FO-based system and then going 
through and hand-fixing 2-3 items per page to your satisfaction, *each* 
time you publish?  Only marketing-ish material gets this treatment these days.

>  >  It used to take 4 to 6 weeks to send
>  > camera-ready copy, get salt prints back, check for (can you be-LEEVE?)
>  > broken type/orphans/widows, review corrections, blah, blah, blah.
>excellent. I bet the documents were better as a result

Well, no.  They had no broken type, but their content was a few weeks more 
"stale" than the software they described.  Our Read Me First documents were 
*huge* in those days.  According to our customers, this was not "better"; 
it was worse than slightly less lovely documents that had fewer errors.

>Knuth would point you at literate programming, and ask why the docs
>were separated from the code in the first place.

For each audience, the hierarchy of topics may be wildly different from the 
software hierarchy, so this is appropriate only for a small subset of the 
documentation.  I challenge anyone to write anything other than 
programmers' references using things like JavaDoc; conceptual material, 
users' guides, etc. simply wouldn't work well done this way.

Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center    elm @ east.sun.com

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS