[scribus] Scribus PDF Error

a.l.e ale.comp_06 at xox.ch
Sat Apr 3 10:26:37 CEST 2010

hi mike

> > Date: Fri, 2 Apr 2010 21:44:01 +0200
> > From: ale.comp_06 at xox.ch
> > To: scribus at lists.scribus.net
> > Subject: Re: [scribus] Scribus PDF Error
> > 
> > hi mike
> > 
> > i start to wonder why i should help you....
> Because you're a nice guy who helps new users who are unfamiliar with
> the program's history and experiencing unexpected results? :)

well, just a hint: i prefer to help people who behave

> > 3 GB should be indeed be enough. but scribus is really not
> > optimized on the side of memory consumption.
> Optimization doesn't matter much to me as long as a job can get done.
> Sure, efficient and fast are important, but the bottom line is
> whether or not an end objective can be met.

without optimization your objective can't be met as it is defined.

we may find a workaround, though, if you're patient enough...

> > the next steps would be to check your images (is the resolution of
> > your images correct? are there broken images? can scribus read
> > images correctly your images?) 
> All images display correctly in the Scribus document.  The PreFlight
> verifier reports "No problems found".  Image resolutions are
> correct.  In fact, when I print the .sla from Scribus directly to my
> printer it prints correctly.

the preflight verifier won't check your image.

and -- mostly if there is a bug somewhere -- scribus may accept to load
a buggy image but not export it to pdf.

> > if you're not using the color management system, you may try to
> > convert all images to jpg and see if then it works.
> I don't like to use jpg for "important" images because the pixels
> "change" often from the compression algorithms.

since you are doing DTP since 20 years you may be aware that exporting
the image to jpg would have resampled the image: that way we will
find out whether the tiff image has an error or not.
the error happens also with jpg so the image seems to be correct.

> I've even noticed
> discrepancies sometimes with no compression.  Therefore, I always use
> gif, bmp, or tif when image quality is of concern.  The .bmp format
> isn't supported by Scribus (according to the Get Image dialog) so
> I've been using .tif images created from either PhotoShop or Gimp.

and today you will learn that it's not a good idea to use GIF for
images that matter (i won't explain you why)
as far as i know, BMP is not a good choice either as soon as your
workflow (from the person producing the image to the print shop) is not
fully on Windows.

> > > Also, lowercase "L" and uppercase "I" are all
> > > generated bold, despite having normal style and display in
> > > the .sla file.
> > 
> > this is probably only a display problem and the printed copy will
> > be correct. (the problem does not happen any more in the unstable
> > versions of scribus)
> This is interesting since the display is fine within Scribus.
> Acrobat is displaying l's and I's in bold, and only when a style is
> applied.

exactly: this is called a display issue.
and -- as i said -- it has been fixed in the unstable branch.

> The problem has been identified as the 8 1/2 x 11 cover image on page
> 1. Deleting it has the export working fine (except for the bold l's
> and I's, which may be just a screen issue that won't be on paper as
> you suggest).  I'll need to reconfigure the .tif to get it working.

so back to RAM consumption.

scribus is putting all the images in your document in RAM. when you
export to pdf there are good chances that it's trying to put a second
copy of the pdf into RAM.

also, when putting the image into RAM, scribus uses the uncompressed
version of the image (so compressing the tif or using a jpeg will do no
difference on that matter).

3 GB is a fair amount of RAM, but it looks like that it's still enough
for that file.

you may try to put the cover page in its own file and produce a PDF
from it. it should not be a problem for your print shop to join the

putting even more RAM in your computer is probably overkill.

depending on what you are doing -- and as other people suggested -- you
may reduce the resolution of the image down to 300 dpi (or even
less; afaik, you need more only if you're producing a glossy high
quality cover; ask your print shop what resolution is needed:
throwing more pixels than needed at the job will not enhance at all the


p.s.: in your other post you write that printing works: printing is
done with native drivers and may indeed have access to better optimized
way of doing.

More information about the scribus mailing list