Xpra: Ticket #1230: windows client printing blue text as red

Specifically came across this on the webpage https://leginfo.legislature.ca.gov/faces/billCompareClient.xhtml?bill_id=201520160SB1279.

0.18.0 r12647 windows client against 0.18.0 r12828 fedora 23 server.

Seems to be confined to windows client (osx client prints the blue text bits in blue).

Testing again with XPRA_DELETE_PRINTER_FILE=0, and then printing the file saved in downloads:

When I test with one of our 0.17.x servers (and 0.16.x clients), the file is saved as a pdf, but otherwise behavior is exactly the same.

Seems like it should be very easily reproducible, but if you need any additional logs, let me know.

Thu, 16 Jun 2016 03:40:52 GMT - Antoine Martin: owner, description changed

I assume that the print PDF file is using the right colours when displayed on screen? Does it help if you manually rename the file to add the ".pdf" extension? (r12830 fixes the missing extension in latest trunk server builds) Is this problem limited to one client machine? Have you tried a different printer?

We use ghostscript for printing on MS Windows. Can you install it separately and see if it prints the same file correctly or not? And maybe try an older version too. If the bug is in ghostscript, it will have to be reported there.

Mon, 27 Jun 2016 23:42:03 GMT - alas: owner changed

Yes, the pdf displays correctly when displayed on screen (when using a pdf viewer application to view it... and likewise, using the printing interface through that same pdf viewer application it prints as expected).

Manually adding the .pdf extension doesn't seem to make any difference.

I'd like to say I was surprised to find that manually changing to a .ps extension (no other difference but re-naming the file to .ps) made no difference either... but I happened to have tried printing page one of the above doc in landscape, and converted that - only to find that (you might want to sit down for this) when I use the above listed windows printing command on the .ps in landscape mode, the portion that would be "in frame" for portrait mode printed the text blue, but then it printed the "spillover" text (beyond the width that would be expected for an 8 1/2" wide doc) ... in red.

Double checking, it does the same with printing through xpra in landscape... but just to make matters extra confusing... when I print the second page, it comes out entirely in blue(??).

Tried on a windows 7 machine with a networked (AD) printer & got the same results.

Tried to install ghostscript... but couldn't manage to make it print.

Closest I managed was to trigger the display of the file, with the following:

C:\Program Files\gs\gs9.19\bin>gswin64c -sOutputFile="%printer%HP-Bob" C:\Users\hassenpfeffer\Downloads\da39a3ee5e6b4b0d3255bfef95601890afd80709-10.pdf
GPL Ghostscript 9.19 (2016-03-23)
Copyright (C) 2016 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
   **** Warning: File has some garbage before %PDF- .
Processing pages 1 through 1.
Page 1
>>showpage, press <return> to continue<<

Pressing the "<return>" as recommended just opened a GS> prompt, but no commands nor syntax I could come up with had any effect there (aside from "quit"). Generally, trying to feed any syntax, like "Print" while the file was displaying (since the displayed file wouldn't respond to right or left clicks...) just threw errors:

GS>gsprint -sOutputFile="%printer%HP-Bob"
Error: /undefined in gsprint
Operand stack:
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   %loop_continue   --nostri
ngval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1195/1684(ro)(G)--   --dict:1/20(G)--   --dict:78/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 8
GS>print -sOutputFile="%printer%HP-Bob"
Error: /stackunderflow in --print--
Operand stack:
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   %loop_continue   --nostri
ngval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1195/1684(ro)(G)--   --dict:1/20(G)--   --dict:78/200(L)--
Current allocation mode is local
Current file position is 6
Error: /stackunderflow in --print--
Operand stack:
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   %loop_continue   --nostri
ngval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1195/1684(ro)(G)--   --dict:1/20(G)--   --dict:78/200(L)--
Current allocation mode is local
Current file position is 6
GS>gswin64 print
Error: /undefined in gswin64
Operand stack:
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   %loop_continue   --nostri
ngval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1195/1684(ro)(G)--   --dict:1/20(G)--   --dict:78/200(L)--
Current allocation mode is local
Current file position is 8

I suppose I better be sure I can print with ghostscript before I report any bugs... what is the syntax you're using to call it? (Is it the syntax that I've been succeeding at with the print.exe from the xpra directory?)

Also... just in case you find yourself trying (or anyone else is foolish enough to try), the "%prinerter%HP-Bob" syntax I'm using is based on a printer named "HP-Bob" and the documentation of section 10 in http://www.ghostscript.com/doc/current/Devices.htm.

(Maybe landscape printing should be considered a workaround?)

Tue, 28 Jun 2016 04:42:06 GMT - Antoine Martin: owner changed

You can find the exact command lines used for printing by running the client with -d printing. It will look like this: GSPRINT_EXE -ghostscript GSWIN32C_EXE -colour] Where gsprint and gswin32c are substituted with the actual path inside the xpra installation folder.

Wed, 29 Jun 2016 01:50:22 GMT - alas:

Well... "made an upstream ticket" - but that turned out to consist of sending an email to the guy who seems to have written gsprint.exe, and now hoping for the best.

Just some notes for myself, and anyone else who comes along... downloaded ghostscript, from linked http://ghostscript.com/download/, but as noted above couldn't get it to print anything - it seems to be meant just for creating images & displaying (?).

Checking the command with the -d printing option, then feeding it back to the xpra win32 client... give a command of

C:\Program Files (x86)\Xpra\gsview>gsprint.exe -ghostscript "C:\Program Files\gs\gs9.19\bin\gswin64c.exe" -colour -printer "HP-Bob" C:\Users\hassenpfeffer\Downloads\

in my particular case.

Searching out gsview leads to the "false trail" of http://www.gsview.com/, which works fine as a pdf viewer, but has no gsprint.exe packaged either.

A significant extra bit of searching turned up http://pages.cs.wisc.edu/~ghost/index.htm ... which, when downloading the v5.0, finally produced a gsprint.exe.

Downloading and massaging a new command line print command

C:\Program Files\Ghostgum\gsview>gsprint.exe -ghostscript "C:\Program Files\gs\gs9.19\bin\gswin64c.exe" -colour -printer "HP-Bob" C:\Users\hassenpfeffer\Downloads\da39a3ee5e6b4b0d3255bfef95601890afd80709-11.pdf

... reproduced the issue.

Will let you know if I get an answer to the email/"posted ticket upstream".

Thu, 30 Jun 2016 08:39:32 GMT - Antoine Martin:

The only mention of gsview's download link was in ticket:598#comment:21, I have added the link to wiki/Dependencies (diff).

The blue vs red thing, coupled with the landscape change sounds to me like the postscript data may not be generated or interpreted correctly.

You may want to try to find other PDF printing tools to compare how they fare. Or change the xpra server setting to use postscript and not pdf, or use a different way of generating a PDF for the same page. (save to pdf, print to file, etc..)

Another solution would be to generate Raw printable data: use win32print directly. This would have the advantage of removing the bundled ghostscript binaries on win32. Some interesting links on PCL:

Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed

Tue, 16 Aug 2016 22:08:02 GMT - alas:

A bit of checking turned up pdfium as a potential solution (https://pdfium.googlesource.com/pdfium/).

Testing with that site listed above, it prints as expected (blue), but I was using it nested in another application. I'll try to convince someone to help me with setting up something independent that I can call through the command line, but it the meantime, it might also be worth you taking a look at it (it has build instructions, that are over my head).

I'll keep hold of the ticket until I manage to confirm that this works form a command line call as well (though, if you find some time to build an application for me to test, that might speed things).

Fri, 26 Aug 2016 17:54:56 GMT - alas: owner changed

Ok, managed to convince someone to build a convenient little .exe from the pdfium source linked above - and it printed a file dropped into my Downloads directory after a win32 client printing with XPRA_DELETE_PRINTER_FILE=0- from windows command line, in the proper color.

C:\Users\hassenpfeffer\Downloads><Test-app>.exe -printer HP-Bob da39a3ee5e6b4b0d3255bfef95601890afd80709.pdf
Selected printer: HP-Bob
print: da39a3ee5e6b4b0d3255bfef95601890afd80709.pdf . 1 pages.

It looks like one can pay a license for framework, language bindings, and presumably all sorts of other bells and whistles, but the source itself seems to be properly open (https://pdfium.googlesource.com/pdfium/+/master/LICENSE).

I'll assign this to you to take a look when you get a chance.

Sat, 27 Aug 2016 05:29:40 GMT - Antoine Martin:

Found some build instructions (better than the upstream ones):

For that you need depot_tools. That thing is weird, it installs some outdated tools (ie: python 2.7.6).

It doesn't seem to want to build on my main XP dev system, and moving to a newer build system is blocked by #678, so this is unlikely to land in this release.

Wed, 07 Sep 2016 10:03:01 GMT - Antoine Martin: milestone changed

Out of time for this release.

Thu, 26 Jan 2017 11:24:34 GMT - Antoine Martin: status, milestone changed

FWIW: there is a PKGBUILD for pdfium in mingw-w64: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-pdfium-git. But the build failed when I tried - something openssl related. Will try again later.

Tue, 07 Feb 2017 16:48:53 GMT - Antoine Martin: owner, status changed

I've just tried again, and the latest pdfium git does build now (both 32 bit and 64 bit). So we have a "libpfium.dll" and the headers, so we can easily write an exe or even integrate the pdfium code into a cython extension or a ctypes wrapper. The method we need to call seems to be RenderPDFPageToDC (see chromium pdf extension : pdf.cc), after getting a DC for the printer.

It does have a number of attributes that would make it better suited to an in-process API call - not sure what the default values should be here, I think we can get at least some of those from the cups spooler (as specified by the user on the print dialog - see also #1344):

@afarr: if you already have an app we can use - especially one that is command line compatible with "Print.exe", maybe we can just use that instead? Can you share it under an open-source license?

Sun, 19 Feb 2017 06:36:59 GMT - Antoine Martin: milestone changed

Sat, 13 May 2017 12:42:48 GMT - Antoine Martin: attachment set

poc that prints a pdf file using pdfium

Sat, 13 May 2017 12:49:48 GMT - Antoine Martin: owner, status changed

Found some pdfium documentation:

And from there, it wasn't too hard to cook up a ctypes wrapper for it, see patch.

We could support 2 new backends with this:

And allow selection of the backend using an env var to make it easier to compare and test.

Sat, 13 May 2017 19:05:59 GMT - Antoine Martin: owner, status changed

We could call pdfium in-process rather than execing the new "PDFIUM_Print.exe" tool but the downside is more memory usage, and maybe also some instability..

@afarr: does this fix the problem for you? (and if not, please save the page as a PDF and attach it to this ticket so that we can print it again reliably)

Sun, 14 May 2017 06:20:24 GMT - Antoine Martin:

Will remove the old print tools in a future release: #1516

Wed, 26 Jul 2017 07:26:58 GMT - Antoine Martin: status changed; resolution set

pdfium printing is now the default, so really too late to test (see #1516).

Mon, 02 Sep 2019 15:03:03 GMT - totaamwin32:

See also #2401

Sat, 23 Jan 2021 05:18:31 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1230