Bug 3686 - Possible printing bug
Summary: Possible printing bug
Status: NEW
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI (show other bugs)
Version: 3.14.1
Hardware: PC All
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2016-09-07 12:56 CEST by Gerard Seibert
Modified: 2016-09-08 14:16 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gerard Seibert 2016-09-07 12:56:43 CEST
claws-mail version 3.14.0-39-g986e6f-dirty
Windows 10 Pro / 64

I am not sure if this is a bug or is a design feature/flaw. I can only confirm that it happens on a Windows machine.

1) Open an email
2) Highlight (select) part of the text
3) Click <File>
4) Click <Print>

The highlighting disappears and the "selection" under "Page Range" is greyed out.

Is this by design or is this a bug? If by design, then why?

Thanks
Comment 1 Andrej Kacian 2016-09-08 12:42:12 CEST
There are in fact two separate topics here:

The "selection" in print dialog is disabled because we do not use the feature[1] - in other words, a selection is not made available to the printing subsystem. See https://developer.gnome.org/gtk2/2.24/gtk2-High-level-Printing-API.html#GtkPrintOperation--support-selection for details.

I tested the selection disappearance under both Linux and Windows, and I see something different than you: On Linux, the selection indeed disappears as soon as the print dialog appears, but on Windows the selection remains. This might be due to the fact that on Windows, native print dialog is used instead of GTK's print dialog, so I'm guessing it doesn't mess with the selection, or something like that.
Comment 2 Gerard Seibert 2016-09-08 13:22:39 CEST
(In reply to comment #1)
> There are in fact two separate topics here:
> 
> The "selection" in print dialog is disabled because we do not use the
> feature[1] - in other words, a selection is not made available to the
> printing subsystem. See
> https://developer.gnome.org/gtk2/2.24/gtk2-High-level-Printing-API.
> html#GtkPrintOperation--support-selection for details.
> 
> I tested the selection disappearance under both Linux and Windows, and I see
> something different than you: On Linux, the selection indeed disappears as
> soon as the print dialog appears, but on Windows the selection remains. This
> might be due to the fact that on Windows, native print dialog is used
> instead of GTK's print dialog, so I'm guessing it doesn't mess with the
> selection, or something like that.

I do not understand why we are experiencing different responses here. I again checked, and indeed the "selection" disappeared as soon as I clicked <PRINT>. I am referring to the <FILE><PRINT> order and NOT the print command in the actual print menu.

Would it be possible to enable this feature or is that not possible? I believe it is a feature that is well worth having if possible.
Comment 3 Andrej Kacian 2016-09-08 13:52:30 CEST
I think I found the culprit. The selection indeed disappears from plaintext e-mails, but does not disappear from HTML e-mails - no matter whether it's on the HTML-rendered Fancy view, or the default HTML-as-plaintext view.
Comment 4 Gerard Seibert 2016-09-08 14:16:55 CEST
(In reply to comment #3)
> I think I found the culprit. The selection indeed disappears from plaintext
> e-mails, but does not disappear from HTML e-mails - no matter whether it's
> on the HTML-rendered Fancy view, or the default HTML-as-plaintext view.

I never thought to analyze it that closely. I virtually never try to print HTML emails anyway, although it has happened occasionally. By the way, I can confirm that it only happens on "plain text" messages.