(old)Puppy Linux Discussion Forum

fantastic work! I installed my printer first time just now which was amazing, then couldn't print a pdf. But i installed your latest and it worked perfectly! Thanks.

Does anybody know why if you change the printer settings to print in black and white, it still comes out in colour?

That's because the pdf-writer backend doesn't look at the arguments but rather uses the deafults. I've started to look at fixing that oversight.

Thanks for pointing it out.

But if I go into the CUPS settings and set the printer to print in grayscale, then print something with lpr -P Cups-PDF, then I thought it should print in grayscale... am I wrong?
It doesn't anyway.

disciple wrote:But if I go into the CUPS settings and set the printer to print in grayscale, then print something with lpr -P Cups-PDF, then I thought it should print in grayscale... am I wrong?
It doesn't anyway.

let me reply in verse...

a pretty workaround
few days ago found.
A ghostscript you need
and these instructions feed
type in console this code
for pdf grey mode:

(needs ghostscript 8.61 or upper - Muppy-Mini have bult-in)

Someone in another thread pointed out that this is creating pdfs with text that isn't selectable (in viewers that respect the security settings). I tried specifying the pdf security settings by changing the gs command in ps2pdf, but it doesn't seem to work. Any ideas anyone?

If I ever get the time I'd like to sort out the problems with CUPS-PDF, and with creating PDF's in general in puppy. To that end, lets compile a list of issues:

1. CUPS-PDF doesn't obey any settings that you choose when printing - e.g. grayscale as I mentioned. It doesn't even seem to obey page choices!
I think because a lot of programs have limited options when printing it would also be good if the dialogue that asks where to save the pdf also has all the different driver options, and picks up any options you put in when you printed it... this is obviously a bit more complicated though.
2. As I mentioned above, CUPS-PDF tends to produce documents with strange permissions - e.g. you can select text, but it isn't searchable. Last time I looked at this I thought something was wrong with ghostscript in Puppy that is causing this. N.B. because I've messed around with my ghostscript I'm now not certain what the original behaviour is - someone said it produces pdfs that aren't searchable and you can't select the text either... I guess they are probably right.
3. Currently if I print to CUPS-PDF from gtklp the print job just vaporises.... no idea what's going on.
4. CUPS-PDF doesn't work when using a remote display (e.g. when running in Colinux ). I think this could be fixed just by reading the DISPLAY variable???
5. Forgot no. 5 but I think it was related to no. 3 or 4.
6. Anyone know anything else?

BTW A related interest I have is creating a gui to help people print booklets or whatever, like some Windows printer drivers have - putting the pages in the right order depending on the print layout, printing half the pages and then telling the user to take the printed pages, rotate them or flip them over or whatever, and put them back in to print the other side... not sure that I'll ever have time to do this - I still haven't got back to working on another program I'm supposed to be doing

N.B. a couple of people have said things like this "The old CUPS-PDF printer backend needs recoding in order to work with the new CUPS security features."
I don't know anything about CUPS security features, but this is not the issue I am talking about with pdf security level, as that is a problem with the old CUPS version too.

Oh, right. My problem with not being able to specify to print pages in a different order (they always come out in numerical order) is an openoffice bug. It's another one of these really basic bugs in OOo that have been around for years and years and years. Vote for it at http://www.openoffice.org/issues/show_bug.cgi?id=11831

I think the trouble with OOo must be that even though everyone uses it they don't have anywhere near enough developers.

To anyone who is interested:
- we should possibly consider using this project, for the sake of not having to maintain our own unique Puppy system: http://code.google.com/p/i-v-p-cups/downloads/list
We would have to write another filter to use ps2pdf instead of pdftk or whatever it was they use.
I think zenity is basically compatible with xdialog... if it isn't, there'd be no point in pursuing this idea - last time I looked zenity plus dependencies was a bit big for Puppy.
Personally I'm not keen on the idea of having a daemon for it either.

I thought I'd have one last google for a program that provided an easy way to manually print duplex when you don't have a duplex printer, and I found http://www.rastersoft.com/gtkpsproc.html

It is a great start. For setting it up as a CUPS printer it has a horrible Gnome/Python daemon, but there must be a simpler way to do that. Apart from that it has these issues:
- [really minor] The "close" button in the "Information" window doesn't work. You can close it with the window manager, but then can't open it again until next time you run gtkpsproc.
- [minor] For some reason when you use the built-in "print to file" option it warns about the printer not being configured.
- [very disappointing] The built-in "Print to file" gives you a choice between ps and pdf, but always produces ps.
- [minor] it doesn't automatically append an extension when you use the "print to file option".
- the built-in "print to file" option doesn't give you a choice of paper size.
- [minor] the built-in "print to file" option doesn't remember where you last saved a file.

It requires these from psutils, which are all pretty small:
ps2ps
psnup
psbook
libpaper

While playing with it I found that half the time the ps2pdf in puppy outputs on letter paper rather than A4, which seems to be a disturbingly common problem if you google it. (Actually, I'm not certain if ps2pdf or psnup is at fault, but I suspect the former). Anyway, if I print to file using gtkpsproc and want to convert to pdf (which Puppy's gsview substitute script does to display ps files in epdfview) I have to use this option with ps2pdf to stop the stupid thing outputting to letter paper, with one side of the page cut off:

Oops, missed one important issue, although it should be easy to fix:
it writes its temporary files inside the save file

ttuuxxx has posted libcups-gnomeprint-2.18.5-i386.pet

here

http://www.murga-linux.com/puppy/viewto ... start=1845

it may be unrelated, but seems to sort some of the printing problems

Aitch

I had the impression it fixed problems in Ttuuxxx'2 2.20 or something like that, not Puppy in general.

disciple wrote:2. As I mentioned above, CUPS-PDF tends to produce documents with strange permissions - e.g. you can select text, but it isn't searchable. Last time I looked at this I thought something was wrong with ghostscript in Puppy that is causing this. N.B. because I've messed around with my ghostscript I'm now not certain what the original behaviour is - someone said it produces pdfs that aren't searchable and you can't select the text either... I guess they are probably right.

Sit Heel Speak asked me if I have made any progress on this, and I thought I should probably post here in case anyone else is interested.

First I'd like to clarify the problem. CUPS-PDF creates pdfs that display correctly in all viewers that I've tested, but:
- the text is neither searchable nor selectable in epdfview
- the text is not searchable in Adobe Reader 9.x (Windows or Linux). It is selectable but copying it just produces nonsense like this (normally shows up as squares in a text editor)


- the text IS searchable AND copies correctly in Foxit Reader (Windows and Linux versions) (Yay!)
- the utility that comes with xpdf for converting pdf to text doesn't recognise the text.
- Gsview doesn't recognise the text
- if the pdf is printed again to PDF (on Windows), using the PDFill pdf printer, or the Adobe PDF printer, the new pdf has the same characteristics.
Interestingly, I've noticed that PDFs exported by some other free software (e.g. QGIS) have the same or similar characteristics.

Here's some of my reply to SHS:

disciple (PM to SHS) wrote:So, my theory is that CUPS-PDF is generating PDFs with an unusual font encoding.
...
If the theory is correct, this is a bug in both epdfview and Adobe Reader... but we should be able to work around it if we can figure out how to generate PDFs with a less unusual encoding.
The theory is reinforced by pages like http://www.rhinocerus.net/forum/lang-po ... earch.html
But Puppy has a more recent ghostscipt than the one reported to work there... so why are our pdfs faulty? Maybe this is the answer http://www.rhinocerus.net/forum/lang-po ... earch.html

Heh ...working on it...

What puppy are you using SHS? Have you tested with a recent version? (I haven't).

Wait... I just booted with pfix=ram and discovered that it works fine...

Copied /etc/cups from the save file and restarted cups - still works.
Copied the updated Poppler from my save file - still works.

What else could be the problem? My locale?

Hmmm.
Installing HPLIP-lite makes no difference.
Copying /etc/profile makes no difference.
The ppd and the backend are the same.

Hmmm.
It doesn't seem to be my pango or my glib or my cairo or my up/downgraded freetype.
`ldd epdfview` isn't showing quite the same thing. Does anyone know how to trace which dependencies are pulled in by which other dependencies?
I thought ldd -v would show me, but it doesn't seem to

disciple wrote:What puppy are you using SHS?

A September 5 local woofbuild of t2-8.0rc Quirky.

What is really needed is a fresh compile of the whole pango chain. Correct compilation of it and especially poppler is, indeed, the key to PDF printing, and Puppy's poppler just isn't complete. I believe that at least somewhere around half our PDF problems stem from our poppler's several features-shortfalls.

Puppy's "stock" gcc just isn't up to the task of compiling pango/poppler. I noticed this a year ago when I was creating my extravagantly-patched gcc 4.4.1. Now I have a nearly almighty gcc 4.4.3, but even it fails. The problem lies in, extends back clear into, the toolchain. Not even Quirky's toolchain is good enough, and it's t2.

So, I've been studying LFS (and CLFS), and keeping an eye on Saluki, and have made a start on an LFS Puppy, or really I should say LFS Quirky.

I'll have a go at compiling poppler then pango this weekend, and may come up with something intelligent to say.