Re: Re: RTF, nested tables, context enhancement - status
- original Nachricht Betreff: Re: RTF, nested tables, context enhancement - status Gesendet: Fr 26 Mai 2006 16:42:13 CEST Von: Jeremias Maerki[EMAIL PROTECTED] On 23.05.2006 08:02:50 b.ohnsorg wrote: - original Nachricht Betreff: Re: RTF, nested tables, context enhancement - status Gesendet: Mo 22 Mai 2006 22:30:07 CEST Von: Jeremias Maerki[EMAIL PROTECTED] page-number-citation and page numbering: Both work to at least a certain degree. Can you elaborate on the problems you're seeing? RTF does not know any «citation», so you need to write a character '2', if you want a link to display a page information refering to page '2'. For example an index at the end of the document does not know, which page explains «Barcode» and all links will show a question mark. That's not correct. RTF has support for page number citations. You should take a lot at the RTF specification and create an RTF file in MS Word with references so you see how this should be implemented. If someone has a reliable resource, let me know. I don't own any Micros~1 component and took OpenOffice-documents. They contain fields like MS-Office, but page numbers are hard coded. (tried cross referencing and TOC-mechanism) I thought about that last night (while cruising through the PDF-renderer to compare my table width «guessing» with the already implemented one) and draw the following conclusion: Fact 1: RTF knows page breaks Wrong. RTF can contain hard page breaks but doesn't have to. That's what I say: «knows page breaks» (and it's obvious, that I mean Insert-Page break-«Manual page break») Fact 2: RTF is page-oriented Wrong. RTF is a flow-oriented format. Microsoft Word is responsible for the page break decisions unless you add hard page breaks. Same intention, other words. Mkay, it's a «stream» of format attributes, but it's intended to render to pages, therefore you may insert a page break. If it would be a drawing program, intended to render to large sheets of paper to stick to walls, it would not include page breaking. Depends on point of view. (You may set the page size to any value one may think of, mkay, but that's not the point. Another example would be an index or cross reference with the page number appended) Fact 3: RTF aligns elements absolute Yes. Fact 4: RTF does not know anything about the document's structuring Depends on what you mean by structure. RTF supports styles which allow some kind of structuring. Telling a block of text to be Arial, 22pt, underlined and bold is not structure, but formatting. You may assume that this is heading level 1 but it could also be a capitalized letter or dadaistic poem. What I mean with structure is something like: h1May there be light/h2, so it's a heading, nothing else (I exclude mistakenly used tags by HTML-beginners). Conclusion: RTF differs not that much from PDF-rendering (only written tokens are a bit different) - Use the PDF-layout management system and add a RTF-writer. So RTF would look exactly like all PDFs. And there's only a slight difference from Office-generated RTFs: page breaks after every page. That would defeat the purpose of the current RTF output support. The clue is that you can edit the generated file and then print it. If you predefine the page breaks you make the editing a lot harder for the end-user. If you don't need RTF editing, then don't generate RTF because PDF offers much better quality. And that's what I wanted to read: There's no need for all that TOC-ing, page number citation and whatsoever. Therefore also indenting makes no sense, esp. when nesting blocks, tables and lists. Mkay, there should be a small amount of space between a list item and it's bullet, but for editing you don't need any formatting attributes - what makes it a lot easier. What's exactly the problem with graphics? We've got pretty good support for many cases, even SVG now. I was only talking about the current RTF export. AFAIK GIFs are not rendered (there was an annoying exception string inside the document). GIF: The LZW patents are expired but still it's a good idea to forget GIF. The legal side is still less than clear. But PDF «understands» GIFs, so I can use them. Should be the same with RTF, and the only thing I'll do is reading them and transform into a RTF-compatible format...if it's not legal I won't do this... PDF doesn't understand GIFs. Images are converted from GIF to a generic bitmap format supported by PDF. In the case of RTF output this code hasn't been written, yet. Patches welcome. That's what I wanted to hear, too. RTF does support referenced images. So there ought to be a switch (render to the document, use references) ...if someone implements that switch. me got list - ugh! Over all, your post seems to address topics which, as far as I know, are mostly solved, so I'm
Re: RTF, nested tables, context enhancement - status
It would be good if we could migrate this thread to fop-dev. Please subscribe there if you're not already. Thanks. On 30.05.2006 08:13:50 b.ohnsorg wrote: - original Nachricht Betreff: Re: RTF, nested tables, context enhancement - status Gesendet: Fr 26 Mai 2006 16:42:13 CEST Von: Jeremias Maerki[EMAIL PROTECTED] On 23.05.2006 08:02:50 b.ohnsorg wrote: - original Nachricht Betreff: Re: RTF, nested tables, context enhancement - status Gesendet: Mo 22 Mai 2006 22:30:07 CEST Von: Jeremias Maerki[EMAIL PROTECTED] page-number-citation and page numbering: Both work to at least a certain degree. Can you elaborate on the problems you're seeing? RTF does not know any «citation», so you need to write a character '2', if you want a link to display a page information refering to page '2'. For example an index at the end of the document does not know, which page explains «Barcode» and all links will show a question mark. That's not correct. RTF has support for page number citations. You should take a lot at the RTF specification and create an RTF file in MS Word with references so you see how this should be implemented. If someone has a reliable resource, let me know. I don't own any Micros~1 component and took OpenOffice-documents. They contain fields like MS-Office, but page numbers are hard coded. (tried cross referencing and TOC-mechanism) You can get it from M$: RTF 1.7 (MS Word 2002): http://www.microsoft.com/downloads/details.aspx?FamilyID=e5b8ebc2-6ad6-49f0-8c90-e4f763e3f04fDisplayLang=en (that's what I currently use) RTF 1.8 (MS Word 2003): http://www.microsoft.com/downloads/details.aspx?familyid=AC57DE32-17F0-4B46-9E4E-467EF9BC5540displaylang=en Don't forget to have an MS Word (or Word Viewer) installed somewhere. The specification alone doesn't really help. OpenOffice is useless for this. I thought about that last night (while cruising through the PDF-renderer to compare my table width «guessing» with the already implemented one) and draw the following conclusion: Fact 1: RTF knows page breaks Wrong. RTF can contain hard page breaks but doesn't have to. That's what I say: «knows page breaks» (and it's obvious, that I mean Insert-Page break-«Manual page break») So, we're talking a completely different language. :-( Someone want to write a FOP glossary? ;-) Fact 2: RTF is page-oriented Wrong. RTF is a flow-oriented format. Microsoft Word is responsible for the page break decisions unless you add hard page breaks. Same intention, other words. Mkay, it's a «stream» of format attributes, but it's intended to render to pages, therefore you may insert a page break. If it would be a drawing program, intended to render to large sheets of paper to stick to walls, it would not include page breaking. Depends on point of view. (You may set the page size to any value one may think of, mkay, but that's not the point. Another example would be an index or cross reference with the page number appended) Fact 3: RTF aligns elements absolute Yes. Fact 4: RTF does not know anything about the document's structuring Depends on what you mean by structure. RTF supports styles which allow some kind of structuring. Telling a block of text to be Arial, 22pt, underlined and bold is not structure, but formatting. You may assume that this is heading level 1 but it could also be a capitalized letter or dadaistic poem. What I mean with structure is something like: h1May there be light/h2, so it's a heading, nothing else (I exclude mistakenly used tags by HTML-beginners). Again the language problem maybe. My styles refers not only to the group of formatting attributes but also to the attributes indicating whether the heading level. However, it seems this is not written down in the RTF specification. If you look at a Word-generated RTF file you'll see the private attribute soutlvl, for example. While this may not be structure by itself but at least an indication of structure. But the argument probably makes no sense as XSL-FO doesn't support structure, either. You can't distinguish a header from a normal paragraph. Conclusion: RTF differs not that much from PDF-rendering (only written tokens are a bit different) - Use the PDF-layout management system and add a RTF-writer. So RTF would look exactly like all PDFs. And there's only a slight difference from Office-generated RTFs: page breaks after every page. That would defeat the purpose of the current RTF output support. The clue is that you can edit the generated file and then print it. If you predefine the page breaks you make the editing a lot harder for the end-user. If you don't need RTF editing, then don't generate RTF because PDF offers much better quality. And that's what I wanted to read: There's no need for all that TOC-ing, page number citation and whatsoever.
Re: OutOfMemoryError: Java heap space
As has been said many times on this list, FOP still has some restrictions concerning the handling of large documents. There are a bunch of work-arounds, most of them documented on the website and many of them elaborated on this list. The long-term solution is to allocate resources to help us improve FOP in this direction. Ideas are there. Resources are not. Yet, anyway. On 30.05.2006 01:10:15 Daniel Noll wrote: David Delbecq wrote: Increase memory allocated to java with -Xmx256m That's an invalid solution for two reasons: 1. Customers who use our application often only have about 256MB maximum RAM or less, and setting more than that will cause excessive paging to disk. 2. We're already using -Xmx512m and FOP is *still* running out of memory. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ImageCache in FOP 0.92beta
We have a strange behaviour in our application. There is the possibility to generate single PDFs or several PDFs in series. There is no problem when producing single PDFs but when generating large series of PDFs (the same as can be generated singly), we ar running in an OutOfMemoryException. As is stated on the FOP Memory webpage, clearing the image from time to time cache might prevent memory exhaustion (we are running FOP embedded). Do you agree that this could solve the problem? How to do this with FOP 0.92beta? The description is only available on the webpage for FOP 0.20.5... Thx for your help Dominic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutOfMemoryError: Java heap space
Daniel Noll wrote: David Delbecq wrote: Increase memory allocated to java with -Xmx256m That's an invalid solution for two reasons: 1. Customers who use our application often only have about 256MB maximum RAM or less, and setting more than that will cause excessive paging to disk. 2. We're already using -Xmx512m and FOP is *still* running out of memory. This is a FAQ. Read the section on FOP Memory: http://xmlgraphics.apache.org/fop/faq.html#OutOfMemoryException The short answer is FOP keeps an entire page-sequence in memory. You probably need to break up your text into multiple page sequences to avoid keeping the entire document in memory. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: Metric Files
Kring, Rainer wrote: After using a font metrics (at least I think the cause is the font metrics) created with FOP's TTFReader out of a True Type Font, I get white spaces above and below the text in PDF-Files. So want I to try it with Type1 fonts. Are you sure the spaces aren't casued by the half-leading? You can try adjusting the line-height property to reduce the amount of leading. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LazyFont NullPointerException
I guessed that you're using 0.20.5 from the stack trace but yes, it's always good to state the FOP version. I don't have access to a MacOSX system that would allow me to track this down. You should find out if there are any apparent differences in the setup between the operating systems. It may necessary to run a debugger. If it's possible I'd suggest you try to see if you can use FOP 0.92beta instead. It may well be that the problem doesn't exist in that version. Otherwise, it's where the fun happens and where problems are much more likely to be solved. 0.20.5 is not maintained anymore. On 29.05.2006 17:59:44 Raphael Parree wrote: Hi, No there is no such message. I should probably also say that I am still using version 0.20.5 and not the latest from SVN. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 29 May 2006 16:42 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Was there a message Failed to read font metrics file... just before the exception? If yes, the NullPointerException is a consequence of that error. Maybe it's just a path which is not correct. On 29.05.2006 08:43:16 Raphael Parree wrote: Hi, I get the following error when trying to run an app on Mac X. I have successfully ran this app on Linux and Windows. I did see a posting back in 2003 with the same problem, but no apparent solution. The fonts I use are Verdana and Arial (bold, italic etc). The TTF files originate from a Windows XP machine (which do work on Redhat). snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: Metric Files
Unfortunately line-height doesn't reduce the white spaces. The white space varies with the used font and the size of the font. White spaces only occur when using font metric files created with TTFReader. It works correctly with Helvetica (see http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#Base-14+Fonts). But I don't need those. So I tried it the other way round. I generated a Type1 font out of the TTF with Fontforge. But when trying to generate the XML-font metrics-file (see http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#type1-metrics) we get OutOfMemoryError: Java heap space. -Ursprüngliche Nachricht- Von: Chris Bowditch [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Mai 2006 09:54 An: fop-users@xmlgraphics.apache.org Betreff: Re: AW: AW: Metric Files Kring, Rainer wrote: After using a font metrics (at least I think the cause is the font metrics) created with FOP's TTFReader out of a True Type Font, I get white spaces above and below the text in PDF-Files. So want I to try it with Type1 fonts. Are you sure the spaces aren't casued by the half-leading? You can try adjusting the line-height property to reduce the amount of leading. Chris - 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: ImageCache in FOP 0.92beta
This will be hard to debug as the generation of this series of PDFs takes almost an hour and the exception happens late in the process. But I will test if the exception does not happen when calling fopFactory.getImageFactory().clearCaches() manually. Jeremias Maerki wrote: The image cache has been improved so the manual image cache clearing should be unnecessary. Still, you can call fopFactory.getImageFactory().clearCaches(). But if this is really necessary then we have a problem in the image cache that should be solved and not worked around. I have done tests a few months ago and did not manage to cause OutOfMemoryErrors. So if your environment does, it would be great if you could try to debug and find out why exactly this happens. The image cache uses a WeakHashMap for the images so the memory should actually be reclaimed if the JVM starts to run out of memory. So if that doesn't happen, something is wrong. On 30.05.2006 10:51:09 Dominic Brügger wrote: We have a strange behaviour in our application. There is the possibility to generate single PDFs or several PDFs in series. There is no problem when producing single PDFs but when generating large series of PDFs (the same as can be generated singly), we ar running in an OutOfMemoryException. As is stated on the FOP Memory webpage, clearing the image from time to time cache might prevent memory exhaustion (we are running FOP embedded). Do you agree that this could solve the problem? How to do this with FOP 0.92beta? The description is only available on the webpage for FOP 0.20.5... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dominic Brügger Software-Ingenieur WIR SIND UMGEZOGEN und haben eine neue Adresse sowie neue Telefonnummern: Puzzle ITC GmbH Eigerplatz 4 CH-3007 Bern Telefon +41 31 370 22 00 Direkt +41 31 370 22 13 Mobile +41 79 740 99 03 Fax +41 31 370 22 01 www.puzzle.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: LazyFont NullPointerException
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?) Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 09:51 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException I guessed that you're using 0.20.5 from the stack trace but yes, it's always good to state the FOP version. I don't have access to a MacOSX system that would allow me to track this down. You should find out if there are any apparent differences in the setup between the operating systems. It may necessary to run a debugger. If it's possible I'd suggest you try to see if you can use FOP 0.92beta instead. It may well be that the problem doesn't exist in that version. Otherwise, it's where the fun happens and where problems are much more likely to be solved. 0.20.5 is not maintained anymore. On 29.05.2006 17:59:44 Raphael Parree wrote: Hi, No there is no such message. I should probably also say that I am still using version 0.20.5 and not the latest from SVN. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 29 May 2006 16:42 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Was there a message Failed to read font metrics file... just before the exception? If yes, the NullPointerException is a consequence of that error. Maybe it's just a path which is not correct. On 29.05.2006 08:43:16 Raphael Parree wrote: Hi, I get the following error when trying to run an app on Mac X. I have successfully ran this app on Linux and Windows. I did see a posting back in 2003 with the same problem, but no apparent solution. The fonts I use are Verdana and Arial (bold, italic etc). The TTF files originate from a Windows XP machine (which do work on Redhat). 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: How to prefer FOP native for JAI
Jeremias Maerki dev at jeremias-maerki.ch writes: As Joerg suggested earlier, this seems to be a class loader problem. We already check for both conditions a) and b). I've just checked and FOP falls back nicely to ImageIO if support for JAI is compiled but JAI is not present during runtime. In my case, loading JAIImage resulted in a ClassNotFoundError (for javax/media/jai/PlanarImage) during class loading which ImageFactory catches nicely. In Raino's case this does not seem to work. Maybe we need to add explicit checks for the presence of a particular library to work around any strange effects by certain class loader setups. First step, however, is to reproduce the problem which I haven't managed. I guess Raino will need to tell us exactly what web container he uses. I use Weblogic 8.1.5.0 and Spring framework. this error never appeared on command line. onli in webconteiner. if i use jpg image evrything is corret. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extra space between following tables
Hi all, I'm rendering several simple tables one by one and experiencing the extra space between them. This space has no (IMHO) any reason, as tables has no space before/after or margin defined. I attached the simple example - two tables with one row and one cell, border defined on the table element to see the table block. When tables are placed as direct children of fo:flow, the output is correct - no space between. When I enclose these two tables to single fo:block, suddenly there is extra space rendered. I would appreciate any help... Cheers Martin === FOP version: 0.92beta Attachments: - tables.fo (source to render table_bug_wrong.pdf) - tables_wrong.pdf (tables with extra space between) - tables_correct.pdf (correct output after removing the enclosing fo:block) === ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin-right=0.5in margin-left=0.5in margin-bottom=0.5in margin-top=0.5in page-width=8.5in page-height=11in master-name=chapter-page fo:region-body margin-left=0.5in margin-right=0.5in margin-top=0.5in margin-bottom=0.5in/ /fo:simple-page-master fo:page-sequence-master master-name=sequence-chapter fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=chapter-page/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence format=1 master-reference=sequence-chapter fo:flow font-family=Times font-size=12pt flow-name=xsl-region-body fo:block!-- remove this element to get correct output -- fo:table table-layout=fixed width=100% border=0.2pt solid green border-collapse=separate fo:table-column column-width=proportional-column-width(1)/ fo:table-body fo:table-row fo:table-cell fo:blockTable 1 Cell/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table fo:table table-layout=fixed width=100% border=0.2pt solid green border-collapse=separate fo:table-column column-width=proportional-column-width(1)/ fo:table-body fo:table-row fo:table-cell fo:blockTable 2 Cell/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block!-- remove this element to get correct output -- /fo:flow /fo:page-sequence /fo:root tables_correct.pdf Description: Adobe PDF document tables_wrong.pdf Description: Adobe PDF document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: LazyFont NullPointerException
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]
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]
RE: LazyFont NullPointerException
That sounds almost too easy to be true... I am hitting my head on the table why I never thought of leaving the FOP extension path and thought of pre processing with a SAX parser... I guess at the time (which is a long time ago) we had restricting requirements (just trying to convince myself). Tx for the eye opener!! My XML has -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: Extra space between following tables
-Original Message- From: Martin Zak [mailto:[EMAIL PROTECTED] I'm rendering several simple tables one by one and experiencing the extra space between them. This space has no (IMHO) any reason, as tables has no space before/after or margin defined. I attached the simple example - two tables with one row and one cell, border defined on the table element to see the table block. When tables are placed as direct children of fo:flow, the output is correct - no space between. When I enclose these two tables to single fo:block, suddenly there is extra space rendered. === FOP version: 0.92beta Attachments: - tables.fo (source to render table_bug_wrong.pdf) - tables_wrong.pdf (tables with extra space between) - tables_correct.pdf (correct output after removing the enclosing fo:block) === Hi, I think this happens because there is some extra space before or after tables, due to allocation rectangle, determinded by the line-stacking-strategy trait. I suppose this is a correct rendering, but I'm not sure. Try to set both line-height and font-size to 0pt (if not specified, line-height defaults to 1.2 font-size). If you do that, you'll need to reset font-size/line-height to your tables, inserting for example a fo:wrapper between fo:block and fo:table. HTH Pascal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to prefer FOP native for JAI
Jeremias Maerki wrote: As Joerg suggested earlier, this seems to be a class loader problem. I noticed the missing class seems to be from the codec jar. Maybe only this jar is missing, or can't be accessed for some other reason. Jai also uses native libraries, which might be a problem too (although that's far fetched). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
