[Bug 51843] Surrogate pairs not treated as single unicode codepoint for display purposes

2012-06-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51843

--- Comment #27 from C.C cuss...@gmail.com ---
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.


[Bug 53412] [PATCH] o.a.f.fo.properties.CondLengthProperty.equals() uses object identity

2012-06-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=53412

Alex Giotis alex.gio...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are the assignee for the bug.


[VOTE] Merge Temp_TrueTypeInPostScript branch into trunk

2012-06-15 Thread 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


Re: [VOTE] Merge Temp_TrueTypeInPostScript branch into trunk

2012-06-15 Thread Pascal Sancho
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 vhenneb...@gmail.com:
 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

2012-06-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676

--- Comment #12 from Luis Bernardo lmpmberna...@gmail.com ---
Created attachment 28944
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=28944action=edit
patch for findbugs

fixes/ignores findbugs

-- 
You are receiving this mail because:
You are the assignee for the bug.


Re: [GUMP@vmgump]: Project xml-fop (in module xml-fop) failed

2012-06-15 Thread Glenn Adams
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 jerem...@apache.orgwrote:

 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
 

Re: [VOTE] Merge Temp_TrueTypeInPostScript branch into trunk

2012-06-15 Thread 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 psancho@gmail.comwrote:

 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 vhenneb...@gmail.com:
  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

2012-06-15 Thread Pascal Sancho
Ok,
then...
+1 for me

2012/6/15 Glenn Adams gl...@skynav.com:
 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 psancho@gmail.com
 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 vhenneb...@gmail.com:
  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

2012-06-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676

--- Comment #13 from Luis Bernardo lmpmberna...@gmail.com ---
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

2012-06-15 Thread Clay Leeds
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 psancho@gmail.com wrote:

 Ok,
 then...
 +1 for me
 
 2012/6/15 Glenn Adams gl...@skynav.com:
 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 psancho@gmail.com
 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 vhenneb...@gmail.com:
 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

2012-06-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676

Glenn Adams gad...@apache.org changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Glenn Adams gad...@apache.org ---
findbugs fix patch applied at http://svn.apache.org/viewvc?rev=1350790view=rev

thanks luis! please review and close if satisfied

-- 
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

2012-06-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676

--- Comment #15 from Glenn Adams gad...@apache.org ---
(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.