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.

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.

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

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

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.

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.

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.

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