Re: svg not working on linux
In that case you can only try a different version of the Sun JVM or try alternative approaches for headless servers: http://xmlgraphics.apache.org/fop/0.95/graphics.html#batik (Xvfb or PJA) Maybe someone else has other ideas. I don't. On 14.04.2008 01:09:30 Roland Neilands wrote: > j2sdk1.4.2_06 > > > Jeremias Maerki wrote: > > Given that it works on some machines but not on others (especially a > > Linux server) could indicate not a problem in FOP but with the JVM. > > Please make sure you use a Sun JVM to avoid any problems coming from not > > fully implemented or buggy class libraries like GNU Classpath (used by > > GCJ, Kaffee etc.). > > > > On 10.04.2008 03:46:28 Roland Neilands wrote: > > > >> Hello foppers, > >> > >> We've just put a watermark on our documents & it works fine on two PC's > >> using FOP 0.20.5, 0.93 & 0.94. > >> > >> It's completely ignored on two linux servers (tested with same 3 fop > >> versions). The rest of the document renders fine, just no watermark, > >> except for 20.5 which fails with an erroneous error about an id already > >> existing (yes it only happens with below svg included). > >> > >> >> position="absolute"> > >> > >> http://www.w3.org/2000/svg";> > >> > >> > >> > >> >> select="substring-before(Header/Amend_Confirm,':')"/> > >> > >> > >> > >> > >> > >> > >> > >> We've tried changing font, colour & opacity & set the xslt xml > >> declaration to standalone. The server already has the headless=true > >> option on. > >> > >> Can anyone see any problems with this? Otherwise it's gif time. > >> > >> Another interesting note is that the svg overlays the region-body text, > >> but not the static-content stuff. This is annoying, hence the no-fill. > >> > >> -- > >> Regards, > >> Roland > >> > > > > > > Jeremias Maerki Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including an image as a page
Please take a look at: http://xmlgraphics.apache.org/fop/0.95/extensions.html#external-document Of course, you can create the same effect by setting up the page-master accordingly and using line-height="0" to avoid half-leading effects. The above extension is simpler but renders your XSL-FO incompatible with other FO implementations. On 13.04.2008 22:40:17 John Brown wrote: > > > Hello all, > > Is it possible to include an image as a page? > > That is, if I have an image that is 8.5in X 11in, and set my > letter-sized page borders to 0 so that the printable area is 8.5in X 11in, > can I add the image to a blank page without cropping or scaling, > or convert the image into a page by itself? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svg not working on linux
j2sdk1.4.2_06 Jeremias Maerki wrote: Given that it works on some machines but not on others (especially a Linux server) could indicate not a problem in FOP but with the JVM. Please make sure you use a Sun JVM to avoid any problems coming from not fully implemented or buggy class libraries like GNU Classpath (used by GCJ, Kaffee etc.). On 10.04.2008 03:46:28 Roland Neilands wrote: Hello foppers, We've just put a watermark on our documents & it works fine on two PC's using FOP 0.20.5, 0.93 & 0.94. It's completely ignored on two linux servers (tested with same 3 fop versions). The rest of the document renders fine, just no watermark, except for 20.5 which fails with an erroneous error about an id already existing (yes it only happens with below svg included). position="absolute"> http://www.w3.org/2000/svg";> select="substring-before(Header/Amend_Confirm,':')"/> We've tried changing font, colour & opacity & set the xslt xml declaration to standalone. The server already has the headless=true option on. Can anyone see any problems with this? Otherwise it's gif time. Another interesting note is that the svg overlays the region-body text, but not the static-content stuff. This is annoying, hence the no-fill. -- Regards, Roland Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Including an image as a page
Hello all, Is it possible to include an image as a page? That is, if I have an image that is 8.5in X 11in, and set my letter-sized page borders to 0 so that the printable area is 8.5in X 11in, can I add the image to a blank page without cropping or scaling, or convert the image into a page by itself? _ Get in touch in an instant. Get Windows Live Messenger now. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: images in pdf file
Wrt to the imagepreloader not found, you might want to check http://xmlgraphics.apache.org/fop/0.95/graphics.html To summarize, you will need JAI Image I/O Tools for bmp to be supported as an input format Hth, Peter On 13 Apr 2008, at 00:07, morten wrote: hi I am trying to do a basic docbook -> xls-fo -> pdf It is a basic docbook book written in conglomerate on my newly installed debian system. I use the latest fop-095beta. I have tried to include an image, but it does not show up in the pdf. What I do: - use conglomerate to create a small docbook called mbndocbooktest.xml - generate the xls-fo : I use the style sheet included in debian to do the conversion. $ xsltproc /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl mbndocbooktest.xml > mbndocbooktest.fo.xml - convert using fop $ ../../download/fop/fop-0.95beta/fop mbndocbooktest.fo.xml mbndocbooktest.pdf Selected output is shown at the end. I also have an issue with draft.png, but I have read that it is a question of status="draft" or something to that effect. The interesting part is that the error related to this image is "Background image not available". This makes sense since the draft.png is unavailable. My error is "No ImagePreloader found". I have tried to google it, and search the archive but apparently I am looking in the wrong place. Any suggestions? cheers Morten Selected texts from the process. --- docbook xml extract --- Hello, world This is my first DocBook file. lkjlkjlkj --- xml-fo extract --- --- Fop error extract --- 12-Apr-08 11:35:47 org.apache.fop.fo.properties.CommonBorderPaddingBackground SEVERE: Background image not available: http://docbook.sourceforge.net/release/images/draft.png 12-Apr-08 11:35:48 org.apache.fop.fo.flow.ExternalGraphic bind SEVERE: Image not available: No ImagePreloader found for file:///home/morten/Devel/FS/SomeImage.bmp - 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]
Re: Fop 0.95beta - svg tif images
Pfff...sorry for the noise.
I'll double check my measurements on MacOS and will also try to
measure on Debian (where the app is in production). I can live with
the slowdown on Mac and so hopefully it does not show up on Debian
Thanks again!
Peter
On 13 Apr 2008, at 11:19, Jeremias Maerki wrote:
That's why I provided two different measurements for the 0.95 branch:
once with JAI's codec and once with Commons' TIFF codec ("internal
TIFF
codec") which is enabled by my fix from Friday. You can see that the
internal TIFF codec adds about 0.4 seconds in my environment
compared to
the JAI codec.
On 13.04.2008 10:38:27 Peter Coppens wrote:
Thanks Jeremiasas always, very thorough work/analysis.
Is it correct you always used JAI TIFF codec in your measurements and
never the xmlgraphics fix you added on Friday. The one that supports
tiff without jai at all?
If so, any chance at all you could measure the performance of that
fix/
patch on your xp box as well?
Thanks,
Peter
On 13 Apr 2008, at 10:02, Jeremias Maerki wrote:
Peter sent me one of his large TIFF images to test with. Thanks,
Peter.
I used his FO snippet he posted at the beginning of the thread so
the
firgures below are including Batik into the picture.
The TIFF file: RGB, LZW compression, 1327x3682 pixels, 2.73MB
I couldn't see a factor 6 increase of time necessary to process the
picture on my Windows XP SP2 except when run inside my profiler but
that's due to method instrumentation overhead. The normal runtime
effect
was far smaller. As you can see I didn't experience slower
performance
with FOP Trunk/0.95beta compared to 0.94. Here's what I measured
(please
note that the figures below always refer to the server VM with
parallel
GC enabled, JVM startup and class loading is included in the times):
FOP 0.94 (Commons' TIFF codec)
Java 1.4.2: 4.0 sec
Java 1.5.0: 3.6 sec
Java 6: 3.3 sec
Trunk (comparable to 0.95beta, JAI TIFF codec)
Java 1.4.2: 2.9 sec
Java 1.5.0: 2.9 sec
Java 1.6: 2.6 sec
When profiled with my YourKit profiler I found two hotspots which
are
now fixed:
http://svn.apache.org/viewvc?rev=647537&view=rev
http://svn.apache.org/viewvc?rev=647536&view=rev
The latter hotspot in Commons is only triggered when my new TIFF
image
loader is used.
0.95 Branch (including my performance fixes, JAI TIFF codec):
Java 1.4.2: 2.2 sec
Java 1.5.0: 2.0 sec
Java 6.0: 1.9 sec
0.95 Branch (including my performance fixes, internal TIFF codec):
Java 1.4.2: 2.7 sec
Java 1.5.0: 2.4 sec
Java 6.0: 2.3 sec
Just as an experiment I've converted the TIFF image to JPEG with
relatively low compression so there are no serious artifacts. The
resulting JPEG image is 425KB. If performance is important and the
images are suitable (fotos), JPEG can be an option since the images
don't have to be decoded for PDF production. Here's the result:
0.95 Branch (including my performance fixes):
Java 6.0: 1.1 sec
On 12.04.2008 11:37:01 Jeremias Maerki wrote:
If Peter sends me his test TIFF I'll profile the problem. A
factor 6
increase is certainly not to be expected.
Jeremias Maerki
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]
Re: Fop 0.95beta - svg tif images
That's why I provided two different measurements for the 0.95 branch:
once with JAI's codec and once with Commons' TIFF codec ("internal TIFF
codec") which is enabled by my fix from Friday. You can see that the
internal TIFF codec adds about 0.4 seconds in my environment compared to
the JAI codec.
On 13.04.2008 10:38:27 Peter Coppens wrote:
> Thanks Jeremiasas always, very thorough work/analysis.
>
> Is it correct you always used JAI TIFF codec in your measurements and
> never the xmlgraphics fix you added on Friday. The one that supports
> tiff without jai at all?
>
> If so, any chance at all you could measure the performance of that fix/
> patch on your xp box as well?
>
> Thanks,
>
> Peter
>
>
> On 13 Apr 2008, at 10:02, Jeremias Maerki wrote:
> > Peter sent me one of his large TIFF images to test with. Thanks,
> > Peter.
> > I used his FO snippet he posted at the beginning of the thread so the
> > firgures below are including Batik into the picture.
> >
> > The TIFF file: RGB, LZW compression, 1327x3682 pixels, 2.73MB
> >
> > I couldn't see a factor 6 increase of time necessary to process the
> > picture on my Windows XP SP2 except when run inside my profiler but
> > that's due to method instrumentation overhead. The normal runtime
> > effect
> > was far smaller. As you can see I didn't experience slower performance
> > with FOP Trunk/0.95beta compared to 0.94. Here's what I measured
> > (please
> > note that the figures below always refer to the server VM with
> > parallel
> > GC enabled, JVM startup and class loading is included in the times):
> >
> > FOP 0.94 (Commons' TIFF codec)
> >
> > Java 1.4.2: 4.0 sec
> > Java 1.5.0: 3.6 sec
> > Java 6: 3.3 sec
> >
> > Trunk (comparable to 0.95beta, JAI TIFF codec)
> >
> > Java 1.4.2: 2.9 sec
> > Java 1.5.0: 2.9 sec
> > Java 1.6: 2.6 sec
> >
> > When profiled with my YourKit profiler I found two hotspots which are
> > now fixed:
> > http://svn.apache.org/viewvc?rev=647537&view=rev
> > http://svn.apache.org/viewvc?rev=647536&view=rev
> >
> > The latter hotspot in Commons is only triggered when my new TIFF image
> > loader is used.
> >
> > 0.95 Branch (including my performance fixes, JAI TIFF codec):
> >
> > Java 1.4.2: 2.2 sec
> > Java 1.5.0: 2.0 sec
> > Java 6.0: 1.9 sec
> >
> > 0.95 Branch (including my performance fixes, internal TIFF codec):
> >
> > Java 1.4.2: 2.7 sec
> > Java 1.5.0: 2.4 sec
> > Java 6.0: 2.3 sec
> >
> > Just as an experiment I've converted the TIFF image to JPEG with
> > relatively low compression so there are no serious artifacts. The
> > resulting JPEG image is 425KB. If performance is important and the
> > images are suitable (fotos), JPEG can be an option since the images
> > don't have to be decoded for PDF production. Here's the result:
> >
> > 0.95 Branch (including my performance fixes):
> > Java 6.0: 1.1 sec
> >
> >
> > On 12.04.2008 11:37:01 Jeremias Maerki wrote:
> >
> >> If Peter sends me his test TIFF I'll profile the problem. A factor 6
> >> increase is certainly not to be expected.
> >
> >
> >
> >
> > Jeremias Maerki
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop 0.95beta - svg tif images
Thanks Jeremiasas always, very thorough work/analysis. Is it correct you always used JAI TIFF codec in your measurements and never the xmlgraphics fix you added on Friday. The one that supports tiff without jai at all? If so, any chance at all you could measure the performance of that fix/ patch on your xp box as well? Thanks, Peter On 13 Apr 2008, at 10:02, Jeremias Maerki wrote: Peter sent me one of his large TIFF images to test with. Thanks, Peter. I used his FO snippet he posted at the beginning of the thread so the firgures below are including Batik into the picture. The TIFF file: RGB, LZW compression, 1327x3682 pixels, 2.73MB I couldn't see a factor 6 increase of time necessary to process the picture on my Windows XP SP2 except when run inside my profiler but that's due to method instrumentation overhead. The normal runtime effect was far smaller. As you can see I didn't experience slower performance with FOP Trunk/0.95beta compared to 0.94. Here's what I measured (please note that the figures below always refer to the server VM with parallel GC enabled, JVM startup and class loading is included in the times): FOP 0.94 (Commons' TIFF codec) Java 1.4.2: 4.0 sec Java 1.5.0: 3.6 sec Java 6: 3.3 sec Trunk (comparable to 0.95beta, JAI TIFF codec) Java 1.4.2: 2.9 sec Java 1.5.0: 2.9 sec Java 1.6: 2.6 sec When profiled with my YourKit profiler I found two hotspots which are now fixed: http://svn.apache.org/viewvc?rev=647537&view=rev http://svn.apache.org/viewvc?rev=647536&view=rev The latter hotspot in Commons is only triggered when my new TIFF image loader is used. 0.95 Branch (including my performance fixes, JAI TIFF codec): Java 1.4.2: 2.2 sec Java 1.5.0: 2.0 sec Java 6.0: 1.9 sec 0.95 Branch (including my performance fixes, internal TIFF codec): Java 1.4.2: 2.7 sec Java 1.5.0: 2.4 sec Java 6.0: 2.3 sec Just as an experiment I've converted the TIFF image to JPEG with relatively low compression so there are no serious artifacts. The resulting JPEG image is 425KB. If performance is important and the images are suitable (fotos), JPEG can be an option since the images don't have to be decoded for PDF production. Here's the result: 0.95 Branch (including my performance fixes): Java 6.0: 1.1 sec On 12.04.2008 11:37:01 Jeremias Maerki wrote: If Peter sends me his test TIFF I'll profile the problem. A factor 6 increase is certainly not to be expected. 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]
Re: Fop 0.95beta - svg tif images
Peter sent me one of his large TIFF images to test with. Thanks, Peter. I used his FO snippet he posted at the beginning of the thread so the firgures below are including Batik into the picture. The TIFF file: RGB, LZW compression, 1327x3682 pixels, 2.73MB I couldn't see a factor 6 increase of time necessary to process the picture on my Windows XP SP2 except when run inside my profiler but that's due to method instrumentation overhead. The normal runtime effect was far smaller. As you can see I didn't experience slower performance with FOP Trunk/0.95beta compared to 0.94. Here's what I measured (please note that the figures below always refer to the server VM with parallel GC enabled, JVM startup and class loading is included in the times): FOP 0.94 (Commons' TIFF codec) Java 1.4.2: 4.0 sec Java 1.5.0: 3.6 sec Java 6: 3.3 sec Trunk (comparable to 0.95beta, JAI TIFF codec) Java 1.4.2: 2.9 sec Java 1.5.0: 2.9 sec Java 1.6: 2.6 sec When profiled with my YourKit profiler I found two hotspots which are now fixed: http://svn.apache.org/viewvc?rev=647537&view=rev http://svn.apache.org/viewvc?rev=647536&view=rev The latter hotspot in Commons is only triggered when my new TIFF image loader is used. 0.95 Branch (including my performance fixes, JAI TIFF codec): Java 1.4.2: 2.2 sec Java 1.5.0: 2.0 sec Java 6.0: 1.9 sec 0.95 Branch (including my performance fixes, internal TIFF codec): Java 1.4.2: 2.7 sec Java 1.5.0: 2.4 sec Java 6.0: 2.3 sec Just as an experiment I've converted the TIFF image to JPEG with relatively low compression so there are no serious artifacts. The resulting JPEG image is 425KB. If performance is important and the images are suitable (fotos), JPEG can be an option since the images don't have to be decoded for PDF production. Here's the result: 0.95 Branch (including my performance fixes): Java 6.0: 1.1 sec On 12.04.2008 11:37:01 Jeremias Maerki wrote: > If Peter sends me his test TIFF I'll profile the problem. A factor 6 > increase is certainly not to be expected. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
