Re: Customer requirement, a critque

Am 24.02.2013 um 17:00 schrieb Dave Pawson <dave.pawson@gmail.com>:

> On 24 February 2013 14:26, Patrick Gundlach <gundlach@speedata.de> wrote:
> 
>>>> I am not sure why you use the term "fo:blocks". As far as I know, this is not a special FO community. The Customer requirements are independent of a special technology.
>>> 
>>> I relate requirements to the xsl-fo wd. Hence requirements are for
>>> implementation against that document
>>> or a later version of it.
>> 
>> I think that most of the requirements are not solvable with any current or future version of XSL-FO, unless XSL-FO changes in a dramatic way.
> 
> Which is why we are here? to specify those changes?
> 
> Or are we here for different reasons?

I am not here to specify changes to XSL-FO 1.1. 
I am here to discuss how we can meet current typesetting / layout demands. I believe thinking in FO terms just blocks our mind to get to the point where we should head.

Don't know about the others. This is (of course) my very own personal motivation. 




Just to have a look at the current situation. If I need to create a pdf document from a data source (text document, product catalogs, data sheets, price lists etc) I see the following possibilities:

1 InDesign, QuarkXPress or any other DTP software, optionally using plugins to automate the page filling process.
2 Any other similar software (Word, Excel, whatever_document_generation_Gui_application)
3 A specialized typesetting system such as TeX, 3b2 / arbortext
4 some web2print software such as princexml
5 Do your own in ruby/perl/c#/... with a PDF library
6 XSL-FO

any others? Probably, but I think the above list covers 90% of the current mechanisms.

AFAICS none of these approaches cover a) 100% automation b) nice DTP features for beautiful documents c) provide enough building blocks to keep layout building to a reasonable amount of time/code.

Our great chance is to jump in and provide the industry / the users a standard that covers the above requirements. I think 1) InDesign is very close to setting a de-facto standard for document processing and we shouldn't give this field to adobe alone. 2) Word and co. are more used than we like. 3)  TeX has excellent capabilities to meet all of the above, but the programming is pretty much insane. I don't know much about arbortext, so I cant' comment on that. 4) is not worth discussing, won't be able to handle any of our requirements. 5) will meet all of the above, but we won't be able to talk about any standardized way. 6) Well, it does not handle the given requirements. Although I wish it would.


Patrick


(sorry Dave for the double post)

Received on Sunday, 24 February 2013 18:32:24 UTC