Skip to content

Printing of HTML messages is confusing/broken

In a recent message to the mailing list a user noted that printing of HTML messages is confusing: he selected the HTML part of the message, which included an external image (which he loaded)downloaded), but the printout misses the image.

Reason: the printout is controlled by the settings on the 3rd tab of the printing dialogue instead of using the actually displayed (html vs. plain text, external content being downloaded) data from which printing is initiated. The natural approach would be to just print the message as it is currently displayed and remove the extra settings for printing.

Looking deeper into this issue, the problem is more complex:

  1. Any external HTML content which has been downloaded is stored in the Webkit cache on disk, but Webkit does not offer any method to check the cache contents.
    Simple solution: add a flag to LibBalsaMessageBody indicating whether external contents has been downloaded (either explicitly, or due to a setting in the HTML preferences database) or not. Using this flag can also fix another weird behaviour: user selects the HTML part of a message, confirms downloading external content, opens the same message again in a separate window, and the button for downloading external content re-appears.
    The drawback of this approach: when the message is de-selected, the flag status is lost, i.e. after selecting the massage again, downloading external contents needs to be re-confirmed (which is loaded from the cache unless it has been cleared in the meantime, though). As alternative, the HTML preferences database could be used, but the implementation may be difficult (association with message and body, cleanup when messages are moved or erased, etc.).
  2. Remember which part of a multipart/alternative is activated.
    Again, the simple solution is an additional LibBalsaMessageBody flag, plus a reference to the parent part of each body, as whenever a different text part is selected we must remember the selection with the multipart/alternative parent.
  3. Testing a very first implementation of 1. and 2. above, it turned out that printing of messages containing a multipart/related (typically a text/html plus embedded images) in completely broken.