windows client printing blue text as red

[totaam]

Issue migrated from trac ticket # 1230

component: client | priority: major | resolution: worksforme

2016-06-16 02:25:59: afarr created the issue

---

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:

• Using "reader", some generic pdf reader that was packaged with this windows 8.1 os, the blue prints blue.

• Using command line (C:\Program Files (x86)\Xpra>print HP-Bob C:\Users\hassenpfeffer\Downloads\da39a3ee5e6b4b0d3255bfef95601890afd80709) - the blue prints red.

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.

[totaam]

2016-06-16 04:40:52: antoine changed owner from antoine to afarr

[totaam]

2016-06-16 04:40:52: antoine edited the issue description

[totaam]

2016-06-16 04:40:52: antoine commented

---

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.

[totaam]

2016-06-28 00:42:03: afarr changed owner from afarr to antoine

[totaam]

2016-06-28 00:42:03: afarr commented

---

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 "" 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
GS>print
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?)

[totaam]

2016-06-28 05:42:07: antoine changed owner from antoine to afarr

[totaam]

2016-06-28 05:42:07: antoine commented

---

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.

[totaam]

2016-06-29 02:50:23: afarr commented

---

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\
da39a3ee5e6b4b0d3255bfef95601890afd80709-11.pdf

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".

[totaam]

2016-06-30 09:39:32: antoine commented

---

The only mention of gsview's download link was in #598#comment:21, I have added the link to Dependencies ([/wiki/Dependencies?action=diff&version=54 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 PCL server-side, then we could feed it directly to the printer as per Raw printable data: use win32print directly.
This would have the advantage of removing the bundled ghostscript binaries on win32.
Some interesting links on PCL:

• Convert all files in a folder from PDF to PCL with Ghostscript (see orientation issues!)
• How do I print PCL? (on Linux)
• CUPS filtering mechanism explained
• How to send pcl files to printer on windows 7?
• GhostPCL

[totaam]

2016-07-12 17:52:23: antoine commented

---

Milestone renamed

[totaam]

2016-08-16 23:08:02: afarr commented

---

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).

[totaam]

2016-08-26 18:54:56: afarr changed owner from afarr to antoine

[totaam]

2016-08-26 18:54:56: afarr commented

---

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
<Test-app>


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.

[totaam]

2016-08-27 06:29:41: antoine commented

---

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

• [https://github.com/pvginkel/PdfiumViewer/wiki/Building-PDFium]
• Creating a dll in pdfium
  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.

[totaam]

2016-09-07 11:03:02: antoine commented

---

Out of time for this release.

[totaam]

2017-01-26 11:24:34: antoine changed status from new to assigned

[totaam]

2017-01-26 11:24:34: antoine commented

---

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.

[totaam]

2017-02-07 16:48:54: antoine changed status from assigned to new

[totaam]

2017-02-07 16:48:54: antoine changed owner from antoine to afarr

[totaam]

2017-02-07 16:48:54: antoine commented

---

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):

• "dpi"
• "bounds" (x, y, width, height)
• "fit_to_bounds"
• "stretch_to_bounds"
• "keep_aspect_ratio"
• "center_in_bounds"
• "autorotate"

@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?

[totaam]

2017-05-13 13:42:48: antoine uploaded file pdfium-poc.patch (15.1 KiB)

poc that prints a pdf file using pdfium

[totaam]

2017-05-13 13:49:48: antoine changed status from new to assigned

[totaam]

2017-05-13 13:49:48: antoine changed owner from afarr to antoine

[totaam]

2017-05-13 13:49:48: antoine commented

---

Found some pdfium documentation:

• Getting Started with PDFium
• fpdfview.h
  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:

• pdfium print via an exe wrapper, command line compatible with the existing "print.exe"
• in-process calls - which may need to run in a thread (the whole do_process_downloaded_file function should probably run in a thread anyway)

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

[totaam]

2017-05-13 20:05:59: antoine changed status from assigned to new

[totaam]

2017-05-13 20:05:59: antoine changed owner from antoine to afarr

[totaam]

2017-05-13 20:05:59: antoine commented

---

• pdfium backend added in r15829, seems to print OK - but my printer is very temperamental so it is difficult to tell (colours are wrong at the best of times..)
• r15830 now uses a dedicated thread for do_process_downloaded_file - but maybe the whole _process_send_file_chunk method should be in a thread since it does file IO? (more difficult: the thread would need a queue... and timeouts)

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)

[totaam]

2017-05-14 07:20:25: antoine commented

---

• r15839 passes the correct document title to the spooler

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

[totaam]

2017-07-26 08:26:58: antoine changed status from new to closed

[totaam]

2017-07-26 08:26:58: antoine set resolution to worksforme

[totaam]

2017-07-26 08:26:58: antoine commented

---

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

[totaam]

2019-09-02 16:03:03: @totaam commented

---

See also #2401