Opened 12 years ago

Closed 10 years ago

Last modified 9 years ago

#248 closed defect (feedback)

1.3.5 prints only garbage

Reported by: ataylor Owned by:
Priority: Feedback Pending Milestone: 1.4.0
Component: Plugin: PDF Version: 1.3
Keywords: Cc:

Description

Updated to 1.3.5 and printing no longer works.

Instead, the printer spits out endless pages with only a gray box containing the message

  ERROR NAME;
     undefined
  COMMAND;
     fi=k,+
  OPERAND STACK;

Reverting to 1.3.4 causes the same PDFs to print successfully again.

Using Brother HL-3075CW (native printer object, PSPRINT driver with imported PPD). The PDF(s) in question were created by Scribus 1.4.1.

Change History (6)

comment:1 by ataylor, 12 years ago

This is a PDF which I was printing:

http://www.altsan.org/creative/fonts/Type-Portfolio.pdf

This ZIP contains the output of printing page 5 to file (using PSPRINT.Generic Postscript Printer), using both Lucide 1.3.4 and 1.3.5.

http://www.altsan.org/creative/fonts/test_print_output.zip

The .PS file produced by 1.3.5 is reported as invalid by GSView. As reported, printing to an actual printer produces the garbage output described above.

comment:2 by Silvan Scherrer, 12 years ago

Milestone: 1.4

this seems a poppler regression. i need to investigate that when i have time.

comment:3 by ataylor, 12 years ago

OK, it appears that the problem specifically occurs with PDFs (generated by Scribus 1.4.1 in this case) which specify a non-standard font which is not included (either embedded or outlined) in the document.

In the example, the font "GaramondNo8" (a free URW font normally included with GhostPCL) is specified in the document for a couple of blank lines. Scribus presumably did not embed or outline it by default because there is no actual visible text in this font. I was able to eliminate the problem by forcing Scribus to outline the font in the document. (I believe embedding is only offered as an option if there is a certain minimum amount of text used.)

I've produced the same error with a different font (Droid Serif) that is used by some visible text. In this case, the font also was not embedded (or outlined) in the PDF, but left for the system to handle.

The problem does NOT appear to be triggered by a font like Helvetica, which is one of the default Postscript fonts and is therefore handled natively by Postscript devices.

Last edited 12 years ago by ataylor (previous) (diff)

comment:4 by Silvan Scherrer, 10 years ago

Priority: majorFeedback Pending

does the same also happen with qpdfview?

comment:5 by Silvan Scherrer, 10 years ago

Resolution: feedback
Status: newclosed

no feedback from the user --> closing it

comment:6 by Lewis Rosenthal, 9 years ago

Milestone: 1.41.4.0

Milestone renamed

Note: See TracTickets for help on using tickets.