This is a bug, and a serious one, but perhaps there is a setting or other trickery to work around it? The problem is best described with screenshots, but it seems that the rendering engine K-9 uses deals with large images by scaling down the rest of the canvas to fit. This results in the text of the email being rendered at an unreadably tiny font size. However, there appears to be a maximum canvas size on top of that, such that the important part of the image is frequently cropped off anyway. The result is that no part of the email is of any use. It requires a mess of zooming and panning to figure out what’s going on in the email.
The correct way to render large images, as implemented in e.g. Thunderbird and the iPhone Mail client, is to scale the images to fit the window size. Note that in this case the tag does not specify a width, this width is derived from the image file itself.
If it’s impossible to control the rendering engine, the next-best option is to not scale the canvas. This makes it very difficult to view the images, but at least the text is readable. In email, typically the text is the most important part. This is the option used e.g. in Roundcube and Gmail.
The developer’s are aware of many HTML & CSS rendering issues and applied a number of fixes, scheduled for the v16 release. They do indicate that further work may be required. See github PR here
This PR will address the majority of emails with complex HTML and CSS being rendered incorrectly. Large images and tables will still zoom out the WebView.
Introduce the :feature:mail:message:reader:api and :feature:mail:message:reader:impl modules
Adds a new feature flag “use_new_message_viewer_css_styles”
Moved CSS styles from DisplayHtml to CssStyleProvider interface implementations, enabling old CSS fallback when the feature flag is off
Add new CSS rules, supporting more complex email rendering for mobile
For future improvements:
We need to figure out a way to verify if we can resize large images and tables without using JavaScript. Otherwise, we will need to decide on either enabling JS, but limiting its usage via HTML preprocessor, or leaving it zooming out the WebView.
Logging your feedback on an existing or new github bug report would be my suggestion as there’s no settings that will fix the behavior.
Oh cool, actually that bug report pretty precisely describes both suggested solutions. I would not have found it myself since I wouldn’t describe these emails as “complex”, but I recognise the problem with large tables as being related. I’ve only come back to K-9 just now but I remember this problem being present many years ago, so it’s kinda crazy that I finally complained just when a fix is already scheduled for the next release I’ll wait for that and file a ticket if I still have problems. Thanks!
I’ll wait for that and file a ticket if I still have problems. Thanks!