You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Peter Coppens <pc...@gmail.com> on 2008/04/10 16:06:56 UTC
Fop 0.95beta - svg tif images
Dearest FOP/Batik fans (I am unclear where to post...sorry),
With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked ok. I
switched to FOP0.95beta (which seems to come with a newer batik
version, 1.7) and get
SEVERE: SVG ErrorCannot load image (no suitable loader/converter
combination available) for file:/lap-pc-migration/Downloads/RenderX/
inx2fo/mda/./Ostern_DIN Lang_back.tif (image/tiff)
org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
(no suitable loader/converter combination available) for file:/lap-pc-
migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_back.tif
(image/tiff)
at
org
.apache
.xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:248)
....
I am guessing this is all about the new image library, but I am not
sure really and I am even less sure how to deal with this.
Anyone any thoughts?
Tx!
Peter
FO fragment
<fo:block-container absolute-position="fixed" left="0pt"
top="0pt" width="318.6pt" height="884pt">
<fo:block>
<fo:instream-foreign-object
content-width="318.6pt" content-height="884pt">
<svg:svg width="318.6" height="884"
viewbox="0, 0, 318.6, 884">
<svg:g
transform="translate(159.3, 442)">
<svg:g
transform="matrix(1, 0, 0, 1, -0.06, 0.04)">
<svg:rect x="-159.24"
y="-441.96000000000004" width="318.48"
height="883.9200000000001" fill="none" stroke="none" />
<svg:g
transform="translate(-159.24, -441.96000000000004)">
<svg:svg overflow="hidden"
width="318.48" height="883.9200000000001">
<svg:g
transform="translate(159.24, 441.96000000000004)">
<svg:g
transform="matrix(1, 0, 0, 1, -159.24,
-441.96000000000004)">
<svg:image
xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
width="318.48" height="883.9200000000001" fill="none"
stroke="none"
xlink:href="Ostern_DIN Lang_back.tif" />
</svg:g>
</svg:g>
</svg:svg>
</svg:g>
<svg:rect x="-159.24"
y="-441.96000000000004" width="318.48"
height="883.9200000000001" fill="none" stroke-width="0pt" />
</svg:g>
</svg:g>
</svg:svg>
</fo:instream-foreign-object>
</fo:block>
</fo:block-container>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
There's now such an implementation available in XG Commons Trunk:
http://svn.apache.org/viewvc?rev=646931&view=rev
On 10.04.2008 17:06:37 Jeremias Maerki wrote:
<snip/>
> But I guess it makes sense to write an additional implementation for the
> built-in TIFF codec we ship. I wanted to get away from that but I guess
> it may not be that simple.
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
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 Jeremias....as 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:
>>> <snip/>
>>>> If Peter sends me his test TIFF I'll profile the problem. A
>>>> factor 6
>>>> increase is certainly not to be expected.
>>> <snip/>
>>>
>>>
>>>
>>> Jeremias Maerki
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 Jeremias....as 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:
> > <snip/>
> >> If Peter sends me his test TIFF I'll profile the problem. A factor 6
> >> increase is certainly not to be expected.
> > <snip/>
> >
> >
> >
> > Jeremias Maerki
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
Thanks Jeremias....as 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:
> <snip/>
>> If Peter sends me his test TIFF I'll profile the problem. A factor 6
>> increase is certainly not to be expected.
> <snip/>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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:
<snip/>
> If Peter sends me his test TIFF I'll profile the problem. A factor 6
> increase is certainly not to be expected.
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 11.04.2008 19:26:55 Andreas Delmelle wrote:
> On Apr 11, 2008, at 18:20, Peter Coppens wrote:
> >
> >>
> >>> Given my non existent knowledge on tiff (and image formats in
> >>> general) and (I am sure recognizable) chronic lack of time to
> >>> dive into image formats at this moment, I am afraid I would not
> >>> even know with which tiff parameters to play
> >>>
> >>
> >> Which properties did you alter exactly? In the meantime, I read
> >> somewhere that Apple's native TIFF codec for JAI does not provide
> >> support for big-endian TIFFs.
> > None to be honest. Just took other tiff files. Would be nice if
> > someone could try to reproduce my findings on another platform with
> > other files. Perhaps this is a macos only issue...
>
> Well, did a very quick test here, and without Jeremias' change, any
> TIFF that is produced by Preview indeed fails with the message you
> provided earlier.
> Seems the issue is isolated to OS X. I guess one important thing to
> check on the side of XMLGraphics is whether the native OS X TIFF
> reader has peculiarities which make it undetectable somehow. Note
> that the message indicates the framework is looking for a 'loader/
> converter combination'. All nice if there is a native codec, but if
> there is no matching ... whichever of the two (*) then we'd get an
> error like that.
>
> (*) not an expert on the image-handling code, here, so I really can't
> say whether it should be 'loader' or 'converter' :/
The "loader/converter combination" message comes from my image loader
framework. Don't confuse that with any codec available inside ImageIO.
For the image loader framework ImageIO is just one single "codec". What
ImageIO does internally doesn't interest the image loader. If the
"loader/converter combination" message is produced, it means there's
simply no image loader around that can load TIFF files.
> > although the fact that 0.94 is faster than 0.95beta-jeremias-tiff
> > would make that ....weird.
>
> Not really. It would be much weirder IMO if FOP (or any software for
> that matter) were to offer increased flexibility/functionality/
> features without any performance penalty whatsoever. If that were the
> case, Vista should run on a 386 without any noticeable slow-down when
> compared to, say, Windows 3.11... errmmm.
>
> I'd think it pretty 'normal' that the new image-handling framework
> adds /some/ overhead.
Uhm, yes, but so did the old image code. And that one had an even larger
overhead. The new image loader framework is supposed to provide minimal
overhead (like not parsing image files if not necessary). The old code
old stuff had some of this too, but doesn't do a very good job and
sometimes even had to additionally convert a RenderedImage into a byte
array, for example. Now this is not necessary anymore.
If Peter sends me his test TIFF I'll profile the problem. A factor 6
increase is certainly not to be expected.
> A factor of six would be on the high side,
> though, but nothing points in the direction of the image-handling
> framework alone. A lot has been changed and added between 0.94 and
> 0.95, so even though this may seem 'weird', I somehow expect 0.95 to
> be slightly slower than 0.94.
>
> Also, since (I presume) you are timing singular runs, there is no
> accounting for things like static initialization. This only occurs
> for the very first run in a given runtime session. If the newer code
> moved some parts to those areas, then this would only slow down that
> first run, but could speed up/save memory in all subsequent runs in
> the same VM.
>
>
> Cheers
>
> Andreas
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
>
>> although the fact that 0.94 is faster than 0.95beta-jeremias-tiff
>> would make that ....weird.
>
> Not really. It would be much weirder IMO if FOP (or any software for
> that matter) were to offer increased flexibility/functionality/
> features without any performance penalty whatsoever. If that were
> the case, Vista should run on a 386 without any noticeable slow-down
> when compared to, say, Windows 3.11... errmmm.
Oh...well let's leave windows out of this .... :)
>
> I'd think it pretty 'normal' that the new image-handling framework
> adds /some/ overhead. A factor of six would be on the high side,
> though, but nothing points in the direction of the image-handling
> framework alone. A lot has been changed and added between 0.94 and
> 0.95, so even though this may seem 'weird', I somehow expect 0.95 to
> be slightly slower than 0.94.
>
I understand that...no such thing as a free lunch. But as you said, a
factor 6 (assuming what I found is correct) irrespective of where in
fop/xmlgraphics/batik the slowdown lies, is...a lot.
> Also, since (I presume) you are timing singular runs, there is no
> accounting for things like static initialization. This only occurs
> for the very first run in a given runtime session. If the newer code
> moved some parts to those areas, then this would only slow down that
> first run, but could speed up/save memory in all subsequent runs in
> the same VM.
Well, the numbers come from single runs yes. Otoh, I started out with
a stylesheet with more tiff's (which is how I originally ran into the
slowdown). There the performance penalty was far worse ...to the
extent that it makes the (web) application unusable with 0.95beta. To
be complete - that was before the 'jeremias-tiff' version.
I'll try to find some time to ...well...not sure what I can do. But
it's either ignore post 0.94 versions or fix something (and I want to
use post 0.94 versions for different reasons)
I will try to profile the code I guess and figure out where the
problem might have been introduced (which will be quite an adventure
having no real idea how the code is structured nor what was changed
when...I know svn does help there).
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
On 12 Apr 2008, at 13:09, Andreas Delmelle wrote:
> On Apr 11, 2008, at 23:30, Peter Coppens wrote:
>
> Hi Peter
>
>>
>> I don't like the jai dependancy (don't like native Java libraries)
>
> Very rightly so. As demonstrated by this particular case, if one
> platform lacks native support, it seriously breaks the usability of
> the library as a platform-independent way of handling images.
>
> Maybe this will be better in Apple Java 6, but I can't test since
> the DP is only available for 64-bit Intel Macs and I'm still on
> PowerPC... :(
I did...and these are decoders that are available
BMP
bmp
jpg
JPG
wbmp
jpeg
png
PNG
JPEG
WBMP
GIF
gif
>
>
>> but Jeremias' patch would solve that. The 6x performance hit
>> is ....more troublesome :(
>
> Does this performance hit here also increase with the number of
> TIFFs you include (as you verified with Sun's pure Java
> implementation),
yes it does...that was the point I was trying to make
> or is the effect restricted to the first one?
No, it does not,.
> If you include, say 6 different images, is there still a 6x
> performance hit, or does it shrink?
Have not tried to be honest
> The latter would ind1icate that the performance hit could actually
> be a sign of good scalability (always think positive ;-)).
> A performance /hit/ for very low numbers, which decreases, then once
> a threshold is reached, translates itself into an actual
> performance /benefit/ for the larger numbers (?)
> An algorithm with linear behavior will perform better (sometimes /
> much/ better) for only one execution, than one with logarithmic
> behavior. The latter, OTOH, will very soon become your friend as the
> number of executions starts to grow. Slower for a single execution
> due to the added complexity, but this added complexity would
> precisely have as its purpose to reduce the runtime for future
> executions. Only if there are none, does this become pure overhead.
Yes thanks for the refreshment (I had my share of csc :) ).
> Another thing you could try out: Is there a similar difference in
> timing if the TIFF is included as an fo:external-graphic? That would
> already allow to factor Batik out of the equation.
Yes indeed...that would be a good parameter to play with.
>
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 11, 2008, at 23:30, Peter Coppens wrote:
Hi Peter
>
> I don't like the jai dependancy (don't like native Java libraries)
Very rightly so. As demonstrated by this particular case, if one
platform lacks native support, it seriously breaks the usability of
the library as a platform-independent way of handling images.
Maybe this will be better in Apple Java 6, but I can't test since the
DP is only available for 64-bit Intel Macs and I'm still on
PowerPC... :(
> but Jeremias' patch would solve that. The 6x performance hit
> is ....more troublesome :(
Does this performance hit here also increase with the number of TIFFs
you include (as you verified with Sun's pure Java implementation), or
is the effect restricted to the first one? If you include, say 6
different images, is there still a 6x performance hit, or does it
shrink? The latter would indicate that the performance hit could
actually be a sign of good scalability (always think positive ;-)).
A performance /hit/ for very low numbers, which decreases, then once
a threshold is reached, translates itself into an actual performance /
benefit/ for the larger numbers (?)
An algorithm with linear behavior will perform better (sometimes /
much/ better) for only one execution, than one with logarithmic
behavior. The latter, OTOH, will very soon become your friend as the
number of executions starts to grow. Slower for a single execution
due to the added complexity, but this added complexity would
precisely have as its purpose to reduce the runtime for future
executions. Only if there are none, does this become pure overhead.
Another thing you could try out: Is there a similar difference in
timing if the TIFF is included as an fo:external-graphic? That would
already allow to factor Batik out of the equation.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
Yeah....I wrote my first jai program earlier today....
import javax.imageio.*;
public class ListImageDecoders {
public static void main (String args[]) {
String rfn[]=ImageIO.getReaderFormatNames();
for(String rf:rfn) {
System.out.println(rf);
}
}
}
and came to the same conclusion you did.
I don't like the jai dependancy (don't like native Java libraries) but
Jeremias' patch would solve that. The 6x performance hit is ....more
troublesome :(
(but I don't want to be whining all the time ...I do appreciate the
time you spent on this)
Peter
Well...for me
On 11 Apr 2008, at 22:59, Andreas Delmelle wrote:
> On Apr 11, 2008, at 19:26, Andreas Delmelle wrote:
>> On Apr 11, 2008, at 18:20, Peter Coppens wrote:
>>>
>> Well, did a very quick test here, and without Jeremias' change, any
>> TIFF that is produced by Preview indeed fails with the message you
>> provided earlier.
>> Seems the issue is isolated to OS X. I guess one important thing to
>> check on the side of XMLGraphics is whether the native OS X TIFF
>> reader has peculiarities which make it undetectable somehow.
>
> Checked closer, and the result of ImageIO.getReaderMimeTypes() does
> not contain "image/tiff" as a supported type on my system, so it's
> normal behavior on the side of XG Commons.
> Browsed around a bit more, and the impression I'm getting is that
> ImageIO TIFF support was available at one point. I read posts
> mentioning tiff as a natively supported type on Java 1.4.2. Then
> again, most posts I found indicate nothing but trouble and security
> issues. The latest I could gather was that it was 'currently
> unavailable, but put on the planning', but as far as I could tell,
> not really with the highest priority...
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 11, 2008, at 19:26, Andreas Delmelle wrote:
> On Apr 11, 2008, at 18:20, Peter Coppens wrote:
>>
> Well, did a very quick test here, and without Jeremias' change, any
> TIFF that is produced by Preview indeed fails with the message you
> provided earlier.
> Seems the issue is isolated to OS X. I guess one important thing to
> check on the side of XMLGraphics is whether the native OS X TIFF
> reader has peculiarities which make it undetectable somehow.
Checked closer, and the result of ImageIO.getReaderMimeTypes() does
not contain "image/tiff" as a supported type on my system, so it's
normal behavior on the side of XG Commons.
Browsed around a bit more, and the impression I'm getting is that
ImageIO TIFF support was available at one point. I read posts
mentioning tiff as a natively supported type on Java 1.4.2. Then
again, most posts I found indicate nothing but trouble and security
issues. The latest I could gather was that it was 'currently
unavailable, but put on the planning', but as far as I could tell,
not really with the highest priority...
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 11, 2008, at 18:20, Peter Coppens wrote:
>
>>
>>> Given my non existent knowledge on tiff (and image formats in
>>> general) and (I am sure recognizable) chronic lack of time to
>>> dive into image formats at this moment, I am afraid I would not
>>> even know with which tiff parameters to play
>>>
>>
>> Which properties did you alter exactly? In the meantime, I read
>> somewhere that Apple's native TIFF codec for JAI does not provide
>> support for big-endian TIFFs.
> None to be honest. Just took other tiff files. Would be nice if
> someone could try to reproduce my findings on another platform with
> other files. Perhaps this is a macos only issue...
Well, did a very quick test here, and without Jeremias' change, any
TIFF that is produced by Preview indeed fails with the message you
provided earlier.
Seems the issue is isolated to OS X. I guess one important thing to
check on the side of XMLGraphics is whether the native OS X TIFF
reader has peculiarities which make it undetectable somehow. Note
that the message indicates the framework is looking for a 'loader/
converter combination'. All nice if there is a native codec, but if
there is no matching ... whichever of the two (*) then we'd get an
error like that.
(*) not an expert on the image-handling code, here, so I really can't
say whether it should be 'loader' or 'converter' :/
> although the fact that 0.94 is faster than 0.95beta-jeremias-tiff
> would make that ....weird.
Not really. It would be much weirder IMO if FOP (or any software for
that matter) were to offer increased flexibility/functionality/
features without any performance penalty whatsoever. If that were the
case, Vista should run on a 386 without any noticeable slow-down when
compared to, say, Windows 3.11... errmmm.
I'd think it pretty 'normal' that the new image-handling framework
adds /some/ overhead. A factor of six would be on the high side,
though, but nothing points in the direction of the image-handling
framework alone. A lot has been changed and added between 0.94 and
0.95, so even though this may seem 'weird', I somehow expect 0.95 to
be slightly slower than 0.94.
Also, since (I presume) you are timing singular runs, there is no
accounting for things like static initialization. This only occurs
for the very first run in a given runtime session. If the newer code
moved some parts to those areas, then this would only slow down that
first run, but could speed up/save memory in all subsequent runs in
the same VM.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
On 11 Apr 2008, at 17:48, Andreas Delmelle wrote:
> On Apr 11, 2008, at 07:18, Peter Coppens wrote:
>> Tried 2 more tiffs (but from the same 'source'). They gave the
>> similar results for relative performance. 1 (0.94) vs 30 (0.95beta)
>> vs 6(0.95beta-jeremias-tiff)
>
>
>> Given my non existent knowledge on tiff (and image formats in
>> general) and (I am sure recognizable) chronic lack of time to dive
>> into image formats at this moment, I am afraid I would not even
>> know with which tiff parameters to play
>>
>
> Which properties did you alter exactly? In the meantime, I read
> somewhere that Apple's native TIFF codec for JAI does not provide
> support for big-endian TIFFs.
None to be honest. Just took other tiff files. Would be nice if
someone could try to reproduce my findings on another platform with
other files. Perhaps this is a macos only issue...although the fact
that 0.94 is faster than 0.95beta-jeremias-tiff would make
that ....weird.
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 11, 2008, at 07:18, Peter Coppens wrote:
> Tried 2 more tiffs (but from the same 'source'). They gave the
> similar results for relative performance. 1 (0.94) vs 30 (0.95beta)
> vs 6(0.95beta-jeremias-tiff)
> Given my non existent knowledge on tiff (and image formats in
> general) and (I am sure recognizable) chronic lack of time to dive
> into image formats at this moment, I am afraid I would not even
> know with which tiff parameters to play
>
Which properties did you alter exactly? In the meantime, I read
somewhere that Apple's native TIFF codec for JAI does not provide
support for big-endian TIFFs.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
Tried 2 more tiffs (but from the same 'source'). They gave the similar
results for relative performance. 1 (0.94) vs 30 (0.95beta) vs
6(0.95beta-jeremias-tiff)
Given my non existent knowledge on tiff (and image formats in general)
and (I am sure recognizable) chronic lack of time to dive into image
formats at this moment, I am afraid I would not even know with which
tiff parameters to play
Perhaps there is some part of the fop/batik tests that could be used
to do some performance regression measurements?
Thanks again for your support!
Peter
On 10 Apr 2008, at 23:40, Andreas Delmelle wrote:
> On Apr 10, 2008, at 23:19, Andreas Delmelle wrote:
>>
>> According to what I found, the problem could be not so much JAI
>> ImageIO itself, but the codecs.
>> Apparently, Apple does not provide native codecs for all formats,
>
> (After some more reading) They do for a TIFF reader, however...
> maybe their native codec is simply much slower than XG's. ;-)
>
> Another reason could be that their native TIFF reader somehow does
> not qualify...
> Have you tried using other TIFFs, with different properties? Try
> opening in Preview, and Export to TIFF, and modify a few.
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 23:19, Andreas Delmelle wrote:
>
> According to what I found, the problem could be not so much JAI
> ImageIO itself, but the codecs.
> Apparently, Apple does not provide native codecs for all formats,
(After some more reading) They do for a TIFF reader, however... maybe
their native codec is simply much slower than XG's. ;-)
Another reason could be that their native TIFF reader somehow does
not qualify...
Have you tried using other TIFFs, with different properties? Try
opening in Preview, and Export to TIFF, and modify a few.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 22:55, Peter Coppens wrote:
> Well...I did the test with only a tif.
>
> 0.94 --> 4sec
> 0.95beta --> 78sec
>
> Somewhat worrying to be honest (although I guess it might be due to
> the fact that I am using a jai image io jar extracted from a linux
> package)
>
> I guess, next is to try Jeremias's version that gets rid of the jai
> image io dependancy for tiff's...
According to what I found, the problem could be not so much JAI
ImageIO itself, but the codecs.
Apparently, Apple does not provide native codecs for all formats, and
the implementation 'gracefully' falls back to pure Java mode, which
is significantly slower...
Seems like it is definitely worth keeping the built-in TIFF codec in
XMLGraphics.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
Well...I did the test with only a tif.
0.94 --> 4sec
0.95beta --> 78sec
Somewhat worrying to be honest (although I guess it might be due to
the fact that I am using a jai image io jar extracted from a linux
package)
I guess, next is to try Jeremias's version that gets rid of the jai
image io dependancy for tiff's...
Peter
Stylesheet
<?xml version="1.0" encoding="utf-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:rx="http://www.renderx.com/XSL/Extensions"
xmlns:doc="for internal documentation"
xmlns:svg="http://www.w3.org/2000/svg">
<fo:layout-master-set>
<fo:simple-page-master page-height="884pt" page-width="318.6pt"
master-name="regular-odd">
<fo:region-body margin-top="56.69291338582677pt"
margin-bottom="56.69291338582677pt"
margin-left="85.03937007874016pt"
margin-right="42.51968503937008pt" />
<fo:region-before region-name="regular-before-odd"
extent="28.346456692913385pt" display-align="before" />
<fo:region-after region-name="regular-after-odd"
extent="28.346456692913385pt" display-align="after" />
<fo:region-start region-name="regular-inner"
extent="56.69291338582678pt" display-align="after" />
</fo:simple-page-master>
<fo:page-sequence-master master-name="text-plain">
<fo:repeatable-page-master-reference
master-reference="regular-odd" />
</fo:page-sequence-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="text-plain" id="rc_ua9">
<fo:flow flow-name="xsl-region-body">
<fo:block>
<fo:block-container absolute-position="fixed" left="0pt"
top="0pt" width="318.6pt" height="884pt">
<fo:block>
<fo:instream-foreign-object
content-width="318.6pt" content-height="884pt">
<svg:svg width="318.6" height="884"
viewbox="0, 0, 318.6, 884">
<svg:g
transform="translate(159.3, 442)">
<svg:g
transform="matrix(1, 0, 0, 1, 0.06, -0.04)">
<svg:rect x="-159.24"
y="-441.96000000000004" width="318.48"
height="883.9200000000001" fill="none" stroke="none" />
<svg:g
transform="translate(-159.24, -441.96000000000004)">
<svg:svg overflow="hidden"
width="318.48" height="883.9200000000001">
<svg:g
transform="translate(159.24, 441.96000000000004)">
<svg:g
transform="matrix(1, 0, 0, 1, -159.24,
-441.96000000000004)">
<svg:image
xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
width="318.48" height="883.9200000000001" fill="none"
stroke="none"
xlink:href="Ostern_DIN Lang_Front.tif" />
</svg:g>
</svg:g>
</svg:svg>
</svg:g>
</svg:g>
</svg:g>
</svg:svg>
</fo:instream-foreign-object>
</fo:block>
</fo:block-container>
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
On 10 Apr 2008, at 20:54, Andreas Delmelle wrote:
>
> On Apr 10, 2008, at 20:01, Peter Coppens wrote:
>>>
>>> You can use the Java-only part of JAI Image I/O Tools. The
>>> platform-specific parts are not necessary for TIFF. In the worst
>>> case,
>>> you can extract the JAR from an installation done on a Windows
>>> machine
>>> I hope you'll have around.
>>
>> That works...kind of...
>>
>> If I 'time' the pdf rendering of 'the' stylesheet with 0.94 it
>> takes about 7 seconds. With 0.95beta it takes 328 seconds
>>
>> I could try to isolate the 'performance' bottleneck...but perhaps
>> this can be explained with the info available right now?
>
> Hmm.. That could be caused by all sorts of things.
> Are you sure the difference is even related to the included TIFF?
> Have you compared the timings for documents without TIFF? If so, is
> there a similar difference?
>
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 20:01, Peter Coppens wrote:
>>
>> You can use the Java-only part of JAI Image I/O Tools. The
>> platform-specific parts are not necessary for TIFF. In the worst
>> case,
>> you can extract the JAR from an installation done on a Windows
>> machine
>> I hope you'll have around.
>
> That works...kind of...
>
> If I 'time' the pdf rendering of 'the' stylesheet with 0.94 it
> takes about 7 seconds. With 0.95beta it takes 328 seconds
>
> I could try to isolate the 'performance' bottleneck...but perhaps
> this can be explained with the info available right now?
Hmm.. That could be caused by all sorts of things.
Are you sure the difference is even related to the included TIFF?
Have you compared the timings for documents without TIFF? If so, is
there a similar difference?
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
>
> You can use the Java-only part of JAI Image I/O Tools. The
> platform-specific parts are not necessary for TIFF. In the worst case,
> you can extract the JAR from an installation done on a Windows machine
> I hope you'll have around.
That works...kind of...
If I 'time' the pdf rendering of 'the' stylesheet with 0.94 it takes
about 7 seconds. With 0.95beta it takes 328 seconds
I could try to isolate the 'performance' bottleneck...but perhaps this
can be explained with the info available right now?
Thanks!
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
>
> You can use the Java-only part of JAI Image I/O Tools. The
> platform-specific parts are not necessary for TIFF. In the worst case,
> you can extract the JAR from an installation done on a Windows machine
> I hope you'll have around.
That works...kind of...
If I 'time' the pdf rendering of 'the' stylesheet with 0.94 it takes
about 7 seconds. With 0.95beta it takes 328 seconds
I could try to isolate the 'performance' bottleneck...but perhaps this
can be explained with the info available right now?
Thanks!
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
<embarassed>Oh, I didn't remember we load the images inside SVG over the
new image loader through a special bridge in FOP.</embarassed>
You can use the Java-only part of JAI Image I/O Tools. The
platform-specific parts are not necessary for TIFF. In the worst case,
you can extract the JAR from an installation done on a Windows machine
I hope you'll have around.
But I guess it makes sense to write an additional implementation for the
built-in TIFF codec we ship. I wanted to get away from that but I guess
it may not be that simple.
On 10.04.2008 16:58:52 Peter Coppens wrote:
> Thanks Jeremias....
>
> As to the cause of the error...can't really see where else it is
> coming from (but in the end that might be a 'detail'). Below the
> complete stack trace...perhaps you find it 'interesting'
>
> Now...for the more problematic part - I am on MacOS...anybody any luck
> getting the 0.95beta fop/batik to work on macos when using tif
> images? It is unclear from my intial www wanderings what the state of
> jai on mac os is.
>
> Pointers or guidance would be appreciated.
>
> Thanks!
>
> Peter
>
>
>
>
>
> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
> (no suitable loader/converter combination available) for file:/lap-pc-
> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_Front.tif
> (image/tiff)
> at
> org
> .apache
> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:248)
> at
> org
> .apache
> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:289)
> at
> org
> .apache
> .fop
> .svg
> .PDFImageElementBridge
> .createImageGraphicsNode(PDFImageElementBridge.java:80)
> at
> org
> .apache
> .batik.bridge.SVGImageElementBridge.buildImageGraphicsNode(Unknown
> Source)
> at
> org
> .apache.batik.bridge.SVGImageElementBridge.createGraphicsNode(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
> at
> org
> .apache
> .fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188)
> at
> org
> .apache
> .fop
> .render
> .AbstractGenericSVGHandler.handleXML(AbstractGenericSVGHandler.java:57)
> at
> org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:
> 799)
> at
> org.apache.fop.render.PrintRenderer.renderDocument(PrintRenderer.java:
> 169)
> at
> org
> .apache
> .fop
> .render
> .AbstractPathOrientedRenderer
> .renderForeignObject(AbstractPathOrientedRenderer.java:717)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:738)
> at
> org
> .apache
> .fop
> .render
> .AbstractPathOrientedRenderer
> .renderViewport(AbstractPathOrientedRenderer.java:557)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:617)
> at
> org
> .apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:
> 1345)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:592)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:
> 1336)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 529)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 564)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 564)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache
> .fop
> .render
> .AbstractPathOrientedRenderer
> .renderBlockViewport(AbstractPathOrientedRenderer.java:478)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 546)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 564)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache.fop.render.AbstractRenderer.renderFlow(AbstractRenderer.java:
> 424)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderMainReference(AbstractRenderer.java:
> 403)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderBodyRegion(AbstractRenderer.java:337)
> at
> org
> .apache
> .fop
> .render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:282)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:255)
> at
> org
> .apache.fop.render.AbstractRenderer.renderPage(AbstractRenderer.java:
> 229)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderPage(PDFRenderer.java:801)
> at
> org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:113)
> at org.apach
>
>
>
> On 10 Apr 2008, at 16:30, Jeremias Maerki wrote:
> > The error message comes from the FOP part, so I don't think that the
> > snippet you posted is really the source of the error. The solution
> > here
> > is simple: Please install JAI Image I/O Tools in your classpath:
> > http://jai-imageio.dev.java.net/
> >
> > This will add an Image I/O codec for TIFF. The new image loader
> > framework used by FOP doesn't have an implementation for the bundled
> > TIFF codec so it uses Image I/O for TIFF loading.
> >
> > HTH
> >
> > On 10.04.2008 16:06:56 Peter Coppens wrote:
> >> Dearest FOP/Batik fans (I am unclear where to post...sorry),
> >>
> >> With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked
> >> ok. I
> >> switched to FOP0.95beta (which seems to come with a newer batik
> >> version, 1.7) and get
> >>
> >> SEVERE: SVG ErrorCannot load image (no suitable loader/converter
> >> combination available) for file:/lap-pc-migration/Downloads/RenderX/
> >> inx2fo/mda/./Ostern_DIN Lang_back.tif (image/tiff)
> >> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
> >> (no suitable loader/converter combination available) for file:/lap-
> >> pc-
> >> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_back.tif
> >> (image/tiff)
> >> at
> >> org
> >> .apache
> >> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:
> >> 248)
> >> ....
> >>
> >> I am guessing this is all about the new image library, but I am not
> >> sure really and I am even less sure how to deal with this.
> >>
> >> Anyone any thoughts?
> >>
> >> Tx!
> >>
> >> Peter
> >>
> >> FO fragment
> >>
> >> <fo:block-container absolute-position="fixed" left="0pt"
> >> top="0pt" width="318.6pt" height="884pt">
> >> <fo:block>
> >> <fo:instream-foreign-object
> >> content-width="318.6pt" content-height="884pt">
> >> <svg:svg width="318.6" height="884"
> >> viewbox="0, 0, 318.6, 884">
> >> <svg:g
> >> transform="translate(159.3, 442)">
> >> <svg:g
> >> transform="matrix(1, 0, 0, 1, -0.06, 0.04)">
> >> <svg:rect x="-159.24"
> >> y="-441.96000000000004" width="318.48"
> >> height="883.9200000000001" fill="none" stroke="none" />
> >> <svg:g
> >> transform="translate(-159.24, -441.96000000000004)">
> >> <svg:svg overflow="hidden"
> >> width="318.48" height="883.9200000000001">
> >> <svg:g
> >> transform="translate(159.24, 441.96000000000004)">
> >> <svg:g
> >> transform="matrix(1, 0, 0, 1, -159.24,
> >> -441.96000000000004)">
> >> <svg:image
> >> xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
> >> width="318.48" height="883.9200000000001" fill="none"
> >> stroke="none"
> >> xlink:href="Ostern_DIN Lang_back.tif" />
> >> </svg:g>
> >> </svg:g>
> >> </svg:svg>
> >> </svg:g>
> >> <svg:rect x="-159.24"
> >> y="-441.96000000000004" width="318.48"
> >> height="883.9200000000001" fill="none" stroke-
> >> width="0pt" />
> >> </svg:g>
> >> </svg:g>
> >> </svg:svg>
> >> </fo:instream-foreign-object>
> >> </fo:block>
> >> </fo:block-container>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: batik-users-
> >> unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
<embarassed>Oh, I didn't remember we load the images inside SVG over the
new image loader through a special bridge in FOP.</embarassed>
You can use the Java-only part of JAI Image I/O Tools. The
platform-specific parts are not necessary for TIFF. In the worst case,
you can extract the JAR from an installation done on a Windows machine
I hope you'll have around.
But I guess it makes sense to write an additional implementation for the
built-in TIFF codec we ship. I wanted to get away from that but I guess
it may not be that simple.
On 10.04.2008 16:58:52 Peter Coppens wrote:
> Thanks Jeremias....
>
> As to the cause of the error...can't really see where else it is
> coming from (but in the end that might be a 'detail'). Below the
> complete stack trace...perhaps you find it 'interesting'
>
> Now...for the more problematic part - I am on MacOS...anybody any luck
> getting the 0.95beta fop/batik to work on macos when using tif
> images? It is unclear from my intial www wanderings what the state of
> jai on mac os is.
>
> Pointers or guidance would be appreciated.
>
> Thanks!
>
> Peter
>
>
>
>
>
> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
> (no suitable loader/converter combination available) for file:/lap-pc-
> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_Front.tif
> (image/tiff)
> at
> org
> .apache
> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:248)
> at
> org
> .apache
> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:289)
> at
> org
> .apache
> .fop
> .svg
> .PDFImageElementBridge
> .createImageGraphicsNode(PDFImageElementBridge.java:80)
> at
> org
> .apache
> .batik.bridge.SVGImageElementBridge.buildImageGraphicsNode(Unknown
> Source)
> at
> org
> .apache.batik.bridge.SVGImageElementBridge.createGraphicsNode(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
> at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
> Source)
> at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
> at
> org
> .apache
> .fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188)
> at
> org
> .apache
> .fop
> .render
> .AbstractGenericSVGHandler.handleXML(AbstractGenericSVGHandler.java:57)
> at
> org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:
> 799)
> at
> org.apache.fop.render.PrintRenderer.renderDocument(PrintRenderer.java:
> 169)
> at
> org
> .apache
> .fop
> .render
> .AbstractPathOrientedRenderer
> .renderForeignObject(AbstractPathOrientedRenderer.java:717)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:738)
> at
> org
> .apache
> .fop
> .render
> .AbstractPathOrientedRenderer
> .renderViewport(AbstractPathOrientedRenderer.java:557)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:617)
> at
> org
> .apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:
> 1345)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:592)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:
> 1336)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 529)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 564)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 564)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache
> .fop
> .render
> .AbstractPathOrientedRenderer
> .renderBlockViewport(AbstractPathOrientedRenderer.java:478)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 546)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
> 564)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
> at
> org
> .apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
> 519)
> at
> org
> .apache.fop.render.AbstractRenderer.renderFlow(AbstractRenderer.java:
> 424)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderMainReference(AbstractRenderer.java:
> 403)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderBodyRegion(AbstractRenderer.java:337)
> at
> org
> .apache
> .fop
> .render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:282)
> at
> org
> .apache
> .fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:255)
> at
> org
> .apache.fop.render.AbstractRenderer.renderPage(AbstractRenderer.java:
> 229)
> at
> org.apache.fop.render.pdf.PDFRenderer.renderPage(PDFRenderer.java:801)
> at
> org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:113)
> at org.apach
>
>
>
> On 10 Apr 2008, at 16:30, Jeremias Maerki wrote:
> > The error message comes from the FOP part, so I don't think that the
> > snippet you posted is really the source of the error. The solution
> > here
> > is simple: Please install JAI Image I/O Tools in your classpath:
> > http://jai-imageio.dev.java.net/
> >
> > This will add an Image I/O codec for TIFF. The new image loader
> > framework used by FOP doesn't have an implementation for the bundled
> > TIFF codec so it uses Image I/O for TIFF loading.
> >
> > HTH
> >
> > On 10.04.2008 16:06:56 Peter Coppens wrote:
> >> Dearest FOP/Batik fans (I am unclear where to post...sorry),
> >>
> >> With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked
> >> ok. I
> >> switched to FOP0.95beta (which seems to come with a newer batik
> >> version, 1.7) and get
> >>
> >> SEVERE: SVG ErrorCannot load image (no suitable loader/converter
> >> combination available) for file:/lap-pc-migration/Downloads/RenderX/
> >> inx2fo/mda/./Ostern_DIN Lang_back.tif (image/tiff)
> >> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
> >> (no suitable loader/converter combination available) for file:/lap-
> >> pc-
> >> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_back.tif
> >> (image/tiff)
> >> at
> >> org
> >> .apache
> >> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:
> >> 248)
> >> ....
> >>
> >> I am guessing this is all about the new image library, but I am not
> >> sure really and I am even less sure how to deal with this.
> >>
> >> Anyone any thoughts?
> >>
> >> Tx!
> >>
> >> Peter
> >>
> >> FO fragment
> >>
> >> <fo:block-container absolute-position="fixed" left="0pt"
> >> top="0pt" width="318.6pt" height="884pt">
> >> <fo:block>
> >> <fo:instream-foreign-object
> >> content-width="318.6pt" content-height="884pt">
> >> <svg:svg width="318.6" height="884"
> >> viewbox="0, 0, 318.6, 884">
> >> <svg:g
> >> transform="translate(159.3, 442)">
> >> <svg:g
> >> transform="matrix(1, 0, 0, 1, -0.06, 0.04)">
> >> <svg:rect x="-159.24"
> >> y="-441.96000000000004" width="318.48"
> >> height="883.9200000000001" fill="none" stroke="none" />
> >> <svg:g
> >> transform="translate(-159.24, -441.96000000000004)">
> >> <svg:svg overflow="hidden"
> >> width="318.48" height="883.9200000000001">
> >> <svg:g
> >> transform="translate(159.24, 441.96000000000004)">
> >> <svg:g
> >> transform="matrix(1, 0, 0, 1, -159.24,
> >> -441.96000000000004)">
> >> <svg:image
> >> xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
> >> width="318.48" height="883.9200000000001" fill="none"
> >> stroke="none"
> >> xlink:href="Ostern_DIN Lang_back.tif" />
> >> </svg:g>
> >> </svg:g>
> >> </svg:svg>
> >> </svg:g>
> >> <svg:rect x="-159.24"
> >> y="-441.96000000000004" width="318.48"
> >> height="883.9200000000001" fill="none" stroke-
> >> width="0pt" />
> >> </svg:g>
> >> </svg:g>
> >> </svg:svg>
> >> </fo:instream-foreign-object>
> >> </fo:block>
> >> </fo:block-container>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: batik-users-
> >> unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 22:11, Andreas Delmelle wrote:
> On Apr 10, 2008, at 22:00, Andreas Delmelle wrote:
>>
>> No idea why the install would fail on your system, though. Maybe a
>> bug, due to the fact that, as you suggested, the install-package
>> is quite old, and no longer works on more recent versions of OS X
>> (?) Unfortunately, I don't know how the installer checks for Java
>> being present,
> ...
>
> Additional question: does the notice appear at the very start?
> (Right after you get the warning about a script needing to run to
> verify whether the installation can proceed?)
>
> If so, you might get a clue if you look at the scripts in
> the .dmg's contents (right-click + show package contents).
... and so I did, and found there is a VolumeCheck script, which
seems to rely on:
/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/
version.plist
Aha, the script apparently always shows an error if the version is
greater than or equal to 10.4. Seems it's been a while since I
installed it. If I try to redo it, then it indeed fails here too...
Then again, as you discovered, the libraries are already available.
Normally, you shouldn't need to do anything special to make these
available, as this folder is added to the bootclasspath of the JVM...
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
On 10 Apr 2008, at 22:11, Andreas Delmelle wrote:
> On Apr 10, 2008, at 22:00, Andreas Delmelle wrote:
>>
>> No idea why the install would fail on your system, though. Maybe a
>> bug, due to the fact that, as you suggested, the install-package is
>> quite old, and no longer works on more recent versions of OS X (?)
>> Unfortunately, I don't know how the installer checks for Java being
>> present,
> ...
>
> Additional question: does the notice appear at the very start?
> (Right after you get the warning about a script needing to run to
> verify whether the installation can proceed?)
Yes...that is when it happens.
>
>
> If so, you might get a clue if you look at the scripts in the .dmg's
> contents (right-click + show package contents).
Hmmm...that might be a bit too ambitious for me at this stage (took a
peek but could not make much sense of it)...and I guess I did find
that jai was installed after all (in /System/Library/Java/
Extensions...see other mail in this thread)
>
>
> Cheers
>
> Andreas
Thanks for taking the time...much appreciated!
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 22:00, Andreas Delmelle wrote:
>
> No idea why the install would fail on your system, though. Maybe a
> bug, due to the fact that, as you suggested, the install-package is
> quite old, and no longer works on more recent versions of OS X (?)
> Unfortunately, I don't know how the installer checks for Java being
> present,
...
Additional question: does the notice appear at the very start? (Right
after you get the warning about a script needing to run to verify
whether the installation can proceed?)
If so, you might get a clue if you look at the scripts in the .dmg's
contents (right-click + show package contents).
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
On 10 Apr 2008, at 22:00, Andreas Delmelle wrote:
> On Apr 10, 2008, at 21:37, Peter Coppens wrote:
>
>> On 10 Apr 2008, at 20:47, Andreas Delmelle wrote:
>>>
>>> Now, I've been looking deeper into my local setup, and IIC, then
>>> for Java 1.5, the JAI libraries are already distributed /with/ the
>>> install package. At least, I do not remember ever having to
>>> configure this manually and still, the JARs are available in the
>>> lib/ext folder.
>
>> Ok..sorry upfront...this is not for this list and extremely
>> newbee....but what should I look for where (I am very new to MacOS
>> and confused by its setup). I have found /System/Library/Frameworks/
>> JavaVM.framework/Versions/ by now with different versions and also
>> e.g. /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/
>> Home/lib/ext/ containing apple_provider.jar, dnsns.jar,
>> localedata.jar, sunjce_provider.jar, sunpkcs11.jar but nothing
>> imageio like. Am I looking in the wrong place or have I not
>> installed enough (I do have XCode installed)
>
> My mistake. It's not the standard lib/ext. When I installed it for
> Java 1.4, apparently JAI was put under /System/Java/Extensions
> (where the Quicktime for Java JAR also resides), hence why it was
> also automagically available under Java 1.5.
>
Ha, that does get me somewhere (not sure where though). I found
'stuff' in /System/Library/Java/Extensions
(jai_core.jar,jai_codec.jar,mlibwrapper_jai.jar )...I explicitly added
them to the classpath (which I guess should not be required) before
running fop but I keep on getting "no suitable loader/converter
combination available".
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 21:37, Peter Coppens wrote:
> On 10 Apr 2008, at 20:47, Andreas Delmelle wrote:
>>
>> Now, I've been looking deeper into my local setup, and IIC, then
>> for Java 1.5, the JAI libraries are already distributed /with/ the
>> install package. At least, I do not remember ever having to
>> configure this manually and still, the JARs are available in the
>> lib/ext folder.
> Ok..sorry upfront...this is not for this list and extremely
> newbee....but what should I look for where (I am very new to MacOS
> and confused by its setup). I have found /System/Library/Frameworks/
> JavaVM.framework/Versions/ by now with different versions and also
> e.g. /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/
> Home/lib/ext/ containing apple_provider.jar, dnsns.jar,
> localedata.jar, sunjce_provider.jar, sunpkcs11.jar but nothing
> imageio like. Am I looking in the wrong place or have I not
> installed enough (I do have XCode installed)
My mistake. It's not the standard lib/ext. When I installed it for
Java 1.4, apparently JAI was put under /System/Java/Extensions (where
the Quicktime for Java JAR also resides), hence why it was also
automagically available under Java 1.5.
No idea why the install would fail on your system, though. Maybe a
bug, due to the fact that, as you suggested, the install-package is
quite old, and no longer works on more recent versions of OS X (?)
Unfortunately, I don't know how the installer checks for Java being
present, but I have stumbled on similar weirdness with other
installers because of folder-permissions being screwed up somehow. To
see whether that is the case, simply run the standard Disk Utility
(under /Applications/Utilities) and verify the file permissions for
the disk in question.
HTH!
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
On 10 Apr 2008, at 20:47, Andreas Delmelle wrote:
> On Apr 10, 2008, at 20:09, Peter Coppens wrote:
>>>> Now...for the more problematic part - I am on MacOS...anybody any
>>>> luck getting the 0.95beta fop/batik to work on macos when using
>>>> tif images? It is unclear from my intial www wanderings what the
>>>> state of jai on mac os is.
>>>
>>> I've not really tested TIFF yet, but I do know that JAI is
>>> definitely available for the Apple JVM:
>>> http://docs.info.apple.com/article.html?artnum=120289
>> Thanks...ran into that as well. I was somewhat 'scared' away as it
>> seems to be version 1.0 and dates from december 2003.
>
> No sure way to find out, other than trying it... :-)
I did...but it refused to install saying it could not find a volume
with Java installed on it
>
>
> Now, I've been looking deeper into my local setup, and IIC, then for
> Java 1.5, the JAI libraries are already distributed /with/ the
> install package. At least, I do not remember ever having to
> configure this manually and still, the JARs are available in the lib/
> ext folder.
Ok..sorry upfront...this is not for this list and extremely
newbee....but what should I look for where (I am very new to MacOS and
confused by its setup). I have found /System/Library/Frameworks/
JavaVM.framework/Versions/ by now with different versions and also
e.g. /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/
lib/ext/ containing apple_provider.jar, dnsns.jar, localedata.jar,
sunjce_provider.jar, sunpkcs11.jar but nothing imageio like. Am I
looking in the wrong place or have I not installed enough (I do have
XCode installed)
All help warmly welcomed. Many thanks indeed!
Peter
>
>
> This could explain why there is no more recent version of the
> separate package (needed only for Java 1.3 and 1.4?)
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 20:09, Peter Coppens wrote:
>>> Now...for the more problematic part - I am on MacOS...anybody any
>>> luck getting the 0.95beta fop/batik to work on macos when using
>>> tif images? It is unclear from my intial www wanderings what the
>>> state of jai on mac os is.
>>
>> I've not really tested TIFF yet, but I do know that JAI is
>> definitely available for the Apple JVM:
>> http://docs.info.apple.com/article.html?artnum=120289
> Thanks...ran into that as well. I was somewhat 'scared' away as it
> seems to be version 1.0 and dates from december 2003.
No sure way to find out, other than trying it... :-)
Apart from that, I browsed around some more on the Apple website, and
found an RSS feed with a date of 2009-01-01... Have I missed a year
somewhere?
I'd as soon presume this means that dates are not really reliable
over there... ;-)
Now, I've been looking deeper into my local setup, and IIC, then for
Java 1.5, the JAI libraries are already distributed /with/ the
install package. At least, I do not remember ever having to configure
this manually and still, the JARs are available in the lib/ext folder.
This could explain why there is no more recent version of the
separate package (needed only for Java 1.3 and 1.4?)
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
>> Now...for the more problematic part - I am on MacOS...anybody any
>> luck getting the 0.95beta fop/batik to work on macos when using
>> tif images? It is unclear from my intial www wanderings what the
>> state of jai on mac os is.
>
> I've not really tested TIFF yet, but I do know that JAI is
> definitely available for the Apple JVM:
> http://docs.info.apple.com/article.html?artnum=120289
Thanks...ran into that as well. I was somewhat 'scared' away as it
seems to be version 1.0 and dates from december 2003.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 10, 2008, at 16:58, Peter Coppens wrote:
Hi Peter
> As to the cause of the error...can't really see where else it is
> coming from (but in the end that might be a 'detail'). Below the
> complete stack trace...perhaps you find it 'interesting'
>
> Now...for the more problematic part - I am on MacOS...anybody any
> luck getting the 0.95beta fop/batik to work on macos when using
> tif images? It is unclear from my intial www wanderings what the
> state of jai on mac os is.
I've not really tested TIFF yet, but I do know that JAI is definitely
available for the Apple JVM:
http://docs.info.apple.com/article.html?artnum=120289
HTH!
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
Thanks Jeremias....
As to the cause of the error...can't really see where else it is
coming from (but in the end that might be a 'detail'). Below the
complete stack trace...perhaps you find it 'interesting'
Now...for the more problematic part - I am on MacOS...anybody any luck
getting the 0.95beta fop/batik to work on macos when using tif
images? It is unclear from my intial www wanderings what the state of
jai on mac os is.
Pointers or guidance would be appreciated.
Thanks!
Peter
org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
(no suitable loader/converter combination available) for file:/lap-pc-
migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_Front.tif
(image/tiff)
at
org
.apache
.xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:248)
at
org
.apache
.xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:289)
at
org
.apache
.fop
.svg
.PDFImageElementBridge
.createImageGraphicsNode(PDFImageElementBridge.java:80)
at
org
.apache
.batik.bridge.SVGImageElementBridge.buildImageGraphicsNode(Unknown
Source)
at
org
.apache.batik.bridge.SVGImageElementBridge.createGraphicsNode(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
at
org
.apache
.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188)
at
org
.apache
.fop
.render
.AbstractGenericSVGHandler.handleXML(AbstractGenericSVGHandler.java:57)
at
org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:
799)
at
org.apache.fop.render.PrintRenderer.renderDocument(PrintRenderer.java:
169)
at
org
.apache
.fop
.render
.AbstractPathOrientedRenderer
.renderForeignObject(AbstractPathOrientedRenderer.java:717)
at
org
.apache
.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:738)
at
org
.apache
.fop
.render
.AbstractPathOrientedRenderer
.renderViewport(AbstractPathOrientedRenderer.java:557)
at
org
.apache
.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:617)
at
org
.apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:
1345)
at
org
.apache
.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:592)
at
org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:
1336)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
529)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
564)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
564)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache
.fop
.render
.AbstractPathOrientedRenderer
.renderBlockViewport(AbstractPathOrientedRenderer.java:478)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
546)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
564)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache.fop.render.AbstractRenderer.renderFlow(AbstractRenderer.java:
424)
at
org
.apache
.fop.render.AbstractRenderer.renderMainReference(AbstractRenderer.java:
403)
at
org
.apache
.fop.render.AbstractRenderer.renderBodyRegion(AbstractRenderer.java:337)
at
org
.apache
.fop
.render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:282)
at
org
.apache
.fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:255)
at
org
.apache.fop.render.AbstractRenderer.renderPage(AbstractRenderer.java:
229)
at
org.apache.fop.render.pdf.PDFRenderer.renderPage(PDFRenderer.java:801)
at
org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:113)
at org.apach
On 10 Apr 2008, at 16:30, Jeremias Maerki wrote:
> The error message comes from the FOP part, so I don't think that the
> snippet you posted is really the source of the error. The solution
> here
> is simple: Please install JAI Image I/O Tools in your classpath:
> http://jai-imageio.dev.java.net/
>
> This will add an Image I/O codec for TIFF. The new image loader
> framework used by FOP doesn't have an implementation for the bundled
> TIFF codec so it uses Image I/O for TIFF loading.
>
> HTH
>
> On 10.04.2008 16:06:56 Peter Coppens wrote:
>> Dearest FOP/Batik fans (I am unclear where to post...sorry),
>>
>> With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked
>> ok. I
>> switched to FOP0.95beta (which seems to come with a newer batik
>> version, 1.7) and get
>>
>> SEVERE: SVG ErrorCannot load image (no suitable loader/converter
>> combination available) for file:/lap-pc-migration/Downloads/RenderX/
>> inx2fo/mda/./Ostern_DIN Lang_back.tif (image/tiff)
>> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
>> (no suitable loader/converter combination available) for file:/lap-
>> pc-
>> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_back.tif
>> (image/tiff)
>> at
>> org
>> .apache
>> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:
>> 248)
>> ....
>>
>> I am guessing this is all about the new image library, but I am not
>> sure really and I am even less sure how to deal with this.
>>
>> Anyone any thoughts?
>>
>> Tx!
>>
>> Peter
>>
>> FO fragment
>>
>> <fo:block-container absolute-position="fixed" left="0pt"
>> top="0pt" width="318.6pt" height="884pt">
>> <fo:block>
>> <fo:instream-foreign-object
>> content-width="318.6pt" content-height="884pt">
>> <svg:svg width="318.6" height="884"
>> viewbox="0, 0, 318.6, 884">
>> <svg:g
>> transform="translate(159.3, 442)">
>> <svg:g
>> transform="matrix(1, 0, 0, 1, -0.06, 0.04)">
>> <svg:rect x="-159.24"
>> y="-441.96000000000004" width="318.48"
>> height="883.9200000000001" fill="none" stroke="none" />
>> <svg:g
>> transform="translate(-159.24, -441.96000000000004)">
>> <svg:svg overflow="hidden"
>> width="318.48" height="883.9200000000001">
>> <svg:g
>> transform="translate(159.24, 441.96000000000004)">
>> <svg:g
>> transform="matrix(1, 0, 0, 1, -159.24,
>> -441.96000000000004)">
>> <svg:image
>> xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
>> width="318.48" height="883.9200000000001" fill="none"
>> stroke="none"
>> xlink:href="Ostern_DIN Lang_back.tif" />
>> </svg:g>
>> </svg:g>
>> </svg:svg>
>> </svg:g>
>> <svg:rect x="-159.24"
>> y="-441.96000000000004" width="318.48"
>> height="883.9200000000001" fill="none" stroke-
>> width="0pt" />
>> </svg:g>
>> </svg:g>
>> </svg:svg>
>> </fo:instream-foreign-object>
>> </fo:block>
>> </fo:block-container>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-
>> unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Peter Coppens <pc...@gmail.com>.
Thanks Jeremias....
As to the cause of the error...can't really see where else it is
coming from (but in the end that might be a 'detail'). Below the
complete stack trace...perhaps you find it 'interesting'
Now...for the more problematic part - I am on MacOS...anybody any luck
getting the 0.95beta fop/batik to work on macos when using tif
images? It is unclear from my intial www wanderings what the state of
jai on mac os is.
Pointers or guidance would be appreciated.
Thanks!
Peter
org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
(no suitable loader/converter combination available) for file:/lap-pc-
migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_Front.tif
(image/tiff)
at
org
.apache
.xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:248)
at
org
.apache
.xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:289)
at
org
.apache
.fop
.svg
.PDFImageElementBridge
.createImageGraphicsNode(PDFImageElementBridge.java:80)
at
org
.apache
.batik.bridge.SVGImageElementBridge.buildImageGraphicsNode(Unknown
Source)
at
org
.apache.batik.bridge.SVGImageElementBridge.createGraphicsNode(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
at
org
.apache
.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188)
at
org
.apache
.fop
.render
.AbstractGenericSVGHandler.handleXML(AbstractGenericSVGHandler.java:57)
at
org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:
799)
at
org.apache.fop.render.PrintRenderer.renderDocument(PrintRenderer.java:
169)
at
org
.apache
.fop
.render
.AbstractPathOrientedRenderer
.renderForeignObject(AbstractPathOrientedRenderer.java:717)
at
org
.apache
.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:738)
at
org
.apache
.fop
.render
.AbstractPathOrientedRenderer
.renderViewport(AbstractPathOrientedRenderer.java:557)
at
org
.apache
.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:617)
at
org
.apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:
1345)
at
org
.apache
.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:592)
at
org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:
1336)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
529)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
564)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
564)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache
.fop
.render
.AbstractPathOrientedRenderer
.renderBlockViewport(AbstractPathOrientedRenderer.java:478)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
546)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:
564)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329)
at
org
.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:
519)
at
org
.apache.fop.render.AbstractRenderer.renderFlow(AbstractRenderer.java:
424)
at
org
.apache
.fop.render.AbstractRenderer.renderMainReference(AbstractRenderer.java:
403)
at
org
.apache
.fop.render.AbstractRenderer.renderBodyRegion(AbstractRenderer.java:337)
at
org
.apache
.fop
.render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:282)
at
org
.apache
.fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:255)
at
org
.apache.fop.render.AbstractRenderer.renderPage(AbstractRenderer.java:
229)
at
org.apache.fop.render.pdf.PDFRenderer.renderPage(PDFRenderer.java:801)
at
org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:113)
at org.apach
On 10 Apr 2008, at 16:30, Jeremias Maerki wrote:
> The error message comes from the FOP part, so I don't think that the
> snippet you posted is really the source of the error. The solution
> here
> is simple: Please install JAI Image I/O Tools in your classpath:
> http://jai-imageio.dev.java.net/
>
> This will add an Image I/O codec for TIFF. The new image loader
> framework used by FOP doesn't have an implementation for the bundled
> TIFF codec so it uses Image I/O for TIFF loading.
>
> HTH
>
> On 10.04.2008 16:06:56 Peter Coppens wrote:
>> Dearest FOP/Batik fans (I am unclear where to post...sorry),
>>
>> With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked
>> ok. I
>> switched to FOP0.95beta (which seems to come with a newer batik
>> version, 1.7) and get
>>
>> SEVERE: SVG ErrorCannot load image (no suitable loader/converter
>> combination available) for file:/lap-pc-migration/Downloads/RenderX/
>> inx2fo/mda/./Ostern_DIN Lang_back.tif (image/tiff)
>> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
>> (no suitable loader/converter combination available) for file:/lap-
>> pc-
>> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_back.tif
>> (image/tiff)
>> at
>> org
>> .apache
>> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:
>> 248)
>> ....
>>
>> I am guessing this is all about the new image library, but I am not
>> sure really and I am even less sure how to deal with this.
>>
>> Anyone any thoughts?
>>
>> Tx!
>>
>> Peter
>>
>> FO fragment
>>
>> <fo:block-container absolute-position="fixed" left="0pt"
>> top="0pt" width="318.6pt" height="884pt">
>> <fo:block>
>> <fo:instream-foreign-object
>> content-width="318.6pt" content-height="884pt">
>> <svg:svg width="318.6" height="884"
>> viewbox="0, 0, 318.6, 884">
>> <svg:g
>> transform="translate(159.3, 442)">
>> <svg:g
>> transform="matrix(1, 0, 0, 1, -0.06, 0.04)">
>> <svg:rect x="-159.24"
>> y="-441.96000000000004" width="318.48"
>> height="883.9200000000001" fill="none" stroke="none" />
>> <svg:g
>> transform="translate(-159.24, -441.96000000000004)">
>> <svg:svg overflow="hidden"
>> width="318.48" height="883.9200000000001">
>> <svg:g
>> transform="translate(159.24, 441.96000000000004)">
>> <svg:g
>> transform="matrix(1, 0, 0, 1, -159.24,
>> -441.96000000000004)">
>> <svg:image
>> xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
>> width="318.48" height="883.9200000000001" fill="none"
>> stroke="none"
>> xlink:href="Ostern_DIN Lang_back.tif" />
>> </svg:g>
>> </svg:g>
>> </svg:svg>
>> </svg:g>
>> <svg:rect x="-159.24"
>> y="-441.96000000000004" width="318.48"
>> height="883.9200000000001" fill="none" stroke-
>> width="0pt" />
>> </svg:g>
>> </svg:g>
>> </svg:svg>
>> </fo:instream-foreign-object>
>> </fo:block>
>> </fo:block-container>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-
>> unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
The error message comes from the FOP part, so I don't think that the
snippet you posted is really the source of the error. The solution here
is simple: Please install JAI Image I/O Tools in your classpath:
http://jai-imageio.dev.java.net/
This will add an Image I/O codec for TIFF. The new image loader
framework used by FOP doesn't have an implementation for the bundled
TIFF codec so it uses Image I/O for TIFF loading.
HTH
On 10.04.2008 16:06:56 Peter Coppens wrote:
> Dearest FOP/Batik fans (I am unclear where to post...sorry),
>
> With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked ok. I
> switched to FOP0.95beta (which seems to come with a newer batik
> version, 1.7) and get
>
> SEVERE: SVG ErrorCannot load image (no suitable loader/converter
> combination available) for file:/lap-pc-migration/Downloads/RenderX/
> inx2fo/mda/./Ostern_DIN Lang_back.tif (image/tiff)
> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
> (no suitable loader/converter combination available) for file:/lap-pc-
> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_back.tif
> (image/tiff)
> at
> org
> .apache
> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:248)
> ....
>
> I am guessing this is all about the new image library, but I am not
> sure really and I am even less sure how to deal with this.
>
> Anyone any thoughts?
>
> Tx!
>
> Peter
>
> FO fragment
>
> <fo:block-container absolute-position="fixed" left="0pt"
> top="0pt" width="318.6pt" height="884pt">
> <fo:block>
> <fo:instream-foreign-object
> content-width="318.6pt" content-height="884pt">
> <svg:svg width="318.6" height="884"
> viewbox="0, 0, 318.6, 884">
> <svg:g
> transform="translate(159.3, 442)">
> <svg:g
> transform="matrix(1, 0, 0, 1, -0.06, 0.04)">
> <svg:rect x="-159.24"
> y="-441.96000000000004" width="318.48"
> height="883.9200000000001" fill="none" stroke="none" />
> <svg:g
> transform="translate(-159.24, -441.96000000000004)">
> <svg:svg overflow="hidden"
> width="318.48" height="883.9200000000001">
> <svg:g
> transform="translate(159.24, 441.96000000000004)">
> <svg:g
> transform="matrix(1, 0, 0, 1, -159.24,
> -441.96000000000004)">
> <svg:image
> xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
> width="318.48" height="883.9200000000001" fill="none"
> stroke="none"
> xlink:href="Ostern_DIN Lang_back.tif" />
> </svg:g>
> </svg:g>
> </svg:svg>
> </svg:g>
> <svg:rect x="-159.24"
> y="-441.96000000000004" width="318.48"
> height="883.9200000000001" fill="none" stroke-width="0pt" />
> </svg:g>
> </svg:g>
> </svg:svg>
> </fo:instream-foreign-object>
> </fo:block>
> </fo:block-container>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop 0.95beta - svg tif images
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
The error message comes from the FOP part, so I don't think that the
snippet you posted is really the source of the error. The solution here
is simple: Please install JAI Image I/O Tools in your classpath:
http://jai-imageio.dev.java.net/
This will add an Image I/O codec for TIFF. The new image loader
framework used by FOP doesn't have an implementation for the bundled
TIFF codec so it uses Image I/O for TIFF loading.
HTH
On 10.04.2008 16:06:56 Peter Coppens wrote:
> Dearest FOP/Batik fans (I am unclear where to post...sorry),
>
> With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked ok. I
> switched to FOP0.95beta (which seems to come with a newer batik
> version, 1.7) and get
>
> SEVERE: SVG ErrorCannot load image (no suitable loader/converter
> combination available) for file:/lap-pc-migration/Downloads/RenderX/
> inx2fo/mda/./Ostern_DIN Lang_back.tif (image/tiff)
> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
> (no suitable loader/converter combination available) for file:/lap-pc-
> migration/Downloads/RenderX/inx2fo/mda/./Ostern_DIN Lang_back.tif
> (image/tiff)
> at
> org
> .apache
> .xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:248)
> ....
>
> I am guessing this is all about the new image library, but I am not
> sure really and I am even less sure how to deal with this.
>
> Anyone any thoughts?
>
> Tx!
>
> Peter
>
> FO fragment
>
> <fo:block-container absolute-position="fixed" left="0pt"
> top="0pt" width="318.6pt" height="884pt">
> <fo:block>
> <fo:instream-foreign-object
> content-width="318.6pt" content-height="884pt">
> <svg:svg width="318.6" height="884"
> viewbox="0, 0, 318.6, 884">
> <svg:g
> transform="translate(159.3, 442)">
> <svg:g
> transform="matrix(1, 0, 0, 1, -0.06, 0.04)">
> <svg:rect x="-159.24"
> y="-441.96000000000004" width="318.48"
> height="883.9200000000001" fill="none" stroke="none" />
> <svg:g
> transform="translate(-159.24, -441.96000000000004)">
> <svg:svg overflow="hidden"
> width="318.48" height="883.9200000000001">
> <svg:g
> transform="translate(159.24, 441.96000000000004)">
> <svg:g
> transform="matrix(1, 0, 0, 1, -159.24,
> -441.96000000000004)">
> <svg:image
> xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0"
> width="318.48" height="883.9200000000001" fill="none"
> stroke="none"
> xlink:href="Ostern_DIN Lang_back.tif" />
> </svg:g>
> </svg:g>
> </svg:svg>
> </svg:g>
> <svg:rect x="-159.24"
> y="-441.96000000000004" width="318.48"
> height="883.9200000000001" fill="none" stroke-width="0pt" />
> </svg:g>
> </svg:g>
> </svg:svg>
> </fo:instream-foreign-object>
> </fo:block>
> </fo:block-container>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org