Closed Bug 53995 Opened 24 years ago Closed 19 years ago

using "text zoom" to scale fonts very small makes them come back normal

Categories

(Core :: CSS Parsing and Computation, defect, P5)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8beta2

People

(Reporter: jruderman, Assigned: dbaron)

References

Details

(Whiteboard: [good first bug])

Attachments

(5 files, 1 obsolete file)

test case
447 bytes, text/html
Details
wrapping previous testcase with <div style="font-size:4%"> has similar effect to ctrl-J
485 bytes, text/html
Details
<div style="font-size:1%"> becomes 100% with normal settings
44 bytes, text/html
Details
Possible patch
1.51 KB, patch
emaijala+moz
: review+
dbaron
: superreview+
dbaron
: approval1.8b2+
Details | Diff | Splinter Review
font-size: 0; and font-size: 0%; testcase
849 bytes, application/xhtml+xml
Details 
Decrease the text size a bunch of times using ctrl-J on the testcase.  You'll 
notice that after a while, the paragraphs that start out with the smallest 
fonts come back really small.  Pressing ctrl-K reverses the effect, so it's 
easy to work around the problem.

This happens with both html 3 style (<font>) and html 4 style (<div style=...>).
Attached file test case — 

    
    

    
  
I guess we hit a font size of 0 pixel and come back to normal.
Marking future.

Status: NEW → ASSIGNED
Target Milestone: --- → Future

    
    

    
  
The Ctrl-J and Ctrl-K shortcuts have been replaced with Ctrl-minus and Ctrl-
plus.

    
    

    
  
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian

    
    

    
  
*** Bug 75334 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 57971 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Hardware: PC → All

    
  
Summary: using "text size" to scale fonts very small makes them come back normal → using "text zoom" to scale fonts very small makes them come back normal

    
    

    
  
*** Bug 122531 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 143974 has been marked as a duplicate of this bug. ***

    
    

    
  
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW

    
    

    
  
*** Bug 153764 has been marked as a duplicate of this bug. ***

    
    

    
  
the text no longer becomes big for me, but the 75% text at the bottom of
attachment 15422 [details] disappears altogether at small font zooms.

    
    

    
  
*** Bug 152476 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 175527 has been marked as a duplicate of this bug. ***

    
    

    
  
Ehemm, you just need a range check, so what? why don't you fix it? This is a
beginner's bug par excellence. Note: this bug occurs in Phoenix 0.3, not in
Mozilla. So why do you change my bug to a two years old mozilla related bug?
Mozilla works fine. 

    
    

    
  
Is this really a bug on all platforms?  The GTK font code already does a range
check on font sizes, and I can't reproduce this bug in the GTK port.

What platforms does it exist on?  (Windows?  Mac?)

    
    

    
  
Still present on Windows 2000.

    
    

    
  
*** Bug 178016 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 185573 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 195321 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 199624 has been marked as a duplicate of this bug. ***

    
    

    
  
I tried the original testcase in 1.4rc2 for Mandrake Linux 9.0 KDE, OS/2 & W32.
WFM in Linux & OS/2. Still broken in W98.

    
    

    
  
Still broken in Windows XP on 1.4 final... why can't there just be a limit set?
(i.e. if the font size is already at the minimum, don't reduce it any further.)

    
    

    
  
Still broken in 1.5b 2003090104. 

    
    

    
  
*** Bug 229288 has been marked as a duplicate of this bug. ***

    
    

    
  
Leonardo: you attached that to the wrong bug.

    
    

    
  
Still exists in Mozilla 1.5 Win98SE, but I couldn't reproduce it on Firebird
20031216 Win2000. Could this be W9x specific?

    
    

    
  
I can repro on WinXP:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040114
Firebird/0.8.0+ (MozJF)

    
    

    
  
I'm sorry, I had minimum font size set. Now I can reproduce it on the mentioned
Firebird and W2k.

Comment 4: If mozilla outputs text in font size 0 and it is displayed as big, it
may be an OS bug. Or it may be a feature. If it is even in XP, Mozilla should
fix it and set an internal limit, e.g. each font can only be scaled down to 1px.

    
    

    
  
*** Bug 208429 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 237836 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 238727 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 241598 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 249450 has been marked as a duplicate of this bug. ***

    
    

    
  
still present with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040707 Firefox/0.9.2 also when the text "goes back to normal size" it
overlaps 

    
    

    
  
*** Bug 256263 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 258145 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 265241 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 268814 has been marked as a duplicate of this bug. ***

    
    

    
  
I think I can fix this...

The problem originates with nscoord not being a float (/me will search for the
depending bug)

I found out where I need to patch (or so I think) will compile a new build
tonight with that in mind, and test:
http://lxr.mozilla.org/mozilla/source/content/base/src/nsRuleNode.cpp#1866

Though since ZoomText returns a nscoord I am not too enthusiastic about this.
http://lxr.mozilla.org/mozilla/source/content/shared/src/nsStyleStruct.cpp#252

For reference it occurs in my environment when (computed) font-size is under 0.5
pixels (< 0.5px).  though <FONT SIZE=...behaves a bit different, and doesnt
directly change computed font-size (according to DOMi), perhaps an issue for a
different bug.
Depends on: 265084

    
    

    
  
Adding bug 265084 as a dependency doesn't make sense.  Fixing this doesn't
depend on it happening first, and fixing it alone won't automatically fix this.

You're probably on the wrong track anyway, since really it should be up to the
system GFX backends to clamp font sizes to what the system can handle.
No longer depends on: 265084

    
    

    
  
dbaron assuming I am right on this, which I feel strongly that I am, nscoord
being float would fix this, my patch I am doing is a hack until such time
(assuming the ZoomText stuff is not to fault)

I agree that it should be up to the Gfx layers to say which font-sizes they can
support (as low as they can go for a particular platform for really small
fonts), though I am fairly sure that I am in teh right ballpark, I am in the
process of compiling a build now for this, to test.

Without any disrespect meant, if you can show me that I am wrong with lxr-links
I will "believe" you on that I am in the wrong area/thought, though I did not
see anything explaining so for Windows users, just yet in my peeks.

I will examine more though later. (got to be in work in 8 hours, and sleep
between now and then)
Depends on: 265084

    
    

    
  
This looks very suspicous as well: 
http://lxr.mozilla.org/mozilla/source/gfx/src/windows/nsFontMetricsWin.cpp#509

This is likely it, though I would like to verify my fix does not help, and this
will take some time if it is the latter.

[quote source="MSDev Help on my computer" of="LOGFONT"]
lfHeight:
Specifies the height, in logical units, of the font's character cell or
character. The character height value (also known as the em height) is the
character cell height value minus the internal-leading value. The font mapper
interprets the value specified in lfHeight in the following manner. Value Meaning:
> 0 = The font mapper transforms this value into device units and matches it
against the cell height of the available fonts. 
  0 = The font mapper uses a default height value when it searches for a match. 
< 0 = The font mapper transforms this value into device units and matches its
absolute value against the character height of the available fonts. 
[/quote]

    
    

    
  
*** Bug 270403 has been marked as a duplicate of this bug. ***

    
    

    
  
I agree with comment 17.

I cannot reproduce this on Linux with official build of Firefox 1.0. I can see
it with a win32 build. Isn't this a Windows only problem?


    
    

    
  
Nobody can read fonts <~9px anyway. The only reasons to fix this are to prevent
additional dupes and "good first bug" (comment 16). Fixing this is waste of time
for anyone with experience.
Severity: minor → trivial
Priority: P3 → P5
Whiteboard: [good first bug]

    
    

    
  
Actually, I like the effect of zooming the fonts to 1px and watching a page
'from distance' :)))) Of course it is not for everyday forum reading :)

Anyway, it should be fixed, because it is and unchecked boundary condition.
Currently, it just wraps and the fonts come back big. What if it crashes someday?

    
    

    
  
*** Bug 273954 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 277326 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 280090 has been marked as a duplicate of this bug. ***

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Possible patch
        — 
          — Splinter Review
      

    


  
How about this?

If height goes to zero, we set it back to -1.

While I was in the file, I corrected a grammar error, and updated the link to
the MS KB article.

-dave

    
  

        Attachment #173253 -
        Flags: review?(dbaron)

        Attachment #173253 -
        Flags: superreview+

        Attachment #173253 -
        Flags: review?(emaijala)

        Attachment #173253 -
        Flags: review?(dbaron)

    
    

    
  
Comment on attachment 173253 [details] [diff] [review]
Possible patch

r=emaijala

        Attachment #173253 -
        Flags: review?(emaijala) → review+

    
    

    
  
Will this patch cause

   font-size: 0

...to fail? It's a legal construct and should make the text disappear.

    
    

    
  
*** Bug 284562 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 288142 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 292682 has been marked as a duplicate of this bug. ***

        Attachment #138543 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #55)
> Will this patch cause
>    font-size: 0
> ...to fail? It's a legal construct and should make the text disappear.

DavidG (or JustinW, or anyone): could you comment on IanH's question ?

    
    

    
  
Comment on attachment 173253 [details] [diff] [review]
Possible patch

This is better than our current behavior even though it's not perfect, and we
should get it in.

        Attachment #173253 -
        Flags: approval1.8b2+

    
    

    
  
dbaron: does it break font-size: 0?

    
    

    
  
It shouldn't break 'font-size: 0' since 'font-size: 0' looks like it's already
broken.  Do you have a testcase?  I don't really care since I think we should
ship with a default minimum font size pref.

Fix checked in to trunk.  Thanks for the patch.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

    
  
After reading all the comments,
undoing
{{
mpt@myrealbox.com
2001-09-22 06:45 PDT
OS/Version 	Windows 98 	All
Platform 	PC 	All
}}
as it does not seem to apply (anymore ?).

(I did not check the duplicates...)
If other OS families are concerned, revert this and explain.
Severity: trivial → minor
OS: All → Windows 98
Hardware: All → PC
Target Milestone: Future → mozilla1.8beta2

    
    

    
  
The only non-Windows duplicates are bug 57971 and bug 185573.

    
    

    
  
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050504] (nightly) (W98SE)

(In reply to comment #58)
> *** Bug 292682 has been marked as a duplicate of this bug. ***

I check with the <about:> page.

The patch fixed the issue on the text parts,
but the bug still appears on the 4 bullets at the left of the text.

Could this be fixed too ?

    
    

    
  
(In reply to comment #64)
> The only non-Windows duplicates are bug 57971 and bug 185573.

I changed bug 185573 which was Windows NT(/2K) in fact.

I guess bug 57971 was fixed in the meantime ? Or should the current bug be
reopened ??

    
    

    
  


  
Testcase for testing the behaviour with font-size: 0; and font-size: 0%;. As
for this patch 'breaking' the behaviour, it does not. It acts the same on trunk
as in 1.0.3. However, as David Baron said in comment 62, it's kind of broken
anyway.
Depends on: 296219

    
    

    
  
(In reply to comment #65)
> but the bug still appears on the 4 bullets at the left of the text.

Fixed by bug 296219.
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 303498 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: