167162 - Fonts interacts badly with CanonicalPixelScale

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[rods (gone)]

I am not sure that this is even the appropriate description for the problem.

See:
http://bugzilla.mozilla.org/show_bug.cgi?id=153080#c9

I think in a nutshell it is this: 
When the font objects are constructed, any font that is derived from a
Pixel-based size converts it's pixel size to twips using the
CanonicalPixelScale, font derived from Point-based sizes do not.

This means that when printing or in PP we now have to figure out which fonts
have already been scaled which have not. The burden of this (at the moment)
would be placed on the nsRuleNode.

dbaron argues correctly that this is really the wrong place to have to worry
about this and make adjustments to these values.

So the problem is really at least twofold:
1) What do we really do with the CanonicalPixelScale and how does it effect 
   Zooming and Scaling
2) What to do about font sizes and how and when they get zoomed/scaled.

Note: 
When in nsRuleNode any fonts being created from style info, the pixel/point
information is available. But the problem is when we try to figure out
inheritance and/or we need to look at any of the existing font objects we run
into a problem that we don't know if the current font size which is already in
twips is pre-scaled (whether it came from a pixel size that was calc'ed using
the CanonicalPixelScale) or not.

A simple solution (to illustrate the problem) is if each generic font object
contained a flag to indicate whether it needed to be scaled or not and possibly
it original size before any scaling was done. This way we could always tell what
to do with the font.

I guess I might implement this by adding a getter method
"GetOriginatingFontSize" or something like that.

------------------------------------------------------------
Here is a different argument:
dbaron argues in comment 9 of Bug 153080, that needing to know such information
so as to undue the scale/zoom in order to calculate an inherited font in
problematic. Creates a maintanence problem and that information should be have
to be know at that level.

Here are some thoughts on that:

It would be great if all font objects held a twips value that was not scaled.
Then we could make an assumption in the code that all sizes are what they ought
to be (pre-scaled) and all calculations could ignore or not worry about any
scaling/zoom.

Then before reflow we could take a pass back thru all the font objects and scale
their sizes. I am not sure if anything would happen that would make us have to
go back and thru nsRuleNode where we would need these sizes to be the original.

But I am not when or where to make this happen.

Comment 1

[rods (gone)]

My concern about this bug which may be considered to be the "real" solution for
Bug 153080, is that it effects too much of layout and style. That it would take
a long time to implement, and add a lot of risk.

If we could easily identify a solution and fix I would be for that over my patch
in 153080. Otherwise we should go with my patch in 153080 as interim solution.

Note: 153080 is and ADT1, nsbeta1+ bug because PP and printing has "ShrinkToFit"
as the default and any page with any CSS fonts on it will not scale correctly.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase showing fonts and borders with different units

This is a good testcase to use -- it shows what happens to different units when
zooming in and out.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch that allows testing of canonical pixel scale zooming (not for checkin)

This patch turns text zoom into canonical-pixel-scale zooming, and is useful
for examining the affects of the canonical pixel scale.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Using Ctrl-+ and Ctrl-- on attachment 98199 [details] with the patch in attachment 98200 [details] [diff] [review]
in my tree, I see that the only units that the canonical pixel scale applies to
are pixel units.  (This is different from my past memory of experimenting on bug
4821 -- attachment 60121 [details] [diff] [review] there, which should have the same affects as attachment
98199 [details], did a lot more at the time.)

Is that what the canonical pixel scale is supposed to do?  (It makes sense.)  If
so, then using it for scaling doesn't seem like the right thing to do.

Comment 5

[rods (gone)]

In a nutshell, the layout system was not designed to do (reflow) scaling of any
kind and the CanonicalPixelScale is really the ratio between two devices (like
from the screen to the printer) so in Printing and PP we actually "co-op" the
value and apply our scaling factor to it. This works fine except for the single
case where Point-based fonts are created without the Printing Scale already
applied to it.

Upon looking at all the usages of GetCanonicalPixel:
http://lxr.mozilla.org/mozilla/search?string=GetCanonicalPixelScale
(ignore most of the GFX and PrintEngine usages)

It looks like we could easily change these few calls, except the PresContext's
GetScaledTwipsToPixel/PixelToTwips uses the CanonicalPixelScale and it is used
in many, many places in the code (see paragraph #1).

So the real problem to be solved centers around the fonts and when they get
scaled. I don't think can just not scale any of the fonts and then scal;e them
one time before reflow. This won't work because there my be style reflows that
end up going into the RuleNode code and then the font problems would still exist.


I think the solution is for the Font objects to remember their original values
(pre-scaled) and then also have their current size. Then if those sizes are
different we know they are already scaled, if the same, then they are not.

This way in the RuleNode code, we don't have to keep track of how a font was
created, we just simply ask the font to scale itself if it isn't already scaled.

Then we never need to "unscale" a font, we can just use its original cached
value. The cost is an additional nscoord value in each font object.

Comment 6

[rods (gone)]

Attachment: crude patch for start of work

In this patch I have renamed GetCanonicalPixelScale to GetDeviceRatio, which
represents the ration between 2 devices.

I also added a new field in to nsFont.h "origScale" which represents it's
original unscale twips value.

I also Added a SetPrintScale to nsIDeviceContext and a help to nsIPresContext
and print/PP doesn't change the DeviceRatio  it sets the PrintScale and from
there everything is suppose to work OK (which it does not)

But before I do anymore work on this I want to know that the approach I am
taking seems correct.

Comment 7

[RNicoletto]

Test case is WFM ==> http://yfrog.com/1g167162viewp

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3