DO NOT REPLY [Bug 49727] Upgrade exceptions from fop 0.95 to fop 1.0 (generate tiff output)
https://issues.apache.org/bugzilla/show_bug.cgi?id=49727 Jeremias Maerki changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE OS/Version||All --- Comment #1 from Jeremias Maerki 2010-09-02 02:59:18 EDT --- *** This bug has been marked as a duplicate of bug 49681 *** -- 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 49681] Upgrade Exceptions from fop 0.95 to 1.o
https://issues.apache.org/bugzilla/show_bug.cgi?id=49681
Jeremias Maerki changed:
What|Removed |Added
Version|0.95|1.0
--- Comment #4 from Jeremias Maerki 2010-09-02 03:10:21
EDT ---
The actual exception:
case DataBuffer.TYPE_INT:
case DataBuffer.TYPE_FLOAT:
if(sampleSize[0] != 32) {
throw new Error("TIFFImageEncoder4");
}
Ugly as hell but this has been so since TIFFImageEncoder has been introduced
into Batik. Anyway, the error probably happens because INT is used as sample
carrier but I assume the sample size is only 24 bits.
One change that happened from 0.95 to 1.0 was the introduction of the new
intermediate format so that TIFF output is now handled by TIFFDocumentHandler
instead of TIFFRenderer by default, but both classes use the same ImageWriter
API from XML Graphics Commons. The default color type (RGBA) has remained the
same. So I'm not sure where this comes from. I'll have to try to reproduce.
A possibility in the meantime is to try different color format settings:
http://xmlgraphics.apache.org/fop/1.0/output.html#bitmap-configuration
--
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 49681] Upgrade Exceptions from fop 0.95 to 1.o
https://issues.apache.org/bugzilla/show_bug.cgi?id=49681 Jeremias Maerki changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #5 from Jeremias Maerki 2010-09-02 03:21:27 EDT --- Ok, on my side, the ImageIO implementation for ImageWriter is used which doesn't show this problem. If I disable the ImageIO implementation the internal codec becomes active and fails on the default configuration settings with said exception. Now, the question is why the ImageIO implementation isn't used. Maybe it has to do with Bug 49696 but I don't really think so. So my next question: What JVM are running this on so you get this result? That might help me figure out why the internal codecs are selected over the ImageIO implementations. In this light, another work-around presents itself: In xmlgraphics-commons.jar you can edit META-INF/services/org.apache.xmlgraphics.image.writer.ImageWriter and remove the following entries: org.apache.xmlgraphics.image.writer.internal.PNGImageWriter org.apache.xmlgraphics.image.writer.internal.TIFFImageWriter org.apache.xmlgraphics.image.writer.internal.JPEGImageWriter -- 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 49681] Upgrade Exceptions from fop 0.95 to 1.o
https://issues.apache.org/bugzilla/show_bug.cgi?id=49681 --- Comment #6 from Jeremias Maerki 2010-09-02 03:36:12 EDT --- Should have thought about it earlier. We're talking about TIFF export, so another work-around: Install JAI ImageIO Tools to give ImageIO a TIFF codec which it hasn't by default. http://jai-imageio.dev.java.net/ So, I guess that's an important clue. Could it be that you had JAI ImageIO Tools installed but didn't add that when upgrading to FOP 1.0? Otherwise, I still can't explain that the error should have appeared when switching to FOP 1.0. -- 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: Is org.apache.fop.apps.FopFactory thread safe ?
Hi Peter,
Thanks for pointing this out. It differs in that the instance of
FOUserAgent was shared, but other than this, it's exactly the same case.
Finally, this leads to
https://issues.apache.org/bugzilla/show_bug.cgi?id=46360
which is still open.
As I read from the thread, this is a complex case and in batik they have
good reasons not to be thread-safe.
Finally, sorry for my other posting with the same title. I though that
only the subscribed email address can post.
Alexis
On 1-9-10 11:30 PM, Peter Coppens wrote:
Alexis,
This reminds me of something similar I ran into a while ago. I can't remember
the details nor how I eventually got around this and/or whether you run into
the same but the (weird) behavior you describe does look very similar.
See
http://old.nabble.com/Batik-exception-when-using-fop-with-svg-images-in-threaded-environment-td20809049.html
Perhaps it helps
Peter
On 01 Sep 2010, at 17:53, Alexios Giotis wrote:
Hello,
The javadoc and the class name suggest that FopFactory should be thread-safe
although this is not explicitly written. If this is not thread-safe then please
ignore what follows.
I am using FOP 1.0 to produce PDF documents concurrently from FOP intermediate
format. The PDF documents share a lot of common images, so I decided to use a
single instance of FopFactory to reduce memory requirements. From the single
FopFactory, I produce different instances for different threads like this:
FOUserAgent userAgent = fopFactory.newFOUserAgent();
IFDocumentHandler targetHandler =
fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat);
IFUtil.setupFonts(targetHandler);
targetHandler.setResult(new StreamResult(outStream));
IFConcatenator concatenator = new IFConcatenator(targetHandler, null);
for (int i = 0; i< numberOfDocumentsToConcatenate; i++) {
Source src = new SAXSource(myOwnApplicationXmlFilters, new
InputSource(myOwnInputStream));
concatenator.appendDocument(src);
}
The problem is that even on my 2-core laptop, I frequently get exceptions silently written in standard error. Different
stacktraces are attached and as you can see happen when batik parses the SVG files. For the same input the strings read are
corrupted. For example the overflow="visible" is read as "vssible" and then later as "vissibll".
Also the fill="#EC2227" is try to parse "E7E8" as color.
The workaround for my application is to have a new instance of FopFactory per
thread but I would like to fix it and create a patch. Since I am quite new to
FOP, I would like some advise on what should be the proper level. The higher
one would be the FopFactory (but it's too high and I could do it externally in
my code), then there is the org.apache.xmlgraphics.image.loader.ImageManager
and at the end we get to the very low level
org.apache.batik.css.engine.CSSEngine or org.apache.batik.css.parser.Parser.
Secondly, I think it's not a good practice that the exceptions are written in
STDERR instead of propagating to the application. What do you think ?
This is my first post to fop-dev and hopefully this is the proper one.
Thanks,
Alexis
Re: Is org.apache.fop.apps.FopFactory thread safe ?
Peter could be right. And there I thought I had this under control. But
with so many open Bugzilla issues, things get lost quickly. I've seen
multi-threading issues inside Batik myself in a production system and
haven't been able to put my finger on it since I though I had this fixed,
but it could be that I haven't really fixed it for all cases. I'll have
to look into it.
At any rate, FopFactory is supposed to be thread-safe. I always have one
FopFactory instance per configuration and that is usually one for the
whole JVM.
On 02.09.2010 10:08:19 Alexios Giotis wrote:
> Hi Peter,
>
> Thanks for pointing this out. It differs in that the instance of
> FOUserAgent was shared, but other than this, it's exactly the same case.
> Finally, this leads to
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46360
>
> which is still open.
>
> As I read from the thread, this is a complex case and in batik they have
> good reasons not to be thread-safe.
>
> Finally, sorry for my other posting with the same title. I though that
> only the subscribed email address can post.
>
> Alexis
>
>
>
> On 1-9-10 11:30 PM, Peter Coppens wrote:
> > Alexis,
> >
> > This reminds me of something similar I ran into a while ago. I can't
> > remember the details nor how I eventually got around this and/or whether
> > you run into the same but the (weird) behavior you describe does look very
> > similar.
> >
> > See
> > http://old.nabble.com/Batik-exception-when-using-fop-with-svg-images-in-threaded-environment-td20809049.html
> >
> > Perhaps it helps
> >
> > Peter
> >
> > On 01 Sep 2010, at 17:53, Alexios Giotis wrote:
> >
> >> Hello,
> >>
> >> The javadoc and the class name suggest that FopFactory should be
> >> thread-safe although this is not explicitly written. If this is not
> >> thread-safe then please ignore what follows.
> >>
> >> I am using FOP 1.0 to produce PDF documents concurrently from FOP
> >> intermediate format. The PDF documents share a lot of common images, so I
> >> decided to use a single instance of FopFactory to reduce memory
> >> requirements. From the single FopFactory, I produce different instances
> >> for different threads like this:
> >>
> >> FOUserAgent userAgent = fopFactory.newFOUserAgent();
> >> IFDocumentHandler targetHandler =
> >> fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat);
> >> IFUtil.setupFonts(targetHandler);
> >> targetHandler.setResult(new StreamResult(outStream));
> >> IFConcatenator concatenator = new IFConcatenator(targetHandler, null);
> >> for (int i = 0; i< numberOfDocumentsToConcatenate; i++) {
> >> Source src = new SAXSource(myOwnApplicationXmlFilters, new
> >> InputSource(myOwnInputStream));
> >> concatenator.appendDocument(src);
> >> }
> >>
> >> The problem is that even on my 2-core laptop, I frequently get exceptions
> >> silently written in standard error. Different stacktraces are attached and
> >> as you can see happen when batik parses the SVG files. For the same input
> >> the strings read are corrupted. For example the overflow="visible" is read
> >> as "vssible" and then later as "vissibll". Also the fill="#EC2227" is try
> >> to parse "E7E8" as color.
> >>
> >> The workaround for my application is to have a new instance of FopFactory
> >> per thread but I would like to fix it and create a patch. Since I am quite
> >> new to FOP, I would like some advise on what should be the proper level.
> >> The higher one would be the FopFactory (but it's too high and I could do
> >> it externally in my code), then there is the
> >> org.apache.xmlgraphics.image.loader.ImageManager and at the end we get to
> >> the very low level org.apache.batik.css.engine.CSSEngine or
> >> org.apache.batik.css.parser.Parser.
> >>
> >> Secondly, I think it's not a good practice that the exceptions are written
> >> in STDERR instead of propagating to the application. What do you think ?
> >>
> >>
> >>
> >> This is my first post to fop-dev and hopefully this is the proper one.
> >>
> >> Thanks,
> >> Alexis
> >>
> >>
> >
Jeremias Maerki
DO NOT REPLY [Bug 46360] Thread-safety issue rendering SVG
https://issues.apache.org/bugzilla/show_bug.cgi?id=46360 --- Comment #6 from Alexis Giotis 2010-09-02 05:01:10 EDT --- I can confirm that this issue is valid for FOP 1.0. A workaround is to use a different instance of FopFactory per thread. -- 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: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline
Just to add my 0.05 CHF: I normally use @todo when adding TODOs as part
of a method or class comment and I use //TODO inline. That's because
plain "TODO" lets the full text bleed into the Javadocs which is
certainly something we don't want. See for example:
org.apache.fop.area.DestinationData.resolveIDRef()
--
public void resolveIDRef(java.lang.String id,
java.util.List pages)
Resolves the idref of this object by getting the PageViewport object that
corresponds to the IDRef This method allows the Resolvable object to resolve
one of its unresolved idrefs with the actual set of PageViewports containing
the target ID. The Resolvable object initially identifies to the
AreaTreeHandler which idrefs it needs resolved. After the idrefs are resolved,
the ATH calls this method to allow the Resolvable object to update itself with
the PageViewport information. List) TODO check to make sure it works if
multiple bookmark-items have the same idref
Specified by:
resolveIDRef in interface Resolvable
Parameters:
id - an ID matching one of the Resolvable object's unresolved idref's.
pages - the list of PageViewports with the given ID
--
Or in org.apache.xmlgraphics.fonts.Glyphs:
--
public static final java.lang.String glyphToString(java.lang.String name)
Deprecated. User getUnicodeCodePointsForGlyphName instead. This method only
returns the first Unicode code point it finds.
Return the glyphname from a string, eg, glyphToString("\\") returns
"backslash"
Parameters:
name - glyph to evaluate
Returns:
the name of the glyph TODO: javadocs for glyphToString and
stringToGlyph are confused
--
I think we may still have various occurences where an empty line instead
of a or was used to delimit a paragraph which sometimes leads
to odd looking Javadocs. (but that's a different topic)
I'm not particularly in favor of @asf.todo because I'm sure most people
will instinctively rather use @todo and have to make an effort to
remember @asf.todo. I'm not sure we have the tooling to make sure noone
uses @todo.
I've checked a few other ASF projects' source code to see what they do.
A few have "TODO" in their Javadocs comments with the side-effect
described above. Others, like Felix, don't put their TODO's in the
Javadoc comment at all but use this pattern:
--
/**
* This class caches conditions instances by their infos. Furthermore, it allows
* to eval postponed condition permission tuples as per spec (see 9.45).
*/
// TODO: maybe use bundle events instead of soft/weak references.
public final class Conditions
--
That would also be safe. Actual Javadoc comments like @todo are
relatively few.
Based on these findings, I recommend we eventually remove TODOs and
@todo from the Javadoc comments and use //TODO comments exclusively.
Eclipse can handle all TODOs correctly by default. And Javadocs don't
get polluted. I believe that would pretty much address everyone's
concerns.
On 31.08.2010 13:33:25 Vincent Hennebert wrote:
> Hi,
>
> I just thought I would homogenize our usage of todo tags and match what
> seems to be the de facto standard (“TODO”) among current committers.
> Most @todo indeed come from very old commits. I didn’t realise that
> javadoc could do something with them, which is why that looked to me
> like a minor change that wasn’t needing prior discussion. Sorry about
> that.
>
> Ok, so there is something that can be done out of @todo tags in javadoc
> comments. Now, having to use our own namespaced version is unfortunate
> and looks overkill to me. Just to have a slightly better formatted
> javadoc? Are such comments of any use to users of the API anyway? Most
> of them rather look like pure internal development issues and should
> probably not even appear in the javadoc.
>
> Also, while @todo tags can be indexed, modern IDEs can index plain TODO
> tokens as well, so that reduces the advantage of @asf.todo IMO.
>
> If there are strong feelings against the removal of @asf.todo, I’ll
> revert the change. Otherwise, I’ll actually complete it by removing the
> definition of the custom tag in build.xml, which I hadn’t spotted.
>
> Vincent
>
>
> Simon Pepping wrote:
> > It would indeed have been better to first have a discussion and then
> > make the change. @asf.todo is specific enough that we could have
> > changed it at any time. That said, Glenn's change was also made
> > without a discussion. My javadoc does not complain about the @todo
> > tag, and I had not understood that this was a motivation.
> >
> > The javadoc documentation (of my sun-java6-jdk) is not clear about
> > this topic, and uses @todo liberally in its section about the -tag
> > option. Its most informative paragraph is this:
> >
> > "Avoiding Conflicts - If you want to slice out your own namespace, you
> > can use a dot-separated naming convention similar to that used for
> > packages: com.mycompany.todo. Sun will co
Re: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline
On Thu, Sep 2, 2010 at 6:04 PM, Jeremias Maerki wrote: > I'm not sure we have the tooling to make sure noone > uses @todo. > Actually, checkstyle 5.1 will report warnings for any use of a non-standard tag that is not qualified with a dotted prefix. Also the standard Doclet in recent JDKs will complain as well. So if committers run checkstyle and javadocs targets before committing, we should be able to keep this usage out. On the other hand, it may be possible to fine tune the checkstyle rules and also the doclet options to permit use of @todo without warnings. I could try to experiment some to see if that is feasible, then we could return to the former usage of @todo. G.
Re: Is org.apache.fop.apps.FopFactory thread safe ?
Jeremias, thanks for the clarification about the FopFactory.
I had a look at your old commit at
http://svn.apache.org/viewvc?view=revision&revision=724163
The current situation in trunk is that in
PDFImageHandlerSVG.handleImage() the SVG document is not cloned but in
other places it is. Examples of cloning are in ImageConverterSVG2G2D,
AbstractGenericSVGHandler, AFPImageHandlerSVG, AFPSVGHandler,
Java2DSVGHandler, PSSVGHandler.
This should be the cause of all the stack traces I get. They all go
through PDFImageHandlerSVG and after adding the document cloning (see
attached patch), I can no longer reproduce the error.
It should be safe to add the SVG document cloning in there but I would
better reduce a little of code duplication. In all those places it is
required to build a GraphicsNode and the way of doing this is similar.
But maybe this is out of scope.
Any suggestion on how to proceed with this ?
On 2-9-10 11:28 AM, Jeremias Maerki wrote:
Peter could be right. And there I thought I had this under control. But
with so many open Bugzilla issues, things get lost quickly. I've seen
multi-threading issues inside Batik myself in a production system and
haven't been able to put my finger on it since I though I had this fixed,
but it could be that I haven't really fixed it for all cases. I'll have
to look into it.
At any rate, FopFactory is supposed to be thread-safe. I always have one
FopFactory instance per configuration and that is usually one for the
whole JVM.
On 02.09.2010 10:08:19 Alexios Giotis wrote:
Hi Peter,
Thanks for pointing this out. It differs in that the instance of
FOUserAgent was shared, but other than this, it's exactly the same case.
Finally, this leads to
https://issues.apache.org/bugzilla/show_bug.cgi?id=46360
which is still open.
As I read from the thread, this is a complex case and in batik they have
good reasons not to be thread-safe.
Finally, sorry for my other posting with the same title. I though that
only the subscribed email address can post.
Alexis
On 1-9-10 11:30 PM, Peter Coppens wrote:
Alexis,
This reminds me of something similar I ran into a while ago. I can't remember
the details nor how I eventually got around this and/or whether you run into
the same but the (weird) behavior you describe does look very similar.
See
http://old.nabble.com/Batik-exception-when-using-fop-with-svg-images-in-threaded-environment-td20809049.html
Perhaps it helps
Peter
On 01 Sep 2010, at 17:53, Alexios Giotis wrote:
Hello,
The javadoc and the class name suggest that FopFactory should be thread-safe
although this is not explicitly written. If this is not thread-safe then please
ignore what follows.
I am using FOP 1.0 to produce PDF documents concurrently from FOP intermediate
format. The PDF documents share a lot of common images, so I decided to use a
single instance of FopFactory to reduce memory requirements. From the single
FopFactory, I produce different instances for different threads like this:
FOUserAgent userAgent = fopFactory.newFOUserAgent();
IFDocumentHandler targetHandler =
fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat);
IFUtil.setupFonts(targetHandler);
targetHandler.setResult(new StreamResult(outStream));
IFConcatenator concatenator = new IFConcatenator(targetHandler, null);
for (int i = 0; i< numberOfDocumentsToConcatenate; i++) {
Source src = new SAXSource(myOwnApplicationXmlFilters, new
InputSource(myOwnInputStream));
concatenator.appendDocument(src);
}
The problem is that even on my 2-core laptop, I frequently get exceptions silently written in standard error. Different
stacktraces are attached and as you can see happen when batik parses the SVG files. For the same input the strings read are
corrupted. For example the overflow="visible" is read as "vssible" and then later as "vissibll".
Also the fill="#EC2227" is try to parse "E7E8" as color.
The workaround for my application is to have a new instance of FopFactory per
thread but I would like to fix it and create a patch. Since I am quite new to
FOP, I would like some advise on what should be the proper level. The higher
one would be the FopFactory (but it's too high and I could do it externally in
my code), then there is the org.apache.xmlgraphics.image.loader.ImageManager
and at the end we get to the very low level
org.apache.batik.css.engine.CSSEngine or org.apache.batik.css.parser.Parser.
Secondly, I think it's not a good practice that the exceptions are written in
STDERR instead of propagating to the application. What do you think ?
This is my first post to fop-dev and hopefully this is the proper one.
Thanks,
Alexis
Jeremias Maerki
Index: PDFImageHandlerSVG.java
===
--- PDFImageHandlerSVG.java (revision 991883)
+++ PDFImageHandlerSVG.java (working copy)
@@ -38,6 +38,7 @@
import org.apache.fop.apps.FOUserAgent;
import org.apache.fop
Re: Is org.apache.fop.apps.FopFactory thread safe ?
Hi Alexis
Thanks for the patch! I'll look at it shortly. Would you mind attaching
it to the Bugzilla issue?
https://issues.apache.org/bugzilla/show_bug.cgi?id=46360
That way it's clearer that you donate the changes to the ASF and
everything concerning this problem is in one place. Thanks!
On 02.09.2010 12:52:37 Alexios Giotis wrote:
> Jeremias, thanks for the clarification about the FopFactory.
>
> I had a look at your old commit at
> http://svn.apache.org/viewvc?view=revision&revision=724163
>
> The current situation in trunk is that in
> PDFImageHandlerSVG.handleImage() the SVG document is not cloned but in
> other places it is. Examples of cloning are in ImageConverterSVG2G2D,
> AbstractGenericSVGHandler, AFPImageHandlerSVG, AFPSVGHandler,
> Java2DSVGHandler, PSSVGHandler.
>
> This should be the cause of all the stack traces I get. They all go
> through PDFImageHandlerSVG and after adding the document cloning (see
> attached patch), I can no longer reproduce the error.
>
> It should be safe to add the SVG document cloning in there but I would
> better reduce a little of code duplication. In all those places it is
> required to build a GraphicsNode and the way of doing this is similar.
> But maybe this is out of scope.
>
> Any suggestion on how to proceed with this ?
>
>
>
>
> On 2-9-10 11:28 AM, Jeremias Maerki wrote:
> > Peter could be right. And there I thought I had this under control. But
> > with so many open Bugzilla issues, things get lost quickly. I've seen
> > multi-threading issues inside Batik myself in a production system and
> > haven't been able to put my finger on it since I though I had this fixed,
> > but it could be that I haven't really fixed it for all cases. I'll have
> > to look into it.
> >
> > At any rate, FopFactory is supposed to be thread-safe. I always have one
> > FopFactory instance per configuration and that is usually one for the
> > whole JVM.
> >
> > On 02.09.2010 10:08:19 Alexios Giotis wrote:
> >> Hi Peter,
> >>
> >> Thanks for pointing this out. It differs in that the instance of
> >> FOUserAgent was shared, but other than this, it's exactly the same case.
> >> Finally, this leads to
> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=46360
> >>
> >> which is still open.
> >>
> >> As I read from the thread, this is a complex case and in batik they have
> >> good reasons not to be thread-safe.
> >>
> >> Finally, sorry for my other posting with the same title. I though that
> >> only the subscribed email address can post.
> >>
> >> Alexis
> >>
> >>
> >>
> >> On 1-9-10 11:30 PM, Peter Coppens wrote:
> >>> Alexis,
> >>>
> >>> This reminds me of something similar I ran into a while ago. I can't
> >>> remember the details nor how I eventually got around this and/or whether
> >>> you run into the same but the (weird) behavior you describe does look
> >>> very similar.
> >>>
> >>> See
> >>> http://old.nabble.com/Batik-exception-when-using-fop-with-svg-images-in-threaded-environment-td20809049.html
> >>>
> >>> Perhaps it helps
> >>>
> >>> Peter
> >>>
> >>> On 01 Sep 2010, at 17:53, Alexios Giotis wrote:
> >>>
> Hello,
>
> The javadoc and the class name suggest that FopFactory should be
> thread-safe although this is not explicitly written. If this is not
> thread-safe then please ignore what follows.
>
> I am using FOP 1.0 to produce PDF documents concurrently from FOP
> intermediate format. The PDF documents share a lot of common images, so
> I decided to use a single instance of FopFactory to reduce memory
> requirements. >From the single FopFactory, I produce different instances
> for different threads like this:
>
> FOUserAgent userAgent = fopFactory.newFOUserAgent();
> IFDocumentHandler targetHandler =
> fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat);
> IFUtil.setupFonts(targetHandler);
> targetHandler.setResult(new StreamResult(outStream));
> IFConcatenator concatenator = new IFConcatenator(targetHandler, null);
> for (int i = 0; i< numberOfDocumentsToConcatenate; i++) {
> Source src = new SAXSource(myOwnApplicationXmlFilters, new
> InputSource(myOwnInputStream));
> concatenator.appendDocument(src);
> }
>
> The problem is that even on my 2-core laptop, I frequently get
> exceptions silently written in standard error. Different stacktraces are
> attached and as you can see happen when batik parses the SVG files. For
> the same input the strings read are corrupted. For example the
> overflow="visible" is read as "vssible" and then later as "vissibll".
> Also the fill="#EC2227" is try to parse "E7E8" as color.
>
> The workaround for my application is to have a new instance of
> FopFactory per thread but I would like to fix it and create a patch.
> Since I am quite new to FOP, I would like some advise on what should be
> t
DO NOT REPLY [Bug 46360] Thread-safety issue rendering SVG
https://issues.apache.org/bugzilla/show_bug.cgi?id=46360 --- Comment #7 from Alexis Giotis 2010-09-02 07:52:22 EDT --- Created an attachment (id=25970) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25970) Patch to clone the SVG document inside PDFImageHandlerSVG The patch is attached after a short discussion in the fop-dev mailing list. Shortly, in PDFImageHandlerSVG.handleImage() the SVG document is not cloned but in other places it is. Examples of cloning are in ImageConverterSVG2G2D, AbstractGenericSVGHandler, AFPImageHandlerSVG, AFPSVGHandler, Java2DSVGHandler, PSSVGHandler. Before the patch, in a multi-threaded environment parsing of the SVG documents was corrupted with a probability close to 80%. After this, the errors can not be reproduced. This patch contains the smallest change I could do, is for a single file and should be safe to apply. On a side note, normally I would first try to gather the building of the GraphicsNode in a single place and then avoid the document cloning by serializing only the parsing of the SVG. But that would affect more files / projects and would make the processing of the patch more difficult. -- 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: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline
On 02.09.2010 12:14, Glenn Adams wrote: also the doclet options to permit use of @todo without warnings. I could try to experiment some to see if that is feasible, then we could return to the former usage of @todo. Javadoc 1.5 or later can be passed a command line option defining additional tokens to accept: http://download.oracle.com/javase/1.5.0/docs/tooldocs/windows/javadoc.html#tag I vaguely remember to have had it working in my local build.xml some times ago. J.Pietschmann
DO NOT REPLY [Bug 49870] New: Border-right not visible if hyphenation is activated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49870 Summary: Border-right not visible if hyphenation is activated Product: Fop Version: 1.0 Platform: PC Status: NEW Severity: major Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: matthias8...@gmx.at Created an attachment (id=25976) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25976) Testcase When setting border-right on fo:inline the border is not visible in PDF output if hyhpenation is activated. Could somebody fix this please? Example file is attached. Thanks -- 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 49870] Border-right not visible if hyphenation is activated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49870 Matthias Reischenbacher changed: What|Removed |Added CC||matthias8...@gmx.at OS/Version||All -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
