Re: possible: footer filled with first and last row of page ?
This can be done using markers: fo:marker and fo:retrieve-marker. For every name you'd add a marker and reference that in the static-content for the region-after using two fo:retrieve-marker elements with the right retrieve-position. Have a look at [1] which is a good example from our test repository. That should give you some ideas. [1] http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/test/layoutengine/standard-testcases/markers_6a.xml On 13.02.2006 02:50:52 Thomas Lutz wrote: > Hi list ! > > Sorry if this is faq, or easy to do, but I've been searching and reading > quite some time now, and have not found a solution or even a hint yet. > > What my output should look like: > -a table spanning multiple pages (around 100 in the final version), no > problem so far > -each row consists of a nested table containing some "person has n > items" rows, no problem, too > -question: is (and if how :-) ) it possible to output a footer, that is > a concat of the first last name and the last last name on this page ? > > Maybe an example is better: > --- > |Page x: > | > |AName > |-item1 > |-item2 > |BName > |-item1 > |CName > |-item1 > |-item2 > | > |Footer: AName - CName > --- > > What I want to achieve is that the printed version of this pdf can be > searched fast... > Is this possible with fop ? > > Thanks for the help, every is input is more then welcome ! > > regards, > tom Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible: footer filled with first and last row of page ?
Thomas, I don't have the XSL-FO spec handy but have a look at and For each name in your table create a element. In the footer retrieve the first and last marker on the current page with the appropriate page-position selector. Manuel > Hi list ! > > Sorry if this is faq, or easy to do, but I've been searching and reading > quite some time now, and have not found a solution or even a hint yet. > > What my output should look like: > -a table spanning multiple pages (around 100 in the final version), no > problem so far > -each row consists of a nested table containing some "person has n > items" rows, no problem, too > -question: is (and if how :-) ) it possible to output a footer, that is > a concat of the first last name and the last last name on this page ? > > Maybe an example is better: > --- > |Page x: > | > |AName > |-item1 > |-item2 > |BName > |-item1 > |CName > |-item1 > |-item2 > | > |Footer: AName - CName > --- > > What I want to achieve is that the printed version of this pdf can be > searched fast... > Is this possible with fop ? > > Thanks for the help, every is input is more then welcome ! > > regards, > tom > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: differnece between fop and xep: which is right?
I think XEP is wrong if it reports an error. XSL-FO 1.0 says in "5.9 Expressions": "All property value specifications in attributes within an XSL stylesheet can be expressions." IMO, your expression for start-indent is valid. On 13.02.2006 04:59:48 Paul Tremblay wrote: > I have the following line in my of.xml file: > > > > > > > text-indent="-12pt"> > In late > winter > > I want to create a hanging indents for long lines of poetry. When I > run this document through xep's processor, I get the following error: > > [warning] Bad attribute start-indent: Cannot add type Word to type > Length > > However, when I run it through fop .91 beta, it works exactly like I > want it to. > > Is xep correct in reporting an error? Is fop cheating? Of course, I am > glad that fop processes the document the way I want! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: differnece between fop and xep: which is right?
Jeremias, just out of curiosity and not directly related to the posters question: The definition of block-start() refers to start-indent. Here we are actually setting start-indent. Which value of start-indent is used in calculating block-start()? Manuel > I think XEP is wrong if it reports an error. XSL-FO 1.0 says in "5.9 > Expressions": "All property value specifications in attributes within an > XSL stylesheet can be expressions." > > IMO, your expression for start-indent is valid. > > On 13.02.2006 04:59:48 Paul Tremblay wrote: >> I have the following line in my of.xml file: >> >> >> >> >> >> >> > text-indent="-12pt"> >> In late >> winter >> >> I want to create a hanging indents for long lines of poetry. When I >> run this document through xep's processor, I get the following error: >> >> [warning] Bad attribute start-indent: Cannot add type Word to type >> Length >> >> However, when I run it through fop .91 beta, it works exactly like I >> want it to. >> >> Is xep correct in reporting an error? Is fop cheating? Of course, I am >> glad that fop processes the document the way I want! > > > Jeremias Maerki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: differnece between fop and xep: which is right?
Manuel, see 7.28.4. provisional-distance-between-starts and 5.10.4. "Property Value Functions" In the source code: org.apache.fop.fo.expr.BodyStartFunction On 13.02.2006 09:31:47 Manuel Mall wrote: > Jeremias, > > just out of curiosity and not directly related to the posters question: > > The definition of block-start() refers to start-indent. Here we are > actually setting start-indent. Which value of start-indent is used in > calculating block-start()? > > Manuel > > > I think XEP is wrong if it reports an error. XSL-FO 1.0 says in "5.9 > > Expressions": "All property value specifications in attributes within an > > XSL stylesheet can be expressions." > > > > IMO, your expression for start-indent is valid. > > > > On 13.02.2006 04:59:48 Paul Tremblay wrote: > >> I have the following line in my of.xml file: > >> > >> > >> > >> > >> > >> > >> >>text-indent="-12pt"> > >> In late > >> winter > >> > >> I want to create a hanging indents for long lines of poetry. When I > >> run this document through xep's processor, I get the following error: > >> > >> [warning] Bad attribute start-indent: Cannot add type Word to type > >> Length > >> > >> However, when I run it through fop .91 beta, it works exactly like I > >> want it to. > >> > >> Is xep correct in reporting an error? Is fop cheating? Of course, I am > >> glad that fop processes the document the way I want! > > > > > > Jeremias Maerki Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
white-space-collapse not working in trunk?
Hi there, again a short question: The FAQ is telling that using white-space-collapse="false" in a is all you need to output preformatted text. Well, not for me. Whitespaces will still collapse. I am using the latest trunk (revision 377250). Am I doing something worng or is this a bug? Thank you guys for your pretty good work. I would have never imagined to use trunk code in such a prolific way (to write my diploma thesis especially =) Here is a brief example: http://www.w3.org/1999/XSL/Format";> border-bottom="solid 1px silver" text-align="end" font-size="10pt" font-family="Helvetica"> Grundlagen Die JADE Extension ist eine an der Universität Hamburg entwickelte BDI Reasoning-Engine, die in Java geschrieben wurde. Ursprünglich als Erweiterung des Java Agent Development Framework konzipiert, sollte Jadex die Defizite von JADE beseitigen. Da sich die Entwickler von JADE auf die Konformität mit den FIPA-Spezifikationen und die Entwicklung von Werkzeugen zum Testen der Agenten konzentriert haben, blieb die Umsetzung eines internen Agentenkonzeptes bewusst unberücksichtigt [PBL03] . Jadex war die Lösung dieses Defizits, indem es auf Basis der relativ einfach gestrickten JADE-Agenten ein Framework aufsetzte, das die Entwicklung von BDI-Agenten ermöglichte. space-after="0.5em" font-size="10pt" font-family="Helvetica" id="code-adf_aufbau"> linefeed-treatment="preserve" white-space-collapse="false" font-size="10pt" font-family="Courier">test XXX Code-Auszug 1: Aufbau des ADF von Jadex Agenten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SOLVED] possible: footer filled with first and last row of page ?
thanks a lot ! got enough ideas, got it running :-). now that i know what to search for, there's enough material on the web... thanks again (to manuel, too), tom Jeremias Maerki wrote: This can be done using markers: fo:marker and fo:retrieve-marker. For every name you'd add a marker and reference that in the static-content for the region-after using two fo:retrieve-marker elements with the right retrieve-position. Have a look at [1] which is a good example from our test repository. That should give you some ideas. [1] http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/test/layoutengine/standard-testcases/markers_6a.xml On 13.02.2006 02:50:52 Thomas Lutz wrote: Hi list ! Sorry if this is faq, or easy to do, but I've been searching and reading quite some time now, and have not found a solution or even a hint yet. What my output should look like: -a table spanning multiple pages (around 100 in the final version), no problem so far -each row consists of a nested table containing some "person has n items" rows, no problem, too -question: is (and if how :-) ) it possible to output a footer, that is a concat of the first last name and the last last name on this page ? Maybe an example is better: --- |Page x: | |AName |-item1 |-item2 |BName |-item1 |CName |-item1 |-item2 | |Footer: AName - CName --- What I want to achieve is that the printed version of this pdf can be searched fast... Is this possible with fop ? Thanks for the help, every is input is more then welcome ! regards, tom Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: white-space-collapse not working in trunk?
On Monday 13 February 2006 21:54, Sven wrote: > Hi there, > > again a short question: The FAQ is telling that using > white-space-collapse="false" in a is all you need to > output preformatted text. Well, not for me. Whitespaces will still > collapse. I am using the latest trunk (revision 377250). Am I doing > something worng or is this a bug? > It's a known bug. Especially leading white space, that is white space at the beginning of each line is incorrectly removed. It is documented, but not very prominently, in the release notes where there is a line saying: # There are several small problems around white space handling. One could argue that this not a really a 'small' problem :-). > Thank you guys for your pretty good work. I would have never imagined > to use trunk code in such a prolific way (to write my diploma thesis > especially =) > > > Here is a brief example: > > > http://www.w3.org/1999/XSL/Format";> > > page-height="29.7cm" master-name="titlepage"> > > > page-height="29.7cm" master-name="default"> > > > > > > > > > border-bottom="solid 1px silver" text-align="end" > font-size="10pt" > font-family="Helvetica"> > Grundlagen > > > > > > > > > > leader-pattern="rule" /> > > > > hyphenate="false" space-after="0.5em" > text-align="justify" font-size="12pt" font-family="Times"> > Die JADE Extension ist eine an der Universität > Hamburg entwickelte BDI Reasoning-Engine, die in Java geschrieben > wurde. Ursprünglich als Erweiterung des > > Java Agent Development Framework > > konzipiert, sollte Jadex die Defizite von JADE > beseitigen. Da sich die Entwickler von JADE auf die > Konformität mit den FIPA-Spezifikationen und die > Entwicklung von Werkzeugen zum Testen der Agenten > konzentriert haben, blieb die Umsetzung eines > internen Agentenkonzeptes bewusst unberücksichtigt > > internal-destination="reference-PBL03"> > [PBL03] > > > . Jadex war die Lösung dieses Defizits, indem es auf > Basis der relativ einfach gestrickten JADE-Agenten > ein Framework aufsetzte, das die Entwicklung von BDI-Agenten > ermöglichte. > > space-after="0.5em" font-size="10pt" font-family="Helvetica" > id="code-adf_aufbau"> > linefeed-treatment="preserve" white-space-collapse="false" > font-size="10pt" font-family="Courier"> >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://jadex.sourceforge.net/jadex > http://jadex.sourceforge.net/jadex-0.94.xsd"; > name="AgentTypeName" > package="your.package.here"> > > > test XXX > > > > Code-Auszug 1: > Aufbau des ADF von Jadex Agenten > > > > > Manuel > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >
Re: white-space-collapse not working in trunk?
On Mon, Feb 13, 2006 at 10:52:07PM +0800, Manuel Mall wrote: > On Monday 13 February 2006 21:54, Sven wrote: > > Hi there, > > > > again a short question: The FAQ is telling that using > > white-space-collapse="false" in a is all you need to > > output preformatted text. Well, not for me. Whitespaces will still > > collapse. I am using the latest trunk (revision 377250). Am I doing > > something worng or is this a bug? > > > It's a known bug. Especially leading white space, that is white space at > the beginning of each line is incorrectly removed. Is it a bug? The default values of suppress-at-line-break="auto" and white-space-treatment="ignore-if-surrounding-linefeed" specify that the space character is removed around a line break, even when white-space-collapse="false". I refer here to the draft of XSL 1.1, which in our opinion clarifies the confusing corresponding parts of XSL 1.0. See our efforts to come to grips with this on the Wiki: http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling. Note that TeX would show a similar behaviour: It removes white space at the start of a line, even when white space is not collapsed. Maybe you should use a zero-width fo:inline element at the start of the line to suppress the suppression. Regards, Simon > > > linefeed-treatment="preserve" white-space-collapse="false" > > font-size="10pt" font-family="Courier"> > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation="http://jadex.sourceforge.net/jadex > > http://jadex.sourceforge.net/jadex-0.94.xsd"; > > name="AgentTypeName" > > package="your.package.here"> > > > > > > test XXX > > > > -- Simon Pepping home page: http://www.leverkruid.nl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >
region-before falls between region-start and region-end
Hi FOP Users, I'm using FOP Version 0.91beta to generate pdf from xsl-fo I think that I'm right in saying that region-before should position like the lintle of a door on top of region-body, region-start and region-end i.e. like so: (as described http://www.w3schools.com/xslfo/xslfo_pages.asp ) ___ | | |region-before | |___| | | | | | region- | | region- | | start | region-body | end | | | | | | | | | | | | | |_|__|__| | | | region-after| |___| However my PDF ends up like: ___ | | | | | | region-before | | | |__| | | | | | | region- | | region- | | start | region-body | end | | | | | | | | | | | | | | |__| | | | | | | | region-after| | |_|__|__| Is that correct? My xsl-fo file looks like: http://www.w3.org/1999/XSL/Format"; xmlns:xhtml="http://www.w3.org/1999/xhtml"; xmlns:xdt="http://www.w3.org/2004/07/xpath-datatypes"; xmlns:fn="http://www.w3.org/2004/07/xpath-functions"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> content stuff Am I misunderstanding this or is there a bug in the pdf Renderer? Cheers Karl NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: region-before falls between region-start and region-end
Hi All I found a mechanism to make it work like I expected... I had to set the prescedence to true on region-before and region-after Eg http://www.w3.org/1999/XSL/Format"; xmlns:xhtml="http://www.w3.org/1999/xhtml"; xmlns:xdt="http://www.w3.org/2004/07/xpath-datatypes"; xmlns:fn="http://www.w3.org/2004/07/xpath-functions"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> content stuff Cheers Karl -Original Message- From: Karl Roberts Sent: Tuesday, 14 February 2006 11:33 AM To: fop-users@xmlgraphics.apache.org Subject: region-before falls between region-start and region-end Hi FOP Users, I'm using FOP Version 0.91beta to generate pdf from xsl-fo I think that I'm right in saying that region-before should position like the lintle of a door on top of region-body, region-start and region-end i.e. like so: (as described http://www.w3schools.com/xslfo/xslfo_pages.asp ) ___ | | |region-before | |___| | | | | | region- | | region- | | start | region-body | end | | | | | | | | | | | | | |_|__|__| | | | region-after| |___| However my PDF ends up like: ___ | | | | | | region-before | | | |__| | | | | | | region- | | region- | | start | region-body | end | | | | | | | | | | | | | | |__| | | | | | | | region-after| | |_|__|__| Is that correct? My xsl-fo file looks like: http://www.w3.org/1999/XSL/Format"; xmlns:xhtml="http://www.w3.org/1999/xhtml"; xmlns:xdt="http://www.w3.org/2004/07/xpath-datatypes"; xmlns:fn="http://www.w3.org/2004/07/xpath-functions"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> content stuff Am I misunderstanding this or is there a bug in the pdf Renderer? Cheers Karl NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: differnece between fop and xep: which is right?
On Mon, Feb 13, 2006 at 09:08:16AM +0100, Jeremias Maerki wrote: > From: Jeremias Maerki <[EMAIL PROTECTED]> > To: fop-users@xmlgraphics.apache.org > Date: Mon, 13 Feb 2006 09:08:16 +0100 > Subject: Re: differnece between fop and xep: which is right? > > I think XEP is wrong if it reports an error. XSL-FO 1.0 says in "5.9 > Expressions": "All property value specifications in attributes within an > XSL stylesheet can be expressions." > > IMO, your expression for start-indent is valid. > Thanks. This is good to know. FOP is more compliant in one area than the closed-source XEP. Paul -- *Paul Tremblay * [EMAIL PROTECTED]* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: white-space-collapse not working in trunk?
> On Mon, Feb 13, 2006 at 10:52:07PM +0800, Manuel Mall wrote: >> On Monday 13 February 2006 21:54, Sven wrote: >> > Hi there, >> > >> > again a short question: The FAQ is telling that using >> > white-space-collapse="false" in a is all you need to >> > output preformatted text. Well, not for me. Whitespaces will still >> > collapse. I am using the latest trunk (revision 377250). Am I doing >> > something worng or is this a bug? >> > >> It's a known bug. Especially leading white space, that is white space at >> the beginning of each line is incorrectly removed. > > Is it a bug? The default values of suppress-at-line-break="auto" and > white-space-treatment="ignore-if-surrounding-linefeed" specify that > the space character is removed around a line break, even when > white-space-collapse="false". I refer here to the draft of XSL 1.1, > which in our opinion clarifies the confusing corresponding parts of > XSL 1.0. See our efforts to come to grips with this on the Wiki: > http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling. > > Note that TeX would show a similar behaviour: It removes white space > at the start of a line, even when white space is not collapsed. > > Maybe you should use a zero-width fo:inline element at the start of > the line to suppress the suppression. > Simon, you are correct white-space-collapse="false" doesn't preserve white space around line breaks. The FAQ refers to 0.20.5 but for 0.91 trunk the shorthand property white-space="pre" should be used or its expanded equivalents: linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" wrap-option="no-wrap" If you do that the bug I was referring to would show because white-space-treatment="preserve" is not correctly implemented. > Regards, Simon Manuel > >> > > > linefeed-treatment="preserve" white-space-collapse="false" >> > font-size="10pt" font-family="Courier"> >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> > xsi:schemaLocation="http://jadex.sourceforge.net/jadex >> > http://jadex.sourceforge.net/jadex-0.94.xsd"; >> > name="AgentTypeName" >> > package="your.package.here"> >> > >> > >> > test XXX >> > >> > > > -- > Simon Pepping > home page: http://www.leverkruid.nl > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]>> > >> > >> > >> >>> > >> > >> > >> >>> > >> > >> > >> >>> > >> > >> > >> >>> > >> > >> > >> >>> > >> > >> > >> >>> > >> > >> > >> >>> > >> > >> > >> >>> > >> > >> > >> >
