Pixel-size font limits do not scale

ASSIGNED
Assigned to

Status

()

Core
XUL
--
major
ASSIGNED
16 years ago
7 years ago

People

(Reporter: Roland Mainz, Assigned: Roland Mainz)

Tracking

({fonts})

Trunk
mozilla1.0.1
All
Linux
fonts
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
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)

Updated

16 years ago
Keywords: fonts
(Assignee)

Comment 1

16 years ago
Taking myself...
Assignee: jaggernaut → Roland.Mainz
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
(Assignee)

Comment 2

16 years ago
Created attachment 83295 [details] [diff] [review]
Patch for 2002-05-08-08-trunk
(Assignee)

Comment 3

16 years ago
Requesting r=/sr= ...
Keywords: patch, review

Comment 4

16 years ago
Roland: would you kindly expound a bit more on what device scaling is?
(Assignee)

Comment 5

16 years ago
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.
(Assignee)

Comment 6

16 years ago
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

16 years ago
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?
(Assignee)

Comment 8

16 years ago
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

16 years ago
> 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.