Re: Form XObject (was: Re: Avalonization?)
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?)
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. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Form XObject (was: Re: Avalonization?)
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]
AW: Form XObject (was: Re: Avalonization?)
> 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. What does your xsl:fo input look like? Standard xsl:fo according to specs? > Von: Keiron Liddle [mailto:keiron@;aftexsw.com]> 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. > What do PDF XObjects, Bookmarks, form fields have to do in the area tree? How about device independence? How will the PCL and AWT renderers process XObjects? A layered distiction between the jobs of a (device independent) fo formatter and the renderers (generation of device dependent graphic streams, caching, ressource management) will keep the system maintainable. This can be achieved by instream-foreign-objects: the fo proscessor calculates page numbers/positions, reserves presentation spaces and passes foreign-object contents/control unchanged and unchecked to renderers. Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Form XObject (was: Re: Avalonization?)
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. 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. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Avalonization?
On Tue, 2002-11-12 at 21:35, Keiron Liddle wrote: > On Tue, 2002-11-12 at 11:28, Kevin O'Neill wrote: > > On Tue, 2002-11-12 at 18:40, Jeremias Maerki wrote: > > > Cool. I'm going to ping you as soon as I'm ready to go for it again. Too > > > little time this week to give you any directions. If you find anything, > > > go for it. IMO the PDF library would also profit from a little > > > refactoring and some additions like signing and encryption > > > > I'm looking at xobject forms and masks at the moment. > > 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. > Keiron > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > -- 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: Avalonization?
On Tue, 2002-11-12 at 11:28, Kevin O'Neill wrote: > On Tue, 2002-11-12 at 18:40, Jeremias Maerki wrote: > > Cool. I'm going to ping you as soon as I'm ready to go for it again. Too > > little time this week to give you any directions. If you find anything, > > go for it. IMO the PDF library would also profit from a little > > refactoring and some additions like signing and encryption > > I'm looking at xobject forms and masks at the moment. I just added a Form XObject but it needs some work (eg. bounds). Keiron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Avalonization?
On Tue, 2002-11-12 at 18:40, Jeremias Maerki wrote: > Cool. I'm going to ping you as soon as I'm ready to go for it again. Too > little time this week to give you any directions. If you find anything, > go for it. IMO the PDF library would also profit from a little > refactoring and some additions like signing and encryption I'm looking at xobject forms and masks at the moment. > On 12 Nov 2002 18:22:02 +1100 Kevin O'Neill wrote: > > On Tue, 2002-11-12 at 18:18, Jeremias Maerki wrote: > > > Not really. I've done some preparational work in August (mostly logging > > > stuff, during my holidays). Back to work there was little free time left > > > to do anything. Now, everything's changed and I'll be able to get back > > > to FOP redesign (and Avalonization) in one or two weeks. Wanna help? > > > > Sure, my area is really PDF, I have some experience with Avalon, but I'd > > be glad to help. > > > > > On 12 Nov 2002 09:35:04 +1100 Kevin O'Neill wrote: > > > > I've been away from FOP for a while (contracts took me to other places) > > > > so I'm playing a little catchup. > > > > > > > > When I departed there was some work going on to "Avalonize" FOP into > > > > components, has this continued? > > > Jeremias Maerki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > -- 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: Avalonization?
Cool. I'm going to ping you as soon as I'm ready to go for it again. Too little time this week to give you any directions. If you find anything, go for it. IMO the PDF library would also profit from a little refactoring and some additions like signing and encryption On 12 Nov 2002 18:22:02 +1100 Kevin O'Neill wrote: > On Tue, 2002-11-12 at 18:18, Jeremias Maerki wrote: > > Not really. I've done some preparational work in August (mostly logging > > stuff, during my holidays). Back to work there was little free time left > > to do anything. Now, everything's changed and I'll be able to get back > > to FOP redesign (and Avalonization) in one or two weeks. Wanna help? > > Sure, my area is really PDF, I have some experience with Avalon, but I'd > be glad to help. > > > On 12 Nov 2002 09:35:04 +1100 Kevin O'Neill wrote: > > > I've been away from FOP for a while (contracts took me to other places) > > > so I'm playing a little catchup. > > > > > > When I departed there was some work going on to "Avalonize" FOP into > > > components, has this continued? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Avalonization?
On Tue, 2002-11-12 at 18:18, Jeremias Maerki wrote: > Not really. I've done some preparational work in August (mostly logging > stuff, during my holidays). Back to work there was little free time left > to do anything. Now, everything's changed and I'll be able to get back > to FOP redesign (and Avalonization) in one or two weeks. Wanna help? Sure, my area is really PDF, I have some experience with Avalon, but I'd be glad to help. > On 12 Nov 2002 09:35:04 +1100 Kevin O'Neill wrote: > > I've been away from FOP for a while (contracts took me to other places) > > so I'm playing a little catchup. > > > > When I departed there was some work going on to "Avalonize" FOP into > > components, has this continued? > > > Jeremias Maerki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > -- 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: Avalonization?
Not really. I've done some preparational work in August (mostly logging stuff, during my holidays). Back to work there was little free time left to do anything. Now, everything's changed and I'll be able to get back to FOP redesign (and Avalonization) in one or two weeks. Wanna help? On 12 Nov 2002 09:35:04 +1100 Kevin O'Neill wrote: > I've been away from FOP for a while (contracts took me to other places) > so I'm playing a little catchup. > > When I departed there was some work going on to "Avalonize" FOP into > components, has this continued? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Avalonization?
I've been away from FOP for a while (contracts took me to other places) so I'm playing a little catchup. When I departed there was some work going on to "Avalonize" FOP into components, has this continued? -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]
