Re: Strange bug in 0.95?
Hi, Andreas Delmelle wrote: On 29 May 2009, at 18:31, Amick, Eric wrote: Hi Eric I have the following simple FO: snip / I was expecting the border to be the same distance from every edge of the page, but the resulting PDF has the side and bottom edges of the box closer to the edges of the page; in fact, the bottom edge of the box is off the page. If I remove the padding, the border appears as I was expecting. It appears that the padding is causing the height and width of the block-container to increase instead of reducing the available area inside the block-container's border. Am I missing something, or is this a bug? Definitely a bug. Apparently, it only occurs for relative-positioned block-containers. If you position it absolutely (position=absolute top=0 left=0), you also get the expected output... This is /not/ a bug. The ‘height’ property specify the /content height/ of the block [1] i.e., excluding the border- and padding-rectangles. If its value is a percentage it refers to the height of the nearest ancestor reference area, loosely speaking here the height of the region-body. In the block-progression-direction, areas are stacked from border rectangle to border-rectangle. So here, the top of the border rectangle coincides with the top of the region-body, and this is why you get a warning that the block doesn’t fit in the page. In the inline-progression-direction, areas are stacked from /content-rectangle/ to content-rectangle, that is, without taking border and padding into account. So if no indent is specified on the block, the border- and padding-rectangle effectively stick out into the margins. This is all explained in official terms in section 4 of the Recommendation [2] (more specifically section 4.2, 4.4 and 4.5). If the block is absolutely positioned, the ‘top’ and ‘left’ properties specify the positioning of the /content-rectangle/, so if set to 0 the top-left corner of the content-rectangle coincides with the top-left corner of the region-body. So in both cases FOP’s behaviour is perfectly normal. [1] http://www.w3.org/TR/xsl11/#block-progression-dimension [2] http://www.w3.org/TR/xsl11/#area_model Please log a report for this in Bugzilla, so we don't lose track of it. Thanks! Andreas Hope this clarifies the topic, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Strange bug in 0.95?
On 01 Jun 2009, at 12:59, Vincent Hennebert wrote: Andreas Delmelle wrote: Definitely a bug. Apparently, it only occurs for relative-positioned block-containers. If you position it absolutely (position=absolute top=0 left=0), you also get the expected output... This is /not/ a bug. The ‘height’ property specify the /content height/ of the block [1] i.e., excluding the border- and padding-rectangles. If its value is a percentage it refers to the height of the nearest ancestor reference area, loosely speaking here the height of the region-body. Right, my mistake. I should have double-checked. The additional space at the top, outside of the block-container is a result of the line's half-leading. I initially thought the padding was being doubled somehow. Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Strange bug in 0.95?
On 01 Jun 2009, at 13:33, Andreas Delmelle wrote: snip / Right, my mistake. I should have double-checked. The additional space at the top, outside of the block-container is a result of the line's half-leading. I initially thought the padding was being doubled somehow. This comment also offers a possible workaround for the sample file: set the flow's font-size to zero, and reset it on the block-container or the block to get the desired result. Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Strange bug in 0.95?
Strange. Is there any reason there is apparently no property to specify the height of the allocation-rectangle for a block-area? It seems like an extremely useful thing to have. Eric Amick Legislative Computer Systems Office of the Clerk -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: Monday, June 1, 2009 7:00 To: fop-users@xmlgraphics.apache.org Subject: Re: Strange bug in 0.95? Hi, Andreas Delmelle wrote: On 29 May 2009, at 18:31, Amick, Eric wrote: Hi Eric I have the following simple FO: snip / I was expecting the border to be the same distance from every edge of the page, but the resulting PDF has the side and bottom edges of the box closer to the edges of the page; in fact, the bottom edge of the box is off the page. If I remove the padding, the border appears as I was expecting. It appears that the padding is causing the height and width of the block-container to increase instead of reducing the available area inside the block-container's border. Am I missing something, or is this a bug? Definitely a bug. Apparently, it only occurs for relative-positioned block-containers. If you position it absolutely (position=absolute top=0 left=0), you also get the expected output... This is /not/ a bug. The 'height' property specify the /content height/ of the block [1] i.e., excluding the border- and padding-rectangles. If its value is a percentage it refers to the height of the nearest ancestor reference area, loosely speaking here the height of the region-body. In the block-progression-direction, areas are stacked from border rectangle to border-rectangle. So here, the top of the border rectangle coincides with the top of the region-body, and this is why you get a warning that the block doesn't fit in the page. In the inline-progression-direction, areas are stacked from /content-rectangle/ to content-rectangle, that is, without taking border and padding into account. So if no indent is specified on the block, the border- and padding-rectangle effectively stick out into the margins. This is all explained in official terms in section 4 of the Recommendation [2] (more specifically section 4.2, 4.4 and 4.5). If the block is absolutely positioned, the 'top' and 'left' properties specify the positioning of the /content-rectangle/, so if set to 0 the top-left corner of the content-rectangle coincides with the top-left corner of the region-body. So in both cases FOP's behaviour is perfectly normal. [1] http://www.w3.org/TR/xsl11/#block-progression-dimension [2] http://www.w3.org/TR/xsl11/#area_model Please log a report for this in Bugzilla, so we don't lose track of it. Thanks! Andreas Hope this clarifies the topic, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Strange bug in 0.95?
Hi Eric, Amick, Eric wrote: Strange. Is there any reason there is apparently no property to specify the height of the allocation-rectangle for a block-area? It seems like an extremely useful thing to have. Indeed I don’t think there is such a property. Whether it would be ‘extremely’ useful might be debatable though. There is a semi-automatic way to achieve what you want: fo:block-container height=100% - 2*1em - 2*1pt ... assuming the padding is 2em and the border 1pt. Since in most cases XSL-FO files are produced in some programmed way, it should be relatively easy to create placeholders in the formula above for the actual values of padding and border. HTH, Vincent Eric Amick Legislative Computer Systems Office of the Clerk -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: Monday, June 1, 2009 7:00 To: fop-users@xmlgraphics.apache.org Subject: Re: Strange bug in 0.95? Hi, Andreas Delmelle wrote: On 29 May 2009, at 18:31, Amick, Eric wrote: Hi Eric I have the following simple FO: snip / I was expecting the border to be the same distance from every edge of the page, but the resulting PDF has the side and bottom edges of the box closer to the edges of the page; in fact, the bottom edge of the box is off the page. If I remove the padding, the border appears as I was expecting. It appears that the padding is causing the height and width of the block-container to increase instead of reducing the available area inside the block-container's border. Am I missing something, or is this a bug? Definitely a bug. Apparently, it only occurs for relative-positioned block-containers. If you position it absolutely (position=absolute top=0 left=0), you also get the expected output... This is /not/ a bug. The 'height' property specify the /content height/ of the block [1] i.e., excluding the border- and padding-rectangles. If its value is a percentage it refers to the height of the nearest ancestor reference area, loosely speaking here the height of the region-body. In the block-progression-direction, areas are stacked from border rectangle to border-rectangle. So here, the top of the border rectangle coincides with the top of the region-body, and this is why you get a warning that the block doesn't fit in the page. In the inline-progression-direction, areas are stacked from /content-rectangle/ to content-rectangle, that is, without taking border and padding into account. So if no indent is specified on the block, the border- and padding-rectangle effectively stick out into the margins. This is all explained in official terms in section 4 of the Recommendation [2] (more specifically section 4.2, 4.4 and 4.5). If the block is absolutely positioned, the 'top' and 'left' properties specify the positioning of the /content-rectangle/, so if set to 0 the top-left corner of the content-rectangle coincides with the top-left corner of the region-body. So in both cases FOP's behaviour is perfectly normal. [1] http://www.w3.org/TR/xsl11/#block-progression-dimension [2] http://www.w3.org/TR/xsl11/#area_model Please log a report for this in Bugzilla, so we don't lose track of it. Thanks! Andreas Hope this clarifies the topic, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Referenced pattern not applied when PDF is encrypted
Hi Andreas, We have ran the latest codebase and this still seems to be a problem. Are you able to confirm this is still the case? If it's still an issue then I will log the issue and have a look into it. Many Thanks Lea. Andreas Delmelle-2 wrote: On Sep 3, 2008, at 14:02, Lea Thurman wrote: Hi We am more than happy to spend time on this and hopefully fix and submit it back. However having never filed a defect or committed to FOP before is there are starter for 10 that tells me about servers/repositories/ locations etc and the general process to be followed. If you mean you potentially will do some development on the FOP codebase, and want to donate it back, then the main 'Development' page would be a good place to start: http://xmlgraphics.apache.org/fop/dev/index.html If OTOH, you simply want to log the issue, supply more info (and preferably some FO/SVG samples as well), then this is where you need to be: http://xmlgraphics.apache.org/fop/bugs.html Cheers Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/Referenced-pattern-not-applied-when-PDF-is-encrypted-tp19197539p23815875.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Strange bug in 0.95?
Fair enough. It still seems like a lot of work (and not exactly intuitive) just to draw a box along the margins of a page. I can't help wondering why they disallowed borders on region-body, for instance. Eric Amick Legislative Computer Systems Office of the Clerk -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: Monday, June 1, 2009 10:23 To: fop-users@xmlgraphics.apache.org Subject: Re: Strange bug in 0.95? Hi Eric, Amick, Eric wrote: Strange. Is there any reason there is apparently no property to specify the height of the allocation-rectangle for a block-area? It seems like an extremely useful thing to have. Indeed I don't think there is such a property. Whether it would be 'extremely' useful might be debatable though. There is a semi-automatic way to achieve what you want: fo:block-container height=100% - 2*1em - 2*1pt ... assuming the padding is 2em and the border 1pt. Since in most cases XSL-FO files are produced in some programmed way, it should be relatively easy to create placeholders in the formula above for the actual values of padding and border. HTH, Vincent Eric Amick Legislative Computer Systems Office of the Clerk -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: Monday, June 1, 2009 7:00 To: fop-users@xmlgraphics.apache.org Subject: Re: Strange bug in 0.95? Hi, Andreas Delmelle wrote: On 29 May 2009, at 18:31, Amick, Eric wrote: Hi Eric I have the following simple FO: snip / I was expecting the border to be the same distance from every edge of the page, but the resulting PDF has the side and bottom edges of the box closer to the edges of the page; in fact, the bottom edge of the box is off the page. If I remove the padding, the border appears as I was expecting. It appears that the padding is causing the height and width of the block-container to increase instead of reducing the available area inside the block-container's border. Am I missing something, or is this a bug? Definitely a bug. Apparently, it only occurs for relative-positioned block-containers. If you position it absolutely (position=absolute top=0 left=0), you also get the expected output... This is /not/ a bug. The 'height' property specify the /content height/ of the block [1] i.e., excluding the border- and padding-rectangles. If its value is a percentage it refers to the height of the nearest ancestor reference area, loosely speaking here the height of the region-body. In the block-progression-direction, areas are stacked from border rectangle to border-rectangle. So here, the top of the border rectangle coincides with the top of the region-body, and this is why you get a warning that the block doesn't fit in the page. In the inline-progression-direction, areas are stacked from /content-rectangle/ to content-rectangle, that is, without taking border and padding into account. So if no indent is specified on the block, the border- and padding-rectangle effectively stick out into the margins. This is all explained in official terms in section 4 of the Recommendation [2] (more specifically section 4.2, 4.4 and 4.5). If the block is absolutely positioned, the 'top' and 'left' properties specify the positioning of the /content-rectangle/, so if set to 0 the top-left corner of the content-rectangle coincides with the top-left corner of the region-body. So in both cases FOP's behaviour is perfectly normal. [1] http://www.w3.org/TR/xsl11/#block-progression-dimension [2] http://www.w3.org/TR/xsl11/#area_model Please log a report for this in Bugzilla, so we don't lose track of it. Thanks! Andreas Hope this clarifies the topic, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
FOP 0.95 fails to compile large PDF files - java heap space
Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23816647.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Strange bug in 0.95?
On 01 Jun 2009, at 16:49, Amick, Eric wrote: Fair enough. It still seems like a lot of work (and not exactly intuitive) just to draw a box along the margins of a page. I can't help wondering why they disallowed borders on region-body, for instance. Heh, FOP allows those. I know this works in FOP Trunk, but not 100% sure whether the related changes are already in 0.95. Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Table of Contents
I am currently using fo:list-block to format my Table of Contents, but this
means I can only make the fo:list-item-body part be a link (with
fo:basic-link). A line in the Table of Contents is formatted as so:
1.0 Introduction..1
Is there an alternative to formatting the items as such?
Below is snippet of my current xsl stylesheet:
xsl:template match=document mode=contents
fo:list-block provisional-label-separation=0cm
provisional-distance-between-starts=1.02cm
xsl:apply-templates select=sect1 mode=contents/
/fo:list-block
fo:block break-after=page/
/xsl:template
xsl:template match=sect1 mode=contents
fo:list-item
fo:list-item-label end-indent=label-end()
fo:block
xsl:number format=1/.0
/fo:block
/fo:list-item-label
fo:list-item-body start-indent=body-start()
fo:block text-align=left text-align-last=justify
fo:basic-link internal-destination={generate-id(.)}
xsl:value-of select=h/
fo:leader leader-pattern=dots/
fo:page-number-citation ref-id={generate-id(.)}/
/fo:basic-link
/fo:block
xsl:if test=count(sect2) gt; 0
fo:list-block provisional-label-separation=0cm
provisional-distance-between-starts=1.02cm
xsl:apply-templates select=sect2 mode=contents/
/fo:list-block
/xsl:if
/fo:list-item-body
/fo:list-item
/xsl:template
I did try but the width on the inline did not apply:
fo:block text-align=left text-align-last=justify
fo:basic-link internal-destination={generate-id(.)}
fo:inline width=1.02cmxsl:number format=1/.0/fo:inline
xsl:value-of select=h/
fo:leader leader-pattern=dots/
fo:page-number-citation ref-id={generate-id(.)}/
/fo:basic-link
/fo:block
Need a Holiday? Win a $10,000 Holiday of your choice. Enter
now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
FOP creating *.tmp files
Hi All, I am using FOP 0.95...I can generate PDF, PCL files. Fop is creating *.tmp files, Those file are not deleting after process. Please someone help on this issue. Thanks, -Soma -- View this message in context: http://www.nabble.com/FOP-creating-*.tmp-files-tp23826246p23826246.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
