Bug report for Fop [2007/07/15]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 2909|New|Maj|2001-07-30|Gradient render error | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3497|New|Cri|2001-09-07|id already exists error when using span=all attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving| | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes | | 8819|New|Nor|2002-05-06|Footnotes lost| | 9054|Opn|Maj|2002-05-14|PDF Tc Text operator BUG | | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | | 9569|New|Maj|2002-06-03|break does not work on block-container| | 9864|New|Nor|2002-06-14|fo:list-item-label at the end of line | | 9885|New|Nor|2002-06-14|link in pdf to another pdf through url doesn't wor| |10379|New|Enh|2002-07-01|Improvement to FOP Classloader| |11032|New|Min|2002-07-22|Height of table-cell is calculated incorrect when | |11783|New|Maj|2002-08-16|fo:block background-color=xtext/fo:block gen| |12262|New|Min|2002-09-03|Lacking detection of endless loops| |12300|New|Nor|2002-09-04|letter-spacing problem on sequencing pages| |12448|New|Nor|2002-09-09|Height of lines set by line-height are too short. | |12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses| |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |13450|New|Cri|2002-10-09|FOP0.20.4 embedded rendering throws exception | |13464|Opn|Nor|2002-10-09|part of word missing when broken across pages | |13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br| |13592|New|Nor|2002-10-14|Converting a FO document with PNG images into PS | |13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string| |13807|New|Nor|2002-10-21|list-block in table-cell | |14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples | |14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu| |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver |
Re: Remove Useless Comments
On Jul 15, 2007, at 14:17, Andreas L Delmelle wrote: On Jul 14, 2007, at 21:22, Andreas L Delmelle wrote: On Jul 14, 2007, at 15:59, Vincent Hennebert wrote: snip / Thanks, Andreas. We should perhaps just wait a couple of days, just to be sure everybody's ok with that? Indeed, let's give everyone a chance to react before committing. snip / Will have to go over them one by one and decide which ones to replace, I guess. :/ FYI: just finished this task, and it's ready to be committed now. The javadocs build with only one small warning concerning @todo tags somewheres (which I don't take to be a major issue) If no objections are raised by Wednesday evening GMT+1, I'll go ahead and commit. Cheers Andreas
DO NOT REPLY [Bug 42906] New: - NullPointerException in area.AreaTreeHandler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42906. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42906 Summary: NullPointerException in area.AreaTreeHandler Product: Fop Version: 0.93 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] during execution of : ./fop -xsl xsl_VmDxcj -xml xml_SRrZf7 -pdf zzz.pdf it fails with NullPointerException in area.AreaTreeHandler all this under Linux FC6; did't try anything else or anywhere else. the files may be found here : http://www.vtech.fr/bugs/xsl_VmDxcj (~ 250K) http://www.vtech.fr/bugs/xml_SRrZf7 (~ 330K) although I don't know if it's a correct way to give you access to sample files. Rgds, -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
Hi Andreas, Author: adelmelle Date: Fri Jul 13 12:21:03 2007 New Revision: 556112 URL: http://svn.apache.org/viewvc?view=revrev=556112 Log: Addition of a general-purpose int-to-int map to replace Integer-to-Integer HashMaps + first usage in TTFFile Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/util/IntMap.java (with props) This change makes me a bit uneasy. No doubt that this class is clever and efficient and working, but that's something more to maintain. By quickly looking at it I couldn't figure out exactly how it is working, and this is the kind of code that is very easy to modify in a wrong way. Granted, it's done, working, and it will probably not change much. But, well, even if a bit inconvenient and probably not the most efficient, hashmaps were basically doing the thing. What I mean is that, well, there are already so many other things to do... Moreover, before an IntMap makes the difference compared to a HashMap of Integers regarding performance, there are somewhat bigger architectural changes to perform ;-) Ok, I guess the fun you had while writing this class was a big motivation for the change ;-) Still. Just a thought, Vincent
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
On Jul 16, 2007, at 16:38, Vincent Hennebert wrote: Hi This change makes me a bit uneasy. No doubt that this class is clever and efficient and working, but that's something more to maintain. By quickly looking at it I couldn't figure out exactly how it is working, and this is the kind of code that is very easy to modify in a wrong way. You're probably right about that. Should've made this more of a proposal than just going ahead. Granted, it's done, working, and it will probably not change much. But, well, even if a bit inconvenient and probably not the most efficient, hashmaps were basically doing the thing. Well, that was the thought. Not so much the HashMaps themselves, but more the look of all the Integers being constructed solely for the purpose of being able to store ints in a Map. What I mean is that, well, there are already so many other things to do... Moreover, before an IntMap makes the difference compared to a HashMap of Integers regarding performance, there are somewhat bigger architectural changes to perform ;-) That certainly is a fact! I just had this still lying around, noticed it while going over a unified diff, and decided to commit it, but it's probably best to wait a while, as I was actually still unsure of how to integrity-test such a thing... :/ Ok, I guess the fun you had while writing this class was a big motivation for the change ;-) Still. Hmm, it was indeed fun :-) OTOH, the small binary search loop is basically copied from some other class in the codebase. For the rest, it's pretty much common sense... That said, you are absolutely correct in questioning this change. I guess the wisest course of action, release-wise, is to revert this change while it is still little. I'll keep it in the closet to revisit at a later time. I'll take care of this tomorrow. Cheers Andreas
Re: Remove Useless Comments
Andreas L Delmelle wrote: The javadocs build with only one small warning concerning @todo tags somewheres (which I don't take to be a major issue) The @todo is a custom tag, which are available with Java 1.4. I thought I added a definition for this to the javadoc task in build.xml. In principle we could use @todo tags to generate a todo document for the web site, if we hadn't already a wiki page for this. J.Pietschmann
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
Vincent Hennebert wrote: Addition of a general-purpose int-to-int map ... ... This change makes me a bit uneasy. No doubt that this class is clever and efficient and working, but that's something more to maintain. Jakarta Commons Collections has all kind of clever implementation. Don't they have already something similar, and if not, would it make sense to donate this implementation to Collections? J.Pietschmann
DO NOT REPLY [Bug 42906] - NullPointerException in area.AreaTreeHandler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42906. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42906 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2007-07-16 14:51 --- Ouch... Seems that I just missed the point and misunderstood something here (and obviously opened a bug without giving this enough thought). Sorry - please close this bug. Flynn -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
FontSources
Hi all, In the process of looking at this bug (http://issues.apache.org/bugzilla/show_bug.cgi?id=42861) I came to the conclusion that I´m not really happy with the current font handling implementation. There is quite a bit of duplicated effort between the renderers with regards to font configuration. I would very much like to see a shared ¨FontSource¨ implementation (e.g. both the Postscript and PDF renderers could make use of a shared Base14FontSource and CustomFontSource) instead of having their own separate configurations. Any new implementation would of course (initially at least) remain backwards compatible with existing FOP font configurations. I believe these ideas were spoken about a while ago and I do not think it would be too much work and it should simplify font configuration somewhat and should be more efficient in embedded implementations that make use of more than one renderer. Its probably a bit late in the day to make the 0.94 release, but in the longer term does anybody have any initial thoughts on this proposal? Adrian.
