support for printing via a cups backend script

[totaam]

We should be able to place our own script in /usr/lib/cups/backend/ and have it forward the data to print to the client using xpra control. (see also #494)

[totaam]

2014-07-14 18:10:42: totaam uploaded file printing.patch (32.5 KiB)

work in progress patch

[totaam]

2015-02-05 11:31:45: antoine uploaded file printing-v3.patch (35.7 KiB)

updated patch with rpm packaging

[totaam]

2015-02-06 05:20:49: totaam commented

---

Some useful links:

• i-v-p-cups Installation And Settings
• Printing to PDF
• pdf printer scripts

On Fedora, the PPD file we can use for PDF is found in /usr/share/ppd/cupsfilters/Generic-PDF_Printer-PDF.ppd and is part of the cups-filters package.

On Fedora, to be able to use lpadmin, you need to be a member of the sys group:

sudo gpasswd -a antoine sys

Each distribution does its own thing (oh great..), see [https://bugs.launchpad.net/hplip/+bug/674570/comments/4]:

• ubuntu it is "lpadmin"
• Suse it is "sys root"
• Fedora it is "sys root"
• Debian it is "lpadmin"

Adding SystemGroup lp to /etc/cups/cupsd.conf and adding yourself to the lp group does nothing. No idea why. You have to use sys..

Running lpinfo -v can take a very long time.

To add a virtual printer which uses the xpraforwarder backend we drop in /usr/lib/cups/backend/, do:

lpadmin -p xpra -E -v xpraforwarder:/tmp/

And to remove it:

lpadmin -x xpra

check its status:

lpstat -p xpra

To check the state of its queue:

lpq -P xpra

Maybe we should allow the client to specify which PPD file to use? And maybe even upload it to the server?
Then we can add the printer using this PPD file? Or pass the PPD file to ghostscript when we generate the PDF?

[totaam]

2015-02-09 16:43:14: antoine commented

---

New TODO / work in progress items:

• include display ID in printer URI so the script can talk to the correct server (via su?) - what do we do with password protected servers? (could add a new option so unix domain sockets are not protected, which is usually fine - no way we can pass the password around safely..), what about socket-path...
• deal with errors: maybe we should send a notification to the client (and maybe not just a simple message - a notification bubble?)
• allow configuration of the lpadmin command, so users can substitute sudo or whatever they want
• server to send the list of ppd files it supports out of the box (and look for them in known places like /usr/share/cups/model/CUPS-PDF.ppd or /usr/share/ppd/cupsfilters/ on Fedora) - client can then choose one of those? (ie: generic PDF mode)
• sync printers: run lpadmin whenever printers are added or removed, and make certain we clean them up on exit!
• make sure that we only make the printer available to the user that runs the session
• pass the job title (argv 2) and number of copies (argv 4) to the client
• maybe support pdfmarks? (ghostscript-ps-pdf)

[totaam]

2015-02-10 11:33:55: antoine commented

---

New problems:

• selinux is being annoying, I don't think we want to make a policy for xpra just yet, but we will need something (for now, setenforce 0 is required)
• the temporary files we generate from the cups backend cannot be seen by the xpra server process.. so now we change everything and introduce an xpra print client (instead of using xpra control) which sends the file to print as a blob rather than by path - and is useful to have in itself, just more code
• we should probably support printing without enabling file transfers..

[totaam]

2015-02-12 05:33:46: antoine uploaded file printing-v5.patch (59.6 KiB)

hacked patch for testing

[totaam]

2015-02-12 10:03:11: antoine uploaded file printing-v6.patch (60.0 KiB)

much better implementation using pipes and straight postscript

[totaam]

2015-02-16 09:34:51: totaam commented

---

Merged most of it in r8667, see long commit message.

Still TODO:

• authentication problems: maybe add a --tcp-password-file option? (so --password-file continues to work as before) Or just a --local-auth=none option?
• support print test page for diagnostics?
• notifications back to the client / server?
• win32: print via acrobat? http://stackoverflow.com/a/12642015/428751 (probably not very safe though!), other ways on win32: Win32 How Do I Print
• handle changes to printers: compare in depth the attributes that matter - poll for printer changes and send to server?
• send list of generic printers that the server supports (client can then choose one of those from tray?)

Note: I have seen lockups sometimes so this feature is currently disabled by default. More work is needed anyway. (the backtrace seemed to be in the clipboard code, hence #812, but had some nvidia stuff in it... which could also play a role here)

[totaam]

2015-02-18 09:59:45: antoine commented

---

New TODO:

• make distutils deal with the 0700 permissions on the cups backend - which is a PITA (see package_data files with executable permissions)
• until selinux is fixed somehow, detect when things aren't working?

[totaam]

2015-02-23 16:26:29: antoine commented

---

• r8690 deals with socket permissions by adding tcp-auth, so we can now start the server without any authentication required on the local socket:

xpra start --bind-tcp=0.0.0.0:10000 --auth=none --tcp-auth=file --password-file=mypasswordfile

• moving the selinux work to SELinux policy for printing #815 (until that's dealt with you have to disable selinux before trying to run the cups backend..)

[totaam]

2015-02-25 13:09:35: antoine commented

---

I think this is ready for an initial round of testing and feedback.
Remember to enable printing, either in the config file or on the command line, for both the client and server.
And disable selinux with a setenforce 0 as root.

[totaam]

2015-02-27 11:37:29: antoine uploaded file selinux-xpra-cups.patch (1.3 KiB)

simpler solution for selinux and cups

[totaam]

2015-02-27 15:13:00: antoine commented

---

Rather than writing a full policy (#815), the patch above creates a very minimal policy which allows us to transition from the cups backend context to a xpra_cups domain, which is allowed to connect to the server.

Except it doesn't work, or works by accident.
Trying to define the context properly, I get a stream of:

libsepol.context_from_record: invalid security context: "system_u:system_r:xpra_cups_t:s0-s0:c0.c1023"
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert system_u:system_r:xpra_cups_t:s0-s0:c0.c1023 to sid

And as usual with selinux, getting meaningful information out of those errors is next to impossible.
A day wasted, solution: just disable selinux for now.

[totaam]

2015-02-27 23:28:54: maxmylyn commented

---

Tested an 8709 Win8.1 client against an r8705 Fedora 20 server:

Running with setenforce 0(selinux disabled) and --printing=yes on both computers, the Windows client receives the print command but then I get the following error output in the CMD window:

   Traceback (most recent call last):
  File "xpra\platform\win32\gui.pyc", line 249, in remove_window_hooks
  File "xpra\platform\win32\window_hooks.pyc", line 85, in cleanup
AttributeError: 'Win32Hooks' object has no attribute 'old_win32_proc'
2015-02-27 13:20:59,697 failed to set group leader: 'module' object has no attri
bute 'SHGetPropertyStoreForWindow'
2015-02-27 13:21:04,198 remove_window_hooks(%s)
Traceback (most recent call last):
  File "xpra\platform\win32\gui.pyc", line 249, in remove_window_hooks
  File "xpra\platform\win32\window_hooks.pyc", line 85, in cleanup
AttributeError: 'Win32Hooks' object has no attribute 'old_win32_proc'

As far as I can tell it successfully adds the virtual printer(it shows up in the print prompt!) and then forwards it to Windows, but the Windows client is failing to print.

[totaam]

2015-02-28 01:57:55: antoine commented

---

SHGetPropertyStoreForWindow errors have now been reported in tickets #775, #756 and here... can we please get to the bottom of those where it belongs: #799.

---

the Windows client receives the print command but then I get...
[[BR]]
This error is fixed in r8713 but should not have been able to affect printing.

Why is it failing to print?
Is there anything in the print queue? In the windows event log?
Please also include the -d printing log for both server and client.

[totaam]

2015-02-28 05:21:09: antoine commented

---

OK, found some problems with win32:

• I can print from some paths, but not others.. when it fails I get A device attached to the system is not functioning. Clearly, this has nothing to do with the device! (looks like it is the file extension that dictates what is allowed and what isn't...)
• when it does print, it prints the postscript as text...

[totaam]

2015-02-28 06:20:07: antoine commented

---

I've tried using this code sample, but nothing happens, no errors... (it briefly shows up in the print queue then disappears!)

        h=win32print.OpenPrinter(printer)
        win32print.StartDocPrinter(h, 1, (title, None, "raw"))
        win32print.WritePrinter(h, file(f).read())
        win32print.EndDocPrinter(h)
        win32print.ClosePrinter(h)

Now, this works, using gsprint:

def print_files(printer, filenames, title, options):
    log("print_files%s", (printer, filenames, title, options))
    assert gsprint_dir, "cannot print files without gsprint!"
    for f in filenames:
        log("win32api.ShellExecute%s", (0, 'open', 'gsprint.exe', '-printer "%s" %s' % (printer, f), '.', 0))
        win32api.ShellExecute(0, 'open', 'gsprint.exe', '-printer "%s" "%s"' % (printer, f), '.', 0)

But somehow the ps files I try to open are showing empty!? (but they do print on unix!)

[totaam]

2015-02-28 16:21:37: antoine commented

---

After further testing, both the gsprint option and the original ShellExecute "printto" options work, as long as we feed it the "right kind" of postscript document. And apparently the one that comes out of cups isn't right. (works for unix printing..)
Maybe we do need different ppd files for each client.. (PITA).
If needed, bundling gsprint it is not a huge problem (it is GPL). Then we can just add the gsview directory to sys.path. (tested OK).

This is all made so much harder by cups on Fedora 21 getting into a spin, not seeing the printer, not giving me the option to re-add it. So now I can test win32 via virtualbox, but not native.

[totaam]

2015-03-01 06:44:21: antoine uploaded file printing-tweaks.patch (3.4 KiB)

hacks to the win32 print code to try to figure out how to make it work..

[totaam]

2015-03-01 06:48:44: antoine commented

---

Some fixes and improvements in r8725 and r8726.
With the printing tweaks patch above, it is much easier to test various implementations of the OS printing request, just by changing the GS env var. (and it also saves the file in C:\toprint.ps} which is easier to check against)

gsprint still crashes, both with ShellExecute and with subprocess.Popen, but the exact same command works fine when I run it from the command shell!? (and the printer output looks ok)

gsprint.exe -printer 'MyPrinterName' C:\toprint.ps

[totaam]

2015-03-01 06:53:52: antoine commented

---

Some useful links I found along the way - which could still be useful:

• Using Your Own Filters to Print with CUPS
• CUPS in a Nutshell: PPD_Files
• Dissecting The CUPS Filtering System - A Network Postscript RIP For non-PS Printers
• [http://www.openprinting.org/driver/Postscript]
• PostScript printer drivers for Windows
• Adobe PDF Printer Driver Plug-in
• wine registry: printing

[totaam]

2015-03-02 05:42:33: antoine commented

---

More improvements in r8732 + r8733.

I swear I had it working reliably, printed stuff using gimp, gedit and abiword without problems.
But now when I look at the resulting postscript file now, it doesn't open! Blank on win32 with gsview, crashes evince on linux. WTF.

New ideas and links:

• redmon: The RedMon port monitor redirects a special printer port to a program. RedMon is commonly used with Ghostscript and a non-PostScript printer to emulate a PostScript printer. RedMon can be used with Ghostscript as a PDF creator. could be used to forward printing from a win32 server (when shadowing).
• query-printers is not very useful I think, best to just make it event based on the client (send after hello and whenever things change if we can figure that out - via dbus?)
• GhostPCL could talk PCL instead of postscript (and use the native win32 API?)
• we should replace the print job polling API with an event interface (and emulate via a timer for those that cannot generate events)
• should we be cleaning up on exit (and killing any pending printing jobs? probably not)

[totaam]

2015-03-02 08:00:58: antoine commented

---

Created a wiki page: Printing

[totaam]

2015-03-02 08:56:58: antoine uploaded file INSTALL.ps (192.8 KiB)

example of a file we get from cups using the Cups-PDF.ppd

[totaam]

2015-03-02 08:59:46: antoine commented

---

As can be seen in the file above, the problem seems to occur somewhere in cups (tested on Fedora 20 and Fedora 21 with the cups pdf filter).
The file contains:

systemdict begin
$error begin
newerror
{(%%[ Error handled by opdfread.ps : )print errorname//ebuf cvs print(; OffendingCommand: )
print/command load//ebuf cvs print( ]%%)= flush
/newerror false store vmstatus pop pop 0 ne
{grestoreall
}if

And something like it gets printed client side...

But I am certain this was working at some point!
Options:

• figure out what to do to fix this error (no idea where to start)
• run without a PPD file in raw mode and run ghostscript ourselves so we have more control over the options (which may not be a bad idea anyway so that we can adjust parameters to match the client: paper size, etc..)

[totaam]

2015-03-03 05:47:22: antoine commented

---

Some more minor tweaks: r8740 + r8742.

Good news: if I capture the file from the spooler, pass it to MS Windows, gsprint can deal with it.
The bad news: systemd's journal is being #### and swallowing my log messages now (it wasn't earlier). Which is the easiest way of capturing stuff in the backend.

[totaam]

2015-03-03 10:24:56: antoine commented

---

I don't understand how it ever worked on win32 before r8743, but I swear that it did!
Python on win32 was screwing with the newline characters of the binary data... despite us opening the file in binary mode!?
(I have verified that this was not the cause of the problems trying to use the win32print API, so we still cannot use that)
In the process of debugging this problem, the logging has been improved and we now include a SHA1 checksum of the file data. (which didn't really help because the data was fine... it was python's IO write that corrupted it!)

Ready for testing, again. Please remember to use -d printing,file in bug reports.

Note: you will need to install gsview 5.0 in its default location on the build machine so it gets included in the installer. (C:\Program Files\Ghostgum\gsview)

PS: I was having problems with Linux clients now! (I suspect cups is a bit hosed, and I haven't tried reverting to the code that did work to confirm it - win32 being harder to support, we can fix posix clients later - shouldn't be as hard)

---

Recap for myself of the tasks that would need to be completed for this release (others can wait):

• fix? posix support
• emulate a callback api with a timer rather than using polling (though it is likely to still use polling underneath)
• remove query-printers
• try raw mode so we can call ghostscript ourselves and deal with the number of pages and paper size on the server side
• it would be nice to have better error handling: maybe register a callback for lpadmin so we can detect error exit codes and provide more help

[totaam]

2015-03-06 23:59:50: maxmylyn commented

---

Retested with r8743 Win8.1 client against an r8743 Fedora 20 server:

• Printing still not working, unfortunately. I see the client detects the printers and forwards the info to the server, with the server adding the printers. However whenever I try to print I see the following output on the server:

lpadmin: Unable to open PPD file "/usr/share/cups/model/CUPS-PDF.ppd" - No such file or directory
lpadmin: Unable to open PPD file "/usr/share/cups/model/CUPS-PDF.ppd" - No such file or directory

And for more prints:

Client:

2015-03-06 15:57:13,563 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (
[r8743](../commit/f40e7ac381d70b4bbb5ae4f6a98b7e85aefa6adc))
2015-03-06 15:57:13,563 found printer: 8388608, Printer Behind Xander,HP LaserJe
t Pro CM1415 MFP PCL6 Class Driver,, Printer Behind Xander,
2015-03-06 15:57:13,579 skipped printer: 8388608, Microsoft XPS Document Writer,
Microsoft XPS Document Writer v4,, Microsoft XPS Document Writer,
2015-03-06 15:57:13,579 found printer: 8388608, Fax,Microsoft Shared Fax Driver,
, Fax,
2015-03-06 15:57:13,579 win32.get_printers()={'Fax': {'printer-info': 'Fax,Micro
soft Shared Fax Driver'}, 'Printer Behind Xander': {'printer-info': 'Printer Beh
ind Xander,HP LaserJet Pro CM1415 MFP PCL6 Class Driver'}}
2015-03-06 15:57:13,579 process_query_printers(['query-printers']) found printer
s={'Fax': {'printer-info': 'Fax,Microsoft Shared Fax Driver'}, 'Printer Behind X
ander': {'printer-info': 'Printer Behind Xander,HP LaserJet Pro CM1415 MFP PCL6
Class Driver'}}
2015-03-06 15:57:13,579 process_query_printers(['query-printers']) exported prin
ters=Fax, Printer Behind Xander
2015-03-06 15:57:13,625 Attached to tcp:10.0.32.52:2200 (press Control-C to deta
ch)

---

And server:

2015-03-06 15:56:55,797 set_printers({'Fax': {'printer-info': 'Fax,Microsoft Shared Fax Driver'}, 'Printer Behind Xander': {'printer-info': 'Printer Behind Xander,HP LaserJet Pro CM1415 MFP PCL6 Class Driver'}})
2015-03-06 15:56:55,798 add_printer(Fax, {'printer-info': 'Fax,Microsoft Shared Fax Driver'})
2015-03-06 15:56:55,798 pycups_printing adding printer: ['-p', 'Fax', '-E', '-v', 'xpraforwarder:/tmp?remote-device-uri=None&source=da39a3ee5e6b4b0d3255bfef95601890afd80709&socket-dir=%2Fhome%2Fjimador%2F.xpra&display=%3A13&remote-printer=Fax', '-D', 'Fax,Microsoft Shared Fax Driver', '-L', 'on Max-Win81-MBP (via xpra)', '-o', 'printer-is-shared=false', '-u', 'allow:jimador', '-P', '/usr/share/cups/model/CUPS-PDF.ppd']
2015-03-06 15:56:55,805 add_printer(Printer Behind Xander, {'printer-info': 'Printer Behind Xander,HP LaserJet Pro CM1415 MFP PCL6 Class Driver'})
2015-03-06 15:56:55,806 pycups_printing adding printer: ['-p', 'Printer-Behind-Xander', '-E', '-v', 'xpraforwarder:/tmp?remote-device-uri=None&source=da39a3ee5e6b4b0d3255bfef95601890afd80709&socket-dir=%2Fhome%2Fjimador%2F.xpra&display=%3A13&remote-printer=Printer+Behind+Xander', '-D', 'Printer Behind Xander,HP LaserJet Pro CM1415 MFP PCL6 Class Driver', '-L', 'on Max-Win81-MBP (via xpra)', '-o', 'printer-is-shared=false', '-u', 'allow:jimador', '-P', '/usr/share/cups/model/CUPS-PDF.ppd']
lpadmin: Unable to open PPD file "/usr/share/cups/model/CUPS-PDF.ppd" - No such file or directory
lpadmin: Unable to open PPD file "/usr/share/cups/model/CUPS-PDF.ppd" - No such file or directory

[totaam]

2015-03-08 06:47:32: antoine commented

---

lpadmin: Unable to open PPD file "/usr/share/cups/model/CUPS-PDF.ppd" - No such file or directory

You need to install cups-pdf.

More generally speaking, you can figure out which package provides a file using either:

• A package search engine like [http://rpm.pbone.net/]
• yum whatprovides FILENAME

[totaam]

2015-03-08 11:32:03: antoine commented

---

Some updates:

• r8750 removes "query-printers"
• r8751 + r8752 add a printers change callback to the pycups client backend, so adding and removing printers on the fly will be synced with the server
• r8753 does the same for win32. Note: I was thinking that we would need to use FindFirstPrinterChangeNotification (which is not implemented in the pywin32 wrapper..) And so I started writing this code using ctypes, based on this: How to catch printer event in python - only to find that we already get a WM_DEVMODECHANGE message.. (and so we use this, hopefully we won't be getting too many spurious ones - the client code already uses a timer to batch things up, so this should also effectively throttle things and prevent us getting swamped with printer updates)
• r8755 also makes us display a more helpful message when the lpadmin command fails
• r8754 + r8756 + r8757 + r8758 + r8761 + r8762: minor tweaks and fixes (including a dbus segfault on posix..)
• r8759 + r8760: we only send a "printers" packet if things have been modified, this should mitigate the fact that we may get more WM_DEVMODECHANGE events than just printer events

Note: when testing, do not mix earlier beta builds with newer ones. Printing will not work as r8750 changes how we sync printers.

[totaam]

2015-03-21 03:52:33: totaam commented

---

Margins are much better
[[BR]]
Margins should be unchanged! (exact same code)

Could you possibly print a page with just a rectangle right at the edge of the print area, so we can see where it ends up on the page? (what margins get added)

[totaam]

2015-03-22 05:13:41: antoine uploaded file osx-cups-print-error.png (36.1 KiB)

osx printing: it is being difficult at doing very basic things, as usual

[totaam]

2015-03-22 05:25:22: antoine commented

---

OSX support (see #533#comment:61 for build instructions)

With 10.6 onwards, it should work... the printer get detected and added, but it doesn't print because cups is being crap:
[[Image(osx-cups-print-error.png)]]
Error: can't open /private/var/spool/cups/d00001-001'.`
That file is created by cups itself when we ask it to print, why on earth can't it open its own file??

For packaging, we just add "cups" to the includes - that's done in r8812.
That works OK, but we should replace the cups printer change notifications with some sort of polling as there is no dbus on OSX (or dig into the osx API - meh)

[totaam]

2015-03-23 10:39:18: antoine commented

---

In order to figure this out, r8818 adds a wrapper for the print tool.
You can use it like so:

• with no arguments to get a list of printers

./Desktop/Xpra.app/Contents/Helpers/Print 

• with the printer name as first argument and a filename as second argument:

./Desktop/Xpra.app/Contents/Helpers/Print "MyPrinterName" /path/to/a/file.pdf

Please let me know if you can get any versions to work, and if not, what is show in the printer queue (as per comment:36)

[totaam]

2015-03-27 00:00:03: afarr commented

---

Testing (locally) with a 0.15.0 8848 osx client smo built for me, both of the above worked as expected (imagine that!). Just for fun, I'll paste in what I ran.

schadenfreude:~ Schadenfreude$ ./Desktop/xpra-catalog/xpra-smo8848/Xpra.app/Contents/Helpers/Print
* Xander_Dome                      : {'printer-is-shared': False, 'printer-info': u'Xander Dome', 'printer-state-message': u'', 'printer-type': 77598924, 'printer-make-and-model': u'HP LaserJet CM1415fnw-AirPrint', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-send-document'], 'printer-uri-supported': u'ipp://localhost:631/printers/Xander_Dome', 'printer-state': 3, 'printer-location': u'Xander_dome', 'device-uri': u'dnssd://HP%20LaserJet%20CM1415fnw%20(9C9B62)._ipp._tcp.local./?uuid=434e4a36-4435-4c52-4d51-a0b3cc9c9b62'}
schadenfreude:~ Schadenfreude$ ./Desktop//xpra-catalog/xpra-smo8848/Xpra.app/Contents/Helpers/Print "Xander_Dome" ~/Desktop/xpra-catalog/ScreenConfigurationList.pdf

Looks like you have parameters right. On to the next step?

[totaam]

2015-03-28 00:49:37: afarr commented

---

Ok, tried to print a random page from the internet using firefox, same client and fedora 20 0.15.0 r8806 server.

The print dialog box, however, doesn't have the above mentioned printer, only a "Cups-PDF" printer.

[[Image(ticket598_osx-print-gui.png)]]

Trying to print saves a pdf to the home directory of the fedora server account, but doesn't output anything server or client side with a -d printing flag, nor does anything land in the client-side printer queue.

Maybe the OSX wrapper just isn't in this server revision?

[totaam]

2015-03-28 00:50:40: afarr uploaded file ticket598_osx-print-gui.png (24.6 KiB)

Cups-PDF only printer showing with osx

[totaam]

2015-03-28 01:58:19: antoine commented

---

@afarr: to debug this printing stuff, please include the -d printing log for both the server and client.
Either the printer is not detected on the client (empty result when running the Printing helper without arguments as per comment:38), or something is going wrong on the server (selinux enforcing mode, no "sys" group membership, etc)

[totaam]

2015-03-28 08:05:53: antoine commented

---

r8853 fixes printing for *nix (all platforms that use pycups: Linux, OSX, etc), simply by using the correct file extension! (ghostprint on win32 ignores it and figures out it is a postscript file!)
I haven't been able to test win32 or OSX today because virtualbox is not letting me pass-through USB devices, for whatever reason (and not the obvious ones: How to set up USB for Virtualbox?, more like this one: Why are my USB devices still grayed out in VirtualBox?) - unlikely to break things, but worth checking.

[totaam]

2015-03-30 15:39:53: antoine commented

---

Some improvements in r8871 (esp support for OSX printer changes), see commit message for details.

[totaam]

2015-03-30 21:18:40: afarr commented

---

Ok, I'm officially a bit flummoxed.

OSX 0.15.0 r8872 client against a Fedora 20 0.15.0 r8872 server.

Server side I didn't forget setenforce 0, and running the gpasswd I got a Adding user jimador to group sys notification.

The local client is finding a printer:

schadenfreude:~ Schadenfreude$ ./Desktop/xpra-catalog/xpra-smo8872/Xpra.app/Contents/Helpers/Print
* Xander_Dome                      : {'printer-is-shared': False, 'printer-info': u'Xander Dome', 'printer-state-message': u'', 'printer-type': 77598924, 'printer-make-and-model': u'HP LaserJet CM1415fnw-AirPrint', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-send-document'], 'printer-uri-supported': u'ipp://localhost:631/printers/Xander_Dome', 'printer-state': 3, 'printer-location': u'Xander_dome', 'device-uri': u'dnssd://HP%20LaserJet%20CM1415fnw%20(9C9B62)._ipp._tcp.local./?uuid=434e4a36-4435-4c52-4d51-a0b3cc9c9b62'}

I start both client and server with --printing=yes and -d printing,file.

And, I get the exact same "Cups-PDF" printer option only, as above... and I get absolutely nothing in the way of client or server side output. When I print, a pdf lands in the home directory of the user server-side. I can only guess that the server isn't getting notification of the printer from the client, though the client can obviously see (and successfully print) via the client-side wrapper you put in. (Presumably the -d printing isn't outputting anything because everything is working as it expects, given that it can't detect the client-side available printer?)

[totaam]

2015-03-30 21:21:00: afarr commented

---

• Hmm, disconnecting the client, I just noticed an error that might be informative:

got signal SIGINT, exiting
2015-03-30 13:19:01,116 server requested disconnect: client request
2015-03-30 13:19:01,116 cleanup_printing=<function cleanup_printing at 0x66b2df0>
2015-03-30 13:19:01,158 internal error: write connection TwoFileConnection() reset: [Errno 32] Broken pipe
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-smo8872/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:250: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
2015-03-30 13:19:01,165 Connection lost
2015-03-30 13:19:01,165 cleanup_printing=<function cleanup_printing at 0x66b2df0>
2015-03-30 13:19:01,213 cleanup_printing=<function cleanup_printing at 0x66b2df0>
2015-03-30 13:19:01,661 cleanup_printing=<function cleanup_printing at 0x66b2df0>

[totaam]

2015-03-31 09:42:10: antoine commented

---

Hmm. There should be messages there if you have correctly enabled printing from the command line (which you should include as well). I will attach a sample log file, which shows the initialization of the printing subsystem - even if there are no printers to send, these messages should remain.

Does the same server allow printing when connecting with a client that is known to work with printing? (ie: MS Windows, or even Linux with latest builds).

You can verify that both the server and client have enabled printing with:

$ xpra info | egrep "client.printing|printing.enabled"
client.printing=True
printing.enabled=True

You could also try one of the builds I have just uploaded, to see if there are any differences.

---

Hmm, disconnecting the client, I just noticed an error that might be informative...
[[BR]]
The only "error" there is the Broken pipe which is probably related to the sound process (we communicate with it using pipes). Nothing to worry about, you could confirm this by running without sound and see if it goes away.

[totaam]

2015-03-31 09:42:47: antoine uploaded file osx-106-client-printing.log (3.5 KiB)

printing debug log from an osx 10.6.8 client with the latest trunk build

[totaam]

2015-03-31 21:37:04: afarr commented

---

Launching your fedora 20 0.15.0 r8802 beta with [jimador@zapopan ~]$ dbus-launch xpra --no-daemon --bind-tcp=0.0.0.0:1201 --start-child=xterm --start-child=xterm --printing=yes start :23 -d printing,file, then connecting with smo's osx 0.15.0 r8872 client with schadenfreude:MacOS Schadenfreude$ ./xpra attach tcp:10.0.32.53:1201 --opengl=on --printing=yes -d printing,file I am getting the exact same behavior as I was with our 0.15.0 r8872 fedora 20 server.

Checking on the printing enabling, however, I see this, again - with both servers:

[jimador@zapopan ~]$ xpra info | egrep "client.printing|printing.enabled"
client.printing=True
printing.enabled=False

Once it was suggested that I install python-cups on the server, however, everything worked fine (aside from an issue with a printer that refused to recognize a wireless networked print job). Details details.

Handing this back, now that that not-bug has been sorted.

[totaam]

2015-04-01 10:04:33: antoine commented

---

I think what we have is good enough for the release. We can revisit and improve in new tickets as people find new issues with it.

PS: as of r8893, we grab the latest ghostscript version we find installed.

[totaam]

2015-04-02 09:53:07: antoine commented

---

Minor packaging tweaks in r8895 + r8896 + r8897: now that we can enable printing safely, add the correct RPM dependencies.

Note: cups-pdf is not available for centos, so it needs to be installed separately / by hand. (and centos 6 does not have pycups at all)

[totaam]

2015-05-08 10:40:33: antoine commented

---

r9284 (+backport in 9285) adds the packages as "suggestions" to the DEB packaging.

The page Printing has been updated.

[totaam]

2015-08-20 09:21:38: antoine commented

---

See also: #955, #494, #913.

[totaam]

2017-11-15 11:29:14: antoine commented

---

Follow up: #1344