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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
