Reto Blunschi/EXT/CSS ist außer Haus.
Ich werde ab 30.08.2003 nicht im Büro sein. Ich kehre zurück am 21.09.2003. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. Während meiner Abwesenheit werde ich vertreten durch Valerio Tricarico ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: AWTRenderer thread safe?
I have investigated this and have done some multithreaded tests with AWTRenderer a few months ago. The conclusions can be found in the archives of this list. Summary: - AWTRenderer and all subclasses of it (TIFFRenderer...) are NOT threadsave. - It is not threadsave because the underlaying AWT libs are not threadsave. It does not help to use different instances of REnderer, Driver , or anything else. You need different VMs to run AWTRenderer concurrently. - There is no simple way to adjust AWTRenderer to be threadsave. It probabaly needs a complete redesign - I don't think it is even possible to make an AWTRenderer threadsave, since it would have to be written without using AWT. cheers, Reto |-+--- | | J.Pietschmann | | | [EMAIL PROTECTED]| | | de | | | | | | 14.06.2003 19:37| | | Bitte antworten | | | an fop-user | | | | |-+--- ---| | | |An: [EMAIL PROTECTED] | |Kopie: | |Thema: Re: AWTRenderer thread safe? | ---| Victor Mote wrote: My suggestion then would be to download 0.20.5 see whether it fixes your problem. I think it will, I don't think so. The issue with randomly changing font families and font weights in the AWT renderer has been reported before, and I vaguely remember this was deemed a problem with JDK 1.4. Searching the mailing list archives may turn it up. Maybe upgrading to 1.4.1_03 is of some help... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: AWTRenderer thread safe?
I agree with you. I am not at all an AWT/Swing expert. When I was investigating this it turned out to be surprisingly difficult to get reliable information about threadsafty of these classes. Especially when I tried to find out where exactly the problem is inside AWT/Swing and what could be done to work around it. It seems that serverside usage of AWT classes is not very common. So, the analysis I provided comes mostly from the bits of information I found and analysis of AWT/Swing sources conducted by myself and a few others that I consider more knowledable than myself in these matters. Anyway, if there is anyone around with more AWT knowledge, I would appreciate their comments. cheers, Reto |-+--- | | Victor Mote | | | [EMAIL PROTECTED]| | | | | | | | | 16.06.2003 16:22| | | Bitte antworten | | | an fop-user | | | | |-+--- ---| | | |An: [EMAIL PROTECTED] | |Kopie: | |Thema: Re: AWTRenderer thread safe? | ---| Reto wrote: I have investigated this and have done some multithreaded tests with AWTRenderer a few months ago. The conclusions can be found in the archives of this list. Summary: - AWTRenderer and all subclasses of it (TIFFRenderer...) are NOT threadsave. - It is not threadsave because the underlaying AWT libs are not threadsave. It does not help to use different instances of REnderer, Driver , or anything else. You need different VMs to run AWTRenderer concurrently. - There is no simple way to adjust AWTRenderer to be threadsave. It probabaly needs a complete redesign - I don't think it is even possible to make an AWTRenderer threadsave, since it would have to be written without using AWT. Yes, your comments are the ones that I referenced in my answer, and they were very helpful. The only thing that troubles me is that although it is well-documented that Swing classes are not thread-safe, I can find nothing similar for AWT, so I am hesitant to list that as the cause. For now, I have documented that the AWT Renderer should not be multi-threaded, but have not documented why. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Fop and multithreading.
After some debugging and quite some time to get information on the
implications of multithreaded access to AWT/Swing classes, I came to the
following conclusion:
To keep thread-safety in Swing/AWT rendering operations can only be called
from one thread - normally this is the AWTEventDispatchThread. Swing/AWT
classes are NOT threadsafe by design.
The current situation:
a) in FOP singlethreaded: it is the main execution thread that does the
rendering. Because the AWTEventDispatchThread does not get any events in
FOP (no UI events) this is the only thread that really does something ()
- no threading issues. The AWTEventDispatchThread also runs in this setup,
but does not do any work.
b) FOP multithreaded: multiple client threads call rendering operations
concurrently, - leading to the issues we see. (again the
AWTEventDispatchThread runs, but does not do any work.)
Solution:
Threadsafety in AWT/Swing is normally achieved by delegating all rendering
calls from client threads to the AWTEventDispatchThread using
javax.Swing.SwingUtilities#invokeLater(Runnable runnable) or #invokeAndWait
(). This means one wraps calls to render into the BufferedImage into
something like:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
graphics.setFont(font);
graphics.drawString(.);
}
});
I have considered to refactor AWTRenderer to work like this, but soon
realized that this means a complete redesign of the involved classes. For
several reasons I can't do this right now (FOP maintenance branch - no big
changes, project work that is urgent)
Workarounds:
- wrap FOP into a singleton and synchronize the render method. - does only
use one processor. Threads are potentially blocked for quite some time :
-((
or
- setup RMI / Corba Service / WebService that does the rendering, so we can
have several JVMs that contain their FOP instance and use some
load-balancing mechanism.
or
- use only one font / font size / color in the layout, it seems to work
then, by coincidence, though no guarantees.
I chose to go with the first for now, until I see that this causes
performance problems.
Additionally it might be good to document that AWTRenderer (and obviously
all subclasses) are not threadsafe.
Any comments?
Thanks,
Reto
___
CSS Versicherung
Reto Blunschi EXTERNE
Rösslimattstrasse 40
CH-6002 Luzern
Telefon ++41 (0)41 369 1236
Telefax ++41 (0)41 369 1212
[EMAIL PROTECTED]
www.css.ch
[EMAIL PROTECTED] on 11.02.2003 13:07:55
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie:
Thema: Re: Fop and multithreading.
Thanks for the testcase, Jeremias.
I got it running and can reliably reproduce the MT problems in AWTRenderer
with it, even on my single-processor NT 4.0 box.
I will have a closer look into the sources of AWTRenderer now...
___
CSS Versicherung
Reto Blunschi EXTERNE
Rösslimattstrasse 40
CH-6002 Luzern
Telefon ++41 (0)41 369 1236
Telefax ++41 (0)41 369 1212
[EMAIL PROTECTED]
www.css.ch
Jeremias Maerki [EMAIL PROTECTED] on 11.02.2003 11:19:55
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie:
Thema: Re: Antwort: Re: Antwort: Fop and multithreading.
Ok, I've put together a ZIP and put it under the URL below:
http://cvs.apache.org/~jeremias/FOPMTTestbed.zip
I hope you don't mind that it's heavily relying on Avalon (especially
Fortress). I've put all the necessary JARs in the lib directory. I
didn't include fop.jar and batik.jar which you can take from your local
FOP. I've also done a little Ant build.xml to make it easy to have some
fast results. You just have to adjust the FOP location in build.xml to
your local environment so it compiles.
To configure the whole thing look at FOPTestbed.xconf. There you can
specify the number of concurrent threads, which files to transform etc.
And finally, to test multithreading with the AWT Renderer just change
FOProcessorImpl.java accordingly. It currently generates PDF.
If you have questions, fire away. Happy debugging!
On 10.02.2003 16:50:18 Jeremias Maerki wrote:
Is the testcase you used in november available as a starter?
I have it here. Just give me a little time to get it running again (I've
got to check if it's still compatible with the latest Avalon Fortress
version. I'll post a URL when I'm finished.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
Re: Fop and multithreading.
Thanks for the testcase, Jeremias. I got it running and can reliably reproduce the MT problems in AWTRenderer with it, even on my single-processor NT 4.0 box. I will have a closer look into the sources of AWTRenderer now... ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch Jeremias Maerki [EMAIL PROTECTED] on 11.02.2003 11:19:55 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: Antwort: Re: Antwort: Fop and multithreading. Ok, I've put together a ZIP and put it under the URL below: http://cvs.apache.org/~jeremias/FOPMTTestbed.zip I hope you don't mind that it's heavily relying on Avalon (especially Fortress). I've put all the necessary JARs in the lib directory. I didn't include fop.jar and batik.jar which you can take from your local FOP. I've also done a little Ant build.xml to make it easy to have some fast results. You just have to adjust the FOP location in build.xml to your local environment so it compiles. To configure the whole thing look at FOPTestbed.xconf. There you can specify the number of concurrent threads, which files to transform etc. And finally, to test multithreading with the AWT Renderer just change FOProcessorImpl.java accordingly. It currently generates PDF. If you have questions, fire away. Happy debugging! On 10.02.2003 16:50:18 Jeremias Maerki wrote: Is the testcase you used in november available as a starter? I have it here. Just give me a little time to get it running again (I've got to check if it's still compatible with the latest Avalon Fortress version. I'll post a URL when I'm finished. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Fop and multithreading.
Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch [EMAIL PROTECTED] on 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RE: Antwort: Fop and multithreading.
I suspect that the singelton approach with synchronized method will solve the issue. But I am not sure whether it is acceptable, because that would mean to execute FOP synchroized, not using the multi-processor box. Rendering is one of the most processing-intensive opertations we do, so synchronizing all this is really only a last resort if we can't find another solution. Reto __ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch [EMAIL PROTECTED] on 10.02.2003 13:00:56 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: RE: Antwort: Fop and multithreading. Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 12:45 À: [EMAIL PROTECTED] Objet: Antwort: Fop and multithreading. Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch [EMAIL PROTECTED] on 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RE: Antwort: Fop and multithreading.
ok, that makes more and more sense. That was also the feedback I got from the FOP devs, that AWTRenderer is probably not threadsave, since it was never designed to be - it was only designed to be a kind of testing tool, to be used on the client. What kind of graphics environment are you on? Is there an X-Server on your UNIX box, or are you using this pja library pja toolkit (http://www.eteks.com/pja/en/) as well? In conclusion we should probably have a closer look on the AWTRenderer source... which I have already done, though unfortunatly I am not an expert on AWT and its multithreading issues. I don't see any obvious problems, but I am sure there are implications of using java.awt.Font and FontMetric classes that I did not realizing so far. and debugging is painful here, because access to the multiproc box is very restricted, and I only see the problem there, can't reproduce it on my dev-box. ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch [EMAIL PROTECTED] on 10.02.2003 13:19:40 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: RE: Antwort: Fop and multithreading. The renderer I use is the PrintRenderer class found in the FopPrintServlet example (this renderer extends the AWTRenderer). -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 13:01 À: [EMAIL PROTECTED] Objet: RE: Antwort: Fop and multithreading. Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 12:45 À: [EMAIL PROTECTED] Objet: Antwort: Fop and multithreading. Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch [EMAIL PROTECTED] on 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Antwort: Fop and multithreading.
Hi Jeremias, I do agree very much with you about the concerns on EJB usage, though unfortunately drop the EJB idea is not an option. EJB is the chosen environment in this company (my client). Since XSL:FO has also been chosen as strategic technology, we are bound to find a way for the two to coexist. Having a special service for the rendering may be an option, but in the end this comes down to the same issues than doing it inside the EJB using seperate ThreadPools, JMS and the like, this is a long-discussed topic in EJB lists... It seems obvious that you have not noticed the problems we see, because the issue is most probably in AWTRenderer and its use of AWT classes (java.awt.Font, java.awt.FontMetrics, java.awt.graphics). Your suggestion is a good way forward: I will try write a TestCase that reproduces the problems outside EJB and we see how we can go on from there. Is the testcase you used in november available as a starter? merci, Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch Jeremias Maerki [EMAIL PROTECTED] on 10.02.2003 14:08:11 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: Antwort: Fop and multithreading. Frédéric and Reto, having read the 24.1.2 Programming restrictions of the EJB 2.0 specification, I'd recommend you guys don't call FOP from an EJB. The programming restrictions forbid among other things the following: - Reading or writing of static variables (FOP still does this too often) - Use of thread synchronization primitives (FOP does that mostly because of the static variables) - Use of AWT functionality - Use of java.io package to access files (which obviously happens as well) So the singleton may also be a bad idea. I recommend you don't use FOP within EJBs. Use a Servlet, a WebService or a custom-built server service instead. I've done some serious debugging of multithreading issues last November by writing a test application that uses FOP in a multi-threaded fashion (PDF only, no AWT). I haven't had the symptoms you describe so I can only imagine it has to do with the enviroment (EJBs). Of course, it could be that my test application was suboptimal, so maybe you two can come up with a test application that triggers your symptoms outside an EJB server. That would help track the error down. If you can't reproduce the bug outside the EJB server I recommend you drop the EJB idea. You can find the spec mentioned above here: http://java.sun.com/products/ejb/docs.html#specs Good luck! On 10.02.2003 13:00:56 frederic.kieffer wrote: Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: multithreading issues - FOP, TIFFRenderer, Solaris 4-proc machine, pja x-server
ok, I run the same thing with PDFRenderer, and I found no problems there. This means that the multithreading issue is either within a) AWTRenderer b) TIFFRenderer (subclass of AWTRenderer) c) pja X-Server emulation. Since the issue is, that fontsize-changes from one Renderer influence another Renderer, I suspect the mistake to be in a) or c). AFAIK FOP paints the characters to the InMemory-Image in these classes. Is this correct? Has anyone used AWTRenderer in a mutlithreaded environment? Are there any known limitations? thanks, Reto Oleg Tkachenko [EMAIL PROTECTED] on 31.01.2003 16:05:31 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: multithreading issues - FOP, TIFFRenderer, Solaris 4-proc machine, pja x-server [EMAIL PROTECTED] wrote: I am using FOP 0.20.5rc to produce TIFF files from XML in an EJB environment. I experience strange multithreading issues when I run the thing in the (production-near) test-environement on a 4-proc box - the font sizes get messed up completly on the 4 proc machine but only if I render more than 1 TIFF in parallel. If I run only one rendering at a time, it is fine. If I run the same thing multithreaded on my dev box, it runs fine (though there is only one proc of course) It is entierly possible that the TIFFRenderer (from Oleg, based on AWTRenderer and JAI), or the pja toolkit (http://www.eteks.com/pja/en/) is the problem. Yes, you have to isolate problem somehow. Can you test it without TIFFRenderer, using just regular PDFRenderer? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multithreading issues - FOP, TIFFRenderer, Solaris 4-proc machine, pja x-server
);
transformer = transFactory.newTransformer(source);
Collection trafoParams = invoice.getTransformParameters();
if (trafoParams != null) {
Iterator i = invoice.getTransformParameters().iterator();
while (i.hasNext()) {
String[] param = (String[]) i.next();
transformer.setParameter(param[0], param[1]);
}
}
Source xmlsource = new StreamSource(new
StringReader(invoice.getXmlString()));
transformer.transform(xmlsource, new
SAXResult(driver.getContentHandler()));
output = outputStream.toByteArray();
outputStream.close();
xslStream.close();
} catch (TransformerFactoryConfigurationError
transformerFactoryConfigurationError) {
CSSLogging.error(e);
throw new CSSFatalErrorException(e);
} catch (TransformerConfigurationException e) {
CSSLogging.error(e);
throw new CSSFatalErrorException(e);
} catch (TransformerException e) {
CSSLogging.error(e);
throw new CSSFatalErrorException(e);
} catch (IOException e) {
CSSLogging.error(e);
throw new CSSFatalErrorException(e);
}
return output;
}
___
CSS Versicherung
Reto Blunschi EXTERNE
Rösslimattstrasse 40
CH-6002 Luzern
Telefon ++41 (0)41 369 1236
Telefax ++41 (0)41 369 1212
[EMAIL PROTECTED]
www.css.ch
attachment: Unde0004.tif-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RE: Antwort: Re: Antwort: Re: Antwort: Which TIFF format is used in batik? How can I get TIFF Type 1?
Afraid not :( A higher scale factor creates a bigger BufferedImage.The end result is a larger 72 dpi tiff. you are correct. (since the viewer app we need to integrate with treats those larger 72 dpi tiffs like smaller higher resolved ones, I did not notice - and it still solves my problems ;-) Though, this can be the first step to a higher resolved TIFF. I read some docs about Graphics2D. The BufferedImage is resolution-independant. It is simply a rectagle of pixels, with no information on what space it should be displayed on. (as are some of the file-formats like GIF, BMP and others). That means the way to higher resolved TIFFs could be: 1. calculate the scale factor, so that the renderer creates the correct size in pixels (72 dpi = sf 100). 2. When writing out the TIFF, somehow set the resolution in the TIFF-file Metadata to the higher dpi value. (need to look into this) - That should result in a correct higher-resolved TIFF. Francis, Ronald [EMAIL PROTECTED] on 18.12.2002 23:32:40 Bitte antworten an [EMAIL PROTECTED] An: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Kopie: Thema: RE: Antwort: Re: Antwort: Re: Antwort: Which TIFF format is used in batik? How can I get TIFF Type 1? Afraid not :( A higher scale factor creates a bigger BufferedImage.The end result is a larger 72 dpi tiff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 11:50 AM To: [EMAIL PROTECTED] Subject: Antwort: Re: Antwort: Re: Antwort: Which TIFF format is used in batik? How can I get TIFF Type 1? Is there any plan to add this feature in near future? Sure. As I'm now FOP committer it should be one more FOP output format (we thought about more bitmap formats, supported by JAI/jimi, but I believe the only tiff makes sense as it supports multi-page images). That's is definitely good news. I think there is a need for other formats too. I see at my customer here that they might want to get rid of multipage TIFF in favor of one JPG-file per page. Producing one file per page might be the way to go for the non-TIFF formats (even for TIFFs that could be an option, since there are applications out there that only support single page TIFFs). just my $0.02 on the file format discussion. Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch Oleg Tkachenko [EMAIL PROTECTED] on 18.12.2002 13:52:24 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: Antwort: Re: Antwort: Which TIFF format is used in batik? How can I get TIFF Type 1? [EMAIL PROTECTED] wrote: Is the assumption correct, that this restriction is in the AWTRenderer of FOP? - I'm not sure actually. TIFFRenderer creates temporary BufferedImage when encoding with fax compression, is that your case, I mean GROPU3 and GROUP4 compression schemas? For the rest compressions it uses directly BufferedImage created by AWTRenderer. Is there any plan to add this feature in near future? Sure. As I'm now FOP committer it should be one more FOP output format (we thought about more bitmap formats, supported by JAI/jimi, but I believe the only tiff makes sense as it supports multi-page images). I was thinking of adding this, though I have not looked into it yet. Is it feasible at all with the current FOP design? Any help is greatly appreciated, feel free to modify sources. But not with the current FOP design, new one will make tiff generation much effective. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Antwort: Which TIFF format is used in batik? How can I get TI FF Type 1?
Hi Oleg, Francis, I was just now looking though the code of AWTRenderer and found the method AWTRenderer.setScaleFactor(). Invoking setScaleFactor(200) on the TIFFRenderer before rendering gives me a TIFF with higher (probably double) resolution. This is all I need. Were you guys aware of this method? Is there any problem with this? cheers Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch Oleg Tkachenko [EMAIL PROTECTED] on 18.12.2002 13:59:53 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: Antwort: Which TIFF format is used in batik? How can I get TI FF Type 1? Francis, Ronald wrote: I've looked at the code in the AWTRenderer where a BufferedImage is created to paint the page on(defaults to 72 dpi) That is addressed by the redesign under way. Out of curiosity, how can we create a high res image / graphics context ? I would be happy to tinker with the code and post any solutions if I find any , but I am not very familiar with 2D. Me too unfortunately :( Is there any java2D expert around? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Antwort: Re: Antwort: Which TIFF format is used in batik? How can I get TIFF Type 1?
Is there any plan to add this feature in near future? Sure. As I'm now FOP committer it should be one more FOP output format (we thought about more bitmap formats, supported by JAI/jimi, but I believe the only tiff makes sense as it supports multi-page images). That's is definitely good news. I think there is a need for other formats too. I see at my customer here that they might want to get rid of multipage TIFF in favor of one JPG-file per page. Producing one file per page might be the way to go for the non-TIFF formats (even for TIFFs that could be an option, since there are applications out there that only support single page TIFFs). just my $0.02 on the file format discussion. Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch Oleg Tkachenko [EMAIL PROTECTED] on 18.12.2002 13:52:24 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: Antwort: Re: Antwort: Which TIFF format is used in batik? How can I get TIFF Type 1? [EMAIL PROTECTED] wrote: Is the assumption correct, that this restriction is in the AWTRenderer of FOP? - I'm not sure actually. TIFFRenderer creates temporary BufferedImage when encoding with fax compression, is that your case, I mean GROPU3 and GROUP4 compression schemas? For the rest compressions it uses directly BufferedImage created by AWTRenderer. Is there any plan to add this feature in near future? Sure. As I'm now FOP committer it should be one more FOP output format (we thought about more bitmap formats, supported by JAI/jimi, but I believe the only tiff makes sense as it supports multi-page images). I was thinking of adding this, though I have not looked into it yet. Is it feasible at all with the current FOP design? Any help is greatly appreciated, feel free to modify sources. But not with the current FOP design, new one will make tiff generation much effective. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Which TIFF format is used in batik? How can I get TIFF Type 1?
Hi Leonid, I am using the special renderer from Oleg to produce the TIFFs. You can find it at http://www.tkachenko.com/fop/tiffrenderer.html It produces several of the formats you asked for and works nicely. The only problem I have is that I cannot change the resolution, it defaults to 72 dpi, which is not enough for my application. cheers, Reto ___ CSS Versicherung Reto Blunschi EXTERNE Rösslimattstrasse 40 CH-6002 Luzern Telefon ++41 (0)41 369 1236 Telefax ++41 (0)41 369 1212 [EMAIL PROTECTED] www.css.ch Leonid Kleiner [EMAIL PROTECTED] on 17.12.2002 11:01:20 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Which TIFF format is used in batik? How can I get TIFF Type 1? Hi, all. I try to transform XML using FOP to one of the following formats: - TIFF Type 1 - TIFF Type 2 - TIFF Type 3 - TIFF Type 4 - TIFF PackBits Which TIFF format is used in batik? How can I get one of the previously listed formats? Any ideas? Best regards, Leonid Kleiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
