[softwarelist] Re: pdf import

  • From: John Tytgat <John.Tytgat@xxxxxxxx>
  • To: davidpilling@xxxxxxxxxxxxx
  • Date: Mon, 22 Jan 2007 21:36:59 +0100

In message <AbzMwcCHrLtFFwWB@xxxxxxxxxxxxxxxxxxx> you wrote:

> I've had a play with this. The conversion from PDF to PostScript does 
> increase the size a great deal (about 74 times)
> 
> I've not been able to find anyway of stopping this occurring.
> 
> My interpretation would be that the problem is that the JPEG data is 
> turned into a bitmap in PostScript, the loss of compression and the 
> inefficient way that PostScript uses to save files leading to the 
> increase.

That doesn't make sense to me.  I'm not following all the details in
this discussion so apologies for that but when you have a JPEG compressed
image in your PDF file, you can literally have the same compressed image
data in a PostScript file using DCTDecode filter which you can use on
Level 2 printers onwards (don't bother with Level 1 printers).  So add
to that some overhead in PostScript procset code (say 100 KByte max), then
I don't see were that 74 multiplication can come from (I suppose the
JPEG data is significant larger than the PostScript procset and PDF
file structure overhead).

So I think somehow you're unnecessary decompressing the JPEG compressed
data.

But are you sure it is JPEG compressed data in the first place, and not
e.g. Flate (ZIP) compression which has no equivalent in Level 2.

> I'm not sure what situation you are in. If your material is in PDF 
> format then you have no choice other than to deal with PDF files. If 
> your material sets off in ArtWorks for example, then saving as JPEG 
> would be a better idea.
> 
> I converted your PDF file to JPEG format using GhostScript the resulting 
> JPEG was a little smaller than the original PDF. I think this would be a 
> better approach for files like the example - i.e. containing bitmaps.
> 
> I have it in mind to offer conversion to JPEG in the TransPDF filter.

From printing standpoint of view, making a bitmap of lineart based data
sounds to me as last resort to work around problems and is certainly not
recommended as 'better idea'.  First of all you will need to select high
resolutions matching the printer resolution for getting the sharp details
right (despite that non 100% ink values will be rastered and don't need
that high resolution on their own) and JPEG compression will detoriate
this also (especially with sharp edges design where you will start seeing
ringing effects).  So it is matter of balancing between large bitmap sizes
and not gettting the best printing quality and this depending from job to
job.

Lineart based exchange is prefered IMHO as this will allow decent trapping
and last minute editing to be done as well (if necessary) and in most cases
be much smaller file sizes.

The real way forward is to be able to place PDF documents in the program
and to output the new design as a PDF file as well which contains the
placed PDF file contents.  It requires a bit more technology than merging
EPS documents in the final PS file... ;-).

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat@xxxxxxxx                             ARM powered, RISC OS driven

Other related posts: