143989 - Pixel-size font limits do not scale

Status: RESOLVED WONTFIX

(Core :: Layout: Text and Fonts, defect)

Description

[Roland Mainz]

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.

Comment 1

[Roland Mainz]

Taking myself...

Comment 2

[Roland Mainz]

Attachment: Patch for 2002-05-08-08-trunk

Comment 3

[Roland Mainz]

Requesting r=/sr= ...

Comment 4

[kill this account]

Roland: would you kindly expound a bit more on what device scaling is?

Comment 5

[Roland Mainz]

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.

Comment 6

[Roland Mainz]

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).

Comment 7

[kill this account]

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?

Comment 8

[Roland Mainz]

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.

Comment 9

[kill this account]

> 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.

Comment 10

[Zack Weinberg (:zwol)]

Is this still a meaningful bug?

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 12

[Neil Deakin]

Doubt this is valid, but let's move it to a better component first.

Comment 13

[Jonathan Kew [:jfkthame]]

I don't think this is something we want to pursue at this point. The (optional) minimum font size preference is expressed in CSS pixels, which means it is inherently independent of page zoom, and that's the right implementation IMO.