Re: Form XObject (was: Re: Avalonization?)

[Kevin O'Neill]

On Wed, 2002-11-13 at 18:53, Keiron Liddle wrote:
 On Tue, 2002-11-12 at 20:44, Kevin O'Neill wrote:
  I'm talking about specific user driven contexts. For instance as the
  designer I may know that I repeat the use of a image in several
  locations throughout the document, say it's a graphic I use at the start
  of a paragraph. It would be nice to be able to add an attribute like
  fop:cache=true to the element including the image to provide a hint to
  the renderer that this image will be reused.
 
 If it is just an image it does this already with (normal) XObject.
 What use case would you have were it is not cached for the same image
 (url) in the same document. We had a discussion recently and the
 concensus was that you wouldn't need to specify caching for images.

It does make a difference for a single repeated image. I've used this to
great effect in personalized stamp production as the raster is cached
and reused. This is especially effective if the image xobject includes
clipping information.

 If you mean a collection of PDF markup things then it could be a case
 for Form XObject.
 For the slide show thing I just wrapped the fo in an xml element which
 converts to wrapping the area with a special area that the renderer can
 pickup and place the contents in a Form XObject.
 
  The static regions are probably another area where we can use xforms
  though we would need to be careful of the more dynamic elements like
  page numbers. 
 
 Hopefully layout managers can deal with this in a nice way.
 
  -k.
  
  ps: I'm also using (and planning to extend my use of) the FOP PDF
  component externally to xsl:fo, so I'm interesting in adding features
  that may not be specifically relevant to fo but very relevant to it's
  usage as a PDF library. 
 
 Understood.

Of course that doesn't mean that I'm not interested in the area model,
just that my efforts are more likely to be aimed at PF.

-k.

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://www.rocketred.com.au/blogs/kevin/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Form XObject (was: Re: Avalonization?)

[Kevin O'Neill]

On Wed, 2002-11-13 at 00:53, Keiron Liddle wrote:
 On Tue, 2002-11-12 at 12:00, Kevin O'Neill wrote:
   I just added a Form XObject but it needs some work (eg. bounds).
  
  How do you intend to pass xobject hits from the fo processor. I had
  thought about a fop specific attribute that was a hint on block level
  objects.
 
 I'm not sure what situation you might be talking about. So to speculate:
 If it is to use xobject when there are things repeated across pages
 (static areas, table header, svg) then it could be done through the
 layout managers. If the content may be repeated and does not depend on
 the page then it could set a value on the area tree saying that the area
 (and contents) should be placed in a xobject. When the same area occurs
 again, indicated by a key or something, then it will render the xobject
 again.

I'm talking about specific user driven contexts. For instance as the
designer I may know that I repeat the use of a image in several
locations throughout the document, say it's a graphic I use at the start
of a paragraph. It would be nice to be able to add an attribute like
fop:cache=true to the element including the image to provide a hint to
the renderer that this image will be reused.

 If you are wondering why I added it. I made a simple and effective
 extension to FOP that creates slide shows (there's something called
 ppower4 that does this with Tex). An xml element is used to indicate
 that the contents should be added to the page progressively. It wraps
 the areas with a special marker area that indicates the areas should be
 placed in an xobject to provide the appearance of adding that area to
 the page. It's actually quite easy.

The static regions are probably another area where we can use xforms
though we would need to be careful of the more dynamic elements like
page numbers. 

-k.

ps: I'm also using (and planning to extend my use of) the FOP PDF
component externally to xsl:fo, so I'm interesting in adding features
that may not be specifically relevant to fo but very relevant to it's
usage as a PDF library. 

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://www.rocketred.com.au/blogs/kevin/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]