[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #35 from Julien Aymé julien.a...@gmail.com --- I will attach both a test case and a patch, later this afternoon. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940
--- Comment #36 from Julien Aymé julien.a...@gmail.com ---
The bug is trivial:
if (source = 10e-3 source 1e7) { is wrong !
if (source = 1e-3 source 1e7) { is right.
My mistake when reading 10 exp -3 in Double.toString javadoc and writing 10e-3
instead of 1e-3.
Patch will follow.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 43962] OutOfMemoryError while auto-detecting fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=43962 --- Comment #4 from Julien Aymé julien.a...@gmail.com --- Created attachment 28849 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28849action=edit patch for both class and test case (DoubleFormatUtil.java and DoubleFormatUtilTest.java) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 43962] OutOfMemoryError while auto-detecting fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=43962 --- Comment #5 from Julien Aymé julien.a...@gmail.com --- Patch attached to wrong issue. Please ignore. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #37 from Julien Aymé julien.a...@gmail.com --- Created attachment 28850 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28850action=edit patch for both class and test case (DoubleFormatUtil.java and DoubleFormatUtilTest.java) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940
--- Comment #38 from Glenn Adams gad...@apache.org ---
(In reply to comment #36)
The bug is trivial:
if (source = 10e-3 source 1e7) { is wrong !
if (source = 1e-3 source 1e7) { is right.
My mistake when reading 10 exp -3 in Double.toString javadoc and writing
10e-3 instead of 1e-3.
Patch will follow.
i'm not satisfied with this patch, since it depends upon the implementation
specific nature of Double.toString(); i would like to see better checking in
the code I listed in comment 34 to remove assumptions about the use of
scientific notation (and assuming that 'E' is present)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 43962] OutOfMemoryError while auto-detecting fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=43962 Glenn Adams gad...@apache.org changed: What|Removed |Added Attachment #28849|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940
--- Comment #39 from Glenn Adams gad...@apache.org ---
(In reply to comment #38)
(In reply to comment #36)
The bug is trivial:
if (source = 10e-3 source 1e7) { is wrong !
if (source = 1e-3 source 1e7) { is right.
My mistake when reading 10 exp -3 in Double.toString javadoc and writing
10e-3 instead of 1e-3.
Patch will follow.
i'm not satisfied with this patch, since it depends upon the implementation
specific nature of Double.toString(); i would like to see better checking in
the code I listed in comment 34 to remove assumptions about the use of
scientific notation (and assuming that 'E' is present)
for example, what happens if source is NaN? just looking at the code makes me
think the same else clause cited in comment 34 will apply, which means yet
again, that parseInt will be invoked on the string NaN
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940
--- Comment #40 from Glenn Adams gad...@apache.org ---
(In reply to comment #39)
(In reply to comment #38)
(In reply to comment #36)
The bug is trivial:
if (source = 10e-3 source 1e7) { is wrong !
if (source = 1e-3 source 1e7) { is right.
My mistake when reading 10 exp -3 in Double.toString javadoc and writing
10e-3 instead of 1e-3.
Patch will follow.
i'm not satisfied with this patch, since it depends upon the implementation
specific nature of Double.toString(); i would like to see better checking in
the code I listed in comment 34 to remove assumptions about the use of
scientific notation (and assuming that 'E' is present)
for example, what happens if source is NaN? just looking at the code makes
me think the same else clause cited in comment 34 will apply, which means
yet again, that parseInt will be invoked on the string NaN
in this regard, please add NaN, +Infinity, and -Infinity to your test cases;
also add the following test cases:
* 1E-3 + Double.MIN_VALUE
* 1E-3
* 1E-3 - Double.MIN_VALUE
* 1E7 + Double.MIN_VALUE
* 1E7
* 1E7 - Double.MIN_VALUE
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #41 from Julien Aymé julien.a...@gmail.com --- My understanding of Double.toString javadoc is that the contract described in the javadoc is mandatory for every implementation of the JVM. But since I may be wrong, feel free to correct the patch. I implemented this feature using Double comparison since I felt it was faster than doing another indexOf on the String (I may be wrong again :-) ). If you feel strongly for a second check I'll do it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 43940] [PATCH] Faster method for double formatting
https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 --- Comment #42 from Vincent Hennebert vhenneb...@gmail.com --- (In reply to comment #41) My understanding of Double.toString javadoc is that the contract described in the javadoc is mandatory for every implementation of the JVM. I agree with that. Otherwise the format return by toString wouldn't be described in such details. However, NaN and Infinity do have to be checked. But since I may be wrong, feel free to correct the patch. I implemented this feature using Double comparison since I felt it was faster than doing another indexOf on the String (I may be wrong again :-) ). If you feel strongly for a second check I'll do it. Vincent -- You are receiving this mail because: You are the assignee for the bug.
[Bug 50852] [PATCH] Improve generation of PDFs with accessibility information
https://issues.apache.org/bugzilla/show_bug.cgi?id=50852 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #40 from Vincent Hennebert vhenneb...@gmail.com --- I applied the artifact patch in rev. 1343632: http://svn.apache.org/viewvc?rev=1343632view=rev This fixes the last remaining issue for this bug. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] New: Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 Priority: P2 Bug ID: 53316 Assignee: fop-dev@xmlgraphics.apache.org Summary: Obscure algorithm of lines break in output PDF Severity: normal Classification: Unclassified OS: All Reporter: navat...@gmail.com Hardware: PC Status: NEW Version: 1.0 Component: page-master/layout Product: Fop Created attachment 28853 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28853action=edit screenshots Some words that can be fit into a one line moved to the following line. In my screenshot (line-width-problem.png) I have big space after word interface. The word its can fit in the first line of the paragraph - page witdh allows it. But as a result that word was moved to the second line. I tried to reduce word a--integration-pack.zip in middle of the paragraph to pack.zip and as a result the word its moved to the first line from second (line-width-problem2.png) The code of the paragraph looks like fo:block font-size=10pt For performing your tasks, you use the public Web service interface of BSS. This interface its documentation and additional resources, templates, samples, and utilities are provided in the BSS integration package (a--integration-pack.zip file). A detailed documentation for these resources is provided as Javadoc. By opening the readme.htm file of the integration package, you can access the available Javadoc documentation as well as the resources themselves. /fo:block Could you explain what affects to lines break? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 Pascal Sancho pascal.san...@takoma.fr changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Pascal Sancho pascal.san...@takoma.fr --- screenshot doesn't help to reproduce what you describe. Please attach (not copy/paste in comment) a short XSL-FO and PDF output that demonstrate what you describe. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 --- Comment #2 from Nawa navat...@gmail.com --- Created attachment 28854 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28854action=edit new samples input1.fo contains simplified input with a--integration-pack.zip word. input2.fo contains input with pack.zip word -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 Nawa navat...@gmail.com changed: What|Removed |Added Status|NEEDINFO|NEW -- You are receiving this mail because: You are the assignee for the bug.
[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 Attachment #28850|0 |1 is obsolete|| --- Comment #43 from Julien Aymé julien.a...@gmail.com --- Created attachment 28855 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28855action=edit patch for both class and test case (DoubleFormatUtil.java and DoubleFormatUtilTest.java) Added test case for limit conditions, and fixed DoubleFormatUtil accordingly. There was a bug in the private format(StringBuffer, ...) method, when checking against tenPow(scale) if scale = 19 (since 10^19 Long.MAX_VALUE). There was also a bug in formatDoublePrecise when trying to reconstruct the full decimal part from the scientific representation, when decLength digits. Again, the tests at limits showed these bugs, and I fixed them. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 --- Comment #3 from Manuel Mall man...@apache.org --- What you are observing is most likely the effect of the FOP linebreaking algorithm that is based on so called Knuth model (http://wiki.apache.org/xmlgraphics-fop/KnuthsModel). In a very informal description it attempts to find the most 'visually pleasing' linebreaks and as such it does not attempt to fill every line to its maximum. Instead it tries to find some optimum which leaves similar amounts whitespace on each line. It will avoid creating paragraphs with 'badly ragged' right margins if you don't use justification, or if you use justification it will result in the inter word gaps on each line to be of similar size. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 --- Comment #4 from Nawa navat...@gmail.com --- Thank Manuel Seems to be true. Is it possible to change linebreaking behavior from Knuth model to simple in my XSL-FO? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 --- Comment #5 from Manuel Mall man...@apache.org --- AFAIK you cannot switch off the Knuth algorithm or fallback to a simpler algorithm. Looking at your output1.pdf it would be interesting to figure out what a first fit algorithm would produce. For example the word 'its' moves to the first line. 'in the' but probably not 'BSS' moves to the second line. That is not enough to move 'documentation' to the 3rd line. Leaving you with a very short 3rd line. My gut feel is it would look inferior to what you have now. But I could be wrong. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53316] Obscure algorithm of lines break in output PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=53316 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Glenn Adams gad...@apache.org --- i'm closing since this is not a bug, but a feature request; if someone wants to create another bug report asking for the addition of one or more other line breaking algorithms along with a new extension property, fox:line-breaking-strategy, or, alternatively, implement the CSS3 Text Module's line-break property [1], then please do so; however, unless such a request is backed up by implementation activity leading to the submission of a patch, then there will likely be little done on such a bug report; i would prefer that no bug be filed unless it is accompanied by a patch to add new features in this area; instead, it would be better to the wanted features wiki; if you want more information about the current implementation, see [3] and [4] [1] http://dev.w3.org/csswg/css3-text/#line-break [2] http://wiki.apache.org/xmlgraphics-fop/MostWantedFeatures [3] http://wiki.apache.org/xmlgraphics-fop/KnuthsModel [4] http://wiki.apache.org/xmlgraphics-fop/LineBreaking -- You are receiving this mail because: You are the assignee for the bug.
[Bug 51150] Re-implement DecimalFormatCache to prevent memory leak with Tomcat
https://issues.apache.org/bugzilla/show_bug.cgi?id=51150 Bug 51150 depends on bug 43940, which changed state. Bug 43940 Summary: [PATCH] Faster method for double formatting https://issues.apache.org/bugzilla/show_bug.cgi?id=43940 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[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 Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #44 from Glenn Adams gad...@apache.org --- patched at: http://svn.apache.org/viewvc?rev=1343794view=rev http://svn.apache.org/viewvc?rev=1343800view=rev if there is another double format bug, please file a new bug report rather than reopening a prior closed bug -- You are receiving this mail because: You are the assignee for the bug.
[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 Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.
