marker and retrive-marker
Hello, I tried to use the fo:marker and fo:retrive-marker for headers showing the page's chapter and section titles. But no success:-( Is that really completely implemented in FOP-Version 0.20.1 ? If YES: Could someone show me an example? Thanks, and Happy New Year! Sako - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
marker and retrive-marker
Hello, I tried to use the fo:marker and fo:retrive-marker for headers showing the page's chapter titles. But there is always an error. Is that really completely implemented in FOP-Version 0.20.1 ? Can you explain what means the error: marker cannot be added to 'org.apache.fop.fo.flow.Block@4f4a2c' Thanks, and Happy New Year! Sako - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties documentation
Hi Peter, Thanks for the work. Maybe this can go with the rest of the design. I would strongly suggest that you do not write the html. The apache web site is done from xml and all the images, layout etc. is done from a stylesheet. These will also be updated by others. If you look at docs/xml-docs/fop/*.xml this is the xml format. It is converted by stylebook (will become cocoon soon) into the html. On 2001.12.29 02:57 Peter B. West wrote: Dear list, After sepnding some days wrestling with various graphics tools in linux in an attempt to make html that looked like the standard apache documentation, I finally surrendered and made do with CSS to create a facsimile that should be sufficient for this list. It works with a recent Mozilla build, and should probably work with IE5.something. I have made some notes and some semi-UML diagrams to illustrate the approach I have been taking to the implementation of properties. These can be found at http://home.iprimus.com.au/pbwest/xml-fop/docs/html-docs/design/properties-new.html. lease let me know if there is some easy way to get full conformance with the Apache XML norm, or if there are severe problems viewing these pages with modern browsers. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: jfor integration: right after the FO tree building stage?
Hi Bertrand,
The layout methods and how they work are subject to change with the layout
process. So don't read too much from these methods.
A visitor pattern sounds right. Instead of building the fo tree and then
using the layout managers to create an area tree. Use a structure renderer
to read from the fo tree.
Fo each element in the fo tree when creating we call: start,
handleAttributes and end. We should be able to put the visitor in various
sections depending on the type of element and the layout managers may also
be able to operate in the same areas (ie. have a common interface).
We want to be able to process elements as soon as possible and dispose of
used data so it should be something that can work from the area tree at
early stages.
Regards,
Keiron.
On 2001.12.17 13:53 Bertrand Delacretaz wrote:
Hi team,
I started looking at the FOP source code in more detail last week, and
from
what I understand at this point I think it would make sense to integrate
jfor
as a structure renderer right after the FO Tree building stage.
At this point my idea would be to:
a) add a Visitor pattern mechanism to visit the FOTree independently of
layout operations
b) split layout() methods in two, adding a method called
getProperties() or
something (see details below)
c) implement a Visitor that would generate RTF from the FOTree, calling
getProperties() on the way
d) maybe having getProperties() do its work only once even if called
multiple
times, and calling it both before the Visit and at the start of layout()
Of course, this shouldn't be limited to jfor, the FOTreeVisitor should be
reusable for other output formats.
Does this sound like I'm on the right track?
- Bertrand
Appendix: layout() method discussion.
For what I've seen in the source code, some computations (property
resolution, if I understand right) done in the layout() methods would
need to
be moved to a pre-layout stage: maybe breaking layout() in two.
Taking flow.Block as an example:
void layout()
{
. . .stage 1): properties acquisition
this.align = this.properties.get(text-align).getEnum();
this.alignLast = this.properties.get(text-align-last).getEnum();
this.breakAfter = this.properties.get(break-after).getEnum();
. . .more property reading
. . .stage 2): actual layout
int breakBeforeStatus = propMgr.checkBreakBefore(area);
. . .
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
