[scribus] Scribus PDF Error - Closed

Mike Sleger chappa-ai at msn.com
Sat Apr 3 16:08:38 CEST 2010


This can be considered closed, thanks for all your help.  Here is what I chose to do:

1. Page 1 (cover page) is just a full-page tiff image and doesn't *really* need to be included in the page layout file.  I found a handy Convert Image to PDF tool (http://www.softinterface.com/Convert-Image-To-PDF%5CConvert-Tiff-To-PDF.htm<http://www.softinterface.com/Convert-Image-To-PDF%5CConvert-Tiff-To-PDF.htm>) that quickly and nicely converts the native TIF to PDF without placing it in any application.

2. Exporting the remaining pages to PDF using Scribus 1.3.6 allows me to embed the Adobe outline font instead of outlining it, and the bold I's and l's issue goes away.  There's also a lot of interface and feature improvements in 1.3.6, but I'm keeping a copy of the 1.3.3.14 document for backup.

3. I could just leave it at that and take two PDF files to the printer, but optionally I can use PDF Split and Merge (http://www.pdfsam.org/<http://www.pdfsam.org/>) to join the cover PDF and content PDF.

Thanks again for everyone's time and suggestions.

  ----- Original Message ----- 
  From: a.l.e<mailto:ale.comp_06 at xox.ch> 
  To: scribus at lists.scribus.net<mailto:scribus at lists.scribus.net> 
  Sent: Saturday, April 03, 2010 2:26 AM
  Subject: Re: [scribus] Scribus PDF Error


  hi mike


  > > Date: Fri, 2 Apr 2010 21:44:01 +0200
  > > From: ale.comp_06 at xox.ch<mailto:ale.comp_06 at xox.ch>
  > > To: scribus at lists.scribus.net<mailto: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
  nicely...


  > > 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
  PDFs.

  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
  result).

  hth
  a.l.e


  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.

  _______________________________________________
  scribus mailing list
  scribus at lists.scribus.net<mailto:scribus at lists.scribus.net>
  http://lists.scribus.net/mailman/listinfo/scribus<http://lists.scribus.net/mailman/listinfo/scribus>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus/attachments/20100403/655ee9ee/attachment.htm>



More information about the scribus mailing list