Re: JPEG images in Postscript

2003-07-11 Thread Jeremias Maerki

On 07.07.2003 10:28:59 Chris Bowditch wrote:
 I'm currently figuring out how best to solve this. I'm looking at the
 code from jpeg2ps which doesn't seem to have a problem with these JPEG
 files. The code in there is made to ignore any trailing bytes but
 processes the whole stream twice if I interpret correctly. Maybe looking
 for the EOI marker in our code and cutting off there is better
 performance-wise. But jpeg2ps' code is on the safe side in any case.
 Preferences anyone?
 
 
 Sorry but this message arrived after I left on Friday. I dont have a 
 preference. Out of interest, which option did you go for? Speed or mimicking 
 the jpeg2ps code?

I can't say for sure what the performance differences are between the
two solutions. Anyway I have chosen the quick  easy path and went for
the jpeg2ps-style approach since I don't have too much time available.

Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



Re: JPEG images in Postscript

2003-07-07 Thread Chris Bowditch
From: Jeremias Maerki [EMAIL PROTECTED]

Moving to fop-dev because it gets technical...
:-)



I'm currently figuring out how best to solve this. I'm looking at the
code from jpeg2ps which doesn't seem to have a problem with these JPEG
files. The code in there is made to ignore any trailing bytes but
processes the whole stream twice if I interpret correctly. Maybe looking
for the EOI marker in our code and cutting off there is better
performance-wise. But jpeg2ps' code is on the safe side in any case.
Preferences anyone?
Sorry but this message arrived after I left on Friday. I dont have a 
preference. Out of interest, which option did you go for? Speed or mimicking 
the jpeg2ps code?

_
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


Re: JPEG images in Postscript

2003-07-04 Thread Jeremias Maerki
Moving to fop-dev because it gets technical...

After a lot of searching I think I know what's wrong. It's not the
ASCII-85 filter behaving wrong. Chris' JPEG images contain trailing
zero's after the FFD9 (EOI, end of image marker) which fill the images
up to 16384 bytes. Now, I guess the error happens because the DCTDecode
filter stops working after encountering the EOI marker. Because there is
still some data unprocessed and because of the way images are currently
written to PostScript this leads to an error.

I'm currently figuring out how best to solve this. I'm looking at the
code from jpeg2ps which doesn't seem to have a problem with these JPEG
files. The code in there is made to ignore any trailing bytes but
processes the whole stream twice if I interpret correctly. Maybe looking
for the EOI marker in our code and cutting off there is better
performance-wise. But jpeg2ps' code is on the safe side in any case.
Preferences anyone?

On 01.07.2003 17:59:52 Jeremias Maerki wrote:
 Correction: I've just dropped my current ASCII85OutputStream in the
 maintenance branch but the bug persists. There's must be another one.
 Will investigate.
 
 On 01.07.2003 17:18:20 Jeremias Maerki wrote:
  Almost suspected itI believe it's a bug in the ASCII-85 encoder
  which I've fixed in the redesign but haven't been able to upload, yet.
  I'll be able to fix the bug for the maintenance branch later this week.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]