[jaunty] cups-pdf no longer embeds fonts in pdf file

Printed w/jaunty cups-pdf. Note: open in Document Viewer, Adobe Reader, etc., and look at the document properties fonts and compare with the hardy pdf; no fonts in the jaunty pdf.

Reliably reproduceable

Can anyone try compiling 2.5.0 against Hardy and see if it works there? If it works on Hardy, we can immediately rule out CUPS-PDF issues and presume this to be a CUPS issues, probably in which default filters are used by CUPS to produce the final document.

I've a dedicated test system with two drives - one of jaunty and one for hardy/intrepid/whatever. If you can give me instructions on how to go about this I'll be happy to give it a go. The hardy/intrepid/whatever gets reinstalled frequently, so it won't matter if it get messed up in the process.

On your Hardy or Intrepid host, open a command line terminal and do:

sudo apt-get install devscripts

dget http://archive.ubuntu.com/ubuntu/pool/universe/c/cups-pdf/cups-pdf_2.5.0-1ubuntu1.dsc

dpkg-source -x cups-pdf_2.5.0-1ubuntu1.dsc

cd cups-pdf-2.5.0

debuild -uc -us

sudo debi

Under Hardy the build succeeded but installation did fail with a dependency problem:

dpkg: Vor-Abhängigkeitsproblem betreffend cups-pdf_2.5.0-1ubuntu1_i386.deb, welches cups-pdf enthält:
 cups-pdf hängt (vorher) von cups (>= 1.1.15) ab
dpkg: Fehler beim Bearbeiten von cups-pdf_2.5.0-1ubuntu1_i386.deb (--install):
 Vor-Abhängigkeitsproblem - installiere cups-pdf nicht
Fehler traten auf beim Bearbeiten von:
 cups-pdf_2.5.0-1ubuntu1_i386.deb
debi: debpkg -i failed

I read it that cups-pdf believes to be dependent on a version of cups >= 1.1.15. However cupsys (that is "cups", right?) in Hardy is 1.3.7. Don't know, what the problem here is.

Ah yes, the package name change occurred starting at Intrepid. For Hardy, you'd need to change occurrences of "cupsys" into "cups" in the source package's debian/control under the Pre-Depends section in the "cups-pdf" section.

Actually, noticing how that issue was introduced at Intrepid (which, IIRC has cups-pdf 2.4.8), trying a recompile of the 2.5.0 package on Intrepid would be a more immediate test.

Hardy testing could also be useful, but only for extra validation.

(Hardy)

I made the following change to "debian/control":

12,13c12,13
< Pre-Depends: cups (>= 1.1.15)
< Depends: ghostscript, libpaper-utils, cups-client, ${shlibs:Depends}, ${misc:Depends}
---
> Pre-Depends: cupsys (>= 1.1.15)
> Depends: ghostscript, libpaper-utils, cupsys-client, ${shlibs:Depends}, ${misc:Depends}
15c15
< Enhances: cups
---
> Enhances: cupsys

compiled again, installed libpaper-utils and cupsys-client, got cups-pdf_2.5.0 successfully installed and and the cups-pdf printer set up.

A test print with Leafpad resulted in a searchable PDF, viewed in evince.
The same test under Jaunty produced a non-searchable PDF.
The Hardy-PDF is roughly twice the size of the Jaunty-PDF.
(see attatchments)

Thank you for testing this, Benedikt.

This seems to confirm that the CUPS-PDF 2.5.0 source code is fine, since the exact same package (minus those Dependencies name changes) compiles and works fine on older Ubuntu releases.

Given this, I'll reassign both this bug and the upstream Debian bug to CUPS, which is where this bug seems to be.

Thanks Benedikt & Martin-Éric. I think this is the reason for the issue that they are also seeing in:
https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/366949
[cups-pdf produces large pdfs and text can not be searched]
Perhaps it might be a good idea to make this a dupe of 366949 or vis a vis in order to consolidate the findings? I'm happy either way.

Can you try the following: Replace the file /usr/lib/cups/filter/pdftops by the attached file and make the new file executable ("sudo chmod 755 /usr/lib/cups/filter/pdftops"). Then try to print into a PDF with cups-pdf again. Do you get a searchable PDF now?

On 05/31/2009 01:11 PM, Till Kamppeter wrote:
> Can you try the following: Replace the file /usr/lib/cups/filter/pdftops
> by the attached file and make the new file executable ("sudo chmod 755
> /usr/lib/cups/filter/pdftops"). Then try to print into a PDF with cups-
> pdf again. Do you get a searchable PDF now?
>

Happy to give it a go, but your file didn't get attached.

Works for me. Attached result.

Dead on! Your pdftops script works, the resulting file is searchable and has fonts embeded.
I'm confused, though. The original file is a binary, yours a script.

The original binary also does not more than calling Ghostscript for turning PDF into PostScript. I use a script for the testing to more quickly apply changes and to allow users to try the changes without needing to compile. The final result will later be implemented in the original binary.

The most important change is that the Ghostscript output device "pswrite" is replaced by "ps2write". The former turns every text character into a little bitmap, producing a huge output file which has lost all text and font information. The latter conserves fonts, but produces a PostScript which is not DSC-conforming. This means one cannot separate the pages in the file. For us it is no problem, as any page manipulation has already been done before calling the pdftops filter, by the pdftopdf filter.

Currently, we are investigating whether Ghostscript's "ps2write" output works correctly with all PPDs and printers and report bugs to Ghostscript upstream if there are problems.

Thanks Till!

FWIW: I also have a pdf printer set up using:
/usr/share/ghostscript/8.64/lib/ghostpdf.ppd
and the output from that and the default cups-pdf appears to be identical, but I'll need to do a little more testing first.

Till, the workaround still has pretty serious issues (font related perhaps?).

The easiest way to see this is to open your pstops file in gedit and then print using cups-pdf. In hardy (using Evince or Adobe Reader 9.1.1) I can easily select any text. In jaunty when I attempt to select text the cursor fills about 2 inches and selects very large portions of unrelated text.

If I compare the fonts in both:
hardy: f-3-0, f-0-0, f-1-0, f-2-0 TrueType Embedded subset
jaunty: No name Type3 embeded.

I should add that this doesn't appear to be a result of your test pdftops script itself. To test I moved the hardy pdftops executable out of the way and replaced it with your pdftops script file. I then printed the pdftops from gedit (in hardy) to the cups-pdf printer and looked at the file in Evince: no issues. So the problem lies somewhere else in cups.

I was having the same symptoms and discovered the problem was the driver I had CUPS set to use.

I had setup the cups-pdf printer using the Generic->Postscript printer driver. The problem with that was that cups was first calling ghostscript to convert whatever input it received into postscript, and would then pass the postscript to the cups-pdf filter.

The first call to ghostscript however, would convert all text to images, before it even got to the pdf creation stage. The solution for me was to change the driver to RAW. This will most likely fail if you print anything other than postscript to it, but is not a problem for me as I'm calling it via Samba with the windows driver set to Apple Laserwriter PS

I think this is new behavior in CUPS, as it used to leave the input alone if it was already postscript.

I have attached a Poppler-based pdftops filter now. Can everyone who has still problems try it?

Note that currently bug 310575 still applies with it, but this will soon be solved by a Poppler fix (https://bugs.freedesktop.org/show_bug.cgi?id=19777, bug 382379).

It's getting closer... the pdftops printed from gedit now behaves properly (attached). However the other test, the release notes, is not rendering many fonts; compare this attached pdf to the one from hardy in http://launchpadlibrarian.net/27282922/job_1351-9_04_Release_Notes___Ubuntu.pdf

Let me know if you'd like me to run further tests.

Can you try the pdftops version attached now? Does it print all text now?

Just like in the movies :-) See attached.

Note: gedit pdf print of the pdftops script file worked just fine as well.

Looked through your attachment and did not find anything wrong in it. Seems that my current version of pdftops solves the bug.

Looks good to me as well, thanks for the great work! I'll test with other applications over the next 1-2 days & report back if I encounter any difficulties. Thanks again Till.

Till, the pdftops file works with pdf. However, I've discovered that it borks all of my standard cups printing.

Every time I try to print now I get
errors with a cute little windows like popup asking me if I wish to
'Diagnose' the error: Print Error 'There was a problem processing
document blah, 'Diagnose' and then I get a Windows type
'Trouble-shooting Printing' "In the next few screens I will ask you some
questions about your problem with printing. Based on your answers I will
try to suggest a solution. Click 'Forward' to begin." It then gets a "Empty print file!" error, which I think may be related to: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/193636
[pdftops does not take -cfg option]

Moving the original pdftops back to /usr/lib/cups/filter allows me to print via cups again.

Same problem here using Jaunty, pdfs are empty. Using the new pdftops is no help.

After wasting way too many hours on this problem, the only result was that Openoffice stopped printing some text files (while others were no problem).

In vain, I started deleting all config files, including all .openoffice-folders in the home dir. Now EVERYTHING including pdfing works again.

Anyone who has still problems please attach an error_log. Proceed as described in the "CUPS error_log" section of https://wiki.ubuntu.com/DebuggingPrintingProblems.

OK... I'm confused. We've already noted that the patched pdftops file works to print pdf's, but as a result creates problems in printing to anything else via cups. Do you want the error log using the patched pdftops file or the original?

NoOp, I need the error_log for the patched pdftops file. It should conmtain the log of a job to a usual printer (as this is the case which fails for you). In addition, I need the PPD file of the failing print queue (/etc/cups/ppd/<queue name>.ppd).

On 06/09/2009 02:02 PM, Till Kamppeter wrote:
> *** This bug is a duplicate of bug 382379 ***
> https://bugs.launchpad.net/bugs/382379
>
> NoOp, I need the error_log for the patched pdftops file. It should
> conmtain the log of a job to a usual printer (as this is the case which
> fails for you). In addition, I need the PPD file of the failing print
> queue (/etc/cups/ppd/<queue name>.ppd).
>

Got it. Will do later today as I'm printing several photos etc., & need
to get that out of the way before I reinstall the patched pdftops file.

Here you go. I am attaching a pdf printed with the patched pdftops (works), error_log, ppd for the printer that works with the original pdftops, and troubleshoot.txt from attempting to print via the troubleshooting dialog.

NoOp, thank you for your files, I have found the problem. A new, fixed pdftops is attached.

Everyone, please replace your current pdftops by the one attached here, test, and report your results.

Till, printing to the printer via cups. But the PDF print is back to
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/381788/comments/22

When I attempt to select text the cursor fills about 1 1/2 inches and selects very large portions of unrelated text.

I've attached the most recent pdf printed using this version.

Same Ubuntu Home page pdf using 'print to file'.

Sorry, I attached the wrong file. Please use the one attached to this comment.

$ md5sum pdftops
4ff551c15c13a8b64880c2b99dba0cfa pdftops

Works! Both PDF and to the printer via cups. Attached is same Ubuntu Home page pdf using this pdftops.

Thanks Till, well done!

Thank you very much, please watch out for the new CUPS packages in bug 382379.

Till! Thank you!

I'm noticing something in all of the pdf examples here, on my machine, and output to an HP Laserjet 6L and HP Photosmart 6280. Is anyone else seeing the odd text kerning? I've noticed that the letter "o" crashes into other letters, etc.

Johnny Bilek, please report this as a new bug instead of hijacking an arbitrary, already fixed bug for this. According to the printers which you are using the pdftops filter which is discussed here is not even used.

Hi, I don't know if this is the proper place to post my problem here but I think it might be related.
My cups-pdf works fine all the time but recently (I don't know when it starts, but surely after I upgraded to Ubuntu 10.10) I found I can't do the text search for the pdf file I created by cups-pdf. Unlike the problem showed above, I still can do text selection, which means the file does not become an image pdf file. However, if I copy the text that I selected, and paste to somewhere else, I only see unknown square blocks (which means the system can't find the fonts for the text). As a result, I can't type a text string and do the search on the pdf file since the system won't recognize the text in the pdf file.

Under firefox, if I choose to print to file and then choose pdf, the created pdf file has no problem to perform the text search task. But pdf file created by cups-pdf printer fails to do such task.

OS: Ubuntu 10.10 (upgraded from 10.04)
$ uname -a
Linux jason-1 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux

$ aptitude show cups-pdf
Package: cups-pdf
State: installed
Automatically installed: no
Version: 2.5.0-16
Priority: optional
Section: universe/graphics

Please find the attached pdf that I created. Can anyone here help me to find the problems?