You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2002/03/16 14:52:46 UTC
Area tree -> renderer
My comments earlier about the area tree and page description languages
have started me thinking about the topic. The way I see it, there's no
daylight between the area tree and the renderer(s). I was talking about
the output from the area tree being a PDL, but Postscript and PDF are
page description languages. The term renderer is misleading. Acrobat
is the renderer; the PS driver, be it Ghostscript, the software in a
printer or something else, is the renderer. The last stage of the FOP
process translates one page description (the area tree) into another
(the input to the target renderer.)
So why would anyone want to interpose another translation step into this
tightly coupled arrangement? Who knows? But let's say that you do.
What would you use? You could express the area tree in xml and churn
that out. Maybe you want to loosely couple a renderer, using SAX
events. The point is, you are passing a page description language
instance across the interface. Furthermore, it's a pdl with some severe
limitations, because is was designed to be tightly coupled with an fo
tree processor and a layout engine. If you want a pdl to pass across
the interface, why not pick one that is well understood, widely
supported, and that does an excellent job of describing pages. E.g.,
Postscript. It's text, like xml. Unlike xml it has elaborate
pre-defined semantics, so there are only certain targets that it makes
any sense to direct it to; printers for example.
You get my drift, I'm sure. To me, it seems a waste of time to
translate the internal representation of the area tree into an external
representation which is then used to reconstruct something like the area
tree as input to a pdl generator. Note the sleight-of-hand in
"something like". The area tree does have to be flattened into a linear
series of drawing instructions, and if there were any place for
externalising the area tree, it would be the output of this flattened
structure.
I would see that flattened structure expressed in an API, however, and
would take advantage of it to construct a stream destined to cross that
particular API boundary into a snap-on pdl generator.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Area tree -> renderer ("pr.fo" for structure renderers)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi Peter,
On Monday 18 March 2002 22:06, Peter B. West wrote:
>. . .
> There's another gotcha - markers. The properties in markers are
> resolved relative to the retrieve-marker invocation point.
>. . .
Thanks - I'll keep this in mind when I get to play with this stuff..
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Area tree -> renderer ("pr.fo" for structure renderers)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Bertrand,
There's another gotcha - markers. The properties in markers are
resolved relative to the retrieve-marker invocation point.
Peter
Bertrand Delacretaz wrote:
>On Monday 18 March 2002 13:37, Peter B. West wrote:
>
>>The big problem is in defining the p.res step. How far do you need
>>to go with this? If you require all of the relative lengths
>>resolved, e.g., you'll have to wait until the layout is done. The
>>properties are only finalised as the area tree is being constructed.
>>It's one of the things that makes this all so frustrating.
>>
>
>ok I see.
>I'll try to play with this for RTF rendering based on jfor, to get a
>feel for how hard/useful this is.
>
>In case of jfor, what is needed is mostly property inheritance, for
>which AFAIK rules are well defined in FOP.
>
>I guess relative lengths will probably stay relative in the RTF code,
>but I'll have to play with it to be positive about this.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Area tree -> renderer ("pr.fo" for structure renderers)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 18 March 2002 13:37, Peter B. West wrote:
>. . .
> Bertrand Delacretaz wrote:
> >In conclusion, I think an interface based on XML documents (possibly
> >this "pr.fo" discussed above) is the best choice to use between the
> > FOP "property resolution" stage and the "structure renderers" like
> > RTF and MIF renderers.
>
> The big problem is in defining the p.res step. How far do you need
> to go with this? If you require all of the relative lengths
> resolved, e.g., you'll have to wait until the layout is done. The
> properties are only finalised as the area tree is being constructed.
> It's one of the things that makes this all so frustrating.
ok I see.
I'll try to play with this for RTF rendering based on jfor, to get a
feel for how hard/useful this is.
In case of jfor, what is needed is mostly property inheritance, for
which AFAIK rules are well defined in FOP.
I guess relative lengths will probably stay relative in the RTF code,
but I'll have to play with it to be positive about this.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Area tree -> renderer ("pr.fo" for structure renderers)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Bertrand,
See below...
Bertrand Delacretaz wrote:
>On Saturday 16 March 2002 14:52, Peter B. West wrote:
>
>>. . .
>>The last stage of the FOP process translates one page
>>description (the area tree) into another (the input to the target
>>renderer.)
>>
>
>ok
>
>>So why would anyone want to interpose another translation step into
>>this tightly coupled arrangement? Who knows?
>>. . .
>>
>For page-based renderers where FOP has to compute the layout (like for
>PDF output), I don't see a need for another translation step either.
>IMHO asking "who knows" is usually a sign that a feature is not needed
>*at this stage of development*...
>
This was purely for rhetorical effect. My point, developed further in
the original, was that shoe-horning an xml-based externalisation step in
here is probably completely redundant. You have to invent a method of
expressing all of the information contained in the area tree, while
flattening the tree into a series of drawing instructions. If you need
to externalise the area tree, why not externalise it using an already
well-defined page description language. Your externalisation is then
Area Tree -> Well defined PDL
Then attach any translators that you like to the end of that PDL; PDL ->
PDF, PDL -> awt, PDL -> PCL, whatever. By the stage of the translation
to the PDL, XSLFO has done its work. If someone wants to define a PDL
in XML, fair enough; but he has fallen off the end of the spec, and is
creating something new. At least that's the way I see it. And if you
want an already well-defined PDL, with, I assume, a number of converters
already in place, why not Postscript? Maybe even PDF.
>
>OTOH, for structure-based renderers like RTF and MIF, I think the only
>parts of FOP that are reusable are the first two stages: parsing and
>property resolution (apart from infrastructure like logging, config,
>etc. which might come from Avalon in the future?).
>
>Last week we had a talk about using XML to communicate between FOP
>pipeline components, but for me this currently would only make sense
>between the "property resolver" and "structure renderers" components.
>
>The deal is being able to reuse FOP's property resolution (p.res) in
>different contexts. I think the following usage scenarios could greatly
>benefit from reusing FOP's front-end (parser + p.res).
>
>In the following I call "pr.fo" an XSL-FO document where all properties
>(fonts, sizes, etc.) are explicitely written, for example when
>inherited from parents:
>
>a) XSL-FO to RTF conversion:
>FOP parser -> FOP p.res -> pr.fo -> jfor converter
>
>b) XSL-FO to MIF conversion
>FOP parser -> FOP p.res -> pr.fo -> yet-to-write XML-to-MIF converter
>
>c) automated testing of first FOP stages
>FOP parser -> FOP p.res -> pr.fo -> XML testing tool
>
>Keeping in mind that RTF and MIF are formats where the page layout is
>left to the client software to compute (word processor or FrameMaker),
>keeping these converters independent of FOP instead of integrating them
>has several advantages:
>
>b) Helps keep FOP focused on its main task: generating great PDF from
>XSL-FO documents
>
>c) If FOP is ever rewritten in another language for performance, these
>converters, being much less compute-intensive, can stay in java and
>keep the same interface to the FOP components that they use
>
>d) assuming I want to write a MIF converter, basing it on XSL-FO input
>instead of on a FOP API allows me to easily include MIF-specific
>constructs for applications where XSL-FO conformance is not needed but
>precise control of the generated MIF is (often a requirement for MIF
>when producing "half-finished" documents that are typographically
>reviewed before printing).
>
>In conclusion, I think an interface based on XML documents (possibly
>this "pr.fo" discussed above) is the best choice to use between the FOP
>"property resolution" stage and the "structure renderers" like RTF and
>MIF renderers.
>
The big problem is in defining the p.res step. How far do you need to
go with this? If you require all of the relative lengths resolved,
e.g., you'll have to wait until the layout is done. The properties are
only finalised as the area tree is being constructed. It's one of the
things that makes this all so frustrating.
>OTOH I agree that using XML between the layout and rendering stages
>doesn't make sense at this stage of FOP development.
>
Ok.
>
>Due to many other commitments, I don't have time right now (sorry,
>I know you're getting used to hear this) to implement this "pr.fo"
>interface, but if we agree on its usefulness I'll put this high on my
>list and hopefully give it a shot in the next few weeks...
>
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Area tree -> renderer ("pr.fo" for structure renderers)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Saturday 16 March 2002 14:52, Peter B. West wrote:
>. . .
>The last stage of the FOP process translates one page
> description (the area tree) into another (the input to the target
> renderer.)
ok
> So why would anyone want to interpose another translation step into
> this tightly coupled arrangement? Who knows?
>. . .
For page-based renderers where FOP has to compute the layout (like for
PDF output), I don't see a need for another translation step either.
IMHO asking "who knows" is usually a sign that a feature is not needed
*at this stage of development*...
OTOH, for structure-based renderers like RTF and MIF, I think the only
parts of FOP that are reusable are the first two stages: parsing and
property resolution (apart from infrastructure like logging, config,
etc. which might come from Avalon in the future?).
Last week we had a talk about using XML to communicate between FOP
pipeline components, but for me this currently would only make sense
between the "property resolver" and "structure renderers" components.
The deal is being able to reuse FOP's property resolution (p.res) in
different contexts. I think the following usage scenarios could greatly
benefit from reusing FOP's front-end (parser + p.res).
In the following I call "pr.fo" an XSL-FO document where all properties
(fonts, sizes, etc.) are explicitely written, for example when
inherited from parents:
a) XSL-FO to RTF conversion:
FOP parser -> FOP p.res -> pr.fo -> jfor converter
b) XSL-FO to MIF conversion
FOP parser -> FOP p.res -> pr.fo -> yet-to-write XML-to-MIF converter
c) automated testing of first FOP stages
FOP parser -> FOP p.res -> pr.fo -> XML testing tool
Keeping in mind that RTF and MIF are formats where the page layout is
left to the client software to compute (word processor or FrameMaker),
keeping these converters independent of FOP instead of integrating them
has several advantages:
b) Helps keep FOP focused on its main task: generating great PDF from
XSL-FO documents
c) If FOP is ever rewritten in another language for performance, these
converters, being much less compute-intensive, can stay in java and
keep the same interface to the FOP components that they use
d) assuming I want to write a MIF converter, basing it on XSL-FO input
instead of on a FOP API allows me to easily include MIF-specific
constructs for applications where XSL-FO conformance is not needed but
precise control of the generated MIF is (often a requirement for MIF
when producing "half-finished" documents that are typographically
reviewed before printing).
In conclusion, I think an interface based on XML documents (possibly
this "pr.fo" discussed above) is the best choice to use between the FOP
"property resolution" stage and the "structure renderers" like RTF and
MIF renderers.
OTOH I agree that using XML between the layout and rendering stages
doesn't make sense at this stage of FOP development.
Due to many other commitments, I don't have time right now (sorry,
I know you're getting used to hear this) to implement this "pr.fo"
interface, but if we agree on its usefulness I'll put this high on my
list and hopefully give it a shot in the next few weeks...
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org