Re: embedded FOP from Document to PDF
It is. Have a look at http://xml.apache.org/fop/embedding.html. This page describes how to embedd FOP into your own applications. The info on this page may already be ahead of time (reflecting changes to logging for the next release), so you may have to consult the docs directory in the distribution. The key method you need to use is Driver.render(Document). Take the sample with XSLTInputHandler as a template and switch to render(Document). I have no Problems reading the XML and the XSL-file and directly generating the PDF-output. That works fine. But in my application I'm filling the XMl-file, writing it to the harddisk and then starting the FOP-conversion. It would be nice to start the conversion directly with the org.w3c.dom.Document in memory and the XSL-File from harddisk. Does someone knows if this is possible with FOP? Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: runtime ExceptionInInitializerError: first steps
- Original Message - From: J.Pietschmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 18, 2002 7:50 PM Subject: Re: runtime ExceptionInInitializerError: first steps Uncaught exception (java.lang.ExceptionInInitializerError) SVGElementMapping.setupSVG() SVGElementMapping.addToBuilder(TreeBuilder) The exception happens in some Batik related code. Do you have Batik in the classpath? YES, it is. If so, it is the version taken from the FOP distribution? SURE!! Is this the only one? yes There could be incompatibilities. of what kind? I don't understand ... the code is simple and small I thing that something is missing ... some initialization ... any idea?? thanks Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: runtime ExceptionInInitializerError: first steps
Ok,thanks ... this is (now) clear!! :-) but why it does not work width the URI??? thanks Massimiliano - Original Message - From: Oleg Tkachenko To: [EMAIL PROTECTED] Sent: Friday, May 17, 2002 11:35 PM Subject: RE: runtime ExceptionInInitializerError: first steps Hello! InputSource class havethe only String constructor and that String is supposed to be system id (URI), for example, file name. See http://www.saxproject.org/apidoc/org/xml/sax/InputSource.htmlfor more info. If you want to create InputSource from serialized xml you need something like new InputSource(new StringReader(src)) ---Oleg Tkachenko,Multiconn International, Israel
Antw: Re: embedded FOP from Document to PDF
Hi, hey that fine, but how can I give the xsl-document to the driver? Thanks Juergen Lippold [EMAIL PROTECTED] 21.05.2002 10.34 Uhr It is. Have a look at http://xml.apache.org/fop/embedding.html. This page describes how to embedd FOP into your own applications. The info on this page may already be ahead of time (reflecting changes to logging for the next release), so you may have to consult the docs directory in the distribution. The key method you need to use is Driver.render(Document). Take the sample with XSLTInputHandler as a template and switch to render(Document). I have no Problems reading the XML and the XSL-file and directly generating the PDF-output. That works fine. But in my application I'm filling the XMl-file, writing it to the harddisk and then starting the FOP-conversion. It would be nice to start the conversion directly with the org.w3c.dom.Document in memory and the XSL-File from harddisk. Does someone knows if this is possible with FOP? Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Antw: Re: embedded FOP from Document to PDF
On Tue, 2002-05-21 at 11:15, Juergen Lippold wrote: Hi, hey that fine, but how can I give the xsl-document to the driver? Thats easy. Create your driver. Call getContentHandler(). Use this content handler to fire sax events on. Use your DOM and xsl with your favourite xml+xsl libraries to fire sax events on the content handler. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: diffs for on-the-fly image support
Hi Paul, I don't think we can apply this patch directly for a number of reasons. Although there are parts in it with value that should be put into cvs when you have finished. The patch should be done against cvs rather than what you did which seems to be in reverse anyway (I suppose this is what you are working on). It's better to avoid the various formatting changes which really confuses things. Using temp files can cause problems in certain situations. I don't see the need for an extra PDFStreamGraphics2D class. Modifying the PDFGraphics2D should suffice. An extension may work better in this situation with the development code. If I understand the problem properly. Thanks, Keiron. On Mon, 2002-05-20 at 17:43, Paul Reavis wrote: Attached are gzipped diffs for the changes I made vs. the 0.20.3 release. I'm working on patches against CVS, but am pretty busy and wanted to get something out soonest. Essentially the patch includes: - support for callback-based, on-the-fly images (URLs like onthefly:SomeImage, you have to preregister the callback named SomeImage before running the FOP transformation) - a modified PDFGraphics2D called PDFStreamGraphics2D that does not use an intermediate byte buffer, but renders direct to a PDFStream - modified PDFStream so that it caches to tempfiles on disk rather than to heap - modified the drawImage portion of PDFStreamGraphics2D so that it only creates a new xObject for the image if it has never seen that image before, otherwise it reuses the reference The combination of these things took us from render times of up to 10 minutes and hundreds of megabytes of heap to render times of less than 10 seconds and less than 64MB of heap (the default max heap size). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: runtime ExceptionInInitializerError: first steps
Hello! What do you mean? Give us some more info, what doesn't work and which URI are you using. -- Oleg Tkachenko Multiconn International, Israel Massimiliano Cuccia wrote: Ok, thanks ... this is (now) clear!! :-) but why it does not work width the URI??? thanks Massimiliano - Original Message - *From:* Oleg Tkachenko mailto:[EMAIL PROTECTED] *To:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Sent:* Friday, May 17, 2002 11:35 PM *Subject:* RE: runtime ExceptionInInitializerError: first steps Hello! InputSource class have the only String constructor and that String is supposed to be system id (URI), for example, file name. See http://www.saxproject.org/apidoc/org/xml/sax/InputSource.html for more info. If you want to create InputSource from serialized xml you need something like new InputSource(new StringReader(src)) --- Oleg Tkachenko, Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Font Metrics AWT
At 05:15 PM 5/19/02, you wrote: There may be still an issue about the actual vertical position of an overline. Yes, I expect so; since java.awt.Font contains no specification for where to put the underline (as I pointed out in my code comments.) Unfortunately my word processor doesn't know about overlines, so I can't even suggest a precedent. btw: On my wp, the top of a superscript appears to lie 1 or 2 graphics units above the uppercase ascender; I guess I'd try putting the overline a hair above that. And there are sporadic hiccups with the inline space text decorations which probably are a result of poor rounding. I haven't found out yet. I don't doubt that - you might notice several places in AwtRenderer (marked aml/rlc) where we tweaked the integer arithmetic slightly to avoid such hiccups. On the larger issue of printing, I've made no progress yet; am hoping to get to it in a day or two; btw: I noticed that in another post Peter is testing expectations for 0.20.4 -- at the very least, when that starts getting real, it will light a fire under me re printing. ;-) Thanks for your help. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
column width in percent
Hello, in my xml-document I'm using a value for the column-width in a table. But this is a fixed value. Is it possible to work with values in percent of the table-width? There is one solution with the right direction to use a proportional-column-width, but this doesn't work with JFOR to create RTF-Files. Does someone knows an other solution? Thanks Juergen Lippold - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Font Metrics AWT
At 05:15 PM 5/19/02, you wrote: There may be still an issue about the actual vertical position of an overline. Yes, I expect so; since java.awt.Font contains no specification for where to put the underline (as I pointed out in my code comments.) Unfortunately my word processor doesn't know about overlines, so I can't even suggest a precedent. Have you seen the methods getStrikethroughOffset() and getUnderlineOffset() on LineMetrics? I've used the StrikethroughOffset but left in your method of determining the underline position. btw: On my wp, the top of a superscript appears to lie 1 or 2 graphics units above the uppercase ascender; I guess I'd try putting the overline a hair above that. How would you express that in Java? getAscent() returns values that result overlines to be printed over the previous line's underline position. That's why I took 0.8 * getAscent(). And there are sporadic hiccups with the inline space text decorations which probably are a result of poor rounding. I haven't found out yet. I don't doubt that - you might notice several places in AwtRenderer (marked aml/rlc) where we tweaked the integer arithmetic slightly to avoid such hiccups. On the larger issue of printing, I've made no progress yet; am hoping to get to it in a day or two; btw: I noticed that in another post Peter is testing expectations for 0.20.4 -- at the very least, when that starts getting real, it will light a fire under me re printing. ;-) Thanks for your help. You're welcome. Often too little time, but working on it... Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: embedded FOP from Document to PDF
Juergen Lippold [EMAIL PROTECTED] It would be nice to start the conversion directly with the org.w3c.dom.Document in memory and the XSL-File from harddisk. Look here for a code sample. You can pass whatever Source subclass you want to the transformer object, including a DOMSource. http://marc.theaimsgroup.com/?l=fop-userm=102011358525336w=2 J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/xml-docs/fop embedding.xml
keiron 02/05/21 05:09:04 Modified:docs/xml-docs/fop embedding.xml Log: added a bit of info about using xalan Revision ChangesPath 1.19 +15 -0 xml-fop/docs/xml-docs/fop/embedding.xml Index: embedding.xml === RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/embedding.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- embedding.xml 19 May 2002 16:34:07 - 1.18 +++ embedding.xml 21 May 2002 12:09:04 - 1.19 @@ -130,6 +130,21 @@ /s2 s2 title=Hints +s3 title=XML/XSL/DOM Inputs + p +You may want to supply you input to FOP from different data sources. +For example you may have a DOM and XSL stylesheet or you may want to +set variables in the stylesheet. The page here: +jump href=http://xml.apache.org/xalan-j/usagepatterns.html; +http://xml.apache.org/xalan-j/usagepatterns.html/jump describes +how you can do these things. + /p + p +You can use the content handler from the driver to create a SAXResult. +The transformer then can fire SAX events on the content handler which +will in turn create the rendered output. + /p +/s3 s3 title=Object reuse p If FOP is going to be used multiple times within your application - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TIFFRenderer
Hello! I'm just wondering if fop developers are interested in one more output format such as TIFF ? I beleive it's very easy to produce tiff having AWTrenderer. The only things one have to do is to extend AWTRenderer, to pick up generated BufferedImages page by page and to encode them by tiff encoder. Actually I developed such TIFFRenderer a couple weeks ago in order to get fax-suitable output from a fop-running system I'm working on now (see http://www.tkachenko.com/fop/tiffrenderer.html). That stuff was downloaded couple of dozens times by the people, so I believe some kind of interest among fop users does exist. btw, size of Batik-dependent version of TIFFRenderer is only 56 kB. Well, I do like fop and I'd be glad to contribute that humble piece of code to the project. -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: runtime ExceptionInInitializerError: first steps
Sorry for missing informations ... now I will try to be more unambiguous this is my Java code 1Driver driver = new Driver( new InputSource(new java.io.FileInputStream(C:\\character.fo)), new FileOutputStream(C:\\prova.pdf)); 2driver.setRenderer(Driver.RENDER_PDF); 3driver.run(); PS: character.fo is the same file of the examples in the distribution the problems comes in the first row (the call to Driver constructor) Uncaught exception is java.lang.ExceptionInInitializerError I'm using VisualAge and all the jars in the lib folder of fop were included (and no other) fop version 0.20.3 are these information enough??? I Hope!! :-) thanks Massimiliano Cuccia - Original Message - From: Oleg Tkachenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 21, 2002 12:56 PM Subject: Re: runtime ExceptionInInitializerError: first steps Hello! What do you mean? Give us some more info, what doesn't work and which URI are you using. -- Oleg Tkachenko Multiconn International, Israel Massimiliano Cuccia wrote: Ok, thanks ... this is (now) clear!! :-) but why it does not work width the URI??? thanks Massimiliano - Original Message - *From:* Oleg Tkachenko mailto:[EMAIL PROTECTED] *To:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Sent:* Friday, May 17, 2002 11:35 PM *Subject:* RE: runtime ExceptionInInitializerError: first steps Hello! InputSource class have the only String constructor and that String is supposed to be system id (URI), for example, file name. See http://www.saxproject.org/apidoc/org/xml/sax/InputSource.html for more info. If you want to create InputSource from serialized xml you need something like new InputSource(new StringReader(src)) --- Oleg Tkachenko, Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: runtime ExceptionInInitializerError: first steps
Massimiliano Cuccia [EMAIL PROTECTED] wrote:
Uncaught exception (java.lang.ExceptionInInitializerError)
SVGElementMapping.setupSVG()
SVGElementMapping.addToBuilder(TreeBuilder)
...
Do you have Batik in the classpath?
YES, it is.
If so, it is the version taken from the FOP distribution?
SURE!!
...
I don't understand ... the code is simple and small
I thing that something is missing ... some initialization ...
any idea??
Ok. From the Java doc:
java.lang.ExceptionInInitializerError: Signals that an unexpected
exception has occurred in a static initializer.
You stacktrace indicates this happens in
org.apache.fop.svg.SVGElementMapping.setupSVG()
The code is (comments trimmed)
private static synchronized void setupSVG() {
if(foObjs == null) {
XMLResourceDescriptor.setXMLParserClassName(Driver.getParserClassName());
foObjs = new HashMap();
foObjs.put(svg, SVGElement.maker());
foObjs.put(rect, SVGObj.maker(rect));
... lots of foObjs.put ...
}
}
It uses the class org.apache.batik.util.XMLResourceDescriptor,
which happens to have a static initializer:
static {
bundle = ResourceBundle.getBundle(RESOURCES, Locale.getDefault());
}
This could cause the above mentioned exception, the other stuff
doesn't seem to do this.
Ergo: something went wrong during loading of the ressource.
What's going wrong is hard to guess. Usually, it's a deployment
problem. However, you seem to run an unusual JVM. Locale.getDefault()
could return an unusual value, perhaps null. If this is the case,
you're hosed, complain to the vendor of your JVM. I'm not familiar
enough with the failure modes of RessourceBundle.getBundle() to
hazard a guess what else could have happened. If you can run the
stuff in a debugger, you might be able to deduce it yourself.
Otherwise, I'd recommend downloading the source for Batik 1.1
(actually which *is* the version of Batik shipped with 0.20.3?)
insert some printlns for debugging in the code and see what
happens.
Batik seems to be somewhat overzealous in early loading all kinds
of stuff all over the place. Someone out there with enough positive
standing with the Batik people to tell them to do something about
this?
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: runtime ExceptionInInitializerError: first steps
Massimiliano Cuccia wrote: Sorry for missing informations ... now I will try to be more unambiguous this is my Java code 1Driver driver = new Driver( new InputSource(new java.io.FileInputStream(C:\\character.fo)), new FileOutputStream(C:\\prova.pdf)); 2driver.setRenderer(Driver.RENDER_PDF); 3driver.run(); PS: character.fo is the same file of the examples in the distribution the problems comes in the first row (the call to Driver constructor) Uncaught exception is java.lang.ExceptionInInitializerError I'm using VisualAge and all the jars in the lib folder of fop were included (and no other) H, that works like a charm for me in WebSphere App Developer 4. As Joerg poined out that is a problem with resource loading. Did you import resources from batik.jar along with classes ? -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TIFFRenderer
I think you're the second one who announced such a TIFF renderer in a short period of time. Personally, I would like to see a bitmap renderer in FOP even though I don't have an immediate need myself. I'd like to offer my sponsorship. If no other committer wants to take it, I'm going to look at the two submissions as soon as possible and see how best to integrate one (or a combination of both) into FOP. If someone is against that move, please speak up. Here's a link to the other post: http://marc.theaimsgroup.com/?l=fop-userm=101965756701667w=2 I'm just wondering if fop developers are interested in one more output format such as TIFF ? I beleive it's very easy to produce tiff having AWTrenderer. The only things one have to do is to extend AWTRenderer, to pick up generated BufferedImages page by page and to encode them by tiff encoder. Actually I developed such TIFFRenderer a couple weeks ago in order to get fax-suitable output from a fop-running system I'm working on now (see http://www.tkachenko.com/fop/tiffrenderer.html). That stuff was downloaded couple of dozens times by the people, so I believe some kind of interest among fop users does exist. btw, size of Batik-dependent version of TIFFRenderer is only 56 kB. Well, I do like fop and I'd be glad to contribute that humble piece of code to the project. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: diffs for on-the-fly image support
Keiron Liddle ([EMAIL PROTECTED]) wrote To FOP on Tue, May 21, 2002 at 11:47:19AM +0200: I don't think we can apply this patch directly for a number of reasons. Although there are parts in it with value that should be put into cvs when you have finished. I figured as much. Mainly I wanted to get an example out for anyone to look at; the code I wrote is hardly high quality and I would rather do a more careful modification against CVS. Sorry about the formatting changes - emacs redid the indentation according to my weird standard and I was just too lazy to fix it back. Is there an apache or fop standard style or style canonicalizer? I know some projects use a tool to fix style to a standard. Using temp files can cause problems in certain situations. Agreed. Here are some possible solutions: 1) a boolean switch (in the api or system properties) 2) intelligence in the buffer itself, where it uses a tempfile after a certain size is reached 3) better overall architecture where buffers are immediately flushed to output rather than remaining in memory (3) seems best and is in line with the next-gen design documents I see on the fop site, but I don't know how far along y'all are with that. I have to use a similar architecture for my map translation software; GIS systems are hundreds of megabytes and scalability requires a flat memory usage model. All my buffers are strictly memory-limited. (1) is easy enough (2) would be fine but probably has pitfalls; the problem is that there are a _lot_ of these buffers and PDFStreams running around, and therefore it's a global problem - I counted dozens for one plot, 24MB total. I was planning on using a switch for the cvs patch, unless y'all have (3) figured out. I don't see the need for an extra PDFStreamGraphics2D class. Modifying the PDFGraphics2D should suffice. Agreed. I just didn't want to break the existing (the current patch uses PDFStreamGraphics2D just for my case). An extension may work better in this situation with the development code. If I understand the problem properly. ?? An extension to the code, or a file extension for the URL? I'm not sure what you mean. As far as my plans for the other features: I figure the drawImage hack is a no-brainer. It's just the right thing to do in that instance. The additional memory usage should be no big deal (it's a hash of image pointer to integer ID). I'll just modify PDFGraphics2D directly to use the underlying PDFStream. I think this is fine for all cases. Should I break it up into several patches? - tempfile buffering - drawImage hack - PDFGraphics2D hack - on-the-fly images -- Paul Reavis [EMAIL PROTECTED] Design Lead Partner Software, Inc.http://www.partnersoft.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TIFFRenderer
We would be real interested in TIFF rendering from FOP since our application includes a fax component. My only concern is the use of the AWTRenderer. Whenever we use the AWTRenderer the output (on screen and print) is not as crisp and sharp as the PDF version. The spacing of letters and words is a major issue with the AWTRenderer (as was mentioned in a previous thread). If however a TIFF renderer could be produced that does NOT have these issues we would be real happy to use it. Jim Urban - [EMAIL PROTECTED] Park City Solutions Inc. Clinical Connectivity Suite Product Manager Suite 295 500 Park Blvd. Itasca, IL 60143 Voice: (630) 250-3045 x106 Fax: (630) 250-3046 CONFIDENTIALITY NOTICE This message and any included attachments are from Park City Solutions Inc. and are intended only for the entity to which it is addressed. The contained information is confidential and privileged material. If you are not the intended recipient, you are hereby notified that any use, dissemination, or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error please notify the sender of the delivery error by e-mail or call Park City Solutions Inc. corporate offices at (435) 654-0621 -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 8:47 AM To: [EMAIL PROTECTED] Subject: Re: TIFFRenderer I think you're the second one who announced such a TIFF renderer in a short period of time. Personally, I would like to see a bitmap renderer in FOP even though I don't have an immediate need myself. I'd like to offer my sponsorship. If no other committer wants to take it, I'm going to look at the two submissions as soon as possible and see how best to integrate one (or a combination of both) into FOP. If someone is against that move, please speak up. Here's a link to the other post: http://marc.theaimsgroup.com/?l=fop-userm=101965756701667w=2 I'm just wondering if fop developers are interested in one more output format such as TIFF ? I beleive it's very easy to produce tiff having AWTrenderer. The only things one have to do is to extend AWTRenderer, to pick up generated BufferedImages page by page and to encode them by tiff encoder. Actually I developed such TIFFRenderer a couple weeks ago in order to get fax-suitable output from a fop-running system I'm working on now (see http://www.tkachenko.com/fop/tiffrenderer.html). That stuff was downloaded couple of dozens times by the people, so I believe some kind of interest among fop users does exist. btw, size of Batik-dependent version of TIFFRenderer is only 56 kB. Well, I do like fop and I'd be glad to contribute that humble piece of code to the project. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TIFFRenderer
Ralph LaChance is working on it. Check the current CVS. Ralph's diff should have improved some of this. But it seems like AWT still has its pitfalls. Implementing a full bitmap renderer without the use of AWT would be a major pile of work, I think. But you can always try to use GhostScript to convert a PDF/PS to TIFF which should have about the same qualities as the PDF. Which method are you using right now? We would be real interested in TIFF rendering from FOP since our application includes a fax component. My only concern is the use of the AWTRenderer. Whenever we use the AWTRenderer the output (on screen and print) is not as crisp and sharp as the PDF version. The spacing of letters and words is a major issue with the AWTRenderer (as was mentioned in a previous thread). If however a TIFF renderer could be produced that does NOT have these issues we would be real happy to use it. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TIFFRenderer
Jim Urban wrote: We would be real interested in TIFF rendering from FOP since our application includes a fax component. My only concern is the use of the AWTRenderer. Whenever we use the AWTRenderer the output (on screen and print) is not as crisp and sharp as the PDF version. The spacing of letters and words is a major issue with the AWTRenderer (as was mentioned in a previous thread). Yes, that's known AWTRenderer's problem, but proposed TIFFRenderer being derived from AWTRenderer at least doesn't add any new problems, so we still have only one :) -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: runtime ExceptionInInitializerError: first steps
GREAT!!! Did you import resources from batik.jar along with classes ? ... very very well!! :-) I had not checked the item in import phase!! sorry ... Now there is another problem import of Xerces 1.2.3 is impossible ... VisualAge starts the import than close the window without any message and the import isn't completed ... I will try something!!! thanks very very much Mr. Oleg Massimiliano Cuccia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TIFFRenderer
Jeremias Maerki wrote: Implementing a full bitmap renderer without the use of AWT would be a major pile of work, I think. But you can always try to use GhostScript to convert a PDF/PS to TIFF which should have about the same qualities as the PDF. Which method are you using right now? You mean GhostScript + ImageMagick probably, I have tried that conversion using JMagick (java clone of ImageMagick) and it worked for me, but I was not satisfied with a performance, producing pdf and converting it to tiff using 2 native libraries looks worse to me than producing tiff at once. But having quality as high priority that way is probably more suitable. -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: diffs for on-the-fly image support
Inserting JPEG into a PDF file is a simple file copy - given the URI, bits/pixel and color model. The latter are coded within JPEG files. PDF stores the image once and allows multiple references to it. Is programmed caching superior to the caching of the file system? From PDF view, memory = (JPEG file size + PDF encoded image) is needed at most during the lifetime of an output page in memory. Why isn't that so: device independence, AWT compatibility? Similar considerations apply to GIF, TIFF and Fax formats. Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: diffs for on-the-fly image support
J.U. Anderegg ([EMAIL PROTECTED]) wrote To [EMAIL PROTECTED] on Tue, May 21, 2002 at 05:31:53PM +0200: Inserting JPEG into a PDF file is a simple file copy - given the URI, bits/pixel and color model. The latter are coded within JPEG files. PDF stores the image once and allows multiple references to it. Is programmed caching superior to the caching of the file system? From PDF view, memory = (JPEG file size + PDF encoded image) is needed at most during the lifetime of an output page in memory. Why isn't that so: device independence, AWT compatibility? Similar considerations apply to GIF, TIFF and Fax formats. I'm not sure exactly what you're referring to. My hacks primarily address the issue I had of rendering large vector plots of maps to pdf. The images that are used do not already exist as jpegs or any other form; they are an amalgam of vector routines and raster icons, and the icons are rotated in memory for speed. Generating this mess to svg, then into pdf was very time consuming and memory-intensive. So I switched to rendering directly into the pdf using the existing PDFGraphics2D, which allowed me to use the exact same routines that I use to render to the AWT window. Once I got that working I ran into memory problems, because the current design of the PDF generation code keeps a lot of things in memory as buffers, I believe because it doesn't know exactly where in the pdf file the data will be placed at final output - it's juggling layout etc. So, this is not a case of file buffering, but of storing chunks of rendered pdf for later use. My hack puts them in tempfiles rather than in in-memory buffers. This is obviously slower but more scalable. As for programmed caching being superior to file system caching, well, that's another debate and really depends on the operating system. For windows systems, especially over SMB networks, the answer is generally yes, because they are very unaggressive about disk caching and they flush a lot. Linux on the other hand is very aggressive (on my 754MB development machine, 320MB is being used for disk cache), and flushes less often. At least in my experience... in one case I got a 20x speed increase with a decent cacheing framework; I finally noticed that machines with crappy disk drive subsystems were far slower than those with good ones even at the same memory and cpu speed. -- Paul Reavis [EMAIL PROTECTED] Design Lead Partner Software, Inc.http://www.partnersoft.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9292] New: - FOP rejects a property value of inherit as an unknown value
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9292. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9292 FOP rejects a property value of inherit as an unknown value Summary: FOP rejects a property value of inherit as an unknown value Product: Fop Version: 0.20.3 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] FOP rejects a property value of inherit as an unknown value for the following inheritable properties: font-weight font-style position hyphenate white-space-collapse wrap-option text-align text-align-last For the font properties, FOP simple passes the string inherit causing an error unknown font sans-serif,italic,inherit Code: ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:src=UBSXMLSrc fo:layout-master-set fo:simple-page-master master-name=seiten page-height=29.7cm page-width=21cm margin-top=2cm margin-bottom=2cm margin-left=1.8cm margin-right=2.0cm fo:region-body column-count=3 column-gap=2mm margin-top=1.0cm margin-bottom=2.0cm / fo:region-before region-name=s2ff-before extent=2.0cm / fo:region-after region-name=s2ff-after extent=2.0cm / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=seiten initial-page-number=1 fo:static-content flow-name=s2ff-after fo:block font-size=11pt font-family=sans-serif line-height=13pt text-align=center padding-top=12mm fo:page-number //fo:page-number-citation ref-id=IDAWEF4 / /fo:block /fo:static-content fo:flow flow-name=xsl-region-body font-weight=bold font-style=italic position=relative break-after=page hyphenate=false white-space-collapse=true wrap-option=wrap span=all border-style=solid border-color=red border-width=1px text-align=end text-align-last=start fo:block span=all This flow has the following properties. These properties should be inherited by all blocks on this page that do not specifically override the settings font-weight=bold font-style=italic position=relative break-after=page hyphenate=false white-space-collapse=true wrap-option=wrap span=all border-style=solid border-color=red border-width=1px text-align=start text-align-last=end /fo:block fo:block font-weight=inheritBlock with font-weight of =inherit/fo:block fo:block font-style=inheritBlock with font-style of =inherit/fo:block fo:block position=inheritBlock with position of =inherit/fo:block fo:block break-before=inheritBlock with break-before of =inherit/fo:block fo:block hyphenate=inheritBlock with hyphenate of =inherit/fo:block fo:block white-space-collapse=inheritBlock with white-space-collapse of =inherit/fo:block fo:block wrap-option=inheritBlock with wrap-option of =inherit/fo:block fo:block span=inheritBlock with span of =inherit/fo:block fo:block border-style=inherit border-color=inherit border-width=inheritBlock with border-style of =inherit border-color of =inherit border-width of =inherit/fo:block fo:block text-align=inheritBlock with text-align of =inherit/fo:block fo:block text-align-last=inheritBlock with text-align-last of =inherit/fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Next maintenace release
Ok, as a lot of people want a date for the next release I propose 1st of june as target date for the release candidate for 0.20.4 What do you think? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build changes
Peter B. West schrieb: Ladies and gentlemen, boys and girls, What's the state of play now with the changes to the build system? Has the elimination of Xalan1 been completed? Who's doing what there? Xalan1 has been removed. Upgrade of xerces/xalan hasn't been done yet (but I'll hopefully get it done this week) I think Joerg wants to make the buildprocess work with any XSLT engine. I am planning to throw a branch off HEAD to tinker with at least the versioning information for the build. I would like to try that before 0.20.4, if possible. What's the expectation with 0.20.4? See my other mail ;-) Peter Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TIFFRenderer
Are the AWTRenderer spacing fixes in a release version of FOP? If so, which version? Thanks, Jim Urban - [EMAIL PROTECTED] Park City Solutions Inc. Clinical Connectivity Suite Product Manager Suite 295 500 Park Blvd. Itasca, IL 60143 Voice: (630) 250-3045 x106 Fax: (630) 250-3046 CONFIDENTIALITY NOTICE This message and any included attachments are from Park City Solutions Inc. and are intended only for the entity to which it is addressed. The contained information is confidential and privileged material. If you are not the intended recipient, you are hereby notified that any use, dissemination, or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error please notify the sender of the delivery error by e-mail or call Park City Solutions Inc. corporate offices at (435) 654-0621 -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 3:11 PM To: [EMAIL PROTECTED] Subject: Re: TIFFRenderer At 10:11 AM 5/21/02, you wrote: Ralph LaChance is working on it. Check the current CVS. Ralph's diff should have improved some of this. But it seems like AWT still has its pitfalls. Implementing a full bitmap renderer without the use of AWT would be a major pile of work, I think. But you can always try to use GhostScript to convert a PDF/PS to TIFF which should have about the same qualities as the PDF. Which method are you using right now? Actually, I (biased!) think the present awt renderer is quite good; the character spacings problems within words that existed in previous versions is fixed, and text decorations seem to work correctly. As Jeremias pointed out, I am chasing a new problem - but that one doesn't really bear on awt itself, but shows up only when the awt renderer is used to print. (The problem appears if fop is run w/ -print option or if the print command is invoked on the -awt display dialog.) Offhand, I do not expect the printing problem to show up if the awt renderer were used as the basis for a tiff renderer. We believe the printing problem stems from a java bug around fonts - the character rasterizer seems to be ending up with text strings being improperly sized when it is drawing into a graphics context created by a PrinterJob. There are several related bugs in the bug parade on this matter. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: column width in percent
Juergen Lippold wrote:
in my xml-document I'm using a value for the column-width in a table.
But this is a fixed value. Is it possible to work with values in percent of the
table-width?
Not implemented yet.
There is one solution with the right direction to use a proportional-column-width,
but this doesn't work with JFOR to create RTF-Files. Does someone knows an other
solution?
No. Bad luck.
You can try to code some advanced magic into you XSLT so that you
can use a parameter to switch between percents and
proportional-column-width.
Something like
xsl:variable name=total select=column/@width/
xsl:for-each select=column
xsl:choose
xsl:when test=$jfor
fo:table-column column-width={@width}%/
/xsl:when
xsl:otherwise
fo:table-column column-width=proportional-column-width({@width/$total})/
/xsl:otherwise
xsl:choose
/xsl:for-each
Or you can create a FO for JFOR and use a the usual identity
transformation with small changes to build a FO with p-c-w()
for FOP PDF from it.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Next maintenace release
Christian Geisert wrote: Ok, as a lot of people want a date for the next release I propose 1st of june as target date for the release candidate for 0.20.4 What do you think? Christian, OK by me. Anyone have any specifics he or she wants to get into the release? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Next maintenace release
Yeah, that's OK. I'm not sure if I can get the bitmap renderer in this weekend. I hope so, but I can't promise. as a lot of people want a date for the next release I propose 1st of june as target date for the release candidate for 0.20.4 What do you think? Christian, OK by me. Anyone have any specifics he or she wants to get into the release? Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TIFFRenderer
Are the AWTRenderer spacing fixes in a release version of FOP? If so, which version? In the next: 0.20.4. It's already fixed in CVS. Christian has announced that we can expect a candidate release around June 1st. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
basedir fix for fop 0.20.4
Hi there, as you are discussing 0.20.4, I have a fix for bug 7608 (The property baseDir is not used when custom fonts are specified.) The fix works ok for me, and some requests that I got on this haven't complained so far. Still, I'm not altogether comfortable with the fix, as I did it with only some peephole knowledge of the source, and with little time. If someone with a more thorough understanding of FOP configuration wants to have a look at it, I would be happy to submit the code. Arnd Beissner -- Cappelino Informationstechnologie GmbH Arnd Beißner Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
