You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by bonekrusher <dj...@yahoo.com> on 2008/02/28 15:15:21 UTC

retrieve-marker to show page continues

Hi,

I am having a heck of a time to get this working. I want to add a
"continued" to the second page (and all subsequent pages) if the page
continues. However the marker shows up on the first page also. What am I
doing wrong?

retrieve marker call:

<fo:retrieve-marker retrieve-class-name="warn-summary-continuation"
retrieve-boundary="page-sequence"
retrieve-position="last-ending-within-page"/>

marker:

<fo:marker marker-class-name="warn-summary-continuation">
	<fo:inline xsl:use-attribute-sets="front-back-matter-header">
		<xsl:text> - Continued</xsl:text>
	</fo:inline>
</fo:marker>


Thanks,

Bones
-- 
View this message in context: http://www.nabble.com/retrieve-marker-to-show-page-continues-tp15737289p15737289.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: retrieve-marker to show page continues

Posted by Chris Bowditch <bo...@hotmail.com>.
bonekrusher wrote:
> Hi,
> 
> I am having a heck of a time to get this working. I want to add a
> "continued" to the second page (and all subsequent pages) if the page
> continues. However the marker shows up on the first page also. What am I
> doing wrong?

If you never want this message on the first page then you need fo:marker 
elements on the first page that set the marker to nothing, e.g.

  <fo:marker marker-class-name="warn-summary-continuation">
  	<fo:inline xsl:use-attribute-sets="front-back-matter-header"><fo:inline>
  </fo:marker>

then at the beginning of the second page insert the marker:

> 
> <fo:marker marker-class-name="warn-summary-continuation">
> 	<fo:inline xsl:use-attribute-sets="front-back-matter-header">
> 		<xsl:text> - Continued</xsl:text>
> 	</fo:inline>
> </fo:marker>

HTH,

Chris



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Table row background images

Posted by Chris Bowditch <bo...@hotmail.com>.
Thanks for the explanation Jeremias. I've raised a bug so we don't 
forget about this limitation.

https://issues.apache.org/bugzilla/show_bug.cgi?id=44507

Jeremias Maerki wrote:

> The problem with PCL (or at least PCL5 which I've worked with) is that
> it doesn't support clipping [1]. Clipping makes these things a lot
> easier. In the absence of clipping capabilities, you'd basically have to
> emulate the clipping in the painter code rather than in the print
> processor which complicates things. One relatively simple possibility
> would be to paint the background image to an in-memory buffer, clip
> there and then paint the resulting bitmap using PCL means but that costs
> a lot of performance and memory. A little more advanced would be to keep
> track which tile actually gets clipped and process the tiles
> individually. Obviously this hasn't been done, yet. Help is definitely
> welcome.
> 
> [1] HP/GL2 actually supports clipping but often doesn't help to
> efficiently overcome the limitations of PCL.
> 
> Note also that many Windows PCL printer drivers just paint a single big
> bitmap for the whole page instead of using the various PCL capabilities.
> For complex pages this produces perfect quality but it comes with a
> cost: In-memory build up of the page may be slower and and the resulting
> print files are often bigger. However, with FOP's Java2D capabilities it
> would actually be relatively easy to write a second PCL renderer which
> just generates a bitmap image of each page and converts that to PCL. The
> user would then have the choice between accuracy and speed.
> 
> On 28.02.2008 17:08:43 David Gerdt wrote:
> 
>>I'm finding a difference in how background images for table rows are rendered in PDF versus PCL. When producing a pdf, the image will fill only the row and be clipped where it runs outside the bounds of the row. This is what I want. However, when producing PCL which is really my ultimate goal, the whole image is displayed and overflows the bounds of the row.
>> 
>>This behavior occurs in both 0.94 and Trunk. I have tried applying the background-image attribute to the table-row, table-cell, and the block each individually, with the same results.
>> 
>>I am not sure exactly what the intended behavior should be (clip the image or let it go) but I'm more confused by the difference between the PDF and the PCL which are rendered from the same fo file.
>> 
>>What I'm really trying to do is create a white background for a table row when rendered in PCL. The background-color attribute produces this effect in a PDF but not in a PCL file. I'm trying to work around this by setting the background-image to a plain white gif, but am running into the problems above.
>> 
>>Any insight on these issues? I can provide a fo file if you like, but I figured these issues were broad enough to not require the specific fo.
>> 
>>Thanks!
> 
> 
> 
> 
> 
> Jeremias Maerki
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Table row background images

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
The problem with PCL (or at least PCL5 which I've worked with) is that
it doesn't support clipping [1]. Clipping makes these things a lot
easier. In the absence of clipping capabilities, you'd basically have to
emulate the clipping in the painter code rather than in the print
processor which complicates things. One relatively simple possibility
would be to paint the background image to an in-memory buffer, clip
there and then paint the resulting bitmap using PCL means but that costs
a lot of performance and memory. A little more advanced would be to keep
track which tile actually gets clipped and process the tiles
individually. Obviously this hasn't been done, yet. Help is definitely
welcome.

[1] HP/GL2 actually supports clipping but often doesn't help to
efficiently overcome the limitations of PCL.

Note also that many Windows PCL printer drivers just paint a single big
bitmap for the whole page instead of using the various PCL capabilities.
For complex pages this produces perfect quality but it comes with a
cost: In-memory build up of the page may be slower and and the resulting
print files are often bigger. However, with FOP's Java2D capabilities it
would actually be relatively easy to write a second PCL renderer which
just generates a bitmap image of each page and converts that to PCL. The
user would then have the choice between accuracy and speed.

On 28.02.2008 17:08:43 David Gerdt wrote:
> I'm finding a difference in how background images for table rows are rendered in PDF versus PCL. When producing a pdf, the image will fill only the row and be clipped where it runs outside the bounds of the row. This is what I want. However, when producing PCL which is really my ultimate goal, the whole image is displayed and overflows the bounds of the row.
>  
> This behavior occurs in both 0.94 and Trunk. I have tried applying the background-image attribute to the table-row, table-cell, and the block each individually, with the same results.
>  
> I am not sure exactly what the intended behavior should be (clip the image or let it go) but I'm more confused by the difference between the PDF and the PCL which are rendered from the same fo file.
>  
> What I'm really trying to do is create a white background for a table row when rendered in PCL. The background-color attribute produces this effect in a PDF but not in a PCL file. I'm trying to work around this by setting the background-image to a plain white gif, but am running into the problems above.
>  
> Any insight on these issues? I can provide a fo file if you like, but I figured these issues were broad enough to not require the specific fo.
>  
> Thanks!




Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Table row background images

Posted by David Gerdt <Dg...@bju.edu>.
I'm finding a difference in how background images for table rows are rendered in PDF versus PCL. When producing a pdf, the image will fill only the row and be clipped where it runs outside the bounds of the row. This is what I want. However, when producing PCL which is really my ultimate goal, the whole image is displayed and overflows the bounds of the row.
 
This behavior occurs in both 0.94 and Trunk. I have tried applying the background-image attribute to the table-row, table-cell, and the block each individually, with the same results.
 
I am not sure exactly what the intended behavior should be (clip the image or let it go) but I'm more confused by the difference between the PDF and the PCL which are rendered from the same fo file.
 
What I'm really trying to do is create a white background for a table row when rendered in PCL. The background-color attribute produces this effect in a PDF but not in a PCL file. I'm trying to work around this by setting the background-image to a plain white gif, but am running into the problems above.
 
Any insight on these issues? I can provide a fo file if you like, but I figured these issues were broad enough to not require the specific fo.
 
Thanks!

Re: retrieve-marker to show page continues

Posted by bonekrusher <dj...@yahoo.com>.
Thanks... That did the trick.

Bones


cbowditch wrote:
> 
> bonekrusher wrote:
>> Hi,
>> 
>> I am having a heck of a time to get this working. I want to add a
>> "continued" to the second page (and all subsequent pages) if the page
>> continues. However the marker shows up on the first page also. What am I
>> doing wrong?
> 
> If you never want this message on the first page then you need fo:marker 
> elements on the first page that set the marker to nothing, e.g.
> 
>   <fo:marker marker-class-name="warn-summary-continuation">
>   	<fo:inline
> xsl:use-attribute-sets="front-back-matter-header"><fo:inline>
>   </fo:marker>
> 
> then at the beginning of the second page insert the marker:
> 
>> 
>> <fo:marker marker-class-name="warn-summary-continuation">
>> 	<fo:inline xsl:use-attribute-sets="front-back-matter-header">
>> 		<xsl:text> - Continued</xsl:text>
>> 	</fo:inline>
>> </fo:marker>
> 
> HTH,
> 
> Chris
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/retrieve-marker-to-show-page-continues-tp15737289p15742262.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