DO NOT REPLY [Bug 45104] Possible Thread Safety Problem in FOP 0.93
https://issues.apache.org/bugzilla/show_bug.cgi?id=45104 Jeremias Maerki [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED]|fop- |rg |[EMAIL PROTECTED] -- 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 45104] Possible Thread Safety Problem in FOP 0.93
https://issues.apache.org/bugzilla/show_bug.cgi?id=45104 --- Comment #1 from Jeremias Maerki [EMAIL PROTECTED] 2008-05-31 02:27:59 PST --- That statement on the website is basically a disclaimer so everyone using FOP in a multi-threaded environment performs some testing and don't just consider themselves on the safe side as this is a complex field. Finding bugs in this area is very difficult especially if you don't have dedicated hardware for continuous testing (and we don't). We are very vigilant to catch any changes that might introduce multi-threading problems. I also do regular tests in this direction. That doesn't mean there cannot be a remaining multi-threading bug somewhere in the codebase. But frankly, I have a very hard time believing that content from one document can end up in the output file of another processing run. I know the whole FOP code base very well and can almost guarantee that such a thing cannot happen as there is no shared data concerning the actual text content between individual processing runs. If you have about 15 incidents in 260'000 hits, I think it should be possible to do some load testing on your system to provoke the failure. I think tools like JMeter (for load testing) and PDFBox (for text extraction) should help you identify such problems and circle in on the cause. Good luck! If anyone else his additional thoughts on this, please share them. I don't know how I could do anything about this particular problem if it's a FOP problem in the first place. I know a number of users who use FOP in a heavily multi-threaded way without any problems. John, I'm afraid you probably have to help yourself in this case (meaning: reproduce the problem as the first step to identifying the cause). Good luck! -- 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 45097] Questionable white-space-treatment behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=45097 --- Comment #10 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-31 03:58:24 PST --- Created an attachment (id=22041) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22041) Result after applying the fix FWIW: the issues with Example 1 and Example 2 have been fixed in FOP trunk. In both cases, with or without wrapping block, the result is now as in the attached PDF. -- 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 45097] Questionable white-space-treatment behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=45097 --- Comment #11 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-05-31 04:00:19 PST --- Fix applied to FOP Trunk. see: http://svn.apache.org/viewvc?rev=661999view=rev I'm keeping the issue open FTM, as a reminder for the dubious/inelegant way of handling preserved white-space around formatter-generated linebreaks. Strictly speaking not a bug, but I agree with the reporter that the current behavior is not really what it should be... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: try without catch in BlockStackingLM.getNextKnuthElements
On May 29, 2008, at 18:23, Vincent Hennebert wrote:
Could anybody explain me what is the purpose of the following piece of
code:
if (!breakBeforeServed) {
try {
if (addKnuthElementsForBreakBefore(returnList, context)) {
return returnList;
}
} finally {
breakBeforeServed = true;
}
}
that we can find, for instance, in
BlockStackingLM.getNextKnuthElements?
Can't explain, other than that it seems to be a remnant of some
refactoring cycle without subsequential cleanup...
Isn’t it equivalent to the following:
if (!breakBeforeServed) {
breakBeforeServed = true;
if (addKnuthElementsForBreakBefore(returnList, context)) {
return returnList;
}
}
Indeed, this has the exact same outcome AFAICT.
Cheers
Andreas
DO NOT REPLY [Bug 45027] Color 'blue' does not render correctly when 'fo: external-graphic' is present
https://issues.apache.org/bugzilla/show_bug.cgi?id=45027 --- Comment #4 from Antonio Rivero [EMAIL PROTECTED] 2008-05-31 08:03:57 PST --- Created an attachment (id=22043) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22043) SVG file with blue text and an opaque box -- 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 45027] Color 'blue' does not render correctly when 'fo: external-graphic' is present
https://issues.apache.org/bugzilla/show_bug.cgi?id=45027 --- Comment #6 from Antonio Rivero [EMAIL PROTECTED] 2008-05-31 08:06:44 PST --- Hello FOP community I have checked the problem again (Bug #45027) and actually this problem resides in the SVG document. When the ‘opacity’ attribute (with a value less than 1) is included in a determinate shape element, this affects the color of the text, even if such text lies outside the shape range. That is what I mean ‘does not render correctly’. As an example, I attached a SVG file with blue text and a rect element with an opacity attribute less than one. If you embed this with a FO/XSL file, the text won’t be blue anymore. Perhaps this issue belongs to the ‘SVG Component’, but it is up to you to decide this... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: try without catch in BlockStackingLM.getNextKnuthElements
Andreas Delmelle wrote:
On May 29, 2008, at 18:23, Vincent Hennebert wrote:
Could anybody explain me what is the purpose of the following piece of
code:
if (!breakBeforeServed) {
try {
if (addKnuthElementsForBreakBefore(returnList, context)) {
return returnList;
}
} finally {
breakBeforeServed = true;
}
}
that we can find, for instance, in BlockStackingLM.getNextKnuthElements?
Can't explain, other than that it seems to be a remnant of some
refactoring cycle without subsequential cleanup...
Isn’t it equivalent to the following:
if (!breakBeforeServed) {
breakBeforeServed = true;
if (addKnuthElementsForBreakBefore(returnList, context)) {
return returnList;
}
}
Indeed, this has the exact same outcome AFAICT.
Cheers
Andreas
What's the scope of breakBeforeServed?
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
