[Enger]

I am new to Blackberry. I purchased a Tour 9630 on Verizon.
I am running the following sw:

• v4.7.1.40 (Platform v4.1.0.40)
• crypto kernel v3.8.5.51
• branding vers 1.0.105.205

I found that when I received HTML E-mail created by old-style HTML senders, that the text was HUGE. I scouted-around online and fond that there has been some discussion of this, but no answers. I decided to do some experiments to try to narrow-down the issue. Here's what I found out.

HTML E-mail written by Outlook is displayed in a more intuitive manner (but all size requests appear to quntized into only three actual displayed font sizes). Outlook creates complex, highly verbose HTML with all manner of very specific formatting. It's bulky, but apparently BB correctly processes it (modulo only three displayed sizes and no increase in displayed size beyond 14).

HTML E-mail created by Thunderbird is comparatively simple and terse. If the sending user doesn't make any special requests, the generated HTML contains NO font-size directives. It relies on the DEFAULT BEHAVIOR of the display engine. THE BB DEFAULT BEHAVIOR IS BROKEN. The correct behavior is to assume font-size=3. Instead, the BB displays something HUGE, larger than ANY CORRECTLY-REQUESTED DISPLAYED SIZE.

I have taken some pictures of the BB display showing different test E-mail messages. These illustrate the issue clearly.

(Click on the thubnails to see the full-sized images; they are over 1000x1000, so you shouldn't have trouble seeing the image! Hover your mouse over the thumbnail to see the file names.)

In "manual_html_relative" the BB display shows the results from a manually created HTML E-mail (using Thunderbird as sender). I show a sample of text displayed with NO font-size directive (thus relying on the default rendering behavior used by the BB), and then I show text samples when one requests x-small (-2); xmall (-1), default/medium (+0), large (+1), x-large (+2), and xx-large (+3). (I also tried illegal values, such as -3, -4 and +4, +5, to see the BB behavior.) As you see in the picture, the DEFAULT and SIZE+0 are displayed at a VERY LARGE SIZE: bigger than the text from samples that should be larger (large, x-large, xx-large). Clearly this behavior is broken. The default should not display larger than requests for "large", "x-large" and so on.

As additional "brokenness", note that there is no difference in the displayed output of +1, +2 and +3. The large, x-large and xx-large directives have no effect. Only the small and x-small work as they should.

In "manual_html_absolute" I repeated the experiment, but used explicit direct calls for font-size. I examined an extended range (including and beyond legal values). Interestingly enough, this reveals that the blackberry is defaulting to FONT SIZE=0 (which is not even a valid directive). Note that the text sample SIZE0 is identical in size to the sample "size (default)". Note again that there is no increase in displayed size between SIZE2 and SIZE3 ("small" and "default/medium"). Note that ALL of the larger font-size requests (4, 5, 6, 7) result in the same displayed size. Finally, note that the illegal request size of "8" results in the display of the HUGE font size yet again. Although not show in this picture, I examined the range up to 15. I found that "9" also displayed the HUGE font. BUT, requests for size 10, 11, 12, 13, 14, and 15 (all illegal) result in sample text that is the same size as SIZE0 (tiny).

To substantiate the validity of the tests, I evaluated the display rendering of the above two test E-mails on both Thunderbird and Outlook2003sp3 clients.
On both of these E-mail systems:

• default text (no font-size directive given) was rendered in medium/default (size=3)
• displayed font size increased properly through the range of legal values (1 was tiny, and each successor was larger through 7)
• out-of-range values displayed at the closest allowed value (ie SIZE=0 displayed as SIZE=1; SIZE=8 and beyond displayed as SIZE=7)

The other two pictures that I have attached show HTML text E-mail created by Thunderbird and Outlook2003sp3 E-mail systems.
[In the case of the Thunderbird, I manually inserted a single "font size=+0" call and sample text "medium+0" to see what the effect would be; this E-mail test was performed earlier in the evening, and is what led me to conduct the detailed tests using manually crafted HTML to narrow-down the issue.]
As you see, when a Thunderbird user utilizes the conventional Formatting menus to request Large, X-large or XX-large, it actually result in SMALLER FONT SIZE being displayed on the Blackberry. This is INCORRECT BEHAVIOR.
(Again, these test E-mails display correctly on both Thunderbird and Outlook2003sp3 mail clients; its the BB E-mail client's HTML rendering engine that seems to be errant.)

The Outlook2003 test mail shows better behavior on the BB. The HTML generated by Outlook includes extremely complex and verbose directives. It does not rely on the default behavior of the html-engine in the E-mail client: it specifies everything (and then some ). However, you'll note that requests for fonts larger than 14 are ignored by the BB E-mail rendering engine. This seems ESPECIALLY BIZARRE given that the DEFAULT font-size (ie visible in simple HTML mail from clients like Thunderbird) displays MUCH MUCH larger than the 14-font. Since the BB is displaying a HUGE font as the default, then why bother to ignore Outlook's requests for specific fonts beyond 14??? What was RIM thinking?!?! In my tests, there appear to be only three actual text sizes displayed: 8, 9to12 (all the same size), and 14-and-up (all the same size).

While RIM may be buoyed by the thought that Outlook is the prevalent E-mail client, they should read the Blackberry user web sites, a lot of E-mail is created by non-Outlook mail sources. And thus, a lot of HTML E-mail is NOT being correctly displayed on the Blackberry E-mail client.

I realize the Blackberry platform is memory and processor limited. But, given the importance of E-mail in today's society, it seems prudent to take whatever steps possible to improve the rendering of the conventional, simple-HTML (html that relies on the defaults of the display client). There is a lot of this simple-HTML E-mail out there, and presently BB gets it wrong.