877105 - <pre> blocks are rendered too small

Status: REOPENED

(Core :: Layout: Text and Fonts, defect)

Description

[Julien Wajsberg [:julienw]]

Attachment: screenshot

STR:
* open Browser
* go to http://everlong.org/mozilla/testcase-pre/

Expected:
* the <pre> block renders big enough so that we can read the letters

Actual:
* the <pre> block renders too small (see screenshot)

Note that it looks good on my Desktop Firefox.

This looks like a bug that I had on Firefox/Linux a long time ago.

For me it's a blocker. This happens on real-world pages (like http://sinonjs.org/).

Comment 1

[Julien Wajsberg [:julienw]]

Ben, you might know who knows ? ;)

Comment 2

[Ben Francis [:benfrancis]]

I'm sorry Julien, I don't know who works on text rendering in Gecko. Maybe Core - Graphics::Text might get us closer to finding someone who knows?

Comment 3

[Jonathan Kew [:jfkthame]]

The issue here is Layout rather than Graphics; moving to Layout:Text.

What's happening is that font-inflation is being applied to the main text, to increase the font size sufficiently to make it comfortably readable. But the <pre> element doesn't get inflated - I presume this is because in general, increasing the font size in <pre> elements is liable to cause unwanted line-wrapping, and thus destroy the carefully "preformatted" text layout. So that's why the <pre> text remains uninflated and looks much smaller than the main text.

I see a similar result on Android (Fennec) with default prefs. The connection with font-inflation can be demonstrated by reducing the font size to "tiny" in Settings / Text size; this disables inflation and renders the page with its "original" font sizes, and now the body text is also very small. (The entire page can of course be pinch-zoomed to a readable size, but then you have to scroll horizontally to see the full width of the lines.)

Not sure there's much we can do about this in general; AFAICT, <pre> elements are by their very nature not really amenable to automatically reformatting for readability (e.g. by enlarging the text and re-wrapping the lines) like we do for other content. In this particular example, it looks like we could in theory have inflated the <pre> text at least somewhat - to about 150% or so of its original size - without needing to wrap lines, but to determine that, we'd have had to check the length of every line within the block; and if we used an "inflate-as-much-as-possible-without-wrapping" strategy, each separate <pre> block on a page might get a different degree of inflation, which would look pretty weird.

cc'ing Scott, who knows far more about all this stuff.

Comment 4

[Scott Johnson (:jwir3)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> The issue here is Layout rather than Graphics; moving to Layout:Text.
> 
> What's happening is that font-inflation is being applied to the main text,
> to increase the font size sufficiently to make it comfortably readable. But
> the <pre> element doesn't get inflated - I presume this is because in
> general, increasing the font size in <pre> elements is liable to cause
> unwanted line-wrapping, and thus destroy the carefully "preformatted" text
> layout. So that's why the <pre> text remains uninflated and looks much
> smaller than the main text.
> 
> I see a similar result on Android (Fennec) with default prefs. The
> connection with font-inflation can be demonstrated by reducing the font size
> to "tiny" in Settings / Text size; this disables inflation and renders the
> page with its "original" font sizes, and now the body text is also very
> small. (The entire page can of course be pinch-zoomed to a readable size,
> but then you have to scroll horizontally to see the full width of the lines.)
> 
> Not sure there's much we can do about this in general; AFAICT, <pre>
> elements are by their very nature not really amenable to automatically
> reformatting for readability (e.g. by enlarging the text and re-wrapping the
> lines) like we do for other content. In this particular example, it looks
> like we could in theory have inflated the <pre> text at least somewhat - to
> about 150% or so of its original size - without needing to wrap lines, but
> to determine that, we'd have had to check the length of every line within
> the block; and if we used an "inflate-as-much-as-possible-without-wrapping"
> strategy, each separate <pre> block on a page might get a different degree
> of inflation, which would look pretty weird.
> 
> cc'ing Scott, who knows far more about all this stuff.

Yeah, so Jonathan summarized the problem. We specifically disable font-inflation on preformatted blocks so as to not disrupt the preformatting.

As for the "inflate as much as possible without wrapping" approach, in addition to having problems with inconsistent sizes, we might also have issues with performance, as we'd likely have to choose a font size, layout, determine if the font size affects line wrapping, and then repeat, which I suspect could be pretty expensive.

As an alternative, the user could simply double-tap to zoom in on the preformatted block - this should fit the viewport to the block's width, which would effectively be the same as increasing the text size to fit within the viewport without wrapping.

Comment 5

[Julien Wajsberg [:julienw]]

Sorry, reopening, I think we can achieve a compromise.

I generally agree with this reasoning for websites that are not adapted to mobile (ie: no <meta viewport>).

However, I think we can do something for mobile-enabled websites (with <meta viewport>).

For example, the "double-tap to zoom" doesn't work on sinonjs.org website, because the <pre> block's width is already adapted to the available width, and therefore double-tapping it doesn't inflate it much.

Of course I don't know how font-inflating works, if there are any heuristic, etc, but to me on mobile-enabled websites (ie: done by mobile-conscious web authors) we should not tamper the font size at all, or increase it for the whole content.