search

freedomofpress / securedrop-workstation

Qubes-based SecureDrop Journalist Workstation environment for submission handling
GNU Affero General Public License v3.0
141 stars 43 forks source link

Improve printing of images #506

Open emkll opened 4 years ago

emkll commented 4 years ago

It was discovered in https://github.com/freedomofpress/securedrop-workstation/issues/499#issuecomment-602789126 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 commented 4 years ago

I was able to print this image test from my LaserJet Pro M404n today via the client, see printed image: printedimage

emkll commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

(Keeping both issue and PR on the board in case freedomofpress/securedrop-workstation#62 only partially resolves.)

sssoleileraaa commented 4 years ago

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?

Printer Info?

Files I couldn't print:

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

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

emkll commented 4 years ago

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 commented 4 years ago

Moved the margin problem to a separate issue: https://github.com/freedomofpress/securedrop-client/issues/1731

eloquence commented 4 years ago

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.