Paul Vriens wrote:
James McKenzie wrote:
Lei Zhang wrote:
On Fri, Mar 13, 2009 at 12:01 PM, Paul Vriens
<paul.vriens.w...@gmail.com> wrote:
Lei Zhang wrote:
Hi,

In my last attempt, I submitted Troy Rollo's EM_FORMATRANGE
implementation and with my test cases. I'm not sure what was wrong
with the implementation, but the test cases should be ok.


------------------------------------------------------------------------


Hi Lei,

Pretty old patch. (June 2007)

I just moved some of my VMware 'boxes' to my new laptop (laptop resolution 1024x800) and I suddenly had some failures. The resolution that VMware can use (with all those borders and the sidebar) is 1044x574. Running the tests
fullscreen makes them pass again.

You can replicate this by playing with the screen resolution. The smaller
the resolution the more test failures.

Any idea where I need to look?

--
Cheers,

Paul.

Is this on Windows in VMWare? I'm not getting any riched20 crosstest
failures here at 800x600.



Interesting that this should fail on a VMWare workstation setup.  The
tests are pretty straightfoward.

Also, I have not worked on this due to other pressures of life.  Would
someone like to take this over and finish it?  This would solve a couple
of open bug reports and fix some complaints about text rendering.

James McKenzie



As said before, this issue can be seen on both VMware and real boxes. It's much easier of course to play around with resolutions on VMware.

I'm currently trying loads of different resolutions to see if there is some logic. I do see that when I'm reducing just the horizontal resolution for example that the result of the EM_FORMATRANGE message changes at certain intervals (no logic found yet though).

The number that keeps coming back is '15' :

Hor    Vert    EM_FORMATRANGE

1040    800    20
937    800    16
832    800    15
712    800    14
652    800    13
547    800    12
517    800    9
412    800    7
382    800    6

The difference between the horizontal resolution when the results change is always a multiple of 15 (can't check the first one as 20 is the maximum returned).

The same behavior can be seen with a vertical resolution of 600:

Hor    Vert    EM_FORMATRANGE

1238    600    20
1222    600    18
1057    600    16
1012    600    15
937    600    9
547    600    7
517    600    6

And with a horizontal resolution of 979 (yeah I know):

Hor    Vert    EM_FORMATRANGE

979    724    20
979    712    15
979    472    7

So any idea about that number '15'? Maybe once I've figured out where that comes from the logic makes more sense.

The magic number '15' is 1440/96(dpi). And sure enough the magic number changes to '12' on 120dpi.

If I read MSDN correctly (http://msdn.microsoft.com/en-us/library/bb787911(VS.85).aspx) the rc and rcPage area should be in twips not pixels.

If I change the code to do exactly that (multiply by 1440/dpi) the tests succeed on all resolutions I've checked.

Another thing I found but I'm not sure it's relevant here is that fr.rc.bottom is changed after a EM_FORMATRANGE message.

--
Cheers,

Paul.


Reply via email to