Page 1 of 1
Puppy 5.20 PDF printing error (semi-solved -- strange bug)
Posted: Fri 28 Jan 2011, 03:33
by RetroTechGuy
OK, I have installed Puppy 5.20 (previous version was 4.3.1), and seem to have everything working except the printer. I want to print to a PDF, and nothing seems to happen.
Opening up the control panel, I see:
Code: Select all
CUPS-PDF-7 Jobs - CUPS 1.4.3 root 136k Unknown canceled at
Sat Jan 29 02:21:58 2011
"/usr/lib/cups/filter/cpdftocps failed"
It's also curious that the date/timestamp is in the future (it's Jan 27 right now...)
I did several searches, but find no such errors for 5.20. Has anyone else seen this? Is there some simple adjustment I need to make?
Trying "pdf-writer" seems to produce no output, which is also strange:
Code: Select all
pdf_writer-8 Jobs - CUPS 1.4.3 root 136k Unknown completed at
Sat Jan 29 02:21:52 2011
Posted: Fri 28 Jan 2011, 03:52
by rcrsn51
I just did a fresh frugal install of Lupu 520 and both PDF writers worked fine. What else have you installed?
Posted: Fri 28 Jan 2011, 04:10
by RetroTechGuy
rcrsn51 wrote:I just did a fresh frugal install of Lupu 520 and both PDF writers worked fine. What else have you installed?
Firefox and the "mg" editor from Debian (I had this latter in 4.3.1). Oh, and I placed tclkit in /usr/local/bin/
Update: I wondered if some of the Firefox plugins were causing the problem, but the same non-print occurs when I try it from Geany.
Posted: Sat 29 Jan 2011, 05:04
by RetroTechGuy
Update #2.
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?
Posted: Sat 29 Jan 2011, 07:35
by jpeps
makes sense, since they're just human readable addresses
Posted: Sun 30 Jan 2011, 15:30
by RetroTechGuy
jpeps wrote:makes sense, since they're just human readable addresses
It doesn't make sense to me...
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"...
Posted: Sun 30 Jan 2011, 16:16
by rcrsn51
RetroTechGuy wrote: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.
Why do you need to change the hostname?
Posted: Sun 30 Jan 2011, 16:30
by rcrsn51
Try this:
Go to /usr/lib/cups/backend and open the file pdf-writer. Line 69 is
Code: Select all
PUPPY_LINUX=`uname -a | grep -ic puppy`
Change "puppy" to the new hostname. Don't accidentally delete the final back-tick character.
I'm not sure why the code was written that way. It appears to have something to do with remote printing.
Posted: Sun 30 Jan 2011, 20:19
by jpeps
I think hostnames are connected to local IP addreses and other identifiers that provide maps to/for the local device.
Posted: Tue 01 Feb 2011, 16:13
by RetroTechGuy
rcrsn51 wrote:Try this:
Go to /usr/lib/cups/backend and open the file pdf-writer. Line 69 is
Code: Select all
PUPPY_LINUX=`uname -a | grep -ic puppy`
Change "puppy" to the new hostname. Don't accidentally delete the final back-tick character.
I'm not sure why the code was written that way. It appears to have something to do with remote printing.
Thanks rcrsn51, I'll give it a try in a few days (not at the machine I was testing).
I'm currently working on migrating all my computers to Lupu 520 (and just LinNWin-ed my XP laptop, which is working fine!)
Posted: Fri 11 Feb 2011, 20:12
by rerwin
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: Select all
[ ! -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
Posted: Fri 11 Feb 2011, 22:56
by 01micko
That looks ok to me rerwin.. but the question in my mind is.. why even have that test at all? It is obvious the script is heavily modded for Puppy.
Cheers
Posted: Sat 12 Feb 2011, 04:50
by Roy
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).
-Roy
Posted: Sat 26 Mar 2011, 12:19
by wuwei
Yep
reporting the exact same problem on luci257.
Changed hostname and pdf printer didn't work anymore.
Thanks to rcrsn51, it's up and running again.
And....Roy's recommendation works, as well (after undoing rcrsn51's).
Thanks to both!
Why change hostname?
With 5 frugal Puppies on one machine, try Xmarks addon in Firefox. You won't be amused about the screw-ups there.
Posted: Sun 27 Mar 2011, 08:45
by charlie6
@rcrsn51!
in puppy 4.20 I edited /usr/lib/cups/backend/pdf-writer
Before editing I had regularly non-working-pdf-writer with an error message as mentionned by forum member Retro TechGuy.
rerwin wrote:Go to /usr/lib/cups/backend and open the file pdf-writer. Line 69 is
Code:
PUPPY_LINUX=`uname -a | grep -ic puppy`
I commented that line (Nr 78 in puppy-4.20-Xtreme) and added afterwards lines 79 and 80 as (copy + paste):
Code: Select all
[ ! -f /etc/rc.d/PUPSTATE ]
PUPPY_LINUX=$?
Now it seems it works.
Thanks to all !
Cheers, Charlie
Posted: Mon 28 Mar 2011, 00:19
by jon4t2
Roy wrote: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).
-Roy
Roy's fix works again!
Thanks!
Posted: Mon 25 Apr 2011, 06:22
by wuwei
Roy wrote:
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).
Careful....!
At least in Wary 511 this fix causes gdmap to crash.
This instruction, however, works in Wary without affecting gdmap:
rcrsn51:
Go to /usr/lib/cups/backend and open the file pdf-writer. Line 69 is
Code:
PUPPY_LINUX=`uname -a | grep -ic puppy`
Change "puppy" to the new hostname. Don't accidentally delete the final back-tick character.
Posted: Sat 20 Aug 2011, 13:10
by night_mare007
rcrsn51 wrote:Try this:
Go to /usr/lib/cups/backend and open the file pdf-writer. Line 69 is
Code: Select all
PUPPY_LINUX=`uname -a | grep -ic puppy`
Change "puppy" to the new hostname. Don't accidentally delete the final back-tick character.
I'm not sure why the code was written that way. It appears to have something to do with remote printing.
On Puppy Lucid 5.25 ( Macpup 5.25 ) this solution solve the problem.
I even made It better...
dosn't just change your user name to your current but change it to the letter "1"... so no matter what's your puppy user name - it will work always.
so you need to have this line look like this:
Code: Select all
PUPPY_LINUX=`uname -a | grep -ic 1`
after the change, save, and restartX.
that's it.
THANK YOU!
Posted: Wed 14 Sep 2011, 18:48
by theinfamousj
rcrsn51 wrote:Try this:
Go to /usr/lib/cups/backend and open the file pdf-writer. Line 69 is
Code: Select all
PUPPY_LINUX=`uname -a | grep -ic puppy`
Change "puppy" to the new hostname. Don't accidentally delete the final back-tick character.
I'm not sure why the code was written that way. It appears to have something to do with remote printing.
I just wanted to let you know that you are a life-saving genius. I have never been able to get the CUPS PDF to work with any Puppy install I have ever done, and this is both the reason and the fix. Oh to be able to print to PDF without having to do a Print to File thing. Happiness.
Posted: Wed 14 Sep 2011, 19:19
by rcrsn51
Why did you change the host name in the first place?