Improve printing of images

[emkll]

It was discovered in #499 (comment) that standalone image formats are not printed correctly, using the client's printing functionality. This likely requires changes in https://github.com/freedomofpress/securedrop-export/. We should ensure that major image formats (jpg, png, bmp are properly supported and can be printed)

[sssoleileraaa]

I was able to print this image

from my LaserJet Pro M404n today via the client, see printed image:

[emkll]

Thanks @creviera for testing! Interesting, I cannot print the above image on a Brother printer (L2320d). I have tried several approaches, and all of them fail with the light flickering and then nothing being printed:

• Tried installing the printer through the interactive printer (in another debian VM)
• Convert the image to pdf using unoconv, and print the pdf
• Using imagemagick and the convert tool to convert the .jpg to .png or .ps, and print those
• The above using various options to change to colors to grayscale or black and white
• Installed the binary proprietary drivers from the manufacturer's website

This seems model/manufacturer specific. It would be good if someone else with the same model printer as I (or similar) double check. I will also increase sample size of images used for testing, to try to better understand why only specific images fail to print.

[rmol]

My HL-L2380DW spits out a blank page for that image, but that's it. I found via jpeginfo that the test image is JFIF, not EXIF, so perhaps some component in the chain can't deal with that, but if it still doesn't print after being converted to another format ... maybe something about the image data itself is breaking Brothers.

I tried a PNG and another JPEG, both fine. The JPEG was 8-bit EXIF instead of the 24-bit JFIF of the satellite picture.

[eloquence]

Tracked as release blocker to reflect severity, but we may have to narrow scope of first round fixes if we run out of time.

[eloquence]

(Keeping both issue and PR on the board in case #62 only partially resolves.)

[sssoleileraaa]

Test results

Today I was able to print 27/28 files provided in our printer test archive on the wiki (ask @emkll for a link because he gave it to me directly).

Workstation Version?

• SecureDrop client v0.1.3-dev-20200326-060127

Printer Info?

• Laser Jet Pro M404n

Files I couldn't print:

• test.svg: I got a sd-devices VMapp command popup that said:

  Unable to print file 'tmp/tmp30923409/export_data/test.svg' - client-error-document-format-not-supported
  

Files that were cut off at the top of the page (this seemed to happen to the files that our export converts them to pdfs right before being printed, see example):

• test.doc
• test.docx
• test.xls
• test.xlsx

Files that I would expect to be able to print that did print fine were:

• test.csv (although there was very little margin on the page)
• test.jpg
• test.gif (maybe it printed just the first image in the gif -- need to verify)
• test.pdf
• test.png
• test.ppt
• test.pptx

Some files don't make sense to print, like mp3 files, but out of curiosity I started to print them and then cancelled immediately (to save the trees <3). I was surprised I was stopped from printing the svg but not other formats.

[eloquence]

This is super helpful, thank you @creviera.

It seems unlikely we'll be able to rush out fixes for all these issues. It would be useful to know if we can advise users on workarounds. For the cut-off issue, does adjusting the margin in the printer dialog help?

I do think it's worth us having an overall print architecture conversation soon; my own hunch is that we're starting to get to the breaking point of this first iteration architecture, and we'll hit diminishing returns by attempting to fix every issue instead of considering different technical approaches (e.g., different front-ends, a different passthrough model) that could improve both printer compatibility and results.

[sssoleileraaa]

I think it would help but I'm suspicious of how we're using https://github.com/unoconv/unoconv to convert the files to pdf. Since all of the files that we convert to pdf were cut off at the margins, I think the issue is there. Here's another example of a doc that we convert to a pdf before it is printed. When I print that document I can change the margins using the X Printing Panel gui, but the top of the pdf (that I printed and linked to here) continues to get cut off in the exact same place, even when I make the top margin 200+ (very large).

[rmol]

I think the margin problem might be because we're defaulting to A4 paper size.

[emkll]

I've successfully printed that image in macos on the same Brother printer. However, does not work in a standalone debian 10 or Ubuntu 18.04 , nor in Fedora-31 workstation. This may be a limitation of the specifc model I have (HL-L2320D) in Linux

[sssoleileraaa]

Moved the margin problem to a separate issue: freedomofpress/securedrop-client#1731

[eloquence]

Moving this back to backlog for now. It looks like the Brother issues with the image may be specific to certain images (@emkll was able to reproduce them even in standard Linux distributions), and could be related to memory limitations. We'll have to investigate further and may want to update our hardware recommendations, depending on findings.