Re: PNG transparency renders as black - urgent
I would like to know what to do for the release: 1. Leave as is, a known problem. 2. Do the quick fix as jeremias suggests: putting the Commons codec before the ImageIO variant in ImageFactory. 3. Test Jeremias' patch and apply it. We can do the fix in the release branch (to be created) only, in the interest of an errorless release. Simon On Tue, Dec 19, 2006 at 11:14:13PM +0100, Jeremias Maerki wrote: Actually, this is so simple, I've created a patch. I'm hesitant to apply it without much testing with various PNGs for which I have no time right now. But maybe one of you can take a look. If it's good JAIImage and JimiImage could be similarly patched. On 19.12.2006 23:01:36 Jeremias Maerki wrote: It turns out the following revision is responsible for the regression: http://svn.apache.org/viewvc?rev=424349view=rev Putting the Commons codec before the ImageIO variant in ImageFactory is a quick fix for this. I originally switched because of speed reasons but obviously I didn't test PNGs with alpha channel. The reason why Martin's PNG doesn't work with the ImageIOImage class is the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a BITMASK it would work. The same problem exists for JAIImage and JimiImage, BTW. Again, this is something a complete redesign of the image package would have addressed. It's on my higher priority list but I still haven't got to it, yet. If someone wants to try to implement that little code that is missing as a temporary fix, please do. It shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for hints. -- Simon Pepping home page: http://www.leverkruid.eu
DO NOT REPLY [Bug 41009] - [PATCH] Remove unwanted attributes from TableCell
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=41009. 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=41009 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-12-20 00:47 --- Patch applied. Thanks. -- 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 41044] - [PATCH] FOP memory usage patches.
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=41044. 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=41044 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #19176|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-12-20 00:50 --- (From update of attachment 19176) Also included in the following attachment -- 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 41044] - [PATCH] FOP memory usage patches.
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=41044. 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=41044 --- Additional Comments From [EMAIL PROTECTED] 2006-12-20 00:51 --- Patch 19177 applied. Thanks. -- 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: New FOP release: FOP 0.93
Done, and branch xmlgraphics/fop/branches/fop-0_93 created. On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote: As discussed recently, I will prepare a release of FOP, to be named 0.93. Two issues need to be addressed: 1. I will apply two patches by Richard Wheeldon, to improve memory usage: Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177 en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155. I will have to study the first patch, as I have not looked at it, and the bugzilla page contains nobody's comments. I will only apply the patch if it seems certain that it breaks nothing. I have studied and commented the second patch, as has Andreas, and I believe it can be safely applied before the release. Applying these patches allows us to present a production version whose memory usage has been trimmed somewhat. Applied both. 2. With this release it is possible to use the original font metrics, without generating a special metrics file for FOP. See http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL PROTECTED] There is no entry for this in the changes file, and there is no documentation on the website. It is important enough to clarify with the release. I will try to add some text to the changes file and perhaps something to the documentation. As I am not familiar with this material, if someone else can do a better job, please do. Change was already in the status file (but not on the web site). Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: UAX#14 implementation
On Tuesday 19 December 2006 23:55, Manuel Mall wrote: snip/ Its looking OK so far and most of the layout engine tests pass. Just discovered the first instance of an existing testcase which gives a different result. Under UAX#14 the following text (Note this is plain text not FO markup!): text-align=center .conditionality=retain linefeed-treatment=preserve. which appears in inline_border_padding_conditionality_2.xml has only a single break opportunity which is before the word linefeed-treatment. The space between center and .conditionality is not a break opportunity as it is before a punctuation (Rule LB13). In our existing code this space is a valid break opportunity and under the specific circumstances this gives a different layout result. I don't think this is actually a problem but it is a noticeable difference. It just shows that UAX#14 is designed to break typical written text and not programming language code which this text snippet resembles. snip/ Manuel Manuel
Re: New FOP release: FOP 0.93
I created the documentation for version 0.93 (see src/documentation/content/xdocs/0.93) and edited it for the new release version. Please, check it. Especial attention is needed for the new release notes, src/documentation/content/xdocs/relnotes.xml, most of which still have to be written, the FAQ, src/documentation/content/xdocs/faq.xml, the main page of this release, src/documentation/content/xdocs/0.93/index.xml, and the upgrading page, src/documentation/content/xdocs/0.93/upgrading.xml. On Wed, Dec 20, 2006 at 10:24:25AM +0100, Simon Pepping wrote: Done, and branch xmlgraphics/fop/branches/fop-0_93 created. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: UAX#14 implementation
Manuel Mall wrote: On Tuesday 19 December 2006 23:55, Manuel Mall wrote: snip/ Its looking OK so far and most of the layout engine tests pass. Just discovered the first instance of an existing testcase which gives a different result. Under UAX#14 the following text (Note this is plain text not FO markup!): text-align=center .conditionality=retain linefeed-treatment=preserve. which appears in inline_border_padding_conditionality_2.xml has only a single break opportunity which is before the word linefeed-treatment. The space between center and .conditionality is not a break Interesting. Just to clarify; are you saying that in the previous release 0.92beta the line breaking code identified 2 BP but in 0.93 just the one BP is identifed? snip/ Chris
Re: UAX#14 implementation
On Wednesday 20 December 2006 23:22, Chris Bowditch wrote: Manuel Mall wrote: On Tuesday 19 December 2006 23:55, Manuel Mall wrote: snip/ Its looking OK so far and most of the layout engine tests pass. Just discovered the first instance of an existing testcase which gives a different result. Under UAX#14 the following text (Note this is plain text not FO markup!): text-align=center .conditionality=retain linefeed-treatment=preserve. which appears in inline_border_padding_conditionality_2.xml has only a single break opportunity which is before the word linefeed-treatment. The space between center and .conditionality is not a break Interesting. Just to clarify; are you saying that in the previous release 0.92beta the line breaking code identified 2 BP but in 0.93 just the one BP is identifed? No quite - what I am saying is that in the current fop trunk version 2 break points are identified but in my local UAX#14 version of FOP only one break point is identified. After looking through the UAX#14 specification the behaviour of my implementation appears to be correct. snip/ Chris Manuel
Re: UAX#14 implementation
On Wednesday 20 December 2006 20:43, Manuel Mall wrote: On Tuesday 19 December 2006 23:55, Manuel Mall wrote: snip/ Its looking OK so far and most of the layout engine tests pass. Just discovered the first instance of an existing testcase which gives a different result. Here is another one: The current FOP implementation treats spaces other than NBSP, e.g. U+2009 (Thin Space) and U+200A (Hair Space) as suppressible around line breaks. I believe that is incorrect as the spec explicitly limits whitespace handling to the normal space U+0020. The test case which shows that is block_white-space_4.xml. It tests for specific Knuth element sequences which are now different because these spaces are now treated as not suppressible. After making the appropriate adjustment to the checks in that testcase ALL testcases are now passing! snip/ Manuel
Re: UAX#14 implementation
Manuel Mall wrote: After making the appropriate adjustment to the checks in that testcase ALL testcases are now passing! Wonderful! I'm really looking forward to see this great new feature! Just a couple of doubts concerning the differences with respect to the old implementation (I must confess I read the Unicode Annex quite quickly ...): Just discovered the first instance of an existing testcase which gives a different result. Under UAX#14 the following text (Note this is plain text not FO markup!): text-align=center .conditionality=retain linefeed-treatment=preserve. which appears in inline_border_padding_conditionality_2.xml has only a single break opportunity which is before the word linefeed-treatment. The space between center and .conditionality is not a break Does this happens because that space is just before a .? Another doubt: why aren't the - signs in text-align and linefeed-treatment possible breaks? Regards Luca
A nit: visibility of FObj.bind()?
Hi all, Just bumped into this and started wondering: currently FObj.bind() has public visibility, but it seems that protected would suffice. The method is only accessed by processNode() (which is already a protected method), but since it needs to be overridden by subclasses, it cannot be made private. Simply wondering whether it would not be 'cleaner' to restrict the visibility to protected... unless it is really necessary for some reason to expose it as part of the public API of FObj? Cheers, Andreas
Re: PNG transparency renders as black - urgent
I'd go with option 2 (in the release branch) to get rid of the regression with practically no risk for the release. Performance-wise, nothing is lost compared to 0.92beta. On 20.12.2006 09:08:38 Simon Pepping wrote: I would like to know what to do for the release: 1. Leave as is, a known problem. 2. Do the quick fix as jeremias suggests: putting the Commons codec before the ImageIO variant in ImageFactory. 3. Test Jeremias' patch and apply it. We can do the fix in the release branch (to be created) only, in the interest of an errorless release. Simon On Tue, Dec 19, 2006 at 11:14:13PM +0100, Jeremias Maerki wrote: Actually, this is so simple, I've created a patch. I'm hesitant to apply it without much testing with various PNGs for which I have no time right now. But maybe one of you can take a look. If it's good JAIImage and JimiImage could be similarly patched. On 19.12.2006 23:01:36 Jeremias Maerki wrote: It turns out the following revision is responsible for the regression: http://svn.apache.org/viewvc?rev=424349view=rev Putting the Commons codec before the ImageIO variant in ImageFactory is a quick fix for this. I originally switched because of speed reasons but obviously I didn't test PNGs with alpha channel. The reason why Martin's PNG doesn't work with the ImageIOImage class is the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a BITMASK it would work. The same problem exists for JAIImage and JimiImage, BTW. Again, this is something a complete redesign of the image package would have addressed. It's on my higher priority list but I still haven't got to it, yet. If someone wants to try to implement that little code that is missing as a temporary fix, please do. It shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for hints. -- Simon Pepping home page: http://www.leverkruid.eu Jeremias Maerki
Re: svn commit: r487972 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/Marker.java
On Dec 20, 2006, at 20:45, Jeremias Maerki wrote: I wonder about the effect of that on very long running server applications producing all kinds of different documents. There's no chance for freeing instances here if memory is needed. I assume that in this case the set of instances will still remain relatively small. But still, this is memory that is never freed and some instances may never be reused after a particular rendering run. True indeed. My bad. Richard was a bit smarter, and used a WeakHashMap, so that the instances that are no longer referenced can be released. OTOH, since the access to the propertyCaches is not synchronized in Richard's patch, I'm wondering whether or not the possibility arises that two parallel threads issue a put() on the Map at the same time for an equal instance...? Maybe we're both slightly off... Anyway, I'll see if I can adapt to use WeakHashMap too. Should work. Thanks for the vigilance! Cheers, Andreas
Re: New FOP release: FOP 0.93
On 19.12.2006 21:02:06 Simon Pepping wrote: As discussed recently, I will prepare a release of FOP, to be named 0.93. Two issues need to be addressed: 1. I will apply two patches by Richard Wheeldon, to improve memory usage: Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177 en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155. I will have to study the first patch, as I have not looked at it, and the bugzilla page contains nobody's comments. I will only apply the patch if it seems certain that it breaks nothing. I have studied and commented the second patch, as has Andreas, and I believe it can be safely applied before the release. Applying these patches allows us to present a production version whose memory usage has been trimmed somewhat. Thanks for taking care of this. 2. With this release it is possible to use the original font metrics, without generating a special metrics file for FOP. See http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL PROTECTED] There is no entry for this in the changes file, and there is no documentation on the website. It is important enough to clarify with the release. I will try to add some text to the changes file and perhaps something to the documentation. As I am not familiar with this material, if someone else can do a better job, please do. Well, this is still sort of experimental. The old functionality is unchanged and stable. I'm not so sure about the part without the font metrics. There wasn't much feedback. If this is to be documented, I'd prefer if it is marked as experimental. After these changes I will create a branch. Manuel, can you hold your changes until the branch has been created? Please, let me know if you have different ideas. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu Jeremias Maerki
Re: UAX#14 implementation
Luca Furini wrote: After making the appropriate adjustment to the checks in that testcase ALL testcases are now passing! Wonderful! Me too! text-align=center .conditionality=retain ... Does this happens because that space is just before a .? The dot (FULL STOP) has property IS and prevents break after any character, also even after a space. Interesting, I didn't remember this. Another doubt: why aren't the - signs in text-align and linefeed-treatment possible breaks? They should be, the dash in Unicode 5.0 has the property HY, which allows for a break after. The tables I generated were for 4.1 (or even 4.0) and might have to be updated, I haven't checked. The UAX14 has been updated too, which might have changed the pair table (cahp. 7.3), which is, oddly enough, part of the report instead of a data file. Links: http://www.unicode.org/reports/tr14/ http://www.unicode.org/Public/UNIDATA/LineBreak.txt J.Pietschmann
Re: UAX#14 implementation
On Thursday 21 December 2006 06:08, J.Pietschmann wrote: Luca Furini wrote: snip/ Another doubt: why aren't the - signs in text-align and linefeed-treatment possible breaks? They should be, the dash in Unicode 5.0 has the property HY, which allows for a break after. The tables I generated were for 4.1 (or even 4.0) and might have to be updated, I haven't checked. The UAX14 has been updated too, which might have changed the pair table (cahp. 7.3), which is, oddly enough, part of the report instead of a data file. My mistake, the code correctly generates break opportunities after the HYPHEN-MINUS U+002D. I didn't notice because the breaker didn't choose them, probably because of their higher penalty value. I tested again with words like: Rindfleisch-etikettierungs-überwachungs-aufgaben-übertragungs-gesetz Donau-dampf-schiffahrts-elektrizitaeten-hauptbetriebswerk-bauunterbeamten-gesellschaft and it breaks correctly after the hyphens. J.Pietschmann Manuel
Re: UAX#14 implementation
Here is a sample from the test case I am developing attached. The ..._old.pdf file shows the current fop-trunk behaviour while the ..._new.pdf file shows what happens in the FOP UAX#14 version. There are quite a few subtle differences (mostly for the better I hope). I also attach the test case file (hasn't got checks yet) if someone would like to study the fo or even better would like to add or comment or improve. Manuel block_linebreaking_old.pdf Description: Adobe PDF document ?xml version=1.0 encoding=UTF-8? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- $Id: inline_border_padding_hyphenate_de.xml 426576 2006-07-28 15:44:37Z jeremias $ -- testcase info p This test checks some of the UAX#14 breaking rules. /p /info fo fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=normal page-width=2.5in page-height=10in margin=5pt fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body font-size=10pt fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt BA -- Break Opportunity After (A) /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt VeryLongWordWithAThinSpace#x2009;PutInTheMiddleOfIt /fo:block fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt BB -- Break Opportunity Before (B) /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt VeryLongWordWithAnAcuteAccent#x00B4;PutInTheMiddleOfIt /fo:block fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt B2 -- Break Opportunity Before and After (B/A) /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt #x2014;Very#x2014;Long#x2014;Word#x2014;With#x2014;LotsOf#x2014;Em#x2014;Dashes#x2014;Put#x2014;InBetween#x2014;And#x2014;Around#x2014; /fo:block fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt B2 -- Break Opportunity Before and After (B/A) - as before but don't break between consecutive Em Dashes /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt AVeryLongWordWithSomeDouble#x2014; #x2014;Dashes#x2014; #x2014;Put#x2014; #x2014;In /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt AVeryLongWordWithSomeDouble#x2014;#x2014;Dashes#x2014;#x2014;Put#x2014;#x2014;In /fo:block fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt CL -- Closing Punctuation (XB) /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt Closing )brackets )even )if )preceeded )by )a )space )are )not )a )break )point /fo:block fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt EX -- Exclamation / interrogation (XB) /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt Question ?marks ?and exclamation !marks !even ?if !preceeded ?by !a ?space !are ?not !a ?break !point /fo:block fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt HY -- Hyphen Minus (XA) /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt Very-Long-Word-With-Lots-Of-Hyphens-Put-In-Between /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt Hyphens-in-numbers-do-not-123-567-890-break /fo:block fo:block background-color=silver font-size=8pt margin=3pt 0pt 0pt 0pt ID -- Ideographic (B/A) /fo:block fo:block background-color=yellow margin=0pt 0pt 0pt 0pt Need#x3000;A#x3000;Proper#x3000;Test#x3000;Case#x3000;For#x3000;This#x3000;As#x3000;Here#x3000;Only#x3000;The#x3000;Ideographic#x3000;Space#x3000;Is#x3000;Used /fo:block
