[desktop] Printing documents

[twiss]

Currently, you can print a document by selecting everything (ctrl-a) first. It would be nice if printing worked without doing that.

[ferndot]

This is an important feature for desktop.

There are several ways to address this issue:

• We could use https://developer.mozilla.org/docs/Web/API/window.print to trigger the print dialog on the iframe with the document's contents. The only caveat is that most browsers print meta information in the header of the document.
• We could cause the browser to download a pdf version of the file (after we implement pdf support). This is what Google Docs does.

Any other ideas?

[twiss]

Another idea is to try and use media=print/@media print to hide everything but the document. One problem with that is that it doesn't print the whole document, just the part that's visible. So you'd have to make all of it visible first.

[twiss]

Calling window.print() from within the iframe in Chrome works fine, including metadata from the top iframe. In Firefox Nightly on linux it doesn't work in at least some cases, I'll see if I can file a bug with them.

[ferndot]

In that case, this feature should be simple to solve. I think that we should wait to fix this until there is a plan in #203. What do you think?

[twiss]

I've filed a bug in Firefox with details: https://bugzil.la/1095808

Only downside of print() versus @media print is that with the latter, selecting print from the browser menu also works. I guess though that a print button inside Firetext is more like what people expect. Also, we could intercept ctrl-p.

[ferndot]

I've filed a bug in Firefox with details: https://bugzil.la/1095808

Thanks! It is definitely a Firefox on Linux issue because it works fine on OS X.

I guess though that a print button inside Firetext is more like what people expect.

I would expect that as well. The print menu item connotes printing the entire page, not just the document. Also, keyboard shortcut interception will be a good feature in the future!

[Ryuno-Ki]

Also, keyboard shortcut interception will be a good feature in the future!

When intercepting keys, please, bear in mind, that screenreader users depend heavily on them.

[twiss]

When intercepting keys, please, bear in mind, that screenreader users depend heavily on them.

Good point, I'll file some issues about that. Is ctrl-p something important in screenreaders (or elsewhere for that matter)?

[Ryuno-Ki]

Umm, I assume not so. Orca didn't get it to upload their default keystrokes, so I have to dig into the code in order to extract them.

Meanwhile, I can point you to

• keystrokes for JAWS
• keystrokes for NVDA
• kesstrokes for VoiceOver

Shall I copy-paste those links into one of the other issues?

[twiss]

Thanks a lot for those links! Just here is fine, I'll refer to them there.

[Ryuno-Ki]

I discovered Orca being hosted on GitHub as well.

At first glance, I'd say, these files look promising:

• keynames
• laptop_keyboardmap
• desktop_keyboardmap
• common_keyboardmap

Of course, all of them can be customised to one's pleasure, but we're just dealing with the default ones.

I'll look after spare some time to wrap the files into a table for easier consuming.

[twiss]

Another option is to window.open() the document.

Depending on how we implement that, that would allow the user to access their browser's print preview and page setup features (Firefox and IE, unlike Chrome have these separately from their window.print() popup).

The question then is whether we want that. Allowing access to page setup would make the most sense if the changes made there would have effect in the editor, and thus we didn't have our own dialog (#239).

[ferndot]

Fixed by #252