Re: riched20: add tests for EM_FORMATRANGE

[Paul Vriens]

Paul Vriens wrote:
> James McKenzie wrote:
> > Lei Zhang wrote:
> > > On Fri, Mar 13, 2009 at 12:01 PM, Paul Vriens
> > >  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.