While thinking about how we can get rid of the issues on high-resolution Xservers I stubled over a very stupid issue: We have limits to avoid that the size of fonts goes lower than a certain limit - however we do not honor any device scaling value.
Assignee: jaggernaut → Roland.Mainz
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Requesting r=/sr= ...
Keywords: patch, review
Roland: would you kindly expound a bit more on what device scaling is?
Brian Stell wrote: > Roland: would you kindly expound a bit more on what device scaling is? Sure. Maybe my english was not exact in this case. I mean the scaling factor from |nsIDeviceContext::GetCanonicalPixelScale()| (I call it "czoom" here) which is used by layout code to scale _everything_ - incl. images and fonts. Since the pixel size limits are designed/calculated for a scaling factor of |1.0| (the default) we should scale them using the "czoom"-value when it is not 1.0 - otherwise a "zoomed" version of the document would not zoom everything correctly since the lower font size limits do not affect the fonts which are too small when czoom is 1.0 but stop hitting these limits when the document gets scaled up.
I am not sure but bug 142400 ("Problems with text within <font size="1">") may be a the same issue when we scale fonts _down_ (previous example was talking about scaling "up"... but scaling "down" should IMHO lower the pixel size limits to avoid differences in layout between the non-zoomed and zoomed(-down) version of the same page).
Let me start by saying that I do not feel that zoom should just be a magnifier. Zoom is slightly different from magnifier. To me magnifier seems like an accessibility tool that enlarges at the pixel level. What ever rounding (errors) happened that forced a particular pixel on or off should get reproduced in the magnified page. To me zoom makes the whole page larger while trying to minimize enlarging individual pixels. Zoom aims at making the elements of the page represent the relatively scaled *desired* size not just a linear scaling of the unzoomed page. Minimum font size ----------------- + minimum *= gDevScale; This is an interesting question. This setting was added because below a minimum size text is not readable. While it would seem silly for a web developer to design an unreadable page in fact we see this all the time. The web designer has a high res screen so a small *point* size on that system is readable and gets more info on a page. On systems with lower res display the small point size ends being too small a pixel size and becomes unreadable. Hence this setting. Since this setting has to do with minimum pixel size that is readable shouldn't moz use the non scaled size so the display will be as near to the the web page's desired (zoomed) size as possible? Minimum outline scaling size ---------------------------- - gOutlineScaleMinimum = scale_minimum; + gOutlineScaleMinimum = scale_minimum * gDevScale; Outline scaled fonts look very poor (even unreadable) when the glyph size is small. Zoom does not change this constraint so I believe that zooming smaller should not change this setting. What should moz do when scaling larger? Moz always tries to use (non scaled) bitmaps first. When zooming larger why should moz change this minimum? If there is an bitmap in a nearby size it will be selected. If there is not and the glyph is large enough that outline scaling will produce reasonable results then why shouldn't moz use it to get the web page's desired (zoomed) size for this font? Minimum anti-aliased bitmap scaling size ---------------------------------------- - gAABitmapScaleMinimum = scale_minimum; + gAABitmapScaleMinimum = scale_minimum * gDevScale; I'd say the discussion is basically identical with outline scaling. Minimum bitmap scaling size ---------------------------------------- - gBitmapScaleMinimum = scale_minimum; + gBitmapScaleMinimum = scale_minimum * gDevScale; X server scaled bitmaps are especially ugly but I'd say the discussion is basically identical with outline scaling. At some point an "ugly font" is better than a "wildly wrong sized font". Do you see any way that zoom changes this? Minimum anti-aliased outline bitmap scaling size ------------------------------------------------ - gAntiAliasMinimum = antialias_minimum; + gAntiAliasMinimum = antialias_minimum * gDevScale; I'd say the discussion is basically identical with outline scaling. Anti-aliased sharpening values ------------------------------- - gAASBDarkTextMinValue = int_val; + gAASBDarkTextMinValue = int_val * gDevScale; - gAASBLightTextMinValue = int_val; + gAASBLightTextMinValue = int_val * gDevScale; - gAATTDarkTextMinValue = int_val; + gAATTDarkTextMinValue = int_val * gDevScale; These value have to do with setting the grey (alpha) level where sharpening begins and have nothing what so ever to do with glyph size. These should not be affected by zoom. Did you see saw a case where where something looked poor?
bstell wrote: > Since this setting has to do with minimum pixel size that is readable > shouldn't moz use the non scaled size so the display will be as near to the > the web page's desired (zoomed) size as possible? Not if we want correct linear scaling. The (currently) unscaled pixel size limits are one of the main reasons why text overlaps in the print preview (CC:'ing rods). > Did you see saw a case where where something looked poor? It is not about "looking poor"... it's about that layout of the scaled page version can differ _a_lot_ from the unscaled version since the pixel size limits do not scale. I think the device scaling value should allow a linear scaling of the content if possible (as an alternative we could introduce a new boolean |DoLinearDeviceScaling| in nsIDeviceContext to enable/disable real linear scaling...). A scaling value of 1.0 should always result in a readable page, scaling the page down does _not_ need to gurantee that the page should still be readable since the user _knows_ that things will be smaller. And scaling a page "up" should always preserve the layout of the page if possible.
> Not if we want correct linear scaling. > The (currently) unscaled pixel size limits are one of the main > reasons why text overlaps in the print preview (CC:'ing rods). There are several subjects here. Printing and print preview are very different beasts from scaling the screen display. First, moz does not want WYSIWYG printing. That is to say that printing is not expected to nor should it match normal screen layout. The horizontal to vertical ratio is different and things like scrolled lists may/may-not not appropiate to simply print as displayed on the screen since scroll bars are of no use on a printed page. Second, print preview should try to match the printed page as much as possible. This is however a tough problem. Even if moz *always* and *only* used scalable fonts then the best that print preview could do would be a rough approximation. The reason is that the resolution on the printed page is (almost) always higher than the screen. Because the screen resolution is lower this means that if we use regular fonts for print preview then we are stuck with pixel aligned glyphs which cannot be aligned with the higher res printed output. I can think of 5 possible approaches to this problem. 1) Use existing fonts and live with text that is too long or too short (due to pixel alignment). Allowing smaller fonts for print preview would help somewhat here but certianly would not produce an accurate representation. 2) Use existing font and truncate longer lines to eliminate overlap. This is very similar to #1 but might be a little bit better. 3) Use glyphs that are no bigger than the scaled size and then individually calculate the position of each glyph and draw each one at the pixel that most nearly represents the printed position. I did something very similar to this in 1989 and it looked quite good. To produce the scaled glyphs we could use the AASB code. 4) Force the printed page to align its glyphs with the print preview positions. This would make the print preview and printed page match but would make the printed page sub-optimal. 5) Render the text off screen at printer res the anti-alias scale it to screen res. This would produce the most faithful screen image since the scaled glyphs would not be pixel aligned. > ... layout of the scaled page version can differ _a_lot_ from > the unscaled version since the pixel size limits do not scale. For scaling up I think that this is a good thing. Because glyphs are (typically) pixel aligned scaling will always be non-linear. Since we already know we will be non-linear so why should we carry limits that applied to the smaller size? Wouldn't we want the display to as accurately match the *desired* size? Scaling down is a very different problem as discussed above. Excluding print preview I have not heard this being requested. > I think the device scaling value should allow a linear scaling > of the content if possible (as an alternative we could introduce > a new boolean |DoLinearDeviceScaling| in nsIDeviceContext to > enable/disable real linear scaling...). ... scaling the page > down does _not_ need to gurantee that the page should still be > readable since the user _knows_ that things will be smaller. Do you want print preview or linear scaling? Other than print preview why would we want this? > And scaling a page "up" should always preserve the layout of the > page if possible. We disagree here. I strongly feel that it should match the *desired* layout and not the layout caused by screen limitation at lower size.
Is this still a meaningful bug?
You need to log in before you can comment on or make changes to this bug.