Last Comment Bug 31961 - feature to zoom so that majority of text on a page is user's default size
: feature to zoom so that majority of text on a page is user's default size
Status: NEW
: access
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 enhancement with 8 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 245468 422093 430211 438794 (view as bug list)
Depends on: 39117 83119
Blocks: 661785
  Show dependency treegraph
 
Reported: 2000-03-15 11:06 PST by Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
Modified: 2013-09-03 07:21 PDT (History)
33 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
First attempt, has issues and includes debug dumping (10.38 KB, patch)
2001-05-31 07:39 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
Minimal test case (255 bytes, text/html)
2001-08-21 10:23 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details
Slightly modified JS for test harness (save as zoomlevel-test.js) (4.87 KB, text/javascript)
2001-08-21 10:24 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details
Test harness (610 bytes, text/html)
2001-08-21 10:25 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details
testcase for use in harness (1.29 KB, text/html)
2001-08-21 17:50 PDT, Dylan Schiemann
no flags Details
New version of zoomlevel-test.js (5.00 KB, application/x-javascript)
2001-08-22 11:25 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details
Patch for chrome--now mostly works (9.60 KB, patch)
2001-09-01 12:48 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
New iterative algorithm (6.01 KB, application/x-javascript)
2006-05-29 02:24 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details
Patch for Firefox that replaces zoom reset function with smart zoom (8.15 KB, patch)
2006-05-30 08:16 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
Patch for Firefox that replaces zoom reset function with smart zoom using DOMI utils (5.88 KB, patch)
2006-06-01 06:38 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
Patch for Firefox that replaces zoom reset function with smart zoom using C++ (10.12 KB, patch)
2006-06-05 07:21 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
Patch for Firefox that replaces zoom reset function with smart zoom using C++, v2 (10.05 KB, patch)
2006-06-06 03:30 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
Patch for Firefox that replaces zoom reset function with smart zoom using C++, v3 (9.12 KB, patch)
2006-07-27 13:32 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
WIP (4.91 KB, patch)
2007-12-01 12:21 PST, hhaamu
no flags Details | Diff | Splinter Review

Description Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2000-03-15 11:06:40 PST
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.
Comment 1 troy 2000-03-15 11:24:40 PST
Reassigning to Erik
Comment 2 Erik van der Poel 2000-03-15 15:43:24 PST
This is an interesting suggestion. I think it would take a while to implement
it, so I'm tentatively setting the milestone to M20.
Comment 3 Akkana Peck 2000-03-20 19:22:05 PST
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.
Comment 4 Matthew Paul Thomas 2000-03-26 09:00:56 PST
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?
Comment 5 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2000-03-26 10:03:41 PST
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.)
Comment 6 Matthew Paul Thomas 2000-03-27 01:09:13 PST
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?
Comment 7 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2000-03-27 01:55:35 PST
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).

Comment 8 fahrner 2000-03-27 23:38:26 PST
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.
Comment 9 ekrock's old account (dead) 2000-06-12 14:23:13 PDT
Enh --> FUTURE.
Comment 10 rbs 2000-10-01 13:08:04 PDT
Is this bug still necessary now that bug 37940 is fixed?
Comment 11 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2000-10-01 13:17:13 PDT
This bug is still necessary.
Comment 12 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2000-10-26 06:34:13 PDT
>- 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.
Comment 13 Karl Ove Hufthammer 2000-10-26 11:04:18 PDT
> 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.
Comment 14 Frank Tang 2001-05-07 23:41:38 PDT
erik resign. reassign all his bug to ftang for now.
Comment 15 Frank Tang 2001-05-08 00:18:17 PDT
mark all future new as assigned after move from erik to ftang
Comment 16 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-05-30 03:29:26 PDT
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.
Comment 17 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-05-31 07:39:44 PDT
Created attachment 36650 [details] [diff] [review]
First attempt, has issues and includes debug dumping
Comment 18 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-05-31 08:05:08 PDT
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.
Comment 19 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-08-21 10:23:57 PDT
Created attachment 46604 [details]
Minimal test case
Comment 20 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-08-21 10:24:56 PDT
Created attachment 46605 [details]
Slightly modified JS for test harness (save as zoomlevel-test.js)
Comment 21 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-08-21 10:25:21 PDT
Created attachment 46606 [details]
Test harness
Comment 22 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-08-21 10:38:57 PDT
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/
Comment 23 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-08-21 11:07:25 PDT
Harish has worked on getComputedStyle(), so maybe he can help... Harish, it
seems like the function sometimes returns unexpected/wrong values.
Comment 24 Dylan Schiemann 2001-08-21 17:50:01 PDT
Created attachment 46687 [details]
testcase for use in harness
Comment 25 Dylan Schiemann 2001-08-21 17:51:52 PDT
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.
Comment 26 Dylan Schiemann 2001-08-21 18:37:42 PDT
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
Comment 27 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-08-22 11:15:04 PDT
Thank you!

I'll change the way I use getComputedStyle().
Comment 28 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-08-22 11:25:23 PDT
Created attachment 46747 [details]
New version of zoomlevel-test.js
Comment 29 Hixie (not reading bugmail) 2001-08-25 18:52:19 PDT
taking qa...
Comment 30 Frank Tang 2001-08-31 14:09:16 PDT
reassign. this is really a browser UI issue. 
Comment 31 Asa Dotzler [:asa] 2001-08-31 18:28:30 PDT
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). 
Comment 32 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-09-01 05:56:08 PDT
Assigning to self.
Comment 33 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-09-01 12:48:33 PDT
Created attachment 47973 [details] [diff] [review]
Patch for chrome--now mostly works
Comment 34 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-09-01 12:57:29 PDT
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.
Comment 35 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-09-03 04:58:46 PDT
Bug 98052 filed about the rounding problem.
Comment 36 Jesse Ruderman 2001-09-23 03:57:08 PDT
Q: What happens while a page is loading, before Mozilla knows how many 
characters of each size there are on the page?
Comment 37 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-09-23 05:02:54 PDT
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.)
Comment 38 Jesse Ruderman 2001-09-23 05:21:31 PDT
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.
Comment 39 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2001-09-23 05:32:10 PDT
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.
Comment 40 Jesse Ruderman 2003-04-01 23:23:18 PST
See also bug 181438, "text zoom should not skip percent that makes page text
match default font size".
Comment 41 Bill Mason 2004-06-03 11:50:21 PDT
*** Bug 245468 has been marked as a duplicate of this bug. ***
Comment 42 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-05-29 02:24:50 PDT
Created attachment 223676 [details]
New iterative algorithm
Comment 43 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-05-30 08:16:28 PDT
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.
Comment 44 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-06-01 06:38:58 PDT
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. :-(
Comment 45 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-06-05 07:21:35 PDT
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.
Comment 46 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-06-06 03:30:53 PDT
Created attachment 224534 [details] [diff] [review]
Patch for Firefox that replaces zoom reset function with smart zoom using C++, v2

Now using nsTArray.
Comment 47 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-07-06 06:44:04 PDT
Test builds for OS X and Ubuntu are available:
http://hsivonen.iki.fi/kesakoodi/builds/
Comment 48 Felix Miata 2006-07-06 07:16:06 PDT
linux-i686.tar.bz2 successfully started on SuSE 10.0
Comment 49 Felix Miata 2006-07-07 01:11:55 PDT
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.
Comment 50 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2006-07-11 11:55:20 PDT
For what it's worth, I think probably this should be a capability provided by Gecko rather than something done as part of Firefox.
Comment 51 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-07-27 13:32:46 PDT
Created attachment 230981 [details] [diff] [review]
Patch for Firefox that replaces zoom reset function with smart zoom using C++, v3

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.
Comment 52 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-08-22 12:13:07 PDT
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?
Comment 53 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2007-02-07 07:18:14 PST
This bug is de facto WONTFIXed, but I leave it open in case someone else wants to try.
Comment 54 Vincent Lefevre 2007-02-07 16:36:43 PST
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)?
Comment 55 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2007-02-11 07:24:21 PST
> Did you have any answer to your question to beltzner (comment #52)?

No.
Comment 56 Mike Beltzner [:beltzner, not reading bugmail] 2007-02-14 10:44:55 PST
(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"
Comment 57 Jesse Ruderman 2007-02-14 17:14:45 PST
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.
Comment 58 Matthew Paul Thomas 2007-02-15 13:44:58 PST
  Bigger    Ctrl +
  Smaller   Ctrl -
  Normal    Ctrl 0
-------------------
/ Automatic
Comment 59 hhaamu 2007-12-01 12:21:32 PST
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.
Comment 60 Jesse Ruderman 2008-03-11 18:52:36 PDT
*** Bug 422093 has been marked as a duplicate of this bug. ***
Comment 61 Bartek 2008-03-11 20:43:36 PDT
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 :)
Comment 62 Matthias Versen [:Matti] 2008-04-22 05:22:53 PDT
*** Bug 430211 has been marked as a duplicate of this bug. ***
Comment 63 Jesse Ruderman 2008-06-16 18:04:57 PDT
*** Bug 438794 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.