[Bug 40676] [PATCH] png graphics are expanded/uncompressed in pdf causing massive file size increase
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676 --- Comment #15 from Glenn Adams --- (In reply to comment #13) > Wiki updated: http://wiki.apache.org/xmlgraphics-fop/HowTo/ImageLoaderRawPNG you may also want to update [1] and [2] [1] http://xmlgraphics.apache.org/fop/trunk/graphics.html#png [2] http://xmlgraphics.apache.org/fop/trunk/configuration.html#image-loading for example, adding info to [1] about the new codecs, and adding info to [2] about negative penalties -- You are receiving this mail because: You are the assignee for the bug.
[Bug 40676] [PATCH] png graphics are expanded/uncompressed in pdf causing massive file size increase
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676 Glenn Adams changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #14 from Glenn Adams --- findbugs fix patch applied at http://svn.apache.org/viewvc?rev=1350790&view=rev thanks luis! please review and close if satisfied -- You are receiving this mail because: You are the assignee for the bug.
Re: [VOTE] Merge Temp_TrueTypeInPostScript branch into trunk
I was going to say that Pascal had a good point, and that it was really up to Glenn. +1 from me "My religion is simple. My religion is kindness." - HH The Dalai Lama of Tibet On Jun 15, 2012, at 6:00 AM, Pascal Sancho wrote: > Ok, > then... > +1 for me > > 2012/6/15 Glenn Adams : >> If Vincent would like this in the 1.1 release, then I'm in favor of a merge >> to trunk. So I'd say +1. >> >> >> On Fri, Jun 15, 2012 at 5:29 AM, Pascal Sancho >> wrote: >>> >>> Hi, >>> >>> Since Glenn is in the process to release the FOP v1.1, I'm not sure >>> it's time to merge such branch to trunk. >>> I guess this new feature will not be part of the 1.1 release. >>> >>> If merging have to be done quickly, then we should create a 1.1 >>> maintenance branch to ensure that merging will not affect the >>> releasing process. >>> >>> Or if this new feature have to be part of the 1.1 release, then >>> perhaps we have to delay the release process *after* this merge. >>> >>> any thought? >>> >>> 2012/6/15 Vincent Hennebert : As you may have noticed, I’ve recently spent some time updating the Temp_TrueTypeInPostScript branch to the latest trunk and doing some clean-up (thanks to Robert for updating the testcases to JUnit 4). We have been using the code from this branch for quite a while now and it has proven to work reasonably well. I won’t hide the fact that some parts of the code are truly ugly (in PSFontUtils mainly), but it’s not possible to clean that up without heavily refactoring the font sub-system, which I unfortunately can’t spend time on right now. At least the ugliness is fairly self-contained. Meanwhile some users may find the additional functionality useful. So I’d like to propose a vote for merging that branch back to Trunk. The vote will run until Thursday 21st, 8:00GMT. Here’s my +1. Thanks, Vincent > > -- > pascal
[Bug 40676] [PATCH] png graphics are expanded/uncompressed in pdf causing massive file size increase
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676 --- Comment #13 from Luis Bernardo --- Wiki updated: http://wiki.apache.org/xmlgraphics-fop/HowTo/ImageLoaderRawPNG -- You are receiving this mail because: You are the assignee for the bug.
Re: [VOTE] Merge Temp_TrueTypeInPostScript branch into trunk
Ok, then... +1 for me 2012/6/15 Glenn Adams : > If Vincent would like this in the 1.1 release, then I'm in favor of a merge > to trunk. So I'd say +1. > > > On Fri, Jun 15, 2012 at 5:29 AM, Pascal Sancho > wrote: >> >> Hi, >> >> Since Glenn is in the process to release the FOP v1.1, I'm not sure >> it's time to merge such branch to trunk. >> I guess this new feature will not be part of the 1.1 release. >> >> If merging have to be done quickly, then we should create a 1.1 >> maintenance branch to ensure that merging will not affect the >> releasing process. >> >> Or if this new feature have to be part of the 1.1 release, then >> perhaps we have to delay the release process *after* this merge. >> >> any thought? >> >> 2012/6/15 Vincent Hennebert : >> > As you may have noticed, I’ve recently spent some time updating the >> > Temp_TrueTypeInPostScript branch to the latest trunk and doing some >> > clean-up (thanks to Robert for updating the testcases to JUnit 4). >> > >> > We have been using the code from this branch for quite a while now and >> > it has proven to work reasonably well. I won’t hide the fact that some >> > parts of the code are truly ugly (in PSFontUtils mainly), but it’s not >> > possible to clean that up without heavily refactoring the font >> > sub-system, which I unfortunately can’t spend time on right now. At >> > least the ugliness is fairly self-contained. Meanwhile some users may >> > find the additional functionality useful. >> > >> > So I’d like to propose a vote for merging that branch back to Trunk. The >> > vote will run until Thursday 21st, 8:00GMT. >> > >> > Here’s my +1. >> > >> > Thanks, >> > Vincent -- pascal
Re: [VOTE] Merge Temp_TrueTypeInPostScript branch into trunk
If Vincent would like this in the 1.1 release, then I'm in favor of a merge to trunk. So I'd say +1. On Fri, Jun 15, 2012 at 5:29 AM, Pascal Sancho wrote: > Hi, > > Since Glenn is in the process to release the FOP v1.1, I'm not sure > it's time to merge such branch to trunk. > I guess this new feature will not be part of the 1.1 release. > > If merging have to be done quickly, then we should create a 1.1 > maintenance branch to ensure that merging will not affect the > releasing process. > > Or if this new feature have to be part of the 1.1 release, then > perhaps we have to delay the release process *after* this merge. > > any thought? > > 2012/6/15 Vincent Hennebert : > > As you may have noticed, I’ve recently spent some time updating the > > Temp_TrueTypeInPostScript branch to the latest trunk and doing some > > clean-up (thanks to Robert for updating the testcases to JUnit 4). > > > > We have been using the code from this branch for quite a while now and > > it has proven to work reasonably well. I won’t hide the fact that some > > parts of the code are truly ugly (in PSFontUtils mainly), but it’s not > > possible to clean that up without heavily refactoring the font > > sub-system, which I unfortunately can’t spend time on right now. At > > least the ugliness is fairly self-contained. Meanwhile some users may > > find the additional functionality useful. > > > > So I’d like to propose a vote for merging that branch back to Trunk. The > > vote will run until Thursday 21st, 8:00GMT. > > > > Here’s my +1. > > > > Thanks, > > Vincent > > > > -- > pascal >
Re: [GUMP@vmgump]: Project xml-fop (in module xml-fop) failed
It looks like my update to XGC didn't get completely propagated. I'm heading to airport now, so won't be able to look at this until later today. FWIW, my local build is working, so I've got to look deeper. On Fri, Jun 15, 2012 at 2:45 AM, Jeremias Maerki wrote: > 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 has an issue affecting its community integration. > This issue affects 3 projects, > and has been outstanding for 20 runs. > The current state of this project is 'Failed', with reason 'Build Failed'. > For reference only, the following projects are affected by this: >- org.apache.xmlgraphics.fop : XSL-FO (Formatting Objects) processor >- xml-fop : XSL-FO (Formatting Objects) processor >- xml-fop-test : 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: > -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/classes] > -INFO- Made directory > [/srv/gump/public/workspace/xml-fop/build/codegen-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: 35 secs > Command Line: /usr/lib/jvm/java-6-openjdk/bin/java > -Djava.awt.headless=true -Dbuild.sysclasspath=only > -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 > [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/sandbox-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-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/workspace/xmlgraphics-commons/build/xmlgraphics-commons-15062012.jar:/srv/gump/public/workspace/xml-batik/batik > > > -15062012/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-gvt.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-parser.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-script.jar:/srv/gump/public/worksp > > > ace/xml-batik/batik-15062012/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/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-15062012.jar:/srv/gump/public/workspace/apache-commons/io/target/commons-io-2.4-SNAPSHOT.jar:/srv/gump/public/workspace/jakarta-servletapi/dist/
[Bug 40676] [PATCH] png graphics are expanded/uncompressed in pdf causing massive file size increase
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676 --- Comment #12 from Luis Bernardo --- Created attachment 28944 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28944&action=edit patch for findbugs fixes/ignores findbugs -- You are receiving this mail because: You are the assignee for the bug.
Re: [VOTE] Merge Temp_TrueTypeInPostScript branch into trunk
Hi, Since Glenn is in the process to release the FOP v1.1, I'm not sure it's time to merge such branch to trunk. I guess this new feature will not be part of the 1.1 release. If merging have to be done quickly, then we should create a 1.1 maintenance branch to ensure that merging will not affect the releasing process. Or if this new feature have to be part of the 1.1 release, then perhaps we have to delay the release process *after* this merge. any thought? 2012/6/15 Vincent Hennebert : > As you may have noticed, I’ve recently spent some time updating the > Temp_TrueTypeInPostScript branch to the latest trunk and doing some > clean-up (thanks to Robert for updating the testcases to JUnit 4). > > We have been using the code from this branch for quite a while now and > it has proven to work reasonably well. I won’t hide the fact that some > parts of the code are truly ugly (in PSFontUtils mainly), but it’s not > possible to clean that up without heavily refactoring the font > sub-system, which I unfortunately can’t spend time on right now. At > least the ugliness is fairly self-contained. Meanwhile some users may > find the additional functionality useful. > > So I’d like to propose a vote for merging that branch back to Trunk. The > vote will run until Thursday 21st, 8:00GMT. > > Here’s my +1. > > Thanks, > Vincent -- pascal
[VOTE] Merge Temp_TrueTypeInPostScript branch into trunk
As you may have noticed, I’ve recently spent some time updating the Temp_TrueTypeInPostScript branch to the latest trunk and doing some clean-up (thanks to Robert for updating the testcases to JUnit 4). We have been using the code from this branch for quite a while now and it has proven to work reasonably well. I won’t hide the fact that some parts of the code are truly ugly (in PSFontUtils mainly), but it’s not possible to clean that up without heavily refactoring the font sub-system, which I unfortunately can’t spend time on right now. At least the ugliness is fairly self-contained. Meanwhile some users may find the additional functionality useful. So I’d like to propose a vote for merging that branch back to Trunk. The vote will run until Thursday 21st, 8:00GMT. Here’s my +1. Thanks, Vincent
[GUMP@vmgump]: 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 gene...@gump.apache.org. Project xml-fop has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 20 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - org.apache.xmlgraphics.fop : XSL-FO (Formatting Objects) processor - xml-fop : XSL-FO (Formatting Objects) processor - xml-fop-test : 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: -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/classes] -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/codegen-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: 35 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -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 [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/sandbox-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-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/workspace/xmlgraphics-commons/build/xmlgraphics-commons-15062012.jar:/srv/gump/public/workspace/xml-batik/batik -15062012/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-gvt.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-parser.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-script.jar:/srv/gump/public/worksp ace/xml-batik/batik-15062012/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-15062012/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-15062012.jar:/srv/gump/public/workspace/apache-commons/io/target/commons-io-2.4-SNAPSHOT.jar:/srv/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [javac] ^ [javac] /srv/gump/public/workspace/xml-fop/src/java/org/apache/fop/render/ps/PSImageHandlerRawPNG.java:51: cannot find symbol [javac] symbol : class ImageRawPNG [javac] location: class org.apache.fop.render.ps.PSImageH
[Bug 53412] [PATCH] o.a.f.fo.properties.CondLengthProperty.equals() uses object identity
https://issues.apache.org/bugzilla/show_bug.cgi?id=53412 Alex Giotis changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 51843] Surrogate pairs not treated as single unicode codepoint for display purposes
https://issues.apache.org/bugzilla/show_bug.cgi?id=51843 --- Comment #27 from C.C --- Same problem here! Do you guys can provide me any work around before the bug is fixed? you know, it takes time to seek a suitable fonts to fit. Anyway, will keep an eye on the thread. Cusson -- You are receiving this mail because: You are the assignee for the bug.
