xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: Fop 0.95beta - svg tif images
Date Fri, 11 Apr 2008 17:26:55 GMT
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.



To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message