Bug report for Fop [2007/04/01]
+---+ | 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| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1773|Opn|Blk|2001-05-16|A table that is bigger than the page produces an e| | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 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| | 4814|Opn|Nor|2001-11-12|0.20.2RC infinitely loops if there are tables in f| | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|New|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 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|
Re: Suggestion: refactoring property access in the FO tree?
Hi Andreas, Andreas L Delmelle a écrit : On Mar 30, 2007, at 11:21, Vincent Hennebert wrote: snip/ In ancient times, each FO had a full PropertyList, so the properties could be queried via a generic get(PROPERTY_ID) accessor that was simply a proxy to the PropertyList's corresponding get(). This was, however, a much less efficient approach than what we currently have. To be sure I understand: each object had the very same list of properties, with null values for the properties wich were not applicable to it? Errm... yes, if what you mean by 'the very same' is 'a different instance of the very same type'. Yes that's what I meant. Am I imprecise sometimes. And I dare complaining about the Rec's uncertainties ;-) Each FObj instance had its very own instance of the same PropertyList type. And the loss of efficiency was due to the indirection caused by the generic get(PROPERTY_ID) I guess? The biggest inefficiency was the space that these lists consume. They allocate space for an array with a number of elements equal to the number of /possible/ properties, effectively wasting space in case of FOs to which only a handful properties apply. On top of that, this space was not reclaimed until very late in the process, whereas now, the PropertyLists and their backing arrays in most cases can be garbage-collected right after endElement(). A FO to which only three properties apply will currently have only three instance variables corresponding to those properties. In the old architecture, it would have one PropertyList member, containing an array that could store some 250 Property instances, but only three elements were actually in use... Not that I want to go back to that situation, but a Map instead of an array would probably have been acceptable? More memory-efficient without being much more CPU-intensive I think. The inefficiency caused by the indirection I would consider to be a small but necessary price to pay for an increased amount of flexibility and extensibility. I fully agree. Good design should not be sacrificed for efficiency. Anyway only the profiling of a FOP run would give us proper indications of what is actually eating time and memory, and where we should start optimizing. snip / Each of the particular FO classes can then define its own implementation, which stores the applicable properties and maybe, for some FOs (like FOText!), this implementation can simply search the ancestors, instead of having to allocate space for properties that are always identical and can't be specified anyway... Hmmm. My understanding of the whole thing is still a bit vague, but wouldn't that lead to the same code replication as we have now? I'm wondering if it's not possible to define a restricted number of implementations of this interface, each applying to a whole set of similar FOs. Good point! Or use object composition: there would be objects dealing with a particular set of properties (say, border/padddin/background), and each FO for which that set applies would be composed of the corresponding object. Perhaps the flyweight pattern could apply here: only one object for each set of properties, initializing the correct fields in the FObj. With some means to automagically wire everything by using marker interfaces or whatever. Also fine suggestions. I'm going to chew on these a bit more. As I said my ideas are still all pretty vague... Also, does anyone have knowledge about aspect programming? I've the feeling that could apply quite well here. Just been reading up on AOSD, and it does indeed seem to be fitting in here. The downside would be the loss in convenience, for instance, where we now have individual accessors returning a Length, LengthRange, Numeric... Not sure how I would address this, yet. :/ I'm not sure of what you mean? The same property can be accessed in different ways? What I mean is that right now, the bind() method already takes care of getting the right type of Property. pList.get(PROPERTY_ID).getLengthRange() for instance... An accessor getInlineProgressionDimension(), for example, returns a LengthRange (not a Property). Ok, I see your point. Well then the specific implementations I was talking about earlier could probably handle that. For example almost every formatting object can have border/padding/background. We would have a specific class in charge of getting the values of these properties set on the object (or retrieving inherited values), and converting them into the right types (e.g., LengthRange). Each applicable object would be given an instance of such a class at its creation. When needed it would call the specific methods from this class (getBorderBefore, etc.). Something like that... Cheers, Vincent
RE: svn commit: r524608 - /xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fop.fo.ElementMapping
Hi, I get 11 errors and cannot build this rev. Latest working rev was 524578 (for me). I attached the build log. Pascal -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : dimanche 1 avril 2007 16:51 À : fop-commits@xmlgraphics.apache.org Author: jbryant Date: Sun Apr 1 07:51:19 2007 New Revision: 524608 URL: http://svn.apache.org/viewvc?view=revrev=524608 Log: changes to support named destinations Modified: xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fo p.fo.ElementMapping Modified: xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fo p.fo.ElementMapping URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/ME TA-INF/services/org.apache.fop.fo.ElementMapping?view=diffrev =524608r1=524607r2=524608 == --- xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fo p.fo.ElementMapping (original) +++ xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fop.fo.E +++ lementMapping Sun Apr 1 07:51:19 2007 @@ -7,4 +7,5 @@ org.apache.fop.fo.extensions.xmp.RDFElementMapping org.apache.fop.render.ps.extensions.PSExtensionElementMapping org.apache.fop.render.afp.extensions.AFPElementMapping -org.apache.fop.render.pcl.extensions.PCLElementMapping \ No newline at end of file +org.apache.fop.render.pcl.extensions.PCLElementMapping +org.apache.fop.fo.extensions.destination.DestinationElementMapping \ No newline at end of file build.log Description: build.log
RE: svn commit: r524608 - /xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fop.fo.ElementMapping
Hi Pascal, I get 11 errors and cannot build this rev. Latest working rev was 524578 (for me). It's because DestinationData.java is missing. Regz, Paul Vinkenoog
startPageSequence() in Renderer interface
Hi, I am working on the postscript renderer and have a query about org.apache.fop.render.Renderer#void startPageSequence(LineArea title). Its seems a bit wrong to me that this method is invoked with just the title of the PageSequence being passed to it, surely it would be better to pass the PageSequence itself (which contains the title). I would think that the PageSequence object itself would be much more useful to the renderer. Am I missing something? Is there a good reason which I have missed as to why it is implemented in this way? Adrian Cumiskey.
DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution
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=41831.
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=41831
--- Additional Comments From [EMAIL PROTECTED] 2007-04-02 02:40 ---
Hi Keith,
Many thanks for trying out the patch and taking the time to provide me with
feedback. My comments are below.
(In reply to comment #17)
I tried out this patch on Ubuntu Linux and found that I needed a few changes
to
get it to work properly. Since this hasn't been checked in, I'm not sure what
to
send a patch against, so I'll just describe them for now.
org.apache.fop.fonts.autodetect.UnixFontDirFinder
It is probably worth adding the .fonts directory in a user's home directory:
e.g.
UNIX_FONT_PATHS = {
System.getProperty(user.home) + /.fonts,
Ok this is a nice easy addition. Andreas, if you are reading this
I believe you have made some small changes. Before I make any of the changes
that Keith suggests, it might be a good idea for you to attach an additional
patch file with your changes.
org.apache.fop.fonts.autodetect.FontFileFinder.find should have the recursive
argument set to true when called from
org.apache.fop.fonts.autodetect.NativeFontFileFinder.find, because the fonts
are
found several layers deep under /usr/share/fonts.
I am thinking that I may make the NativeFontFileFinder class a little more
flexible so that implementing classes are able to specify whether each
individual search file path should be searched recursively or not.
org.apache.fop.fonts.autodetect.FontInfoFinder
If you use
embedUrl = fontFile.toURI().toURL().toExternalForm();
then it seems to do escaping of spaces, otherwise font filenames containing
spaces cause problems.
This is also a quick easy change.
It is probably worth handling UnsupportedOperationException within the
org.apache.fop.fonts.autodetect.FontInfoFinder.find() method to prevent one
bad
font breaking everything. I find OpenType fonts with CFF data are not
supported, yet errors thrown by org.apache.fop.fonts.truetype.TTFFontLoader
break the caching otherwise.
Yes this is a case I did not cater for. I will change this.
I'm not convinced that the cache is working properly for failed fonts,
because I
always seem to get log messages about them, not just on the first run.
However,
I haven't had time to investigate that properly.
I believe this to be working fine. Bad/failed fonts are also recorded in the
cache. The error is still printed to remind the user of the problem but the
font is not parsed again unless the file has been changed.
Thanks again Keith for taking time to try out the patch and provide feedback
:-).
Cheers,
Adrian Cumiskey.
--
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.
DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution
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=41831. 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=41831 --- Additional Comments From [EMAIL PROTECTED] 2007-04-02 06:37 --- Created an attachment (id=19890) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19890action=view) updated files from org.apache.fop.fonts.autodetect package Following feedback from Andreas and Keith I have updated the autodetect package. I hope this does not cause you too many merge problems Andreas. -- 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.
DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution
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=41831. 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=41831 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #19890|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2007-04-02 06:55 --- Created an attachment (id=19891) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19891action=view) updated files from org.apache.fop.fonts.autodetect package Whoops.. This is what I should have submitted. Please ignore the last attached archive file. Andreas, this patch is getting a little out of date with the trunk now - if you need me to create a fresh patch from the latest trunk code let me know. -- 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.
[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 38 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only package [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xmlgraphics-commons/build/xmlgraphics-commons-02042007.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-02042007.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-02042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-02042007.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-02042007.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [javac] import org.apache.fop.area.DestinationData; [javac]^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/apps/FopFactory.java:209: warning: [deprecation] Fop(java.lang.String,org.apache.fop.apps.FOUserAgent) in org.apache.fop.apps.Fop has been deprecated [javac] return new Fop(outputFormat, newFOUserAgent()); [javac]^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/apps/FopFactory.java:229: warning: [deprecation] Fop(java.lang.String,org.apache.fop.apps.FOUserAgent) in org.apache.fop.apps.Fop has been deprecated
[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 38 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only package [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xmlgraphics-commons/build/xmlgraphics-commons-02042007.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-02042007/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-02042007.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-02042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-02042007.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-02042007.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [javac] import org.apache.fop.area.DestinationData; [javac]^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/apps/FopFactory.java:209: warning: [deprecation] Fop(java.lang.String,org.apache.fop.apps.FOUserAgent) in org.apache.fop.apps.Fop has been deprecated [javac] return new Fop(outputFormat, newFOUserAgent()); [javac]^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/apps/FopFactory.java:229: warning: [deprecation] Fop(java.lang.String,org.apache.fop.apps.FOUserAgent) in org.apache.fop.apps.Fop has been deprecated
DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution
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=41831. 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=41831 --- Additional Comments From [EMAIL PROTECTED] 2007-04-02 10:22 --- Hi Adrian, Thanks for making those changes, they seem to work for me. (In reply to comment #18) I believe this to be working fine. Bad/failed fonts are also recorded in the cache. The error is still printed to remind the user of the problem but the font is not parsed again unless the file has been changed. Sorry, yes, the failed fonts are recorded fine. However, I wonder whether it is worth changing this log from info to debug after the first run (FontInfoFinder line 151). If you have a lot of fonts, it can produce several pages of messages (mainly from /usr/share/fonts/type1/gsfonts on my system). thanks for a very useful patch. Keith Stribley -- 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.
DO NOT REPLY [Bug 42024] New: - ClassCastException: InlineLayoutManager cannot be cast to BlockLevelLayoutManager
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=42024. 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=42024 Summary: ClassCastException: InlineLayoutManager cannot be cast to BlockLevelLayoutManager Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Converting the attached FO file to PDF raises the following exception. Caused by: java.lang.ClassCastException: org.apache.fop.layoutmgr.inline.InlineLayoutManager cannot be cast to org.apache.fop.layoutmgr.BlockLevelLayoutManager at org.apache.fop.layoutmgr.BlockContainerLayoutManager.mustKeepTogether(BlockContainerLayoutManager.java:990) at org.apache.fop.layoutmgr.BlockLayoutManager.mustKeepTogether(BlockLayoutManager.java:213) at org.apache.fop.layoutmgr.inline.LineLayoutManager.postProcessLineBreaks(LineLayoutManager.java:1093) at org.apache.fop.layoutmgr.inline.LineLayoutManager.createLineBreaks(LineLayoutManager.java:927) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:606) -- 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.
DO NOT REPLY [Bug 42024] - ClassCastException: InlineLayoutManager cannot be cast to BlockLevelLayoutManager
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=42024. 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=42024 --- Additional Comments From [EMAIL PROTECTED] 2007-04-02 16:07 --- Created an attachment (id=19893) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19893action=view) class-cast-exception.fo -- 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.
DO NOT REPLY [Bug 42028] New: - Incorrect rendering of GIF images
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=42028. 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=42028 Summary: Incorrect rendering of GIF images Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Attached zip file contains an example with a single GIF, which exhibits two problems: 1. the GIF is scaled in a strange fashion, and 2. the black lines are lost. -- 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.
DO NOT REPLY [Bug 42028] - Incorrect rendering of GIF images
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=42028. 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=42028 --- Additional Comments From [EMAIL PROTECTED] 2007-04-02 22:22 --- Created an attachment (id=19896) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19896action=view) gif-scaling-bug.zip -- 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.
DO NOT REPLY [Bug 42028] - Incorrect rendering of GIF images
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=42028. 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=42028 --- Additional Comments From [EMAIL PROTECTED] 2007-04-02 22:23 --- I may have a fix for #1 -- ImageIOImage was using the image data array to determine the image size, which isn't necessarily the case for GIF. -- 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.
DO NOT REPLY [Bug 42028] - Incorrect rendering of GIF images
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=42028. 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=42028 --- Additional Comments From [EMAIL PROTECTED] 2007-04-02 22:39 --- Created an attachment (id=19897) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19897action=view) Proposed patch Attached patch uses the ImageIO metadata DOM to obtain the width and height, as well as the horizontal and vertical pixel offset. When building the bitmap array, offsets the stored image pixels. I'm not sure how to solve problem #2 though. -- 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.
