Closed
Bug 95267
Opened 23 years ago
Closed 22 years ago
Text zooming causes overlap since line-height ('px') remains same
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9.8
People
(Reporter: SkewerMZ, Assigned: jesup)
References
()
Details
(Keywords: access, testcase, Whiteboard: INVALID/WONTFIX)
Attachments
(3 files)
6.02 KB,
text/html
|
Details | |
758 bytes,
patch
|
Details | Diff | Splinter Review | |
4.79 KB,
patch
|
Details | Diff | Splinter Review |
Procedure: View <http://www.wpdfd.com/> 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 <http://www.wpdfd.com/wpdstyles2.css> 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
Note that this only occurs at zoom levels of 300% or higher.
Keywords: access
Updated•23 years ago
|
Whiteboard: DUPEME
Comment 3•23 years ago
|
||
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???
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...
Comment 7•23 years ago
|
||
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.
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.
Comment 9•23 years ago
|
||
I agree, it's just that I don't know what we can do...
Comment 10•23 years ago
|
||
*** Bug 100226 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
I'm going to attach a simple fix (beware: maybe too simple?) Marc/DBaron: please review.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
Comment 12•23 years ago
|
||
Comment 13•23 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•23 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•23 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•23 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•23 years ago
|
||
With the explanations above, any volunteer to review these few lines of code?
Comment 19•23 years ago
|
||
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).
Comment 21•23 years ago
|
||
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•23 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.
Comment 23•23 years ago
|
||
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•23 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
happens.
lxr.mozilla.org/seamonkey/source/content/html/style/src/nsRuleNode.cpp#141
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•23 years ago
|
||
Collision in mid-air with a similar description.... Ian, did you volunteer for it?
Comment 27•23 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.
Comment 28•23 years ago
|
||
Pierre: No, I'm QA. :-)
Comment 29•23 years ago
|
||
Forget my last comments above, the boolean route is much easier to extend to other properties if need arises.
Comment 30•23 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•23 years ago
|
||
Updated•23 years ago
|
Attachment #49869 -
Flags: needs-work+
Updated•23 years ago
|
Attachment #49943 -
Flags: needs-work+
Comment 32•23 years ago
|
||
People copied on this bug might be interested in bug 4821.
Comment 33•23 years ago
|
||
*** Bug 105262 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
*** Bug 105811 has been marked as a duplicate of this bug. ***
Comment 35•23 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•23 years ago
|
||
*** Bug 106416 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Whiteboard: DUPEME
Comment 37•23 years ago
|
||
At the risk of making this longer, I'm going to weigh in. Go to http://www.meyerweb.com/eric/css/edge/. 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•23 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•23 years ago
|
||
*** This bug has been marked as a duplicate of 41847 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 40•23 years ago
|
||
reopening: this bug contains more info than bug 41847
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Priority: -- → P3
Target Milestone: mozilla1.0 → mozilla0.9.7
Comment 41•23 years ago
|
||
*** Bug 41847 has been marked as a duplicate of this bug. ***
Comment 42•23 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. www.linuxfab.cx "Simplied Chinese" result has been checked by addr. www.linuxeden.com
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Assignee | ||
Comment 43•23 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 ideas?
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.
Assignee | ||
Comment 45•23 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•23 years ago
|
||
*** Bug 113004 has been marked as a duplicate of this bug. ***
Comment 47•23 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.
Assignee | ||
Comment 48•23 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
Status: ASSIGNED → NEW
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.
s/inherit/inherent/
Assignee | ||
Comment 51•23 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 http://bugzilla.mozilla.org/show_bug.cgi?id=113013#c2 . There's probably not much debugging to get that working, at least if you're willing to let scrollbars scale too...
Assignee | ||
Comment 53•23 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 readable.) 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.
Comment 54•23 years ago
|
||
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.
Comment 55•23 years ago
|
||
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 http://www.meyerweb.com/eric/css/edge/ 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).
Comment 56•23 years ago
|
||
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.
Whiteboard: INVALID/WONTFIX
Updated•23 years ago
|
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.
Assignee | ||
Comment 58•23 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 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. 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•23 years ago
|
||
What about trying to iterate on pierre's patch v2? It might perhaps help in your situation.
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•23 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).
Assignee | ||
Comment 62•23 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•23 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•23 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%.
Assignee | ||
Comment 67•23 years ago
|
||
OS -> all, adding aaronl since this is an accessibility issue as well
OS: Windows 98 → All
Comment 68•23 years ago
|
||
Randell: I'm confused. Your comments don't make complete sense. We *do* scale fonts with absolute font sizes. cnn.com scales fine, except for some minor overlapping on the left hand side, which is caused by us only scaling fonts and not everything.
Assignee | ||
Comment 69•23 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 discussion.)
Comment 70•23 years ago
|
||
> 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•23 years ago
|
||
Having had the chance to experiment both modes (text zoom & full zoom), I too agree that both modes are needed.
Assignee | ||
Comment 72•23 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.
Reporter | ||
Comment 74•22 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.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Comment 75•22 years ago
|
||
VERIFIED. Randell: does the fix satisfy your needs?
Status: RESOLVED → VERIFIED
Comment 76•22 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.
Description
•