xsl-list
[Top] [All Lists]

Re: [xsl] Prince XML vs Docbook

2018-01-19 09:56:57
I'm not as savvy as you folks, but having done some work with XML workflows in 
STM publishing, I see several factors that keep publishers from getting behind 
either FO or CSS solutions. 

First is an attachment to nearly un-automatable print-legacy layout: pages that 
have four or five elements that need to grow or shrink in relation to each 
other, 3-column ragged right pages in a journal with equations, all sorts of 
content that needs to go into footers and margins, footnotes that start on page 
1 but, if too long, may continue in a space above the references. By the time 
you mention multi-pass processing, people have left the room.

Second is lack of an easily editable intermediate format, both for problem 
solving and for tweaking. Someone with a few hours of experience in InDesign 
can break an equation or move a figure from page 3 to page 2, and they can do 
it in a few minutes. Solving the same problems in automated systems is more 
difficult and requires a rarer skill set.

Third is the variability of input, which others have already mentioned, and how 
it interacts with the first two issues.

That said, I've seen some dirt-simple layouts that still use 3B2 (or whatever 
it's called now). My impression is that publishers don't want to give up the 
safety net that cheap offshore typesetting gives them. 

-Charles

*****************************************

From: Michael Kay mike(_at_)saxonica(_dot_)com 
[mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com] 
Sent: Thursday, January 18, 2018 2:02 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Prince XML vs Docbook


On 18 Jan 2018, at 17:06, Eliot Kimber mailto:ekimber(_at_)contrext(_dot_)com 
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

There’s no inherent reason CSS pagination has to be mediocre. 
 
My observation is it’s another case of simply not having enough resources 
available to get the work done.

I think you've just given the inherent reason. Getting the resources to do a 
high quality job for people with high-end requirements requires significant 
investment. Getting the resources to do a mediocre job (by which I mean, to 
satisfy the needs of those who aren't very fussy) is much easier.

(I wasn't trying to suggest there's any architectural problem with a CSS-based 
solution. Just that the economics always favours meeting the 50% of the 
requirements that are enough to satisfy 90% of the users, and stopping there.)

Michael Kay
Saxonica
http://www.mulberrytech.com/xsl/xsl-list 
-list/2963104 () 
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>