DO NOT REPLY [Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #25 from Julien Aymé julien.a...@gmail.com 2012-04-27 10:07:19 UTC --- Hi everyone, sorry for the late response, I was not aware that a ICLA was required for a patch. I will gladly sign it, so how should I do it ? A scan of the signed ICLA attached to this bug will do? Regards, Julien -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #26 from Ognjen Blagojevic ognjen.d.blagoje...@gmail.com 2012-04-27 10:58:04 UTC --- A scan of the signed ICLA attached to this bug will do? No, I think you should send scan to the secret...@apache.org. Plase read: http://www.apache.org/licenses/#clas -Ognjen -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #23 from Ognjen Blagojevic ognjen.d.blagoje...@gmail.com 2012-04-26 17:36:29 UTC --- Created attachment 28686 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28686 Unified patch for PDFColorHandler and IFUtil -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Ognjen Blagojevic ognjen.d.blagoje...@gmail.com changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #24 from Ognjen Blagojevic ognjen.d.blagoje...@gmail.com 2012-04-26 17:38:49 UTC --- (In reply to comment #17) Other than o.a.f.pdf.PDFNumber, I found two more occurrences of DecimalFormatCache: 1. o.a.f.pdf.PDFColorHandler 2. o.a.f.render.intermediate.IFUtil Those need to have DecimalFormatCache appropriately replaced with DecimalFormatUtil, before we can safely remove DecimalFormatCache. I am working on the patches for those two classes. Unified patch is attached. All the patches attached to this issue are functional. After applying all patches to xmlgraphics-commons and fop, one may delete DecimalFormatCache class safely... and solve memory leaks. -Ognjen -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #17 from Ognjen Blagojevic ognjen.d.blagoje...@gmail.com 2012-04-25 16:30:40 UTC --- Other than o.a.f.pdf.PDFNumber, I found two more occurrences of DecimalFormatCache: 1. o.a.f.pdf.PDFColorHandler 2. o.a.f.render.intermediate.IFUtil Those need to have DecimalFormatCache appropriately replaced with DecimalFormatUtil, before we can safely remove DecimalFormatCache. I am working on the patches for those two classes. -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #18 from Glenn Adams gad...@apache.org 2012-04-25 17:05:23 UTC --- (In reply to comment #17) Other than o.a.f.pdf.PDFNumber, I found two more occurrences of DecimalFormatCache: 1. o.a.f.pdf.PDFColorHandler 2. o.a.f.render.intermediate.IFUtil Those need to have DecimalFormatCache appropriately replaced with DecimalFormatUtil, before we can safely remove DecimalFormatCache. I am working on the patches for those two classes. just a reminder, but i will need a ICLA filed by Julien in order to apply his patch; see comment 15 -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #19 from Vincent Hennebert vhenneb...@gmail.com 2012-04-25 17:17:17 UTC --- (In reply to comment #18) (In reply to comment #17) Other than o.a.f.pdf.PDFNumber, I found two more occurrences of DecimalFormatCache: 1. o.a.f.pdf.PDFColorHandler 2. o.a.f.render.intermediate.IFUtil Those need to have DecimalFormatCache appropriately replaced with DecimalFormatUtil, before we can safely remove DecimalFormatCache. I am working on the patches for those two classes. just a reminder, but i will need a ICLA filed by Julien in order to apply his patch; see comment 15 Please also see comment 13. I think some modifications to the patch are necessary. Vincent -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #20 from Ognjen Blagojevic ognjen.d.blagoje...@gmail.com 2012-04-25 22:26:51 UTC --- Vincent, (In reply to comment #19) Please also see comment 13. I think some modifications to the patch are necessary. I don't know why Jeremias asked for two parameters for number of decimal places (one general, and one for [-1,+1] range). Maybe he planned to use this patch also for transformation matrices with values in range [-1,+1], but that's just a guess. Anyway, I believe that we could use this patch without problems since it really does not change current behavior of the trunk. The trunk will always call format method with those two parameters being equal: (3,3), (4,4), (8,8), etc. If you think that there should be change in the way FOP handles doubles, in terms of always using 8 decimal places, is it possible to open separate issue? I would really like to close this one, and potentially solve memory leak problems introduced by ThreadLocal. -Ognjen -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #21 from Ognjen Blagojevic ognjen.d.blagoje...@gmail.com 2012-04-25 22:33:15 UTC --- Glenn, (In reply to comment #18) just a reminder, but i will need a ICLA filed by Julien in order to apply his patch; see comment 15 I understand. Let me test all Julien's patches first, to see if there are still usable. Then we could think about ICLA. -Ognjen -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #22 from Glenn Adams gad...@apache.org 2012-04-25 23:27:38 UTC --- (In reply to comment #20) Vincent, (In reply to comment #19) Please also see comment 13. I think some modifications to the patch are necessary. I don't know why Jeremias asked for two parameters for number of decimal places (one general, and one for [-1,+1] range). Maybe he planned to use this patch also for transformation matrices with values in range [-1,+1], but that's just a guess. Anyway, I believe that we could use this patch without problems since it really does not change current behavior of the trunk. The trunk will always call format method with those two parameters being equal: (3,3), (4,4), (8,8), etc. If you think that there should be change in the way FOP handles doubles, in terms of always using 8 decimal places, is it possible to open separate issue? I would really like to close this one, and potentially solve memory leak problems introduced by ThreadLocal. i'm more interested in solving the immediate problem than changing the way FOP handles doubles; i agree it could be a separate issue (if there is a desire to address it... but i don't know there is a need) -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Glenn Adams gad...@apache.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #16 from Glenn Adams gad...@apache.org 2012-04-11 03:21:16 UTC --- increase priority for bugs with a patch -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Ognjen Blagojevic ognjen.d.blagoje...@gmail.com changed: What|Removed |Added Blocks||51150 -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Glenn Adams gl...@skynav.com changed: What|Removed |Added Severity|minor |normal -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #15 from Glenn Adams gl...@skynav.com 2012-04-09 18:44:12 UTC --- (In reply to comment #5) Created attachment 25508 [details] The proposed patch Add an implementation of the format method as described. The main format method is split between formatFast and formatPrecise, using one or the other depending on the source and precision input. I will attach a test case shortly after. hi julien, in order to commit your non-trivial patch, it is necessary to have you submit an individual contributor license agreement, about which see http://www.apache.org/licenses/icla.txt; once you submit and you have been listed http://people.apache.org/committer-index.html#unlistedclas, then i can proceed to commit your patch to xmlgraphics-commons; thanks, glenn -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #14 from Glenn Adams gl...@skynav.com 2012-04-07 01:42:48 UTC --- resetting P2 open bugs to P3 pending further review -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #13 from Vincent Hennebert vhenneb...@gmail.com 2011-12-20 15:00:14 UTC --- While looking at the patch something struck me as odd in the requirements. Taking the same example of decimals being 4 and precision 8, 1.1 will be rounded to 1, while 0. will be kept as is. Yet the latter is much closer to 1 than the former (1000 times, to be precise). So if rounding had to be done, that would rather have to be the other way round, that is: keep 1.1 as is and round 0. up to 1. It seems to me that if drawing commands are used with numbers around 1, then the result is likely to look sub-optimal. Especially since transformation matrices can potentially scale up rounding errors quite a bit. At the other end of the spectrum, 12345678901.2345 will be output as is (15 significant digits), while 1.23456789012345 will be rounded to 1.2346 (5 significant digits). What justifies to have 15 significant digits on one hand, and only 5 on the other hand? I understand that this exercise has to do with outputting real numbers to PDF or PostScript (or other formats). According to the PDF Reference, Acrobat uses single-precision floating-point numbers to represent reals (the 'float' type in Java). Given that a float has approximately 8 significant digits —which is actually what the PostScript Reference puts in its Implementation Limits section— I suggest that we use this as the sole parameter. Now, would we really want this parameter to be configurable? Using a smaller number of significant digits probably makes no sense; using a higher number may allow to achieve higher precision with those applications (viewers or printers) that go beyond Acrobat and use doubles to represent real numbers. Such applications may actually become more and more common with the rise of 64-bit processors. Then again, will that increased precision make a significant difference in the context of drawing graphics? Any thoughts on this are welcome. As a side note, if we choose to fix the precision to 8 then the implementation becomes almost trivial: just convert the double into a float and 'de-scientificize' the output of toString. Thanks, Vincent -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Ognjen Blagojevic ognjen.d.blagoje...@gmail.com changed: What|Removed |Added CC||ognjen.d.blagojevic@gmail.c ||om -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #12 from Ognjen Blagojevic ognjen.d.blagoje...@gmail.com 2011-07-27 13:58:53 UTC --- Nice job, Julien. I reviewed DoubleFormatUtil and DoubleFormatUtilTest. DoubleFormatUtil contains requested static method formatDouble, and few other utility methods that may be used for double maniupation. As test case shows, all requested (and some additional) examples are formatted right: + 0.0 should be rendered as 0 (true) + 0.1 should be rendered as 0.1 (true) + 1234.1 should be rendered as 1234.1 (true) + 1234.1234567 should be rendered as 1234.1235 (note the trailing 5! Rounding!) + 1234.1 should be rendered as 1234 (true) + 0.1 should be rendered as 0.1 (here you see the effect of the + precision parameter. (true, need to add test case) + 0.0001 should be rendered as 0.0001. (true) + 0.1 should be rendered as 0. (true) Also, acceptance criteria are fulfilled: + The method has to prove to be faster than new DecimalFormat(0.##, new DecimalFormatSymbols(Locale.US)).format(value) on Sun Java 1.4, 1.5 an 6.0. (true) 1.4.2_05 - 672 ms for formatDecimal compared to 1782 ms ms for DecimalFormat.format 1.5.0_11 - 562 ms for formatDecimal compared to 1625 ms for DecimalFormat.format 1.6.0_24 - 485 ms for formatDecimal compared to 1188 ms for DecimalFormat.format Tested on Windows XP SP3, Intel Core 2 Duo, E6550, 2.33 GHz. + The method must be thread-safe. (true) Static method, using only local variables. + The method must have a javadoc comment. (true) + It must be accompanied by a JUnit TestCase testing all aspects of the method. (true) + It should not depend on any additional library not already in the dependency (true) list of Apache XML Graphics Commons (its destination in the end). Commiters, could you please add attachments 1 and 2 to the code base. Note that attachments 1 and 2 are for packages org.apache.xmlgraphics.util. If you prefer putting them into package org.apache.fop.util, please change the package declaration. Attachments 3 and 4 are not tested, I propose that those attachments be part of solution for bug #51150. -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #9 from Julien Aymé julien.a...@gmail.com 2010-06-11 07:53:00 EDT --- Created an attachment (id=25585) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25585) Patch for PSGenerator using the new class -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #10 from Julien Aymé julien.a...@gmail.com 2010-06-11 07:53:43 EDT --- Created an attachment (id=25586) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25586) Patch for PDFNumber using the new class -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #11 from Julien Aymé julien.a...@gmail.com 2010-06-11 07:56:01 EDT --- We could also use the new fast class in PCLGenerator and in IFUtil. (I will provide the patchs later if this is required). -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Julien Aymé julien.a...@gmail.com changed: What|Removed |Added Keywords||PatchAvailable -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Julien Aymé julien.a...@gmail.com changed: What|Removed |Added Summary|Faster method for double|[PATCH] Faster method for |formatting |double formatting -- 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 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #8 from Julien Aymé julien.a...@gmail.com 2010-06-02 11:20:56 EDT --- Maybe this bug should be put in XML Graphics Commons instead of FOP, so that all the XML Graphics projects would benefit from it. What do you think? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
