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 conveniently. 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 shortcut. 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 size. - 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
This is an interesting suggestion. I think it would take a while to implement it, so I'm tentatively setting the milestone to 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 until 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 dialog).
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.
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.
mark all future new as assigned after move from erik to ftang
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.
Created attachment 36650 [details] [diff] [review] First attempt, has issues and includes debug dumping
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.
Created attachment 46605 [details] Slightly modified JS for test harness (save as zoomlevel-test.js)
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 http://www.pcworld.com/ 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 http://www.pcworld.com/
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 http://www.dylanschiemann.com/examples/fontSize3.html 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 document.getElementById("contentarea").contentDocument.documentElement.defaultView , I get it to work as expected... See http://www.dylanschiemann.com/examples/fontSize4.html
Thank you! I'll change the way I use getComputedStyle().
reassign. this is really a browser UI issue.
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).
Assigning to self.
I attached a new patch. Highlights: * Now it mostly works in the browser! * Using the autozoom on a pref-respecting page works the same as returning to 100%. Lowlights: * 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 loaded.)
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.
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. ***
Created attachment 223676 [details] New iterative algorithm
Created attachment 223787 [details] [diff] [review] Patch for Firefox that replaces zoom reset function with smart zoom 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.
Created attachment 224058 [details] [diff] [review] Patch for Firefox that replaces zoom reset function with smart zoom using DOMI utils 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. :-(
Created attachment 224433 [details] [diff] [review] Patch for Firefox that replaces zoom reset function with smart zoom using C++ 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.
Created attachment 224534 [details] [diff] [review] Patch for Firefox that replaces zoom reset function with smart zoom using C++, v2 Now using nsTArray.
Test builds for OS X and Ubuntu are available: http://hsivonen.iki.fi/kesakoodi/builds/
linux-i686.tar.bz2 successfully started on SuSE 10.0
Puzzling and discouraging results. Using the "shame" column links from http://mrmazda.no-ip.com/shame.html 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.
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?
This bug is de facto WONTFIXed, but I leave it open in case someone else wants to try.
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)? No.
(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
Created attachment 291009 [details] [diff] [review] WIP 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 :)