Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Text zooming causes overlap since line-height ('px') remains same

VERIFIED FIXED in mozilla0.9.8



CSS Parsing and Computation
16 years ago
16 years ago


(Reporter: Skewer, Assigned: jesup)


({access, testcase})

access, testcase

Firefox Tracking Flags

(Not tracked)




(3 attachments)



16 years ago
Procedure: View <> using a text zoom.

Expected: Text zoom should always be possible (for accessibility reasons), but
should not overlap due to the line-height rule in
<> for the "bodytextspaced" class. This
property should be ignored or adjusted when it has this effect on zoomed text.
The ideal thing to do would be to take the difference of the modified height of
the text in pixels and change the line-height value by that much. Similar
situations in different measurement units should be considered when writing the
fix to this bug.

Actual: Text overlaps when it is zoomed, making it unreadable to users who
browse with an increased font size.

Build: 2001081003 W98

Comment 1

16 years ago
Note that this only occurs at zoom levels of 300% or higher.
Keywords: access


16 years ago
Whiteboard: DUPEME

Comment 2

16 years ago
Created attachment 45883 [details]
Line-height reduced testcase


16 years ago
Keywords: testcase
If the line-height is in pixels, there isn't much we can do about it... What
you are really asking for is pixel zoom, which is a different thing altogether.

Basically, authors should never use pixels for text and line-height...

cc'ing dbaron for suggestions. We can't just apply font zoom to line-height 
because usually line-height is _dependent_ on the font-size itself anyway.
Yeah, I think the solution would be to implement Zoom in addition to "Text
Size".  There's a bug on that, right???

Comment 5

16 years ago
In all fairness, you can't really call any valid CSS "wrong." But the browser
should be able to handle such a situation without these overlapping problems.
Oops.  Do we scale pixel/physical-sized text with Text Zoom?  If so, we probably
need to do something about this...
Skewer: "valid" CSS doesn't mean it won't be unreadable or whatever. For example
the stylesheet which says:

   p { color: white; background: white; }

...will result in unreadable paragraphs, even though it is invalid.

dbaron: What can we do though? If someone gives line-height in pixels then they
are just asking for trouble -- it will clash with user stylesheets just as much
as with font zoom. IMHO 'line-height' should always be given in numbers, or, in 
certain rare cases, using '%', 'em' or 'ex' units.

Comment 8

16 years ago
ian: Whether or not this stylesheet is "correct," it is still a situation that
anyone who browses with zoomed text will encounter. If Mozilla can zoom
pixel-height text without encountering problems like this, it will be the
browser of choice for users with poor vision. This could just be as simple as
checking for overlapping and overriding any CSS values that cause it.
I agree, it's just that I don't know what we can do... 

Comment 10

16 years ago
*** Bug 100226 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
I'm going to attach a simple fix (beware: maybe too simple?)

Marc/DBaron: please review.
Target Milestone: --- → mozilla0.9.5

Comment 12

16 years ago
Created attachment 49869 [details] [diff] [review]
simple patch

Comment 13

16 years ago
I am afraid the patch will have a "doubling" effect when the proper fix for 
CalcLength() is made in nsRuleNode.cpp to use GetEmHeight() for 'em', 'ch' and 
'en' (= em/2). Actually, I just saw an XXX comment over there for that. What 
about bitting the bullet w.r.t. CalcLength() now that you are at it.

Comment 14

16 years ago
We can't do it in CalcLength() because the zoom ratio should be used when 
calculating the actual value, not the computed value. Did I miss something? :-(

Talking about zoom, I had forgotten about bug 51578 on my list.  Marking 
dependency although there isn't any: it's just for reference.
Blocks: 51578

Comment 15

16 years ago
If 'em' cannot come from GetEmHeight() then, there is a contradiction somewhere 
in the model. Take 'ex' which comes GetXHeight(), it works like a charm. I have 
no recollection of complains about it. All problems that I have seen seem to be 
connected to 'em' because it comes from nsFont::size which has not zoom. 
(Sometimes I see complains about 'px' too, and these situations can be traced to 
the fact that zoom is missing too, but 'px' is much harder to handle in a clean 
way since the intention is TEXTzoom, not the zoom of everything everywhere.)
It might be worth giving a try to GetEmHeight() to see how it goes...
rbs:  Is this fixed by your font changes?  (Or will there be a cleaner way once
they land?)

Comment 17

16 years ago
That's what I tried at first, although I zoomed GetNormalLineHeight() and 
GetMaxHeight() instead of GetEmHeight().  It did not work so I looked in Layout 
for the place (see my patch) where we compute the line height.  For pixel values 
however, we have "specified value = computed value = actual value" which 
incidentally means that the font changes won't change anything to the problem.  
If we want to apply the zoom, as far as I can tell, it must be done there.

I'm as bummed as you are by this because apparently, and if more bugs are filed, 
we may have to apply the zoom in other places as well.

Comment 18

16 years ago
With the explanations above, any volunteer to review these few lines of code?
This is wrong, as I mentioned above.

There is no correct "fix" for this. If line height is set in pixels, then this
is just the kind of problems you run into, and that's why you shouldn't set the
height in pixels. You'll get this problem *anyway*, even without font zoom, just
from the fact that the actual font size might not be the same as the specified
font size, and therefore will differ in ways the author did not expect. 

Having said that, if the patch looks for the exact case where line-height is set
to an absolute length (mm, cm, in, pt, pc) or in pixels (px), and in that exact
case zooms the line-height by the text zoom, then I won't block the patch.

If it affects 'em', 'ex', '%' or ratio line heights, then it is wrong and should
not be checked in.

Note that this will not make font zoom work for other cases where the author has
incorrectly assumed that if font-size is set to an absolute value, he can assume
that that will be the actual font-size. This is exactly why authors should be
using the 'em' unit.
Ian -- one of the problems is that our zoom is implemented at the wrong level. 
I'd rather see two separate zooms, one at a higher level (simply a dynamic
tweaking of the font size prefs) and one at a lower level (that scales
everything, perhaps by manipulating t2p when used in one direction but not the
other, which would require maintaining two different t2p constants).
Agreed, a pixel zoom is indeed a type of zoom we need. The font zoom, however,
as currently  written, works well with CSS, and should (IMHO) be kept as a
separate feature. (In an earlier draft of my comment above, in fact, I mentioned
that the "correct" solution was a zoom like Opera has.)

Comment 22

16 years ago
Tweaking the font size prefs is covered by bug 38521.  It's basically what the 
current Text Zoom does.

Scaling the t2p is another matter and I'm not sure users would like it.  For 
instance, go to CNN and enlarge the text using Text Zoom.  The text gets bigger 
but the columns stay of the same width and the page still fits within a regular 
monitor.  If we enlarge everything, users will have to scroll left and right in 
order to read the text.
The enlarging would happen before reflow, not after. Try it in Opera to see what
we are referring to.
Fixing this bug is just one step towards t2p scaling.  Once this is fixed there
will be other bugs reporting other types of overlop with text zoom, and to fix
them all, you need to move to t2p scaling...

Furthermore, horizontal scrolling would only be needed for pages that give
explicit widths (e.g., a 640px wide table, an 800px wide table, etc., which
causes horizontal scrolling for many people anyway).

Comment 25

16 years ago
dbaron: my fonts changes are not related to the problem. 

hixie: this is an interesting clue on how to attack problem:

>if the patch looks for the exact case where line-height is set
>to an absolute length (mm, cm, in, pt, pc) or in pixels (px), and in that exact
>case zooms the line-height by the text zoom

Yep, when aValue.IsFixedLengthUnit() && aCanTextZoom, then zoom-it... In other
cases, let the fix for GetEmHeight() do the rest... I think CalcLength() 
provides the centralized location to try to experiment that and see what 

141 nscoord CalcLength(const nsCSSValue& aValue,
142                    nsFont* aFont, 
143                    nsIStyleContext* aStyleContext,
144                    nsIPresContext* aPresContext,
145                    PRBool& aInherited, PRBool aCanTextZoom=PR_FALSE)
146 {
147   NS_ASSERTION(aValue.IsLengthUnit(), "not a length unit");
148   if (aValue.IsFixedLengthUnit()) {
        if (aCanTextZoom) {
          -> return zoomed value...
149     return aValue.GetLengthTwips();
150   }
151   nsCSSUnit unit = aValue.GetUnit();
152   switch (unit) {
153     case eCSSUnit_EM:
154     case eCSSUnit_Char:
          -> GetEmHeight()
        case eCSSUnit_EN
          -> tweak GetEmHeight()
188     case eCSSUnit_Pixel:
189       float p2t;
190       aPresContext->GetScaledPixelsToTwips(&p2t);
          if (aCanTextZoom) {
            -> return zoomed value...
191       return NSFloatPixelsToTwips(aValue.GetFloatValue(), p2t);

Further down:
SetCoord(..., aCanTextZoom=PR_FALSE)

2043  // line-height: normal, number, length, percent, inherit
2044  SetCoord(textData.mLineHeight, text->mLineHeight, parentText->mLineHeight,
2045           SETCOORD_LPFHN, aContext, mPresContext, inherited);
2045           SETCOORD_LPFHN, aContext, mPresContext, inherited, PR_TRUE);

Comment 26

16 years ago
Collision in mid-air with a similar description....
Ian, did you volunteer for it?

Comment 27

16 years ago
Perhaps, a less invasive way to try might be to instead do:
SetCoord(..., float aTextZoom=1.0f)

CalcLength(..., float aTextZoom=1.0f)
149     return aTextZoom * aValue.GetLengthTwips();
191     return NSFloatPixelsToTwips(aTextZoom * aValue.GetFloatValue(), p2t);

and let the caller (in the case of line-height, line 2043) set the textzoom.
Pierre: No, I'm QA. :-)

Comment 29

16 years ago
Forget my last comments above, the boolean route is much easier to extend to 
other properties if need arises.

Comment 30

16 years ago
Here is patch v2 based on roc's suggestion.  It doesn't work any better maybe 
because, as I wrote earlier, it modifies the computed value. I did not 
investigate further, I have to work on more urgent things.  Too bad.

For the record:
- The 'simple patch' does not work for 'ex' and '%' but works for 'em'.
- The 'patch v2' doesn't work for any relative unit.

Moved to mozilla1.0...
Target Milestone: mozilla0.9.5 → mozilla1.0

Comment 31

16 years ago
Created attachment 49943 [details] [diff] [review]
patch v2


16 years ago
Attachment #49869 - Flags: needs-work+


16 years ago
Attachment #49943 - Flags: needs-work+

Comment 32

16 years ago
People copied on this bug might be interested in bug 4821.

Comment 33

16 years ago
*** Bug 105262 has been marked as a duplicate of this bug. ***

Comment 34

16 years ago
*** Bug 105811 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
There was no such bug in Mozilla Ver.0.7. What code has been added to Ver.0.9 
to make this bug? Could it be compare between them?

Comment 36

16 years ago
*** Bug 106416 has been marked as a duplicate of this bug. ***


16 years ago
Whiteboard: DUPEME
At the risk of making this longer, I'm going to weigh in.  Go to  The page is laid out with
absolutely-positioned DIVs that are placed using 'em' units (e.g., 'top: 3em;').
 It also contains paragraph text with the declaration 'line-height: 1.25em;'. 
If you use Text Zoom either up or down, the positions of the DIVs don't change
and the line-height doesn't increase or decrease.  So... apparently 'em' is not
being recomputed during Text Zoom.  That's a bug, yes?  Sure seems like it to me.

If anyone wants me to report this in a new entry, let me know.

Comment 38

16 years ago
No need to open a new bug, it is the same problem with line-height.  I will have 
to revisit it: what we worked on with Ian and rbs last month did not work.

Comment 39

16 years ago

*** This bug has been marked as a duplicate of 41847 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 40

16 years ago
reopening: this bug contains more info than bug 41847
Resolution: DUPLICATE → ---


16 years ago
Priority: -- → P3
Target Milestone: mozilla1.0 → mozilla0.9.7

Comment 41

16 years ago
*** Bug 41847 has been marked as a duplicate of this bug. ***

Comment 42

16 years ago
Version 0.95+ font size control OK at "Traditional Chinese"  But fail 
at "Simplified Chinese".
"Tradition Chinese" result has been checked by addr.
"Simplied Chinese" result has been checked by addr.


16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 43

16 years ago
Pierre: I'm willing to work on this; I need to be able to zoom all font sizes
including em and px, but this bug causes layout problems with some pages.  Any
The basic problem is that there are two reasonable ways to do zoom:
 * scale everything by changing the definition of a pixel
 * change the base font size

The problem with text zoom is that I tries to do halfway between these -- scale
only text by changing the definition of a pixel.  That just doesn't work.  There
are a bunch of other bugs on this same problem.

Comment 45

16 years ago
Complete page zoom (including images, etc) would be bug 4821.  That's on hold
waiting for work to avoid zooming scrollbars/etc, and for better image-scaling code.

If changing the base font size in prefs would fix pages that specify in px, then
that would be fine too (in fact better); I posted bug 113013 for unifying the
text sizing prefs.

I have a display that simply can't readably display fonts in the sizes specified
on pages like CNN (in px units).

We could change the px -> point-size conversion to "match" the change in default
font size selected (choose a 20% larger default font and px values translate
into 20% larger point sizes).  If you did that, perhaps textZoom would no longer
be needed?  Of course, this would be problematic for standards (if you modified
the base font size), so perhaps you'd need a pref to turn off this px scaling
(the default should IMHO be to scale the px values for POLA reasons).

As I stated in bug 113013, this is also an accessibility issue.

Comment 46

16 years ago
*** Bug 113004 has been marked as a duplicate of this bug. ***

Comment 47

16 years ago
Randell: you can take this bug, thanks.  I don't like the idea of pixel scaling 
very much, it generates more problems as I described in bug 4821 comment #14.

Comment 48

16 years ago
Ok, taking this bug.  Pierre (rbs, Hixie), I can certainly use some suggestions
on what to attack to solve this.
Assignee: pierre → rjesup
The way to fix this bug is to implement zoom in a sensible way.  The current way
is simply broken-as-designed and this is an inherit problem with it.

Comment 51

16 years ago
Well, I'm open to suggestions.  I absolutely need this feature (larger fonts,
including CSS-specified fonts - even px-specified) in the short term, so either
we come up with a reasonable design, or I'll have to hack something to fix the
current one.
I think the solution here should be a real zoom (bug 4821), as I described in .  There's probably not
much debugging to get that working, at least if you're willing to let scrollbars
scale too...

Comment 53

16 years ago
Unfortunately, while I need real zoom (for other reasons), I need to be able to
increase the size of text without increasing the size of everything else. 
Setting the existing font prefs only picks up <font size=n> and CSS small,
medium etc, which leaves minor sites like CNN unreadable.  (Quite literally on
our display system a smallish font specified in pixels is barely if at all

In fact when I do a "zoom everything", I'll want the fonts to be even bigger to
maintain the relative size.

Also, I'm not the only person who would like text zoom to work properly; lots of
people with iffy eyesight probably would like to increase font sizes.  That's
one reason why web browsers almost from the very beginning have had the ability
to adjust what is considered "normal" font size.  Until Opera, none (or none
that I knew of) typically gave the option to adjust image sizes - though it does
make sense to have that option.

I'm going to be trying to solve this; if I can do so in a manner that's useful
to the mozilla tree/community that's all the better and my preference, but
otherwise I may have to do some foul hack that gets me working and can't go back
into the tree.  Bug 4821 is something I care about, but cannot substitute for a
working text zoom (and right now the only things broken by the current text zoom
that I can see are px and em/ex specified sizes for things like line-height). 
I'm open to suggestions.

I could simply warp the font engine to provide larger fonts than are requested,
which might fix the em/ex issues, and to an extent would probably fix
px-specified fonts (since I could just return a font that's larger than
requested) - but line heights, etc in px values would be still be off.  It may
be that it's the simplest (partial) solution to the whole CSS versus control of
font size question.
We *have* working font size zoom.

The only problem this bug is talking about is that authors that specify the font
size in pixels (or any absolute unit), i.e. independenantly of the font size,
are finding their pages do not work well when the font is not what they expected.

Well duh.

This bug is akin to one saying that we should make sure we handle the case where
an author specifies a page's background colour but no the foreground colour and
this results in a clash with the user's preferred colours.

There's not much we can do (certainly not while remaining within the specs).
Scaling line-heights set in pixels or absolute units while not scaling
line-heights correctly set in ratios, percentages, ems or exs will result in
well designed pages that _want_ that behaviour (e.g. when using line-height for
layout purposes unrelated to text) to screw up.
Sorry, Ian, but it's not that simple.  I contributed examples (see midway
through the discussion) where elements are positioned, and line heights defined,
entirely in ems-- and they don't scale on text resize.  See which is what I offered before.  When you
resize the text, the positioned boxes don't move (they use ems for 'top' and
'left' and so on) and the line-heights don't increase even though they're also
set with ems.

The whole question of whether pixel measure should scale is a tough one-- if we
allow the text resize to override pixel-set font sizes, then at a minimum
line-heights should scale as well.  But there should be no question about ems,
obviously, and there's still a problem there (unless that was fixed in a recent
build and I missed it).
emeyer: The 'em' issue is a separate and totally valid issue, covered by bug
41847, which I only just noticed was very incorrectly closed as a dup of this
one. That is wrong. These two bugs are totally independent.

This bug covers specifically the interaction of font zoom with the 'line-height'
property and the 'px', 'mm', 'cm', 'in', 'pt' and 'pc' units. Bug 41847 covers
the font zoom property interacting with the 'em' unit on all properties.

Regarding _this_ bug:

Note that this is not actually related to font zoom, it's just shown with font
zoom. You can also show this bug simply by changing your font prefs to a higher
font size, or by overriding font sizes in your userContent.css file.

<mkaply> maybe we should have a popup when you zoom "this site sucks and uses
lineheight so your zoom will look like crap. let them know"

If the suggestion given much higher in this bug (scale pixels and absolute units
if the font size is zoomed) is used, then it should imho be optional and default
to off. "[ ] Adapt font zoom to deal with badly designed pages" or something.

To fully fix this and other as yet unreported font zoom issues, we will need to
implement full zoom, as dbaron has pointed out.
Summary: Text zooming causes overlap since line-height remains same → Text zooming causes overlap since line-height ('px') remains same
> emeyer: The 'em' issue is a separate and totally valid issue, covered by bug
> 41847, which I only just noticed was very incorrectly closed as a dup of this
> one. That is wrong. These two bugs are totally independent.

It's not a separate issue in terms of implementation.  It's very difficult to do
a text zoom that:
 * is not a full zoom
 * doesn't have bug 41847, and
 * scales pixel-sized fonts.
(When I say very difficult, I mean that I can't think of a way to do it without
rewriting half of layout, and I'm not even sure if it's theoretically possible.
 Well, actually, I can think of a way to do it -- implement full zoom, and then
implement hacky code to *undo* that zoom for images.)

However, I'm still not anywhere close to convinced that the two types of zoom
defined/allowed by CSS specifications (change of default font size and full
pixel zoom) are not sufficient to solve all the problems described.  I don't
know why you say that "[bug 4821] cannot substitute for a working text zoom" --
I'm really not sure what you mean by working text zoom, but I'm reasonably
confident that nothing that's any stronger than changing the default font size
short of doing full (or quasi-full as I described above) zoom will work reliably
on arbitrary web pages.

Comment 58

16 years ago
Let me try explaining this issue another way.

I have a display device that will _not_ produce readable fonts if they're
specified as they are on CNN in px values (etc) and we follow the spec.  My
pixels are degraded by the display chain such that I need to be able to use
fonts on average about 150% larger.  This is all fonts in all situations (I'm
also flattening the font size curve try to keep layout reasonable with large
fonts and bump the <font size=1> fonts up, but that's a separate issue).

Scaling images up as well as fonts is not a feasible option (for the default). 
I have way too few pixels already, and most pages are fine.  Those pages with
very fine detail (small text) in images will require the user to hit a Zoom
button that will zoom text and images (bug 4821).  I cannot make that the
default, or layout goes to shit and the users spend half their life scrolling or
reading 2-word-wide columns.

Other users of Mozilla/Netscape/etc who have poor sight (or poor displays, or
just like large text) may well wish to do the same thing, which was
traditionally available in browsers - increase the font sizes of all fonts. 
Under CSS, the absolute sizing made available removes the ability for the user
to affect text sizes on some sites.

It's all well and good to say "they shouldn't use that".  Well, the committee
put it in there, and they're using it.  Getting 'them' to stop using these nice,
convenient, standards-compliant mechanisms is unlikely.

I could simply return bigger fonts than they requested when they ask for an X
point font, or a Y px font.  This would I believe solve many of the issues with
em, ex, etc units.  This would still be broken when they do something evil (like
on CNN) like specify a line-height in px.  If need be I could use this solution
and wallpaper over problems with line-height, etc - I hope.

I can live with Ian's suggestion:
>If the suggestion given much higher in this bug (scale pixels and absolute
>if the font size is zoomed) is used, then it should imho be optional and
>to off. "[ ] Adapt font zoom to deal with badly designed pages" or something.

I have no problem with this being something which, if selected, breaks strict
conformance.  Perhaps "[ ] Scale absolute font sizes on pages according to
preferred font size".  Or some such.

I am quite open to alternatives for increasing font sizes.  I orginally tried
adjusting the default font prefs, which doesn't help with much of CSS.  The
table/calcs in nsStyleUtil.cpp for mapping user font pref to points has the same
problem (though I can use it to flatten the font size curves for <font size=n>
and CSS small, medium, etc.

Comment 59

16 years ago
What about trying to iterate on pierre's patch v2? It might perhaps help in your
rjesup: I think the solution to your problem is to implement full zoom (see
patch in bug 4821) and then implement undoing of that full zoom for images so
that everything except images are scaled.

Comment 61

16 years ago
I just tried dbaron's patch for bug 4821 and it nicely zooms the content as 
expected (there is a remaining bug with scrollbars though). Indeed that might be 
the way to go for your problem. And if you have a fix to turn image zoom off, 
the end result will be equivalent to the current text zoom without the
line-height (and form control) bugs.

Eventually therefore, text zoom and full zoom could be implemented using the two 
modes (i.e., with an image zoom on & off state that images can query).

Comment 62

16 years ago
It could be that this full zoom with images un-zoomed will work - though I'd
have to solve the scrollbar issue (any suggestions on that btw?  I could take a
look at it.)

If I suppress zoom of images, will there be any other issues?  Will this cause
confusion with code that plays with width/height on images, or any other code? 
Hmmmmmm.  Just thought of something.  This will affect things like <td width=N>
even if we undo it for images.  That could cause some serious wierdnesses for
tables of images, which are very very common, and some other tables.  So I'm
worried this might cause as many problems as it will solve.

If we can undo zooming of images (anything else need it?) and get it to work,
then we could change the text zoom menu to use that mechanism.

God do I wish I could outlaw absolute positions/units in CSS.

Comment 63

16 years ago
I think only zoom text is unacceptable, because the Chinese characters are 
images. It would be mixed up without space between the words. In worst case 
that could not be recognized. 
Printing needs zooming of images.  A full zoom feature also does.  So you
probably need to implement an additional unzoom-images feature rather than
breaking zoom for images.

Comment 65

16 years ago
> Just thought of something.  This will affect things like <td width=N>
> even if we undo it for images.

Your problem is definitely peculiar... Full zoom will scale the width, height,
borders, paddings, margins, etc. Things stay nice to look at because its scaling
keeps the overall aspect, but it doesn't look like that is what you want since
scrollbars appear where there wasn't. Pierre's patch is an option that you might
want to consider at this stage.
Hmmm.  The td issue is a problem -- earlier I was thinking it wouldn't be as
long as the zoom was more than 100%, but I had it backwards -- it's a problem
whenever the zoom is more than 100%.

Comment 67

16 years ago
OS -> all, adding aaronl since this is an accessibility issue as well
OS: Windows 98 → All
Randell: I'm confused. Your comments don't make complete sense. We *do* scale
fonts with absolute font sizes. scales fine, except for some minor
overlapping on the left hand side, which is caused by us only scaling fonts and
not everything.

Comment 69

16 years ago
Ian: sorry if this is confusing; the discussion has gone back and forth several
times due to suggestions from dbaron, etc.

The base bug this is about is the problem with the line heights (and all other
font-size-relative dimensions for non-font objects).  The suggestion was made
that instead of trying to fix that problem (which apparently isn't easy), we
instead fix 4821 (general zoom).  While that's an admirable thing to do and I
very much want to see it done, it doesn't solve my problem because I need a
working (as well as possible) text zoom.  The discussion has also touched on the
font prefs, what they affect, how, etc.  (See bug 113013 for most that that
> I have a display device that will _not_ produce readable fonts if they're
> specified as they are on CNN in px values (etc) and we follow the spec.

I assume this device is one such as a TV, where so called "pixels" are a
somewhat  fuzzy concept and small text is indeed unreadable, because you get
rather unfortunate smudging effects (the same effects which actually make
photographic images look ok even when not scaled).

As I see it, these are our options:

1. Provide no scaling.
   Layout is preserved.
   Text is unreadable.
   Already implemented.

2. Provide spec-compliant font zoom.
   Layout is mostly preserved, but looks out of scale compared to text.
   Text is readable, some overlap occurs.
   Already implemented (but has major bug 41847).

3. Provide font zoom supplemented by line-height adjustment.
   Layout is mostly preserved, but looks out of scale compared to text.
   Text is readable.
   Mostly implemented except for line-height adjustment (this bug).

4. Provide font zoom supplemented by adjustment of pixels and absolute units.
4. Provide general zoom except for pictures.
   Layout is broken.
   Text is readable.
   Not implemented. Would require major, non-standards-compliant, invasive and 
   dangerous changes to layout.

5. Provide spec-compliant general zoom.
   Layout is preserved but viewing area is reduced.
   Text is readable.
   Not implemented but frequently requested. See bug 4821 or bug 112018.

There's no perfect answer, but we can narrow them down: 1 is out of the
question, 2 is sub-optimal because of the text overlap (this bug), 4 is
unacceptable because of the seriously broken layout. This leaves 3 and 5.

I think we should implement both. In particular, I think we should fix this bug
by scaling 'line-height's set in absolute units and pixels if and only if a
hidden pref (default to off) is set, and we should separately implement bug 4821.

Is this an acceptable compromise?

Comment 71

16 years ago
Having had the chance to experiment both modes (text zoom & full zoom), I too
agree that both modes are needed.

Comment 72

16 years ago
Ian, RBS: Absolutely, numbers 3 (this bug) and 5 (bug 4821) are exactly what I'd
like to see done.  I agree totally.
The bug this report initially described should now be fixed (see bug 41847), but
this bug sems to be a bit broader now, and I think there may be a bunch of
issues that should be split into other bugs.

Comment 74

16 years ago
Indeed it has. The testcase and URL zoom without overlapping now in 2002021708 WXP.

As it was reported, this bug has been fixed. We should cover other issues
mentioned here in new bugs. For example, bug 4821 for the suggestion of zooming
objects with text.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
VERIFIED. Randell: does the fix satisfy your needs?

Comment 76

16 years ago
*** Bug 128281 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.