I booted booted to RAM (no lupusave), and before installing anything at all, tried printing both to CUPS-PDF and pdf_writer. Neither produced an output -- neither asked for a filename...

checking the job status shows pdf_writer as "completed", and CUPS-PDF as "failed".

Again, the dates on each job is shown about 48 hours in the future...

Update #3: OK, now this is REALLY, REALLY, REALLY SILLY...

What apparently broke the printer was changing the Hostname from "puppypc" to something else.

Now why would this name make any difference to the local PDF "printer"?

I guess that what remains to be seen is whether naming every computer on my network "puppypc" will cause issues...

Update#4: Booting up my previously fully configured and working lupusave (but with broken printer), I edited /etc/hostname and changed the name back to puppypc. Rebooted and reloaded this lupusave, and now the printer works...

Is the printer hard wired to look for that hostname, and thus a name change breaks the path?... What gives?_________________Add swapfileWellMinded Search

It would be like having a working Chevy truck, and as soon as I put a Ford sticker on it, the wheels all fall off...

I would not expect the machine (or more relevantly, the local machine) to care what you call the local machine, for tools in the local machine to work.

It seems that the PDF printers somehow only want to print on the machine "puppypc", and could not "print to PDF" on the exact same hardware, if that machine were called "jpeps"..._________________Add swapfileWellMinded Search

What apparently broke the printer was changing the Hostname from "puppypc" to something else.Now why would this name make any difference to the local PDF "printer"?Is the printer hard wired to look for that hostname, and thus a name change breaks the path?... What gives?

This issue came up a while ago. There is some code in the pdf-writer backend that is tied to the hostname. There are some work-arounds, but I've forgotten. I'll get back to you on this.

Go to /usr/lib/cups/backend and open the file pdf-writer. Line 69 is
Code:
PUPPY_LINUX=`uname -a | grep -ic puppy`

Looking at that code, I see that PUPPY_LINUX is used only to identify running in a puppy environment, versus any other distro. A bit tricky, to me, with an unintended consequence. Here is another way to set it to indicate running in puppy:

Code:

[ ! -f /etc/rc.d/PUPSTATE ]
PUPPY_LINUX=$?

I have not tested pdf-writer with this, but those who are already modifying the script might try it. (I tested in a console.) The variable is set to "1" for puppy, otherwise zero -- the later test is for zero.

Barry might have a "standard" way to identify that a distro is a puppy, but this is what came to mind right now.
Richard

If I remember correctly, the work-around or fix for creating (printing to file) a .pdf document with a changed host name was to add a blank file named .Xauthority to root (the period before the file name indicating that it is a hidden file).

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum