preprocessing of images
Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: preprocessing of images
Hi Maxime, Fop can work with quite a lot of image types. For resizing there are img attributes. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.dehttp://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.dehttp://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.dehttp://www.willmy.de Willmy Consult Content GmbH: www.willmycc.dehttp://www.willmycc.de Von: Maxime Bégnis [mailto:max...@neodoc.biz] Gesendet: Dienstag, 5. Oktober 2010 13:56 An: fop-users@xmlgraphics.apache.org Betreff: preprocessing of images Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis
Re: AW: preprocessing of images
hi Georg, Thanks for your answer. My question wasn't very precise, sorry. I would like to be able to convert the images referenced in the FO file whatever the attributes. For example, if I have a PNG file referenced in an fo:external-graphic element, I would like to convert the image into JPEG format with a quality of 40% and limit the dimensions to 400x400. This is mostly to provide control on the size of the resulting PDF without having to change the FO file or the referenced images. Thanks a lot. Maxime Bégnis Le 05/10/2010 14:03, Georg Datterl a écrit : Hi Maxime, Fop can work with quite a lot of image types. For resizing there are img attributes. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de http://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de http://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de http://www.willmy.de Willmy Consult Content GmbH: www.willmycc.de http://www.willmycc.de *Von:* Maxime Bégnis [mailto:max...@neodoc.biz] *Gesendet:* Dienstag, 5. Oktober 2010 13:56 *An:* fop-users@xmlgraphics.apache.org *Betreff:* preprocessing of images Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: AW: preprocessing of images
Hi Maxine, We preprocess the images with ImageMagick and put the preprocessed images into the PDF. I don't think there's another way nor will there ever be (in FOP). Maybe you can call a function during the transformation, but I'm no expert there. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.dehttp://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.dehttp://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.dehttp://www.willmy.de Willmy Consult Content GmbH: www.willmycc.dehttp://www.willmycc.de Von: Maxime Bégnis [mailto:max...@neodoc.biz] Gesendet: Dienstag, 5. Oktober 2010 14:19 An: fop-users@xmlgraphics.apache.org Betreff: Re: AW: preprocessing of images hi Georg, Thanks for your answer. My question wasn't very precise, sorry. I would like to be able to convert the images referenced in the FO file whatever the attributes. For example, if I have a PNG file referenced in an fo:external-graphic element, I would like to convert the image into JPEG format with a quality of 40% and limit the dimensions to 400x400. This is mostly to provide control on the size of the resulting PDF without having to change the FO file or the referenced images. Thanks a lot. Maxime Bégnis Le 05/10/2010 14:03, Georg Datterl a écrit : Hi Maxime, Fop can work with quite a lot of image types. For resizing there are img attributes. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.dehttp://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.dehttp://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.dehttp://www.willmy.de Willmy Consult Content GmbH: www.willmycc.dehttp://www.willmycc.de Von: Maxime Bégnis [mailto:max...@neodoc.biz] Gesendet: Dienstag, 5. Oktober 2010 13:56 An: fop-users@xmlgraphics.apache.orgmailto:fop-users@xmlgraphics.apache.org Betreff: preprocessing of images Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis
Re: AW: AW: preprocessing of images
Ok, thanks for your answers. Le 05/10/2010 14:23, Georg Datterl a écrit : Hi Maxine, We preprocess the images with ImageMagick and put the preprocessed images into the PDF. I don't think there's another way nor will there ever be (in FOP). Maybe you can call a function during the transformation, but I'm no expert there. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de http://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de http://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de http://www.willmy.de Willmy Consult Content GmbH: www.willmycc.de http://www.willmycc.de *Von:* Maxime Bégnis [mailto:max...@neodoc.biz] *Gesendet:* Dienstag, 5. Oktober 2010 14:19 *An:* fop-users@xmlgraphics.apache.org *Betreff:* Re: AW: preprocessing of images hi Georg, Thanks for your answer. My question wasn't very precise, sorry. I would like to be able to convert the images referenced in the FO file whatever the attributes. For example, if I have a PNG file referenced in an fo:external-graphic element, I would like to convert the image into JPEG format with a quality of 40% and limit the dimensions to 400x400. This is mostly to provide control on the size of the resulting PDF without having to change the FO file or the referenced images. Thanks a lot. Maxime Bégnis Le 05/10/2010 14:03, Georg Datterl a écrit : Hi Maxime, Fop can work with quite a lot of image types. For resizing there are img attributes. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de http://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de http://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de http://www.willmy.de Willmy Consult Content GmbH: www.willmycc.de http://www.willmycc.de *Von:* Maxime Bégnis [mailto:max...@neodoc.biz] *Gesendet:* Dienstag, 5. Oktober 2010 13:56 *An:* fop-users@xmlgraphics.apache.org mailto:fop-users@xmlgraphics.apache.org *Betreff:* preprocessing of images Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Preprocessing
Thanks, I have most stuff working again However, ... My SAXFilter does not work anymore (the one that performs syntax highlighting). It might be due to some ordering problem. The filter is injected using: CodeBlockXMLFilter filter = new CodeBlockXMLFilter(); filter.setContentHandler(fop.getDefaultHandler()); transformer.transform(xmlSource, new SAXResult(filter)); When the filter reaches my element, it writes all characters to a buffer, which is than processed in the endElement. The last step in the processing is inserting multiple fo:inline element (with the color of a specific keyword). I insert these elements using the methods of super (i.e., XMLFilterImpl): startElement, characters and endElement. It did work under 0.20.5... Any clues? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 11:30 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing On 05.06.2006 11:12:22 Raphael Parree wrote: Thanks yes I know the reason for the error, it is just that I didn't had so many with the 0.20.5 release. Probably has to do with the fact that 0.92 is more strict. Also many of my indentations have changed, and text seems to be more compressed. A few changes I see so far in the produced PDF: -Indentations (start-indent) is much larger. Is this because the start-indent from parent blocks are accumulated now? 0.20.5 had an awful compliance level in this area. The new codebase is a 100% compliant implementation for start-indent and friends. start-indent can accumulate if you cross reference-area boundaries (block-containers or tables in between. That is due to indent inheritance which is described in detail in: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance -space-before seems to be ignored? No, no. 0.20.5 always behaved as if space-before.conditionality=retain were specified. The new codebase does full space resolution (XSL 1.0, 4.3) except in footnote areas. That's what you're seeing. Just set space-before.conditionality=retain and your spaces will miraculously appear again. :-) -Some (all?) images seem to be bigger than before (SVG, I use the external-graphic element default) Hmm, depends on your SVGs. If they have absolute width and height (not specified in pixels) attributes and a viewbox (which is preferred in the first place), they will be the same as 0.20.5 or even better. Try setting source-resolution96/source-resolution (default is 72) in the user configuration file or use FopFactory.setSourceResolution(96). This changes the way the size of images only made up by a number of pixels are determined. Most SVG editors seem to use 96dpi, but that's not a hard value. Therefore, it is best practice to specify the size of SVG images in centimeters or inches or whatever. (-Bookmarks don't work (I saw the note on the website)) Where? XSL 1.1 bookmarks are fully implemented for PDF output. You simple have to change from fox:outline to XSL 1.1 bookmarks. See: http://xmlgraphics.apache.org/fop/0.92/upgrading.html For the rest it looks promising. snip/ 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: Preprocessing
Found it... The namespace on fo:inline's attributes must be NULL and not http://www.w3.org/1999/XSL/Format. -Original Message- From: Raphael Parree [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 16:31 To: 'fop-users@xmlgraphics.apache.org' Subject: RE: Preprocessing Thanks, I have most stuff working again However, ... My SAXFilter does not work anymore (the one that performs syntax highlighting). It might be due to some ordering problem. The filter is injected using: CodeBlockXMLFilter filter = new CodeBlockXMLFilter(); filter.setContentHandler(fop.getDefaultHandler()); transformer.transform(xmlSource, new SAXResult(filter)); When the filter reaches my element, it writes all characters to a buffer, which is than processed in the endElement. The last step in the processing is inserting multiple fo:inline element (with the color of a specific keyword). I insert these elements using the methods of super (i.e., XMLFilterImpl): startElement, characters and endElement. It did work under 0.20.5... Any clues? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 11:30 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing On 05.06.2006 11:12:22 Raphael Parree wrote: Thanks yes I know the reason for the error, it is just that I didn't had so many with the 0.20.5 release. Probably has to do with the fact that 0.92 is more strict. Also many of my indentations have changed, and text seems to be more compressed. A few changes I see so far in the produced PDF: -Indentations (start-indent) is much larger. Is this because the start-indent from parent blocks are accumulated now? 0.20.5 had an awful compliance level in this area. The new codebase is a 100% compliant implementation for start-indent and friends. start-indent can accumulate if you cross reference-area boundaries (block-containers or tables in between. That is due to indent inheritance which is described in detail in: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance -space-before seems to be ignored? No, no. 0.20.5 always behaved as if space-before.conditionality=retain were specified. The new codebase does full space resolution (XSL 1.0, 4.3) except in footnote areas. That's what you're seeing. Just set space-before.conditionality=retain and your spaces will miraculously appear again. :-) -Some (all?) images seem to be bigger than before (SVG, I use the external-graphic element default) Hmm, depends on your SVGs. If they have absolute width and height (not specified in pixels) attributes and a viewbox (which is preferred in the first place), they will be the same as 0.20.5 or even better. Try setting source-resolution96/source-resolution (default is 72) in the user configuration file or use FopFactory.setSourceResolution(96). This changes the way the size of images only made up by a number of pixels are determined. Most SVG editors seem to use 96dpi, but that's not a hard value. Therefore, it is best practice to specify the size of SVG images in centimeters or inches or whatever. (-Bookmarks don't work (I saw the note on the website)) Where? XSL 1.1 bookmarks are fully implemented for PDF output. You simple have to change from fox:outline to XSL 1.1 bookmarks. See: http://xmlgraphics.apache.org/fop/0.92/upgrading.html For the rest it looks promising. snip/ 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]
Preprocessing
Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) 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] 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: Preprocessing
I don't have a working example ready to pass over but I can give you some pointers. Essentially, I think you'd best implement an org.xml.sax.XMLFilter (you can case XMLFilterImpl as a base class). That's the recommended way. You can get some hints to the approach from: http://www.javalobby.org/java/forums/m91825016.html http://www.javalobby.org/forums/thread.jspa?threadID=16216tstart=0 In FOP we also have code that operates similarly although it's not a filter/conversion operation on the XML level. Since we're on the receiving end of the SAX chain and thus have to operate purely on the passive side, we can't use XMLFilter. Everything is implemented as a passive ContentHandler (active would mean it would be an XMLReader with parse() methods). This is all code used to build the FO tree and foreign elements. Building blocks are: - org.apache.fop.fo.FOTreeBuilder and it's nested MainFOHandler. - org.apache.fop.util.DelegatingContentHandler - org.apache.fop.util.ContentHandlerFactory - org.apache.fop.util.ContentHandlerFactoryRegistry But don't look too much at FOP. I'd use the XMLFilter approach. Good luck! On 02.06.2006 08:56:25 Raphael Parree wrote: Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing
Thanks got the highlighter working again using an XMLFilter (working on 0.20.5). Trying now to move to 0.92, but that is giving many headaches...many Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop occur...(I am now moving first without the extension/filter) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 02 June 2006 09:50 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing I don't have a working example ready to pass over but I can give you some pointers. Essentially, I think you'd best implement an org.xml.sax.XMLFilter (you can case XMLFilterImpl as a base class). That's the recommended way. You can get some hints to the approach from: http://www.javalobby.org/java/forums/m91825016.html http://www.javalobby.org/forums/thread.jspa?threadID=16216tstart=0 In FOP we also have code that operates similarly although it's not a filter/conversion operation on the XML level. Since we're on the receiving end of the SAX chain and thus have to operate purely on the passive side, we can't use XMLFilter. Everything is implemented as a passive ContentHandler (active would mean it would be an XMLReader with parse() methods). This is all code used to build the FO tree and foreign elements. Building blocks are: - org.apache.fop.fo.FOTreeBuilder and it's nested MainFOHandler. - org.apache.fop.util.DelegatingContentHandler - org.apache.fop.util.ContentHandlerFactory - org.apache.fop.util.ContentHandlerFactoryRegistry But don't look too much at FOP. I'd use the XMLFilter approach. Good luck! On 02.06.2006 08:56:25 Raphael Parree wrote: Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) 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]
