DO NOT REPLY [Bug 52477] FOP always uses the same prefix for embeded font
https://issues.apache.org/bugzilla/show_bug.cgi?id=52477 --- Comment #4 from quamis quamis+...@gmail.com 2012-01-18 08:16:33 UTC --- (In reply to comment #3) 2) We use the deterministic trait of the prefixes in our testing framework. The value of having a comprehensive test suite is far greater than making the code change for this scenario. That why i was saying that a command-line switch to disable the randomized behavior should exist. The change seemed trivial enough. I understand that none of the above particularly helps you, but we can't very well go changing FOP to accommodate nuanced bugs in ghostscript. Mehdi I understand that, but generating the same sequence over and over just seems to be a compromise for easier automated testing, not for an actual workingtested product. For now we'll go on by using pdftk, which seems to handle multiple fonts-same-name case correctly, but its too bad one would have to use 3 different applications all with their own quirks and bugs and usage patterns simply because the standard isn't very clear for a specific issue, and that issue could easily be fixed by any of the 2 applications involved in this chain... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52477] FOP always uses the same prefix for embeded font
https://issues.apache.org/bugzilla/show_bug.cgi?id=52477 --- Comment #6 from Mehdi Houshmand med1...@gmail.com 2012-01-18 10:51:13 UTC --- (In reply to comment #5) /snip An alternative approach that will also make it easier for applications to extract or de-duplicate font resources when merging multiple PDFs is to allow FOP to fully embed the font resources in the PDF, rather than creating a subset. I believe this is possible today for a limited use-case, by specifying encoding-mode=single-byte on the font element within the fop.xconf file. I say limited because that only works if no characters outside the ASCII range are required. That wouldn't necessarily fix the issue here. Fully embedding a font means that the pseudo-unique prefix isn't used, however this isn't necessarily a good thing. A parser like ghostscript, could and apparently does assume that if 2 fonts have the same name (prefix or not) that they are the same font. This is an assumption that I've made previously and has proved manifestly naive. Also, any implementation CANNOT clash within the same document. Using a glyph subset idea, there could be a scenario in which the 2 fonts with the same glyph subsets produce the same prefix. We have to be careful what we're supporting here. There is no standardised method to identify a font, since anyone can call any font by any name. I don't agree that making the prefix more unique (not sure there is a scale by which something can be measured unique, it's binary, it is or it isn't), would help here, because given time, inevitably you'll get a clash. Then what? The prefixes are 6 chars long, the guys at Adobe made no indication that they wanted it to be unique in a global sense, only within a document. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52477] FOP always uses the same prefix for embeded font
https://issues.apache.org/bugzilla/show_bug.cgi?id=52477 --- Comment #7 from quamis quamis+...@gmail.com 2012-01-18 11:27:19 UTC --- (In reply to comment #6) That wouldn't necessarily fix the issue here. Fully embedding a font means that the pseudo-unique prefix isn't used, however this isn't necessarily a good thing. A parser like ghostscript, could and apparently does assume that if 2 fonts have the same name (prefix or not) that they are the same font. This is an assumption that I've made previously and has proved manifestly naive. Also, any implementation CANNOT clash within the same document. Using a glyph subset idea, there could be a scenario in which the 2 fonts with the same glyph subsets produce the same prefix. But if 2 fonts have the same glyph subsets used within a document, then it wouldn't be necessary to include them twice, so no clashing would occur. I think that glyph subsets are a good idea, but i do realize that it would be more complex to implement. We have to be careful what we're supporting here. There is no standardised method to identify a font, since anyone can call any font by any name. I don't agree that making the prefix more unique (not sure there is a scale by which something can be measured unique, it's binary, it is or it isn't), would help here, because given time, inevitably you'll get a clash. Then what? Because the prefix is 6 chars long, its inevitably that one would eventually get a clash, if he uses enough millions of different fonts within the same file. But this is an acceptable limitation. The prefixes are 6 chars long, the guys at Adobe made no indication that they wanted it to be unique in a global sense, only within a document. Yes, the Adobe guys probably meant that the prefix should be unique within the same file and it would be the pdf reader/writer's job to handle duplicate fonts coming from different fonts. It makes sense. This is why i think both fop and gs handle this particular case wrong, as they both assumed things about that prefix, and it seems that this assumptions are now proven wrong. gs in particular should warn about merging files with embedded fonts, either when merging, or at least in the manual, or a known-issues page. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51209] [PATCH] SVG text in AFP creates miscoded GOCA text
https://issues.apache.org/bugzilla/show_bug.cgi?id=51209 --- Comment #4 from Chris Bowditch bowditch_ch...@hotmail.com 2012-01-18 11:54:59 UTC --- Hi Luis, Thanks for the patch. This has been committed in revision 1232845. Thanks, Chris -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52477] FOP always uses the same prefix for embeded font
https://issues.apache.org/bugzilla/show_bug.cgi?id=52477 --- Comment #8 from Pascal Sancho pascal.san...@takoma.fr 2012-01-18 12:11:52 UTC --- Since font files are versionned, how this will be handled when 2 subsets use the same glyphes of the same font, but in different version? subset reduction should take care of that. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Findbug exclusions
Hi Fellow Committers, I was reviewing the current set of warnings generated by FindBugs and found myself needing to add an extra exclusion. I noticed that the exclusions file contains a lot of duplicates, e.g. Match Class name=org.apache.fop.render.afp.AFPImageHandlerRawCCITTFax/ Method name=setAdditionalParameters/ Bug pattern=BC_UNCONFIRMED_CAST/ /Match Match Class name=org.apache.fop.render.afp.AFPImageHandlerRawCCITTFax/ Method name=setAdditionalParameters/ Bug pattern=BC_UNCONFIRMED_CAST/ /Match Does anyone know why the duplicates exist? I confirmed that removing the duplicates does not re-introduce any warnings with FindBugs 1.3.9. Thanks, Chris
[no subject]
Hi Team I am stuck with a peculiar problem. My client uses FOP v 0.20.5 and I ran thru the entire website but could not find certain feature matrix which can tell me whether Image-As-Hyperlink or Text-As-Hyperlink will work or not. We tried to make such hyperlinks in v0.95, and everything worked, but since client has older version we are not sure if it works or not. Can you guys please send us some details using which we can decide whether this functionality will work in older version or not. Hope this does not cause much trouble. :) Thanks Regards Ankit Saxena Extension No: 364 Nihilent Technologies Pvt. Ltd. 4th Floor, Weikfield IT City Info Park, Nagar Road, Pune 411014. Tel.: + 91 (20) 3984 6100 (Ext-364)| Fax: + 91 (20) 3984 6498 ankit.sax...@nihilent.com mailto:rahul.in...@nihilent.com | www.nihilent.com http://www.nihilent.com/ http://www.nihilent.com/ | Pune | Mumbai | Johannesburg | London | New Jersey
Re: Hyperlinks in 0.20.5
On 18/01/2012 13:49, Ankit Saxena wrote: Hi Team Hi Ankit, Please post questions about using FOP to fop-user mailing list. The developers are subscribed there too. I am stuck with a peculiar problem. My client uses FOP v 0.20.5 and I ran thru the entire website but could not find certain feature matrix which can tell me whether */Image-As-Hyperlink/* or */Text-As-Hyperlink/* will work or not. We tried to make such hyperlinks in v0.95, and everything worked, but since client has older version we are not sure if it works or not. FOP v0.20.5 was released 9 years ago, so its no longer supported. It's so old no one can remember it. Can't you just take your test XSL-FO and run it in client's environment to see whether it works or not. Please encourage your client to upgrade to FOP v1.0 to benefit from 7 years of development! Can you guys please send us some details using which we can decide whether this functionality will work in older version or not. Hope this does not cause much trouble. :) Thanks, Chris Thanks Regards Ankit Saxena Extension No: 364 Nihilent Technologies Pvt. Ltd. 4^th Floor, Weikfield IT City Info Park, Nagar Road, Pune 411014. *Tel.:* + 91 (20) 3984 6100 (Ext-364)| *Fa**x:* + 91 (20) 3984 6498 ankit.sax...@nihilent.commailto:rahul.in...@nihilent.com**| **www.nihilent.com http://www.nihilent.com/*http://www.nihilent.com/***| *** ***Pune | Mumbai | Johannesburg | London | New Jersey**
DO NOT REPLY [Bug 52416] [PATCH] Suppress unnecessary font not found warnings when generating AFP with raster fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=52416 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Chris Bowditch bowditch_ch...@hotmail.com 2012-01-18 14:27:47 UTC --- Hi Luis, Thanks for submitting the patch. Can you attach a test FO to demo the issue? Thanks, Chris -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52287] [PATCH] fox:orphan/overwrite-content-limit ignore forced breaks
https://issues.apache.org/bugzilla/show_bug.cgi?id=52287 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added OS/Version||All --- Comment #2 from Chris Bowditch bowditch_ch...@hotmail.com 2012-01-18 15:23:44 UTC --- Hi Matthias, I've taken a look at your test case and I don't think it is a good test case for fox:widow-content-limit and fox:orphan-content-limit. That's because there's only 2 list items. To honour the 2em limits both items must be kept together. If I alter the test case so that there are several items in column 1 that naturally flows 1 item onto column 2 then the fox:widow-content-limit extension is demo'd more readily. The last item from column 1 is then moved to column 2 to honour the widow limit. If I then add the forced break back to the last item then the last item on column 1 goes back to column 1. This shows that the forced break does work in some scenarios at least. I have uploaded 2 further test cases; 1 with the forced break and 1 without. In conclusion it seems there is a bug with forced breaks not being honoured in all circumstances and your patch seems to fix it, but I'm not 100% certain if that's the correct solution. It probably needs to be reviewed by one of the layout gurus. Thanks, Chris -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52287] [PATCH] fox:orphan/overwrite-content-limit ignore forced breaks
https://issues.apache.org/bugzilla/show_bug.cgi?id=52287 --- Comment #3 from Chris Bowditch bowditch_ch...@hotmail.com 2012-01-18 15:24:22 UTC --- Created attachment 28167 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28167 Improved Test Case with no break -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52287] [PATCH] fox:orphan/overwrite-content-limit ignore forced breaks
https://issues.apache.org/bugzilla/show_bug.cgi?id=52287 --- Comment #4 from Chris Bowditch bowditch_ch...@hotmail.com 2012-01-18 15:24:48 UTC --- Created attachment 28168 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28168 Improved test Case with forced break -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52416] [PATCH] Suppress unnecessary font not found warnings when generating AFP with raster fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=52416 --- Comment #2 from Luis Bernardo lmpmberna...@gmail.com 2012-01-18 15:51:53 UTC --- Created attachment 28169 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28169 example fo file that shows the issue This is the warning that is suppressed by the patch: 18-Jan-2012 15:47:00 org.apache.fop.afp.fonts.RasterFont getCharacterSet WARNING: No 10.001pt font Helvetica found, substituted with 10.0pt font -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Findbug exclusions
I recall that someone (Jeremias or Simon?) had mechanically generated some exclusions to add to this file. It is possible that duplicates got inserted in that process. I know of no reason to retain duplicates. On Wed, Jan 18, 2012 at 6:39 AM, Chris Bowditch bowditch_ch...@hotmail.comwrote: Hi Fellow Committers, I was reviewing the current set of warnings generated by FindBugs and found myself needing to add an extra exclusion. I noticed that the exclusions file contains a lot of duplicates, e.g. Match Class name=org.apache.fop.render.**afp.**AFPImageHandlerRawCCITTFax/ Method name=setAdditionalParameters**/ Bug pattern=BC_UNCONFIRMED_CAST/** /Match Match Class name=org.apache.fop.render.**afp.**AFPImageHandlerRawCCITTFax/ Method name=setAdditionalParameters**/ Bug pattern=BC_UNCONFIRMED_CAST/** /Match Does anyone know why the duplicates exist? I confirmed that removing the duplicates does not re-introduce any warnings with FindBugs 1.3.9. Thanks, Chris
Re: Findbug exclusions
On 18/01/2012 15:51, Glenn Adams wrote: I recall that someone (Jeremias or Simon?) had mechanically generated some exclusions to add to this file. It is possible that duplicates got inserted in that process. I know of no reason to retain duplicates. Thanks Glenn. I've removed the duplicates that I noticed initially, but I can see there are some more. Due to the size of the file, it will probably require some automated process to remove all the duplicates. Thanks, Chris On Wed, Jan 18, 2012 at 6:39 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Fellow Committers, I was reviewing the current set of warnings generated by FindBugs and found myself needing to add an extra exclusion. I noticed that the exclusions file contains a lot of duplicates, e.g. Match Class name=org.apache.fop.render.afp.AFPImageHandlerRawCCITTFax/ Method name=setAdditionalParameters/ Bug pattern=BC_UNCONFIRMED_CAST/ /Match Match Class name=org.apache.fop.render.afp.AFPImageHandlerRawCCITTFax/ Method name=setAdditionalParameters/ Bug pattern=BC_UNCONFIRMED_CAST/ /Match Does anyone know why the duplicates exist? I confirmed that removing the duplicates does not re-introduce any warnings with FindBugs 1.3.9. Thanks, Chris
[GUMP@vmgump]: Project xml-fop-test (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 gene...@gump.apache.org. Project xml-fop-test 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-test : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/xml-fop/build/test-reports The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/gump_work/build_xml-fop_xml-fop-test.html Work Name: build_xml-fop_xml-fop-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 49 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Dant.build.clonevm=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml gump-test [Working Directory: /srv/gump/public/workspace/xml-fop] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-fop/build/codegen-classes:/srv/gump/public/workspace/xml-fop/build/test-classes:/srv/gump/public/workspace/xml-fop/lib/build/asm-3.1.jar:/srv/gump/public/workspace/xml-fop/lib/build/qdox-1.12.jar:/srv/gump/public/workspace/xml-fop/build/fop.jar:/srv/gump/public/workspace/xml-fop/build/fop-sandbox.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspac e/xmlgraphics-commons/build/xmlgraphics-commons-19012012.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-gvt.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-pars er.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-script.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-19012012/lib/batik-xml.jar:/srv/gump/packages/apache-attic/avalon-framework-api-4.3.jar:/srv/gump/packages/apache-attic/avalon-framework-impl-4.3.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-19012012.jar:/srv/gump/public/workspace/apache-commons/io/target/commons-io-2.2-SNAPSHOT.jar:/srv/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/srv/gump/packages/fop-hyph/fop-hyph.jar:/srv/gump/public/workspace/junit/dist/junit-19012012.jar:/srv/gump/public/w orkspace/junit/dist/junit-dep-19012012.jar:/srv/gump/public/workspace/mockito/target/mockito-all-19012012.jar:/srv/gump/public/workspace/mockito/target/mockito-core-19012012.jar:/srv/gump/public/workspace/xmlunit/build/java/lib/xmlunit-sumo-19012012.jar - [eventResourceGenerator] Event model
