Re: Customer requirement, a critque

On 02/25/2013 02:32 AM, Patrick Gundlach wrote:
> Am 24.02.2013 um 22:23 schrieb Arved Sandstrom <arved.sandstrom@magiclampsoftware.net>:
>
>> I think my thinking aligns with Patrick, high-level. Where I may differ - probably do - based in having been a programmer since the mid-70's, is that we can provide a more interactive solution based on FO. We just have to provide more control over the formatting process.
>
> I'd be very interested in seeing a theoretical model how for example requirement 4,5 or 6 will be typeset with (a future version of) XSL-FO. How do you get renderer feedback?
#6 is quite simple, provided that you have FO (as in XML FO) support for 
properties *feedback* (reading values and applying actions), or the 
equivalent in a programmatic API. I shared some thoughts about #6 in a 
very recent post.

#5 I think I'd like to see worded maybe more precisely. Maybe some 
precise explanation of the provenance of those "filler" images. But can 
I think of a theoretical construct already? I think so. Simply the 
ability to specify multiple streams of content, under controlled 
conditions like space filling, say, into a region. So the next level of 
granularity below flows mapped to regions.

#4, and referring to your below, there's nothing that stipulates a 
single pass A -> B -> C processing model in FO formatting and rendering. 
It may be common to do that just because it handles current FO 
constructs and it's simpler to code up. But it's not engraved in stone. 
But extending this out to scenarios that I think your #4 likely falls 
into, to me that's a 2-pass situation that you handle explicitly as 
such, no feedback per se but simply properties reporting in the first pass.
> AFAICS the current standard workflow for XML to PDF with XSL-FO is:
>
> A) create "enriched" XML from a data source and layout instructions, possibly with XSLT or some other program.
> B) put this enriched XML into the renderer
> C) get the PDF and be happy :)
>
> so a strict  A -> B -> C model. IMO you need a very close interaction between A and B to do more advanced layout. It would then be more something like this:
>
>    A -> B -> A -> B -> A -> B -> A -> B -> C
>
> And then I have a hard time to see how this can be compared to existing XSL-FO 1.1 workflows.
>
>
> (additional note:)
> And by my exaggerated comment that XSL-FO is a dead end, I just want to point out that the computational model (= no renderer feedback) does not work for the more advanced requirements. I really do see the usefulness of XSL-FO and I think having a 2.0 standard is reasonable), but XSL-FO is in the same layout class of Markdown, HTML and other simple formatting languages. I.e user creates contents + layout wishes + renders it and hopes that the outcome will be 'all right'. I think we can do better and agree on a different class of layout engines.
>
>
I think you do need that feedback, yes.

Arved

Received on Monday, 25 February 2013 07:24:51 UTC