Hi, let's distuingish between "pinch-to-zoom" and increasing font size by using volume buttons or menu.
Indeed, they are not the same.
And one big advantage of "pinch-to-zoom" is that it works on both text and images. So, if a message contains both that one wants to "enlarge to make legible", you don't need to fiddle with two ways of controlling the effective zoom.
Yet another advantage of using pinch-to-zoom is that is it is the same as in Opera. And pinch-to-zoom exists in most image-viewing apps. It also exists in a bunch of other apps that deal with text reading (albeit in many cases without reflow). So, it is a standard mechanism implemented by many apps across mobile platforms for zooming in on both images and text.
That makes it a pity that a definite strength (but obviously not quite recognized by Kostya and/or MobiSystems as such) of Aquamail gets abandoned this way.
Personally I'm fine using the volume buttons to make text size bigger. And text reflow works like a charm.
....
Suggestion:
You know, that we have a configurable button bar in message view. Maybe we could have two buttons there to increase/decrease size the same way the volume buttons do?
Maybe the complaining people would like and use it instead of "pinch-to-zoom"...?
Nica, you may or may not have seen it in an earlier thread on this issue: Kostya reminded about the volume keys (which I've been using as well), and I responded. Indeed, that functionality is helpful in some cases. But in some messages, increasing font size results in the overlap of the lines. No line overlap occurs in case of "pinch-to-zoom".
I just looked at a bunch of the recent messages (on the phone with the pre-change version), and all of these messages where fonts overlap work well with "pinch-to-zoom", and with most of them, reflow works nicely.
For the gurus and curious, here is an example of the HTML that is used in such messages:
<td width="560" align="left" valign="top"
style="padding:15px 20px 0px; font-family:Arial, Helvetica, sans-serif;
font-size:14px; line-height:18px; color:#58585a; font-weight:normal;"
class="lr04">
This email is to inform you that your account
information has been updated. If you did not initiate this change, please
<a
href="..." target="_blank" style="color:#0068b3; font-weight:normal;
text-decoration:underline;">click here</a> or contact us at
<a href="tel:1-800-KRO-GERS"
alias="Footer:1-800-KRO-GERS" target="_blank" style="color:#0068b3;
font-weight:normal; text-decoration:underline;">1-800-KRO-GERS</a>.
</td>
Obviously, in this short example the text reflow is not overly important, I am just using it to illustrate the HTML code where "pinch-to-zoom" works, but the volume buttons - not. While I do not consider this style of e-mail message coding being a good one, unfortunately, there is an appreciable volume of such messages.
When using "pinch-to-zoom", the text reflow does not work anymore. And it seems to be difficult to implement this without having the "jump issue" (if I understood correctly).
Based on the responses of people who chimed in here about the "reflow" issue, - all these people are happy to live with the "jump issue". So, an option that enables one and disables the other is an obvious solution, since the code for the functionality already exists. (I feel as a broken record, repeating what several people have suggested already). And so far no reason was offered why this toggle option would be a problem.
Well, actually, I think I know the reason, and understand MobiSystem's hesitation to re-enable it: it might be hard to explain to many "unsuspecting" users that if they experience the jump, they need to disable reflow, and vice versa. And if it is not re-enabled, the new users will not know that they could've had something better. So, there might be less headache to deal with if MobiSystems withstand this initial wave of complaints.
However, a carefully worded option item can work; setting its default value to the "new" behavior: no reflow/reduced jump [with a warning: "changing this may create focus jumping when you are zooming"] would reduce potential for the complaints from the users.
But for those people who know and who are used to the reflow functionality, it's a pity if it will be thrown away. (And as I've written before, and as acknowledged by Kostya, this "jump issue" is not eliminated completely, just significantly reduced.)
Personally, I don't want to waste any more time on this issue, as I don't think any of my further comments would help the cause. (I am just still hoping Kostya and MobiSystems will make the right decision.)
@Kostya: I'd like to point out that I haven't seen many people celebrating in these forums or in the comments on Google Play (I just looked there), the improvement for the "jump issue". (And I very much doubt you've received many e-mails with the praise for that, have you?)
But there are complaints about the lack of reflow.
