armooo
"skipping" my printer
Had an issue with cloudprint not working. Now when I start cloudprint, it says "Skipping" and my printer name, and the printer isnt shared. What can I do to solve this?
Brent
Same issue here. Its now to that state that all printer that should be shared are skipped. Why would that happen?
Looking at the code, I'd start with a Cloud Print authentication. Monitor the output to see if there are any messages about it. Note that if you do not use the '-u' option, the authentication will timeout after two weeks.
I too am having a problem where a printer is skipped. I have a hundred (or so) printers on a cups system. The names of the two printers I'm interested in are "enet" and "enetcolor. I start cloudprint with "-i enet". The "enetcolor" printer works, but I get this message: Skipping enet
What (besides authentication problems) should I look for?
That message happens when there is cups error, or a Unicode error.
Can you print to the affected printers straight from the Linux host?
Are there extended Unicode characters in the printer name or description, etc? (Unicode support is not mature in the package).
I can print from my FreeBSD client (where cloudprint is running). The printer is called "enet". The cups description is: "enet - ENET MechE 12 (HP LaserJet P3010 Series PS)"
For comparison, one of the ones that works is called "enetcolor" The description of that is "enetcolor - ENET MechE 12 (HP Color LaserJet 5550 PS)"
So, cups seems to work for things besides cloudprint, and I don't see anything but ASCII in the name and description in cups.
I'm not a Python coder so I probably did something wrong, but looking at the concerns about encoding I changed line 347 in cloudprint.py from
with io.open(ppd_path, encoding='utf-8') as ppd_file:
to
with io.open(ppd_path, encoding='Latin1') as ppd_file:
and I now see the printers I want to see.
Of course I don't know what I might have hurt in the process.
Good catch.
I took a quick look at the Go client, and didn't find evidence that it considers encoding at all.
It looks like we only support "Globalized" ppd files. The base strings should be the ASCII subset of latin-1 and the the I18N strings are in utf-8.
http://www.cups.org/documentation.php/spec-ppd.html#I18N
From that link"
We use a LanguageEncoding value of ISOLatin1 and limit the allowed base translation strings to ASCII to avoid character coding issues that would otherwise occur
... implying that the existing utf-8 decode is correct. I wonder how to properly handle this - try whichever encoding doesn't throw an exception?
My guess is that we need to parse the ppd files as byte strings into a dict. Then we can use the LanguageEncoding to decode the all of the values unless the base decoding is ISOLatin1 then if it has non-base strings we should decode it as UTF-8 otherwise ISOLatin1.
This other option may be that google updated the parsing on the server size and we can send it as a raw text string now.
On Mon, Mar 7, 2016 at 11:13 PM, Jason [email protected] wrote:
This other option may be that google updated the parsing on the server size and we can send it as a raw text string now.
That would be my guess.