Open Bug 31961 Opened 25 years ago Updated 2 years ago

feature to zoom so that majority of text on a page is user's default size


(Core :: Layout, enhancement, P3)





(Reporter: hsivonen, Unassigned)


(Blocks 1 open bug)


(Keywords: access, Whiteboard: FFI?)


(5 files, 9 obsolete files)

255 bytes, text/html
610 bytes, text/html
1.29 KB, text/html
9.12 KB, patch
Details | Diff | Splinter Review
4.91 KB, patch
Details | Diff | Splinter Review
Executive summary:
This RFE describes an algorithm for picking a good zoom factor for font zoom. The 
intent is to make zooming fonts easy for the user by reducing the number of user 
events required to pick a suitable zoom factor.

Longer description:

The problem
Some Web designers make the fonts on their pages too small for users to read 

The usual solution
The problem is usually alleviated by implementing a font zoom and providing 
commands for zooming in and zooming out incrementally. This way the user has to 
experiment with a few zoom factors before finding a suitable one.

Adding automation
The usual page with which the user wants to use the font zoom is a page with a 
lot of text. The user has already set the preferred font size. Mozilla could 
automatically pick the best suited zoom factor once the user has chosen to use 
the zoom.

"Increase Font Size" and "Decrease Font Size" in the View menu could be replaced 
with a single two-state menu item "Autozoom fonts". A check mark could be use to 
indicate whether the feature is enabled. The menu item should have a keyboard 

When enabled, the following algorithm would be performed on the page:
- Convert all font sizes to pixel height of the lower case x (or something 
equivalent in non-Latin fonts).
- For the purpose of size counting, reduce the variance of sizes by 
flooring all odd sizes to even sizes. 
- For each font size, count the number of characters on the page in that 
- Find out which size had the largest number of characters.
- Scale all font sizes on the page accordingly to make the dominant size 
match the user's preferred font size.

Answers to possible questions

Q: Wouldn't this feature just cause designers to make fonts even smaller.
A: No. The feature shouldn't be enabled by default, so the designers should have 
no illusion that Mozilla uses a font that is larger than the designer intends.

Q: The algorithm could fail fail occasionally. What about that?
A: The algorithm would fail with pages with particularly small amount of 
paragraph level text. The user is not likely to enable the feature in such a 
case, since there is not a lot of text to read.

Q: Why this should be a menu item and not a preference?
A: This is not a feature that should be enabled all the time. It should only be 
enable when needed. This way well designed Web pages would not be affected. 
Features that are enabled and disabled during the normal use of an application do 
not belong in preferences.

Q: I never use the View menu. Why should the command be there?
A: The de facto place for commands related to zooming is the View menu if the 
application has one. This does not mean that there couldn't be alternative way to 
enable and disable the feature.

Q: Why isn't a setting for minimum font size adequate?
A: To optimize readability, the bulk of the text should be displayed at the 
user's preferred size. The user may well be able to read short pieces of text 
such as captions in a slightly smaller size. The algorithm described here takes 
this into account.
Reassigning to Erik
Assignee: troy → erik
This is an interesting suggestion. I think it would take a while to implement
it, so I'm tentatively setting the milestone to M20.
Ever confirmed: true
Target Milestone: M20
Very cool.  Though if this weren't automatic and I had to go to the menus to
invoke it, I suppose I'd be just as happy with an "increase fonts" item.
Q: What do I do the auto-zoom is turned on, and most of the text on the page is
   in my default size, but I actually want to zoom in and see a small chunk of
   text which is too small for me to read?
A: It seems that the algorithm needs also a minimum size that is smaller than the 
preferred size but still big enough for captions. If you still want to zoom in on 
some small chunk of text, use "Zoom to Level ..." command.

("Autozoom Fonts" should have a command of its own. Putting it behind a "Zoom to 
Level ..." dialog would defeat its purpose.)
Q.  Let's say I have a page on a shopping site (using one-click ordering), with
    chunks of text in two sizes, A and B. The amount of text in each size is
    roughly equal. The auto-zoom comes down in favor of A, because there are a
    few more characters in size A than there are in size B.

    On the page are `Fewer' and `More' buttons for increasing and decreasing the
    quantity from the default (5 items, say), a `Cancel' button for cancelling
    the order, and a `Buy' button for completing the purchase. The `More' and
    `Fewer' buttons use DOM to dynamically update the total price and other
    purchasing details on the page.

    The user only wants to buy 3 items, not 5, so they move to click the `Fewer'
    button twice. They click it the first time, and some of the content on the
    page is changed. As a result, there are now a few more characters in size B
    than in size A, so the auto-zoom recalculates the size of all text using size
    B as the standard.

    The user goes to click the `Fewer' button again, but where the `Fewer' button
    was a moment ago, there is now the `Buy' button. So the user inadvertently
    clicks the `Buy' button, and buys more than they intended. Or he/she
    inadvertently clicks the `Cancel' button, and wipes his/her painstakingly
    prepared order.

    How would this problem be solved?
A: The zoom factor should remain constant after the user has enabled the feature 


a) the user disables the feature

b) the user uses the Zoom to Level... command

c) the user moves to a different page

DOM changes should not retrigger the zoom factor calculating algorithm. If the 

changes in the document are big enough to require a different zoom level, the 

user can disable the autozoom and re-enable it (two user events) or use the Zoom 

to Level... command (two or more user events depending on the complexity of the 


Do check out the Text Zoom feature in MacIE5 for reference. While not 

nearly as sophisticated as the algorithm Henri proposes, it's quite good 

IMO, and certainly easier to implement. The scaling intervals used match 

those that govern the CSS absolute font size keywords, as now 

implemented in both MacIE5 and Mozilla.
Enh --> FUTURE.
Target Milestone: M20 → Future
Is this bug still necessary now that bug 37940 is fixed?
This bug is still necessary.
>- For the purpose of size counting, reduce the variance of sizes by 
>flooring all odd sizes to even sizes.

Actually, it would make sense to floor to odd sizes if the user-preferred ex-height 
happens to be odd (and to even if the user-preferred ex-size happens to be even). This 
way the user-preferred size would always remain unchanged in the process.
> Q: Why this should be a menu item and not a preference?
> A: This is not a feature that should be enabled all the time. 

Q: Won't it be *possible* to have it enabled all the time?
   I would like that.
erik resign. reassign all his bug to ftang for now.
Assignee: erik → ftang
mark all future new as assigned after move from erik to ftang
Depends on: 39117
Depends on: 83119
I have preliminary DOM traversal code written for this feature. Now I need to figure out how to put it in the 
chrome and make it work with the zoom manager.
I attached a patch. There are, of course, issues. (Why must there always be issues?)

* It works with my simplified test cases. It doesn't work on some notable real pages. I don't know why that 
happens. (I suspect the Quirks mode and inheritance to tables is involved.) Need to investigate.
* The target size is the Western proportional font size. Monospaced fonts are also scaled according to the 
proportional font pref. (I don't think it is worth the rouble to work around that.) If the user has chosen another 
preferred side for other encoding, the Western pref is still used as the target.
* It doesn't work in Mail&News.

* The keyboard shortcut is an ad hoc choice.

Design modifications:
* The ex size is not used, because it hasn't been implemented, yet.
* I dropped the idea about reducing the size variance.
* I didn't implement the menu item as a two-state item. It doesn't make sense in the context of the current 
zooming submenu. The Autozoom menu item always invokes the Autozoom algorithm. Choosing "100% 
(Original Size)" is needed to return to original size.
* The minimum zoom is 100. The Autozoom will only scale up.

Other things:
* Zoom persistance is outside the scope of this bug.
* General zoom problems like bug 80817 are outside the scoe of this bug.
Attached file Test harness
Now I could use some help.

I can extract the proper font size from the minimal test case. However, on a
real-world site such as the font sizes extracted from
the DOM are bogus--they always equal the font size pref.

I would appreciate it, if someone could help in tracking down the problem.

Here's how to test:
* Set your font size to 18px. (The test harness version requires this as it
doesn't read prefs.)* Save attachment 46605 [details] as zoomlevel-test.js
* Save attachment 46606 [details] in the same folder and load it in Mozilla.
* In the text field, enter a URL for a page that has small fonts.
* Unfocus* The text field
* Wait for the page to load in the iframe.
* Click the zoom button
* Grant privileges if you trust me :-)
* An alert with a zooming factor appears. It is supposed to be the ratio of 18px
and the most common size on the page.
* For diagnostics, a dump of the the encountered nodes is appended to the doc.
You can check whether the sizes match the sizes of dislayed fonts.

Actual results:
Works with attachment 46604 [details] but doesn't work at
Harish has worked on getComputedStyle(), so maybe he can help... Harish, it
seems like the function sometimes returns unexpected/wrong values.
The attached testcase shows that it is not a problem with getComputedStyle
returning the wrong value... it is something that the harness is doing that is
causing getComputedStyle to always return 16px... I'll keep looking at the
harness and see if I can isolate this.
I have placed an example at which seems to show that
using getComputedStyle() across frames does not work the way you are trying to
do so in the test harness.  This is a cross-document issue... if you replace
window with
, I get it to work as expected... See
Thank you!

I'll change the way I use getComputedStyle().
Attached file New version of zoomlevel-test.js (obsolete) —
taking qa...
QA Contact: petersen → ian
reassign. this is really a browser UI issue. 
Assignee: ftang → asa
Component: Layout → Browser-General
QA Contact: ian → doronr
Target Milestone: Future → ---
Frank, browser-general is for people who don't know how to file bugs on the
correct components or bugs which don't fit into any other component. This does
not belong in browser-general and moving it here only delays the bug on the way
to being fixed.  The best component for this would probably be XPApps (along
with additional bugs on UI Design for design review). 
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Assigning to self.
Assignee: pchen → henris
Attachment #36650 - Attachment is obsolete: true
I attached a new patch.

* Now it mostly works in the browser!
* Using the autozoom on a pref-respecting page works the same as returning to 100%.

* Some pages might show rounding problems.
* Still doesn't work in Mail&News.
* With this patch applied, the last submenu item doesn't show up correctly on
Mac OS X.
* Keyboard shortcut is unofficial.* The target size is the Western pref
regardless of page encoding.
Bug 98052 filed about the rounding problem.
Q: What happens while a page is loading, before Mozilla knows how many 
characters of each size there are on the page?
A: The current zoom is used since the autozoom doesn't run automatically. (I
haven't tested what happens if the user invokes the autozoom while a page is
loading. The command should probably be deferred until the page has been fully
Q: What's the point then?  Hitting Ctrl++ a variable number of times is easier 
and faster to hit than Ctrl+Shift+9, gives the user more control over the zoom, 
and won't screw up when the portion of the page the user is interested in isn't 
also the part with the largest amount of text.
A: The point is that one keyboard shortcut does the job. In my experience
zooming with Ctrl++ and Ctrl+- requires more key strokes and still the result
isn't exactly what I wanted. First I press Ctrl++ repeatedly until the text is
too big. Then I press Ctrl+- once. Then the result is still a bit off the
optimal target.
Summary: [RFE] Easier to use font zoom → feature to zoom so that majority of text on a page is user's default size
See also bug 181438, "text zoom should not skip percent that makes page text
match default font size".
*** Bug 245468 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Keywords: access
Attached file New iterative algorithm (obsolete) —
Attachment #46605 - Attachment is obsolete: true
Attachment #46747 - Attachment is obsolete: true
Attachment #47973 - Attachment is obsolete: true
Component: XP Apps → Menus
Product: Mozilla Application Suite → Firefox
The attached patch replaces the zoom reset function with the new smart zoom function. (This is for testing so that testing doesn't require XUL changes.)

When running with this patch, accel-0 activates the smart zoom. If the current page is already zoomed to the smart zoom level, the zoom level reverts to 100%.

Even though the reset function is here overwritten for test purposes only, in the interest of avoiding menu bloat, actually shipping this feature as a replacement for the "Normal"/reset() menu item could make sense. In any case, this whole feature is rather pointless if it doesn't get a keyboard shortcut. Using accel-0 would mean not hoarding more keys for zoom.

The Western font pref is used as the reference size. I really don't know how to deal with the different font prefs that do not really fit in the CSS font size model.

The code is not as fast as I'd like it to be. In fact, it is shamefully slow compared to what native code should be able to do with the same algorithm. My measurements suggest that a non-trivial part of the slowness is due to the security model. The same code placed into an HTML document and accessing the DOM of its own document runs much faster. Any ideas how to make it run faster from chrome would be appreciated.

Perhaps I should try to use a more coarse nsITextContent-based heuristic instead of my precise regexp-based heuristic. Also, I should try using instanceof instead of checking the SVG namespace.

Moreover, better ideas of how to deal with SVG would be welcome.
I think is about as fast as it gets with JS.

Looks like I have to rewrite this in C++ to avoid UI lockups with big docs like the Web Apps 1.0 spec. :-(
Attachment #223787 - Attachment is obsolete: true
Moved the tree walk to C++. Now it is fast enough even with large test cases.

The code is most likely in the wrong place. Also, nsIFrame is not a stable API.
Attachment #224058 - Attachment is obsolete: true
Now using nsTArray.
Attachment #224433 - Attachment is obsolete: true
Test builds for OS X and Ubuntu are available:
linux-i686.tar.bz2 successfully started on SuSE 10.0
Puzzling and discouraging results. Using the "shame" column links from where most links on hover summarize the method of undersizing the text at the destination URI, on opening each URI in turn in same tab and repeating accel-0, here's what I see per URI (1792x1344, DPI 168, 28px default):

accessites - 0-initial; 1-near my default; 2-smaller than 1, but better than 0; 3-same as 0. Good result.
afl-cio - 0-initial mousetype; 1-larger, major mess; 2-similar (slightly larger);3-same as 1; 4-same as 0. Poor result.
aimia - 0-initial mousetype; 1-near my default; 2-also good, larger than 1; 3-same as 1; 4-same as 0. Good result.
aol - 0-initial; 1-same as 0; 2-same as 0; 3-same as 0. Ineffective result.
apple - 0-initial mousetype; 1-minescule improvement; 2-same as 0; 3-same as 1. Useless result.
AT&T - 0-initial mousetype; 1-minimal improvement; 2-almost same as 1; 3-same as 0. Inneffective result.
BOA - 0-initial; 1-near my default; 2-same as 0. Fair result.
B&N - 0-initial mousetype; 1-near my default; 2-also good, larger than 1; 3-same as 1; 4-same as 0. Usable result.
bigcharts - 0-initial mousetype; 1-better, but still tiny; 2-same as 0. Marginal result.
CBSTV - 0-initial mousetype; 1-near my default, but not particularly usable; 2-slightly larger than 1; 3-same as 1; 4-same as 0. Marginally helpful result.
CBSMW - 0-initial mousetype; 1-near my default, unusable; 2-slightly larger than 1; 3-same as 1; 4-same as 0. Poor result.
certified - 0-initial; 1-near my default, with overlapping & hidden text; 2-same as 0. Fair result.
chase - 0-initial; 1-near my default; 2-same as 0. Usable result.
chathouse - 0-initial mousetype; 1-mixed improvement; 2-same as 0. Marginally helpful result.
chitrib - 0-initial mousetype; 1-near my default; 2-slightly larger than 1; 3-same as 1; 4-same as 0. Usable result.
jacksonville - 0-initial; 1-near my default in left div, gigantic in right div; 2-slightly smaller than 1; 3-same as 1; same as 0. Marginally helpful result.
LA - 0-initial; 1-nominal improvement (text in images); 2-same as 0. Marginally helpful result.
NY - 0-initial mousetype; 1-near my default, overlapping/hidden text; 2-slightly larger than 1; 3-same as 1; 4-same as 0. Mostly usable result.
tampa - 0-initial; 1-near my default; same as 0. Good result.
cnet - 0-initial; 1-near my default, but overlapping text; 2-same as 0.  Marginally helpful result.
cnn - 0-initial mousetype; 1-larger, major mess; 2-similar to 1; 3-same as 1; 4-same as 0. Unusable result.

Just guessing that this needs to be using the bug 4821 (page zoom) fix. Barring that, it probably needs to be disabling all container sizing and absolute positioning to avoid overlapping and/or hidden text. Overall, view -> page style -> no style produces more usable results.
For what it's worth, I think probably this should be a capability provided by Gecko rather than something done as part of Firefox.
This new patch moves the code to the place suggested by dbaron, fixes assertions from nsTArray and makes the behavior correct on pages with iframes.

Who should I talk with about changing the UI to provide an entry point for this feature?

Re comment #49: This feature is only a front end for choosing the zoom level for the existing text zoom feature. Nothing more, nothing less. This doesn't provide Opera-style image zoom, for example. With this revised patch, this feature works as designed with the random samples from the shame gallery that I tried.

Re comment #50: Pushed the rest of the feature to the C++ side, so embedders don't need to reimplement what was previously left to JavaScript.
Attachment #223676 - Attachment is obsolete: true
Attachment #224534 - Attachment is obsolete: true
beltzner, what's your take on the UI entry point for automatic font zooming? Do you approve of replacing the View->Text Size->Normal menu item with an item that autozooms but reverts to 100% if the view is already at the autozoom level? Or should this have a new UI entry point?
QA Contact: bugzilla → menus
This bug is de facto WONTFIXed, but I leave it open in case someone else wants to try.
Assignee: hsivonen → nobody
I disagree that this bug should be WONTFIXed, but I agree with comment #50 (this is what I thought when I reported bug 245468, which was then marked as a duplicate of this bug).

Did you have any answer to your question to beltzner (comment #52)?
> Did you have any answer to your question to beltzner (comment #52)?

(In reply to comment #52)
> beltzner, what's your take on the UI entry point for automatic font zooming? Do
> you approve of replacing the View->Text Size->Normal menu item with an item
> that autozooms but reverts to 100% if the view is already at the autozoom
> level? Or should this have a new UI entry point?

Would this be a modal toggle (like: auto-zoom=on/off) or would it be a one time "analyze this page and zoom to the optimal level"? Either way it would require a new entry point, I think, probably best labelled "Zoom to Fit"
I don't think this feature should be called "Zoom to Fit".  Many programs use a similar-sounding name for the feature that makes the width of the document (which is usually equal to the width of a printed page) fit exactly on the screen, regardless of the size or legibility of text.
  Bigger    Ctrl +
  Smaller   Ctrl -
  Normal    Ctrl 0
/ Automatic
Attached patch WIPSplinter Review
I took a different approach in this and scrapped the automagical part altogether.

What it basically does is add a context menu item to selected text which auto-zooms the page according to text. Hardcoded x-western, and only for SeaMonkey, for now. Appears to work.
Shouldn't this be almost trivial to implement with the current full-page zoom thing in beta 4 of firefox 3?

1) grab the smallest font in the document
2) scale the document (in full, no character counting or other fancy things) to a size where that smallest font corresponds to a user specified minimum
3) make people with seeing disabilities or HTPC users happy :)
Component: Menus → Layout
Product: Firefox → Core
QA Contact: menus → layout
Blocks: 661785
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.