[
Lists Home |
Date Index |
Thread Index
]
- From: Marcus Carr <mrc@allette.com.au>
- To: xml-dev@xml.org
- Date: Tue, 13 Jun 2000 09:44:05 +1000
Peter Murray-Rust wrote:
> If we want high-quality print I can only think of the following:
> - Develop XSL-FO and one or more FOP-like solutions
> - Use TeX as an intermediate
> - Tear up the current XSL-FO and try again
Anyone reading that would probably be amazed to know that SGML data has actually made
it to paper over the past couple of decades without the aid of TeX. :-)
Seriously, you overlook at least two well established practices - one is using a tool
like FrameMaker+SGML to generate hardcopy. Its typesetting capabilities are well
regarded amongst professional publishers, so the addition of structure made it a
powerful authoring environment, insulating the user from having to understand DTDs,
etc. The second is writing code to turn the data into something that a typesetting
engine can render - before you discount that, remember that you already have to do
this to create FOs.
The really nasty issue is that two applications making use of FOs are not required to
produce identical results. This reflects the fact that writing a good typesetting
engine is very difficult. People who have been involved with typesetting for any
reasonable period of time accept that, and avoid problems by allowing themselves to be
tied to a specific workflow in order to obtain a specific result. For example, suppose
you had converted XML to RTF for print, then your customer phoned you to complain that
their pages didn't look like the ones that they had signed off on. They're not
importing the RTF into Word, but that shouldn't matter, right...
The likely outcome is that FO data gets shipped with a "Best results with FO-bar
version 1.0", just as now (informally) happens with other typesetting data. Believing
that anything else will be acceptable flies in the face of what is currently
acceptable practice with relation to the creation of data for hardcopy. If FO data was
specifically created for a single application, why would I use it instead of just
going directly to the syntax that the application dealt with anyway? (I don't consider
portability to be a good reason - if the application is being used purely as an
automated page generator, there is little reason to change it.) The whole idea of FO
trivialises typesetting issues by adopting the approach that near enough is good
enough. Imagine the reaction of programmers if an stream editor made subtle changes to
their code, or for a scientist, if an application chose to render your complex formula
slightly differently than it was created - that's the equivalent of what typesetters
will be expected to accept with FO documents.
--
Regards,
Marcus Carr email: mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia) www: http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
- Einstein
***************************************************************************
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/
***************************************************************************
|
