Closed Bug 53995 Opened 24 years ago Closed 20 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: 20 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: