705278 - Find sweet spot for font.size.inflation.minTwips?

Status: RESOLVED DUPLICATE of bug 712760

(Firefox for Android Graveyard :: General, defect, P1)

Description

[Aaron Train [:aaronmt]]

Attachment: Nightly (11/25) Screenshot

David Baron landed https://hg.mozilla.org/projects/birch/rev/ce03d0240a30 as a patch from bug 627842 as patch #18 to adjust font size inflation for Fennec on Android -- with this change it is rather obvious that something is not 'right' as font sizes are seemingly 'jumbo' on a variety of websites.

Perhaps this newly added pref needs some tweaking to find a sweet spot?

See screenshot attached as an example of a variety of sites.

--
Samsung Nexus S (Android 4.0.1)
20111125040216
http://hg.mozilla.org/projects/birch/rev/2aec00aaf211

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See also bug 703029.

It could also be we're not picking up the dimensions of the screen properly.  I should probably write something that allows us to test that more directly.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: display screen size information

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So on my Archos A32 attachment 577084 [details] reports 240x400 (correct) at 133dpi (a bit low; should be around 150dpi).

On my Galaxy Tab 10.1 attachment 577084 [details] reports 1280 x 752 or 800 x 1232 (correct; 1280 x 800 with the bar at the bottom subtracted) at 160dpi (a bit high; should be 149dpi).

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm trying
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/65a2e628c189/accurate-android-dpi
to make the DPI more accurate.  Based on comments in bug 602322 I'm not sure if it'll help content... though I suppose with the new native UI it'll probably be ok, even if it doesn't work for the XUL UI.  (Not a great situation, though.)

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And also see http://developer.android.com/reference/android/util/DisplayMetrics.html

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: make android DPI reporting more accurate

This makes my Archos A32 report 145dpi, which seems a lot more accurate (see above estimates).  The documentation in comment 5 also suggests this should be more accurate.

For some reason my Samsung Galaxy Tab 10.1 continues to report 160dpi.  Perhaps it's somehow missing this if:
http://hg.mozilla.org/mozilla-central/file/36b62de19e9e/widget/src/android/nsWindow.cpp#l351

I also wonder why the AndroidBridge code passes the result as an int when the Android code starts with a float and the caller wants to end up with a float.  (Are there issues with the C++/Java stuff, or was it just an oversight?)

On birch, the location of this file has changed to mobile/android/base/GeckoAppShell.java but the patch still applies (with harmless fuzz).

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I turned down the inflation pref a bit for now, until we get the device sizing stuff sorted out better:
https://hg.mozilla.org/mozilla-central/rev/854aabf544d4
https://hg.mozilla.org/projects/birch/rev/79f85a955bc4

Comment 8

[Matt Brubeck (:mbrubeck)]

Comment on attachment 577116 [details] [diff] [review]
make android DPI reporting more accurate

See bug 605024 for some reasons we don't want to do this: One some devices, xdpi and ydpi are less accurate than densityDpi.

Comment 9

[Matt Brubeck (:mbrubeck)]

For what it's worth, I think we should stick with densityDpi, which is a nominal value that is "close" to the actual physical value.  The value of densityDpi is used for all UI rendering on Android, and for layout in WebKit.  When densityDpi is inaccurate then text inflation will result in text that is enlarged or reduced compared to the specified preferences -- but it will be enlarged or reduced by the same amount as all text and layout in every app on the phone.

Comment 10

[Madhava Enros [:madhava]]

Aside from the calculations based on the screen size, what font size are we aiming for by default right now? Patryk has some suggestions of what we should aim for.

Comment 11

[Patryk Adamczyk [:patryk] UX]

Here is a link to the wiki entry I made on the topic which should provide enough info to fix the bug.

https://wiki.mozilla.org/Fennec/NativeUI/UserExperience/Readability

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What do you mean by "content", "title", and "caption"?

Comment 13

[Patryk Adamczyk [:patryk] UX]

Title - the header of the article
Content - body text of the article
Caption - label underneath pictures

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The Web platform doesn't divide text into those categories.

Comment 15

[Madhava Enros [:madhava]]

Yeah - I think we should try to get to the default "optimal reading size" (i.e. for "content") and then see where we are.

Comment 16

[Madhava Enros [:madhava]]

We're currently inflating to something bigger than I think we want (comparing to what the iphone does). Patryk's recommendation was for "Content (body text of the article): 8pt" Further illustrated here: http://www.flickr.com/photos/patrykdesign/6426531853/in/set-72157628209207387

I'm not sure how the current prefs related to point size, exactly, but can we reduce the size to something that maps to this?

Comment 17

[Madhava Enros [:madhava]]

AHA! "The value given is in twips, i.e., 1/20 of a point, or 1/1440 of an inch."

OK. So, the current default of 120 maps to 6pt? How does that square with what we're seeing? Is that the _minimum_ inflation, but we get larger inflation under other circumstances?

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's a minimum.

The idea is that *when you scale a block to be the width of the device*, text directly within that block to which we apply inflation will be scaled so that:
 * no text is smaller than 6pt
 * text that would be larger than 9pt (because it's 150% of 6pt) is not affected

We scale the text that would have been in the range 0pt-9pt to occupy sizes 6pt-9pt instead.  (That is, sizes 0%-150% are scaled to be 100%-150% of the minimum instead, so that we both enforce the minimum and still have some differentiation between smaller vs. larger text.)

Comment 19

[Patryk Adamczyk [:patryk] UX]

Using 2011.12.08's nightly build on a Galaxy Nexus (ICS)
Modified the following field in about:config "font.size.inflation.minTwips" to 200 from 120. And yes that screen's text does inflate. However when I go to a website... ie. cnn.com the text is still TINY. 

So has this option been turned on outside of the config screens? Or is there another option that will inflate the text on external websites?

Comment 20

[Matt Brubeck (:mbrubeck)]

(In reply to Patryk Adamczyk from comment #19)
> So has this option been turned on outside of the config screens? Or is there
> another option that will inflate the text on external websites?

Yes, the pref affects all web pages.  However, there are some rules controlling which elements on a page get inflated, and in some cases those rules may be wrong or buggy.  You can file bugs for any web pages where text is not inflated but should be.  Make the bugs block bug 627842.

Comment 21

[Patryk Adamczyk [:patryk] UX]

Ok I played around with the settings (they seem to work on the current nightlys) can we inflate the default twip size to 160 twips (8pt)
See screenshot for more info / examples.

Comment 22

[Patryk Adamczyk [:patryk] UX]

Attachment: 120v160 example

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That's what I landed it as originally, and I got lots of reaction that it was way too big.

Comment 24

[Patryk Adamczyk [:patryk] UX]

Attachment: Default Font Size Settings at Browser Launch (Small Font Pref, 120 Twip Inflation)

With the creation of the font size user preference (bug 703029 & 711418) the focus of this bug should shift as we will specify an ideal starter font size (probably 7 or 8pt) locked to the "medium" setting in those bugs.

What is still important to sort out in this bug, is to have a consistent starting point, and I agree with you that 120 twips is a good size in optimal settings (low ambient light / user possess good vision). 

However we are finding that on different devices the 120 twip font size differs (see screenshot taking from today's nightly). We should aim to keep this consistent on every device, I was referring to point size as its a physical measurement resolution independent. Is that the case with twips.

Comment 25

[Matt Brubeck (:mbrubeck)]

(In reply to Patryk Adamczyk from comment #24)
> However we are finding that on different devices the 120 twip font size
> differs (see screenshot taking from today's nightly). We should aim to keep
> this consistent on every device, I was referring to point size as its a
> physical measurement resolution independent. Is that the case with twips.

It is not a precise physical measurement; it uses the same "device-independent" scale that Android uses for all of its UI and content.  This scale is *roughly* the same across devices -- for example, a 320dpi device will use a scaling factor 2x larger than a 160dpi device, so the physical size will be roughly the same.

But rather than use a precise physical measurement, Android prefers to ensure that the ratio between device-indpendent pixels ("dips") and physical pixels is a *simple* number like 1.0, 1.5, or 2.0.  This means that devices in a given class like "HDPI" (~240dpi) all use the same scaling factor of 1.5 dip/pixel.  For details, see:

http://developer.android.com/guide/practices/screens_support.html

So the Nexus One (3.7" screen at 800x480, 250dpi) and the HTC Evo (4.3" screen at 800x480, 217dpi) are in the same class, so both use the same number of physical pixels for a given UI or content element even though the Evo's pixels are physically larger.  This means that every app on the Evo will use the exact same pixels as on the Nexus One, but will be 15% larger physically to fit the 15%-larger screen.

Since this affects app on the device (not just Firefox text inflation), I think this difference between devices is something we should accept and be consistent with.  People who buy larger screens with lower resolution will be used to everything appearing larger than the nominal values.  People with small, high-resolution screens will be used to everything appearing smaller.  They will presumably use different postures and viewing distances to compensate.  (And of course, they can adjust font sizes in prefs if the defaults dosn't suit them on their devices.)

One attraction of larger-screened Android devices might be that they enlarge everything by default and so are good for people who benefit from large print for reading.

Comment 26

[Patryk Adamczyk [:patryk] UX]

Attachment: Bigger than expected inflation.

See screenshot... perhaps the sizing is off somewhere, but the fonts are inflated a little more than expected... small which should be 6pt renders / inflates to 7pt. So perhaps on larger screened devices we'll also need a "extra small" size which would be 4pt.

Comment 27

[JP Rosevear [:jpr]]

Release blockers.

Comment 28

[Ian Barlow (:ibarlow)]

Based Patryk's last comment, it sounds like all we still need is an "extra small" setting for larger phones, which would be around 4pt / 80twips.

Is that correct? Or do you need more information from us to proceed?

Comment 29

[Matt Brubeck (:mbrubeck)]

(In reply to Ian Barlow (:ibarlow) from comment #28)
> Based Patryk's last comment, it sounds like all we still need is an "extra
> small" setting for larger phones, which would be around 4pt / 80twips.

An 80twips option was added in bug 712760.  I'll resolve this bug now.