View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010736 | Scribus | public | 2012-06-05 23:02 | 2012-06-09 03:31 | |
| Reporter | nzmc | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Platform | Latitude E6520 | OS | LinuxMint | OS Version | Rel 12 3.0.0 |
| Product Version | 1.4.1 | ||||
| Summary | 0010736: POD printer rejects pdf/X3 file, unprintable | ||||
| Description | File 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 Reproduce | Uncertain. Cannot upload file as it is 1.9 Gb. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
the problem is probably that the file is that huge... the printer has not enough ram to handle it... |
|
|
Please provide a link to download the file so we can have it tested. |
|
|
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." |
|
|
>> 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. |
|
|
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). |
|
|
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. |
|
|
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? |
|
|
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" |
| 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 |
