View Issue Details

IDProjectCategoryView StatusLast Update
0010736ScribusPDFpublic2012-06-09 03:31
Reporternzmc Assigned To 
PriorityhighSeveritymajorReproducibilityN/A
Status newResolutionopen 
PlatformLatitude E6520OSLinuxMintOS VersionRel 12 3.0.0
Product Version1.4.1 
Summary0010736: POD printer rejects pdf/X3 file, unprintable
DescriptionFile passes compliancy checks, however, cannot be printed. Printer advises that they are unable to RIP the file, hence the printer will not print the file. Several printers report same result. File can be converted to ps file with Acrobat; ps file conversion back to pdf with Distiller fails.
Steps To ReproduceUncertain. Cannot upload file as it is 1.9 Gb.
TagsNo tags attached.
Patch

Activities

ale

2012-06-06 06:39

manager   ~0028095

the problem is probably that the file is that huge... the printer has not enough ram to handle it...

cbradney

2012-06-06 07:13

administrator   ~0028096

Please provide a link to download the file so we can have it tested.

nzmc

2012-06-07 20:04

reporter   ~0028103

Re file being huge - could be, however, the POD provider is blurb, who specifies that they take files up to 2Gb, and on their forum you encounter many users who submit files of 1-2 Gb w no problem - some generated with scribus. Re link - https://docs.google.com/open?id=0B7CQ03nSVsrgZWxvOHpuU0NfRVE. From various posts, seems the most likely culprit relates to problems with font embed/outline into pdf/X3. Ale posted on one thread where user self-resolved by changing fonts. Alternate causes reported as well. Though scribus may not be generally aware of the issue, blurb is. Blurb was not informed that the pdf was generated with scribus; their feedback was "Unfortunately, PDF files created with Scribus have had inconsistent results, which is why we haven't been able to offer an official workflow for it."

jghali

2012-06-07 21:42

administrator   ~0028104

>> however, the POD provider is blurb

Blurb does not print or rip the files itself. That work is subcontracted to printers usually depending on customer location. The success of rip operation totally depends on the printer equipment. However such big files are notorious cause for rip failures. In my previous company we were systematically splitting such files before processing them to avoid such errors.

nzmc

2012-06-08 06:37

reporter   ~0028105

Correct, blurb does not print or rip. This point about other printers has been investigated on blurb's end - see original report. They sent the file to a variety of printers. They have had files this large, made by Scribus - and other apps, printed, however, also as previous, they do note "inconsistent results with Scribus" (see previous comment about their file size limit and user experiences with printing large files on blurb forums). Of previous problems with scribus of this ilk, some did not involve large files, see, for instance, http://nashi.altmuehlnet.de/pipermail/scribus/2005-December/014451.html http://old.nabble.com/Font-problem-with-PDF-treated-by-the-printer-td30547481.html continued http://old.nabble.com/Font-problem-with-PDF-treated-by-the-printer-td30547481.html http://www.desktoppublishingforum.com/bb/archive/index.php/t-4588.html http://forums.scribus.net/index.php/topic,62.15.html (and previous page), etc. (list not complete, as also noted, other sources of same result for scribus pdfs reported in various on-line posts).

jghali

2012-06-08 11:58

administrator   ~0028106

Last edited: 2012-06-08 12:06

Downloaded and tested your PDF :
- Acrobat X preflight does not report any warning or error vs pdf syntax.
- Acrobat X preflight does not report any warning or error vs PDF/X-3 compliancy
- Acrobat X convert file to postscrit without any problem
- Acrobat X Distiller converts back that file to PDF without any warning or error
- Ghostscript can rip that file without any problem (yes Ghostscript is also a Rip and is embedded as such in several printers).

So that keeps pointing at problems on the printer side.

Finally some comments about posted message

> http://nashi.altmuehlnet.de/pipermail/scribus/2005-December/014451.html
> http://old.nabble.com/Font-problem-with-PDF-treated-by-the-printer-td30547481.html
> http://old.nabble.com/Font-problem-with-PDF-treated-by-the-printer-td30547481.html

Old rips had often broken support for Type 3 fonts and custom font encoding. Those type of fonts and encoding are fully described by PDF 1.3 specifications and their support is *not* optionnal. Same kind of problem than Harlequin rips which claimed PDF 1.3 compliancy but did not implement support for CID-keyed fonts which are also part of PDF 1.3 specs, so when Indesign was released, they were not able to rip Indesign files. Failure to implement specs is rip provider responsibility.

> http://www.desktoppublishingforum.com/bb/archive/index.php/t-4588.html

Typical problem of printer whose workflow support only partially PDF/X-3 and who should request PDF/X-1a instead. Denote lack of technical skills on the printer side.

> http://forums.scribus.net/index.php/topic,62.15.html

Only thing we can really improve. Caused by outlining of fonts.

nzmc

2012-06-09 03:19

reporter   ~0028110

about tests last message and "keeps pointing at problem on the printer side" - makes sense, though, does printer problem seem as likely when the POD provider shopped the file around to a variety of shops (are they all clueless)?

the original file, intent was to use only Fontin fonts (regular, bold, italic, small caps) - for some reason, bitstream charter appears as used in the file - could not find this. Any advice/insight about the font role in present problem? Document setup/fonts in scribus indicates that Fontin does embed, embed checked in pdf/x3 export dialog, and Fontin is not MS font.

Plenty of examples (others' work) of large files, made with scribus, sent to blurb, rave results - any idea why this particular file is hosed? Did find examples of other apps, same problem - not reported lately re InDesign - any clues there?

nzmc

2012-06-09 03:31

reporter   ~0028111

This just back from blurb. Note: two files were sent - a "pages" file (the problem file that you have examined), and a "cover" file. The latter was ok. About the "page" file, regarding file size and file splitting (jghali comment Jun 07 23:42), blurb says

"As a matter of fact, instead of simply splitting the PDF file into smaller pieces, they split it up page by page and were still unable to RIP the file"

Issue History

Date Modified Username Field Change
2012-06-05 23:02 nzmc New Issue
2012-06-06 06:39 ale Note Added: 0028095
2012-06-06 07:13 cbradney Note Added: 0028096
2012-06-07 20:04 nzmc Note Added: 0028103
2012-06-07 21:42 jghali Note Added: 0028104
2012-06-08 06:37 nzmc Note Added: 0028105
2012-06-08 11:58 jghali Note Added: 0028106
2012-06-08 11:58 jghali Note Edited: 0028106
2012-06-08 12:00 jghali Note Edited: 0028106
2012-06-08 12:01 jghali Note Edited: 0028106
2012-06-08 12:06 jghali Note Edited: 0028106
2012-06-09 03:19 nzmc Note Added: 0028110
2012-06-09 03:31 nzmc Note Added: 0028111