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 Stephan Thesing <th...@gmx.de> on 2009/09/02 20:22:21 UTC
Re: Implementing Change bars
Hello,
just a short status / question update.
I have added the fo:change-bar-begin/end elements with their properties.
Validation is also implemented, but:
- In contrast to the other fo: elements, the change-bar-* elements
are allowed to occur everywhere, as long as they have an
fo:flow or fo:static-content ancestor.
All the elements do their content validation via validateChildNode()
(e.g. Block.java in o.a.fop.fo.flow).
As I didn't want to add acceptance of change-bar-* children to all
fo: elements under o.a.fop.fo.flow, I added to FNode.java a
validateChildNodeGlobal() function that performs the "global"
check for change-bar-* children and then calls validateChildNode()
to perform the local check for each element.
in FOTreeBuilder.java this is then called instead of
validateChildNode().
The version of validateChildNodeGlobal() applicable for change bars
is added in FObj.java
Validation of the stacking constraints of change-bar-begin and -end are
also done.
Error messages and codes for validation errors are also already added.
What remains is layout and producing the change bar areas.
If I read the spec right, the intended semantics of the change-bar-elements is the following:
- for all elements generating areas that are under the influence of
a change bar, add fixed areas as tall as the generated areas and
placed beside the column of that area as given by the change bar
properties.
- "being under the influence of a change bar" is defined by the file
order of elements in the input.
I.e., any element between a change-bar-start and corresponding change-bar-end (same class) is influenced by that change bar.
For me, that means that an element can be under the influence of multiple change bars, naturally.
My idea is now along the following lines:
- Remember for each element during parsing the change bars it is influenced by.
- After layout, go over all areas produced by those influenced elements
and add the areas for the change bars (thus, only an area with proper
border attributes).
Can this be realizes in such a way in FOP?
I appreciate any comments and suggestions!
I will be able to produce a first diff of my code this weekend.
Best regards...
Stephan
> - retrieving the start- and end locations of the bars during layout
> (org.apache.fop.layoutmgr)
> - creating the appropriate areas (will probably have to be done in
> o.a.f.layoutmgr.PageSequenceLayoutManager)
>
> That should be enough to get you started. If you have any question, see
> you on fop-dev!
>
> Vincent
--
Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 München
GERMANY
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
RE: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
try this...
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:r="http://nwalsh.com/xmlns/extreme2006/recipes/"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:fn="http://www.w3.org/2005/xpath-functions"
xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:template match="data">
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master master-name="A4" page-height="11in"
page-width="8.5in" margin-top="0.5in" margin-left="0.5in"
margin-right="1.0in">
<fo:region-body region-name="xsl-region-body" margin-top=".6in"
margin-bottom="1in" overflow="auto"/>
<fo:region-before region-name="xsl-region-before" extent="1in"/>
<fo:region-after region-name="xsl-region-after-last-even"
extent="0.75in"/>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="A4">
<fo:flow flow-name="xsl-region-body">
<xsl:apply-templates/>
</fo:flow>
</fo:page-sequence>
</fo:root>
</xsl:template>
<xsl:template match="p">
<fo:block>
<xsl:call-template name="rev.bar"/>
<xsl:attribute name="margin-top">5px</xsl:attribute>
<xsl:attribute name="margin-bottom">5px</xsl:attribute>
<xsl:choose>
<xsl:when test="parent::note">
<fo:block start-indent="1.5in" end-indent="1.5in">
<xsl:apply-templates/>
</fo:block>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates/>
</xsl:otherwise>
</xsl:choose>
</fo:block>
</xsl:template>
<xsl:template match="note">
<fo:block>
<xsl:attribute name="text-align">center</xsl:attribute>
<xsl:attribute name="font-size">10pt</xsl:attribute>
<xsl:attribute name="font-weight">bold</xsl:attribute>
<xsl:apply-templates/>
</fo:block>
</xsl:template>
<xsl:template name="rev.bar">
<xsl:if test="@rev">
<xsl:attribute name="border-start-color">black</xsl:attribute>
<xsl:attribute name="border-end-color">white</xsl:attribute>
<xsl:attribute name="border-after-color">white</xsl:attribute>
<xsl:attribute name="border-start-style">solid</xsl:attribute>
<xsl:attribute name="padding-start">13pt</xsl:attribute>
<xsl:attribute name="border-start-width">2pt</xsl:attribute>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38772.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
using start-indent or end-indent on the fo:block has the same result as using margin
using padding does not work either the padding-left / padding-right has no effect on the text
Thanks,David
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38771.html
Sent from the FOP - Users mailing list archive at Nabble.com.
RE: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
Dont use margins, use start-indent or end-indent on the fo:block instead of
margin.
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38770.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
Hi, your sample works because you removed the left and right margin from the "note" fo:block. I need this margin.
The layout for a note and many other elements need to be indented.
any suggestions?
David
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38763.html
Sent from the FOP - Users mailing list archive at Nabble.com.
RE: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
See below. The key is how you set up your page layout.
<data>
<p rev="1">text with revbar</p>
<note>
<p>text in a note No revbar</p>
<p rev="1">text in a note with revbar</p>
</note>
<p>no rev bar</p>
</data>
xslt:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:r="http://nwalsh.com/xmlns/extreme2006/recipes/"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:fn="http://www.w3.org/2005/xpath-functions"
xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:template match="data">
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master master-name="A4" page-height="11in"
page-width="8.5in" margin-top="0.5in" margin-left="0.5in"
margin-right="1.0in">
<fo:region-body region-name="xsl-region-body" margin-top=".6in"
margin-bottom="1in" overflow="auto"/>
<fo:region-before region-name="xsl-region-before" extent="1in"/>
<fo:region-after region-name="xsl-region-after-last-even"
extent="0.75in"/>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="A4">
<fo:flow flow-name="xsl-region-body">
<xsl:apply-templates/>
</fo:flow>
</fo:page-sequence>
</fo:root>
</xsl:template>
<xsl:template match="p">
<fo:block>
<xsl:call-template name="rev.bar"/>
<xsl:attribute name="margin-top">5px</xsl:attribute>
<xsl:attribute name="margin-bottom">5px</xsl:attribute>
<xsl:apply-templates/>
</fo:block>
</xsl:template>
<xsl:template match="note">
<fo:block>
<xsl:attribute name="text-align">center</xsl:attribute>
<xsl:attribute name="font-size">10pt</xsl:attribute>
<xsl:attribute name="font-weight">bold</xsl:attribute>
<xsl:apply-templates/>
</fo:block>
</xsl:template>
<xsl:template name="rev.bar">
<xsl:if test="@rev">
<xsl:attribute name="border-start-color">black</xsl:attribute>
<xsl:attribute name="border-start-style">solid</xsl:attribute>
<xsl:attribute name="padding-start">13pt</xsl:attribute>
<xsl:attribute name="border-start-width">2pt</xsl:attribute>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38762.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
here is a simplified fully functioning xml and xsl.
ThanksDavid
xml
<data>
<p rev="1">text with revbar</p>
<note>
<p>text in a note No revbar</p>
<p rev="1">text in a note with revbar</p>
</note>
</data>
xsl
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:r="http://nwalsh.com/xmlns/extreme2006/recipes/"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:fn="http://www.w3.org/2005/xpath-functions"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
version="1.0">
<xsl:template match="data">
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master master-name="A4">
<xsl:attribute name="margin">10mm 13.5mm 10mm 25mm</xsl:attribute>
<xsl:attribute name="page-width">215.9mm</xsl:attribute>
<xsl:attribute name="page-height">279.4mm</xsl:attribute>
<xsl:attribute name="font-family">Helvetica</xsl:attribute>
<fo:region-body region-name="xsl-region-body">
<xsl:attribute name="margin">21mm 0mm 9.5mm 0mm</xsl:attribute>
</fo:region-body>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="A4">
<fo:flow flow-name="xsl-region-body">
<xsl:apply-templates />
</fo:flow>
</fo:page-sequence>
</fo:root>
</xsl:template>
<xsl:template match="p">
<fo:block>
<xsl:call-template name="rev.bar" />
<xsl:attribute name="margin-top">5px</xsl:attribute>
<xsl:attribute name="margin-bottom">5px</xsl:attribute>
<xsl:apply-templates />
</fo:block>
</xsl:template>
<xsl:template match="note">
<fo:block>
<xsl:attribute name="text-align">center</xsl:attribute>
<xsl:attribute name="font-size">10pt</xsl:attribute>
<xsl:attribute name="font-weight">bold</xsl:attribute>
<xsl:attribute name="margin">2mm 37mm 0mm 37mm</xsl:attribute>
<xsl:apply-templates />
</fo:block>
</xsl:template>
<xsl:template name="rev.bar">
<xsl:if test="@rev='1'">
<xsl:attribute name="border-start-color">black</xsl:attribute>
<xsl:attribute name="border-start-style">solid</xsl:attribute>
<xsl:attribute name="padding-start">13pt</xsl:attribute>
<xsl:attribute name="border-start-width">2pt</xsl:attribute>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
RevBarSample.zip (12K) <http://apache-fop.1065347.n5.nabble.com/attachment/38756/0/RevBarSample.zip>
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38756.html
Sent from the FOP - Users mailing list archive at Nabble.com.
RE: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
Hi David,
I would need to see a sample of the xml as well as the xslt to help more.
But basically you need to use XSLT axes
http://www.w3schools.com/xpath/xpath_axes.asp
<http://www.w3schools.com/xpath/xpath_axes.asp> to test node conditions.
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38739.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
I am sorry, i did not understand.
if I put the rev.bar template on the note how would I check when the first p in the note does not need a rev bar and the second does.if my understanding of xslt is correct, in this sample the code would only get to the note template 1 time.
my expected result needs to look like this
NOTE text in a note No revba | text in a note with revbar Where the "NOTE" and all the p tags under the note are text align centered, and on the indivdual p tags that need rev bar would have it in the margin of the page Thanks again for your inputs David
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38738.html
Sent from the FOP - Users mailing list archive at Nabble.com.
RE: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
Hi David,
Remember you are using XSLT. You can wrap the rev.bar template call in a
choose/if statement and check if a condition is met to apply the template
rev.bar.
e.g. if child::p/@change='true' ....
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38737.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
But the note template does not need a revbar only the second P needs the revbar
David
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38736.html
Sent from the FOP - Users mailing list archive at Nabble.com.
RE: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
Note sure if this work, but try calling <xsl:call-template name="rev.bar" />
on the the note template.
<xsl:template match="note">
<fo:block xsl:use-attribute-sets="atsNote">
<xsl:call-template name="rev.bar" />
<xsl:apply-templates />
</fo:block>
</xsl:template>
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38735.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
This works great when the element that needs the change bar is not nested in an element that has a left margin. Any advise on how to implement when my block is nested and the ancestor has set margin
example :-------------------------<data> <p rev="1">text with revbar</p> <note> <p>text in a note No revbar</p> <p rev="1">text in a note with revbar</p> </note></data>
....<xsl:template match="note"> <fo:block xsl:use-attribute-sets="atsNote"> <!-- ( atsNote = <xsl:attribute name="margin">2mm 37mm 0mm 37mm</xsl:attribute>) --> <xsl:apply-templates /> </fo:block></xsl:template>
<xsl:template match="p"> <fo:block> <xsl:call-template name="rev.bar" /> <xsl:apply-templates /> </fo:block></xsl:template>.....
The p that is out of the note works well, however in the note does not. The Note is just one example of an ancestor block that effects the margins there are many others so I dont want to create a template match for "note/p"
Thanks,David
Date: Tue, 18 Jun 2013 07:33:37 -0700
From: ml-node+s1065347n38720h99@n5.nabble.com
To: drevivo@hotmail.com
Subject: RE: Implementing Change bars
the outer most fo:block...
If should work with alternating page margins. My odd pages have a 1 inch margin on the left and my even has a 1in margin on the right and it works.
If you reply to this email, your message will be added to the discussion below:
http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38720.html
To unsubscribe from Implementing Change bars, click here.
NAML
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38728.html
Sent from the FOP - Users mailing list archive at Nabble.com.
RE: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
the outer most fo:block...
If should work with alternating page margins. My odd pages have a 1 inch
margin on the left and my even has a 1in margin on the right and it works.
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38720.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
Thanks for the quick response.
what element are these attributes getting set on?
I have nested fo:blocks that have margins, and I need the change bar to always be in the same location in the page margin (right or left side depending on even or odd page)
Date: Tue, 18 Jun 2013 05:48:44 -0700
From: ml-node+s1065347n38718h37@n5.nabble.com
To: drevivo@hotmail.com
Subject: Re: Implementing Change bars
I have been able to use the following with XSLT to render change bars with much success:
<fo:block>
<xsl:call-template name="rev.bar"/>
.....
<xsl:template name="rev.bar">
<xsl:if test="(matches($changetype, 'changed') or matches($changetype, 'revised') or matches($changetype, 'revised-pending') or matches($changetype, 'modify')) and not(matches($changetype, 'new'))">
<xsl:attribute name="border-end-color">black</xsl:attribute>
<xsl:attribute name="border-after-color">white</xsl:attribute>
<xsl:attribute name="border-before-color">white</xsl:attribute>
<xsl:attribute name="border-end-style">solid</xsl:attribute>
<xsl:attribute name="font-family" select="$default-font"/>
<xsl:attribute name="padding-end">13pt</xsl:attribute>
<xsl:attribute name="border-end-width">2pt</xsl:attribute>
</xsl:if>
</xsl:template>
If you reply to this email, your message will be added to the discussion below:
http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38718.html
To unsubscribe from Implementing Change bars, click here.
NAML
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38719.html
Sent from the FOP - Users mailing list archive at Nabble.com.
Re: Implementing Change bars
Posted by Bonekrusher <dj...@yahoo.com>.
I have been able to use the following with XSLT to render change bars with
much success:
<fo:block>
<xsl:call-template name="rev.bar"/>
.....
<xsl:template name="rev.bar">
<xsl:if test="(matches($changetype, 'changed') or matches($changetype,
'revised') or matches($changetype, 'revised-pending') or
matches($changetype, 'modify')) and not(matches($changetype, 'new'))">
<xsl:attribute name="border-end-color">black</xsl:attribute>
<xsl:attribute name="border-after-color">white</xsl:attribute>
<xsl:attribute name="border-before-color">white</xsl:attribute>
<xsl:attribute name="border-end-style">solid</xsl:attribute>
<xsl:attribute name="font-family" select="$default-font"/>
<xsl:attribute name="padding-end">13pt</xsl:attribute>
<xsl:attribute name="border-end-width">2pt</xsl:attribute>
</xsl:if>
</xsl:template>
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38718.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Implementing Change bars
Posted by drevivo <dr...@hotmail.com>.
Hi Stephan,
I wanted to know if this feature was checked in.
Thanks,
David
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/Implementing-Change-bars-tp16058p38717.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Implementing Change bars
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Stephan,
Stephan Thesing wrote:
> Hello,
>
<snip/>
>>> My idea is now along the following lines:
>>> - Remember for each element during parsing the change bars it is
>> influenced by.
>>> - After layout, go over all areas produced by those influenced elements
>>> and add the areas for the change bars (thus, only an area with
>> proper
>>> border attributes).
>> It all depends on how this is implemented, therefore I’m awaiting your
>> patch. But that seems to imply a two-pass process that I’m not sure we
>> want. Imagine a change-bar that starts on page 2 and ends on page 50. We
>> don’t want to wait that the areas for page 50 have been created to add
>> the change-bar areas on page 2.
>
> I don't pretend to really understand the layout in FOP yet, but my basic
> understanding was:
> - As soon as a page-sequence has been parsed, it is layouted, the
> layout managers are created.
> - When a page has been filled (approx), little adaptations are done,
> the area tree for that page is complete and can be rendered.
This doesn’t exactly happen like this, although that doesn’t change much
of what you would have to do.
FOP implements a total-fit algorithm. Basically, instead of creating one
page at a time, it optimises the layout over the whole page sequence. It
does so by playing with elastic spaces between blocks in order to
homogenise pages. Suppose that a big unbreakable block doesn’t fit on
page 10 and must be deferred to page 11. By slightly increasing vertical
spaces between earlier blocks, content can progressively be shifted to
the following page until page 10 is reached, and fill up that latter
instead of leaving it half empty.
So the actual layout of page 1 may actually not be known until the very
end of the page sequence has been reached.
I must actually refine my concern above: at the moment, a two-pass
process would degrade performance only if a change-bar encompasses
several page sequences, which I guess would rarely happen. Still, if
later on we want to implement a lower quality, lower resource demanding
layout process, we wouldn’t want such a two-pass process.
<snip/>
> BTW, as far as I understand FOP, the area tree is never used for RTF output, but rather the event mechanism is used, that notifies the RTF backend for start/end of fo elements, which are then directly transfered into RTF.
> Thus, the change bar stuff tied to the areas will not work for RTF and
> extra code has to be added to the RTF backend to handle the change bars.
If you don’t need change bars for RTF output, then don’t worry about it.
If that were depending only on me the RTF backend would have been
deprecated long time ago :-) It doesn’t fit well in the rest of FOP and
anyway is no longer so much useful now that ODF, among others, is
around.
Vincent
Re: Implementing Change bars
Posted by Stephan Thesing <th...@gmx.de>.
Hello,
> The area tree described in the Recommendation is non-normative,
> therefore we are free to deviate from it as long as the final visual
> result is the same.
>
> And I’m actually not keen on the idea of generating a change-bar area
> for /each/ area under the influence of a change bar. This will give many
> overlapping areas (for example an fo:block produces a normal area, plus
> possibly a line-area, which will itself contain many inline areas. If
> a change-bar area must be generated for each of them...). The visual
> result is likely to look non-continuous, as the borders of a table for
> which we have already had complaints. Ideally a single area would be
> generated on each column.
yes, this would be merging of the generated areas, which should be easy
enough.
> > My idea is now along the following lines:
> > - Remember for each element during parsing the change bars it is
> influenced by.
> > - After layout, go over all areas produced by those influenced elements
> > and add the areas for the change bars (thus, only an area with
> proper
> > border attributes).
>
> It all depends on how this is implemented, therefore I’m awaiting your
> patch. But that seems to imply a two-pass process that I’m not sure we
> want. Imagine a change-bar that starts on page 2 and ends on page 50. We
> don’t want to wait that the areas for page 50 have been created to add
> the change-bar areas on page 2.
I don't pretend to really understand the layout in FOP yet, but my basic
understanding was:
- As soon as a page-sequence has been parsed, it is layouted, the
layout managers are created.
- When a page has been filled (approx), little adaptations are done,
the area tree for that page is complete and can be rendered.
Here, as soon as the page has been really created, one can add the change bar areas to it and render it.
The general problem with the change bars is that they don't create any
areas in themselves but rather add a property to each fo element between
the begin and end marker. That property being that a change bar should
accompany the element.
Thus, they are initially an element related property.
If such an influenced element creates several areas when being layouted,
all areas have to be accompanied by change bars.
Thus, we have to wait, until the areas of the influenced elements have been created, which (my understanding) is when a page layout has been finished (the page created with the areas on it).
Only then can we know the vertical positions of the areas, which are needed for the change bar areas.
I may be missing something here:-)
> > Can this be realizes in such a way in FOP?
>
> To be honest I don’t have a precise idea of how to implement that in
> FOP. But maybe that could be done using some kind of listener. An event
> would be generated when a change-bar-begin is encountered. It would be
> handled by ‘the proper LayoutManager’ that would record the current
> offset from the top of the applicable reference-area. Once the
> ‘change-bar-end’, ‘bottom-of-column’ or ‘end-of-document’
> event occurs,
> it creates the change-bar area.
I have to look into that:-)
> Where should that code be put? Good question... PageBreaker maybe,
> although StaticContentLM must also do something.
>
> Moreover, change-bar areas must also be produced for out-of-line areas
> like footnotes, returned by objects that are under the influence of the
> change-bar.
Thanks for your comments!
BTW, as far as I understand FOP, the area tree is never used for RTF output, but rather the event mechanism is used, that notifies the RTF backend for start/end of fo elements, which are then directly transfered into RTF.
Thus, the change bar stuff tied to the areas will not work for RTF and
extra code has to be added to the RTF backend to handle the change bars.
Best regards...
Stephan
--
Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 München
GERMANY
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Re: Implementing Change bars
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Stephan,
Stephan Thesing wrote:
> Hello,
>
> just a short status / question update.
>
<snip/>
>
> What remains is layout and producing the change bar areas.
>
> If I read the spec right, the intended semantics of the change-bar-elements is the following:
> - for all elements generating areas that are under the influence of
> a change bar, add fixed areas as tall as the generated areas and
> placed beside the column of that area as given by the change bar
> properties.
> - "being under the influence of a change bar" is defined by the file
> order of elements in the input.
> I.e., any element between a change-bar-start and corresponding change-bar-end (same class) is influenced by that change bar.
> For me, that means that an element can be under the influence of multiple change bars, naturally.
The area tree described in the Recommendation is non-normative,
therefore we are free to deviate from it as long as the final visual
result is the same.
And I’m actually not keen on the idea of generating a change-bar area
for /each/ area under the influence of a change bar. This will give many
overlapping areas (for example an fo:block produces a normal area, plus
possibly a line-area, which will itself contain many inline areas. If
a change-bar area must be generated for each of them...). The visual
result is likely to look non-continuous, as the borders of a table for
which we have already had complaints. Ideally a single area would be
generated on each column.
> My idea is now along the following lines:
> - Remember for each element during parsing the change bars it is influenced by.
> - After layout, go over all areas produced by those influenced elements
> and add the areas for the change bars (thus, only an area with proper
> border attributes).
It all depends on how this is implemented, therefore I’m awaiting your
patch. But that seems to imply a two-pass process that I’m not sure we
want. Imagine a change-bar that starts on page 2 and ends on page 50. We
don’t want to wait that the areas for page 50 have been created to add
the change-bar areas on page 2.
> Can this be realizes in such a way in FOP?
To be honest I don’t have a precise idea of how to implement that in
FOP. But maybe that could be done using some kind of listener. An event
would be generated when a change-bar-begin is encountered. It would be
handled by ‘the proper LayoutManager’ that would record the current
offset from the top of the applicable reference-area. Once the
‘change-bar-end’, ‘bottom-of-column’ or ‘end-of-document’ event occurs,
it creates the change-bar area.
Where should that code be put? Good question... PageBreaker maybe,
although StaticContentLM must also do something.
Moreover, change-bar areas must also be produced for out-of-line areas
like footnotes, returned by objects that are under the influence of the
change-bar.
> I appreciate any comments and suggestions!
Hoping the above gives you some hints,
Vincent
Re: Implementing Change bars
Posted by Andreas Delmelle <an...@telenet.be>.
On 03 Sep 2009, at 22:07, Stephan Thesing wrote:
Hi Stephan,
<snip />
>> Seems reasonable, although... validateChildNode() is more meant to
>> take care of very specific cases, mentioned in the definition of the
>> content model. Now I'm thinking: a change-bar-* is a neutral item
>> that
>> is basically allowed anywhere, except as a child/descendant of a very
>> limited set of FOs that cannot appear as descendants of an fo:flow or
>> fo:static-content.
>> The requirement of a flow/static-content ancestor is specific to the
>> change-bar-* nodes, not to their parent/ancestor, so I'm not entirely
>> sure whether FObj is the right place to enforce that rule...
>
> Yes, that rule is enforced in the ChangeBar class' startNode(),
> which is the base class for the ChangeBarBegin and ChangeBarEnd
> classes.
>
> But the validateChildNode() has to accept change-bar-begin and
> change-bar-end children for all nodes in order to allow them to
> occur at the allowed places.
For the answer to this, see the pointer I gave about
'isNeutralItem()'. That's basically ALL that really needs to be
modified in FObj AFAICT.
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
Re: Implementing Change bars
Posted by Stephan Thesing <th...@gmx.de>.
Hello,
> Yep, that's what I was referring to, and AFAICT, it is not mandated
> that the change-bar-begin and the corresponding change-bar-end appear
> in the same flow/page-sequence.
yes, it can occur across page-sequences, etc.
> Seems reasonable, although... validateChildNode() is more meant to
> take care of very specific cases, mentioned in the definition of the
> content model. Now I'm thinking: a change-bar-* is a neutral item that
> is basically allowed anywhere, except as a child/descendant of a very
> limited set of FOs that cannot appear as descendants of an fo:flow or
> fo:static-content.
> The requirement of a flow/static-content ancestor is specific to the
> change-bar-* nodes, not to their parent/ancestor, so I'm not entirely
> sure whether FObj is the right place to enforce that rule...
Yes, that rule is enforced in the ChangeBar class' startNode(), which is the base class for the ChangeBarBegin and ChangeBarEnd classes.
But the validateChildNode() has to accept change-bar-begin and change-bar-end children for all nodes in order to allow them to occur at the allowed places.
Thus, as I see it, either this has to be added to all validateChildNode() methods, or validation of children for an arbitrary element has to be split in checking for elements that may always be children (the change bars currently) and element specific checks mandated by the content model of each node.
I used the later approach.
If all elements that may be in a flow call a common validateChildNode() (via super()), then the code could be moved there (I didn't check).
Best regards...
Stephan
--
Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 München
GERMANY
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Implementing Change bars
Posted by Andreas Delmelle <an...@telenet.be>.
On 02 Sep 2009, at 20:22, Stephan Thesing wrote:
Hi Stephan
> just a short status / question update.
>
> I have added the fo:change-bar-begin/end elements with their
> properties.
> Validation is also implemented, but:
> - In contrast to the other fo: elements, the change-bar-* elements
> are allowed to occur everywhere, as long as they have an
> fo:flow or fo:static-content ancestor.
Yep, that's what I was referring to, and AFAICT, it is not mandated
that the change-bar-begin and the corresponding change-bar-end appear
in the same flow/page-sequence.
> All the elements do their content validation via validateChildNode()
> (e.g. Block.java in o.a.fop.fo.flow).
> As I didn't want to add acceptance of change-bar-* children to all
> fo: elements under o.a.fop.fo.flow, I added to FNode.java a
> validateChildNodeGlobal() function that performs the "global"
> check for change-bar-* children and then calls
> validateChildNode()
> to perform the local check for each element.
> in FOTreeBuilder.java this is then called instead of
> validateChildNode().
> The version of validateChildNodeGlobal() applicable for change bars
> is added in FObj.java
Seems reasonable, although... validateChildNode() is more meant to
take care of very specific cases, mentioned in the definition of the
content model. Now I'm thinking: a change-bar-* is a neutral item that
is basically allowed anywhere, except as a child/descendant of a very
limited set of FOs that cannot appear as descendants of an fo:flow or
fo:static-content.
The requirement of a flow/static-content ancestor is specific to the
change-bar-* nodes, not to their parent/ancestor, so I'm not entirely
sure whether FObj is the right place to enforce that rule...
A common superclass ChangeBarNode for ChangeBarBegin and ChangeBarEnd
could take care of that 'validation' in its processNode()
implementation. The stacking-validation could probably be performed in
the same go. No changes necessary so high up in the class hierarchy.
To trigger correct validation when the eventual (parent) FObj calls
its validateChildNode() method, all that needs to be altered there, is
the addition of "change-bar-begin" and "change-bar-end" to the
isNeutralItem() method.
> Validation of the stacking constraints of change-bar-begin and -end
> are
> also done.
> Error messages and codes for validation errors are also already added.
>
> What remains is layout and producing the change bar areas.
>
> If I read the spec right, the intended semantics of the change-bar-
> elements is the following:
> <snip />
> For me, that means that an element can be under the influence of
> multiple change bars, naturally.
Indeed, and if no offset is specified the bars will be drawn over each
other.
<snip />
I'll get back on your further ideas ASAP.
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---