Okay, so we think we know the source of the problem. All the text in the PDF is drawn with text rendering mode 7, which means "add to clip". So drawing the text accumulates an enormous path, which is then use to clip. Hence the limitcheck error on clip.
Now the Ghostscript ps2write output (for some architectural reasons) simply emits the accumulated path, and drops the fonts from the output. The poppler output retains the fonts, and uses the Postscript charpath operator to create the path which it then uses to clip. So, the question is: does the poppler output work? There really should be no difference in the complexity of the path that Ghostscript emits explicitly, and the one that poppler creates via charpath, by the time the "clip" operator gets called. There is a small chance that Ghostscript could be changed to also emit the fonts and use charpath for this class of file, but it would be a lot of work, and rather pointless if it still won't work. It's possible that the answer is simply: the Postscript resulting from that PDF is simply too complicated for your printer to handle. So, in conclusion, can we test the poppler output? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1049635 Title: Cannot print a PDF on Kyocera Laser Printer To manage notifications about this bug go to: https://bugs.launchpad.net/gs-gpl/+bug/1049635/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
