Re: display-mm-width return value off on Windows

[Ralf Angeli]

* Jason Rumney (2006-08-20) writes:

> Ralf Angeli wrote:
>> * Jason Rumney (2006-08-19) writes:
>>   
>>> I didn't react the first time because I don't think your statement above 
>>> was true, but it is pointless continuing the argument.
>>
>> Then we have a different perception of the reactions.
>>   
> I have re-read the thread, and do not see where you could have got the 
> impression that the majority of developers were in favour of your patch. 
> Eli expressed concern that the results were still not correct in the two 
> test cases you provided. I suggested that if reordering the operations 
> to preserve precision made the results correct, then it might be a good 
> fix, otherwise I agree with Eli.

I interpreted this message of yours more positively.  In addition
there was an explicitely positive message from Kim.  Whatever, I guess
you are right and I take back that statement.

> Lennart Borgman posted a link to a mail 
> from Microsoft where they advised against using LOGPIXELSZ in 
> calculations involving physical sizes on screen.
>
>> I guess, I was the only one who actually checked the results of
>> `display-mm-width' and `display-mm-height' with the final patch
>> applied.  Here they are again for reference:
>>
>>                    display-mm-*   display-mm-*
>>         Real size  without patch  with patch
>> Width   285mm      370            296
>> Height  215mm      277            222
>>   
>
> The other test case you posted at the time started with both width and 
> height being overestimated by about 20%, and ended with the height 
> overestimated by 10% and the width underestimated slightly. I would not 
> call this an improvement, as the aspect ratio gets messed up with the 
> new code.

The other test case was with the old version of the patch, before
calculation was reordered.  That means those numbers do not reflect
the current version of the patch.

>> I'd say this is a vast improvement.  Until now nobody showed any
>> evidence that the patch leads to more inaccurate results on other
>> machines compared to the current code.
>
> Is the mail from someone at Microsoft that Lennart found, and the 
> documentation about Logical vs Physical dimensions on MSDN not evidence 
> enough?

The message you are probably referring to contains this:

,----[ <news:address@hidden> ]
| The problem you have encountered is the fact that the Logical metrics from
| GetDevCaps often do not agree with the size or resolution metrics returned
| from GetDevCaps when it is called on Windows NT.
| 
| The numbers returned from GetDeviceCaps() for HORZRES, HORZSIZE,  VERTRES,
| VERTSIZE, LOGPIXELSX, and LOGPIXELSY are defined by the  driver. It is
| common for NT drivers to return values that are not mathematically
| consistent (you can't calculate logpixelsx from horzres and horzsize), but  
| that isn't a bug, it is by design. The easy workaround is to use  HORZRES,
| HORZSIZE, VERTRES, and VERTSIZE (rather than LOGPIXELSX and LOGPIXELSY) in
| all calculations related to the metafile. This  will provide consistent
| results on both Win9x and NT.  
| 
| Q145999 How to Create & Play Enhanced Metafiles in Win32
| http://support.microsoft.com/support/kb/articles/q145/9/99.asp
| 
| Contains sample code that creates metafiles that are dimensionally
| consistent.
`----

So he wrote that the *RES and *SIZE values don't fit together with the
LOGPIXELS* values.  But he also wrote that _all_ of these values are
defined by the driver.  That means no matter which type of calculation
we are using, we are at the mercy of the device driver.  In my case
the device driver returns much better results with the LOGPIXELS*
method.

At the same time you will find a lot of reports on the Internet about
*SIZE returning incorrect values.  Eli, however, showed that the *SIZE
method returns accurate values for him.  What I'd be interested in
would be if the values get less accurate withthe LOGPIXELS* method.
The only problem I am seeing with LOGPIXELS* is the potential
difference between logical and real inches.

While digging a bit in the Microsoft site I found the howto "How to
Make an Application Display Real Units of Measurement"
(<URL:http://support.microsoft.com/default.aspx?scid=kb;EN-US;q127152>)
which emphasizes the fact that it's impossible to reliably calculate
real dimensions of a screen.  The article mentions the problems with
LOGPIXELS* returning logical inches and it doesn't even mention *SIZE.
Instead, it suggests to let the user specify explicitely the physical
size of the screen.

Given that both ways of calculating the screen size are unreliable I
am still interested in data allowing to judge which method returns
more accurate results in the majority of cases.

>> No, I haven't given up on that.  I modified the patch for frame.el for
>> it to be able to cope with multiple displays and provided it in
>> <URL:http://mid.gmane.org/address@hidden>.
> The patch does not seem to be there.

Hm, seems to be a Gmane bug.

> But it can be found at this link:
>
> http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00755.html

Thanks for sorting this out.

>>   Nobody replied
>> to this message.  I provided that patch (again) together with the
>> patch for w32fns.c in
>> <URL:http://mid.gmane.org/address@hidden>.
>>   
> I think they should be kept separate. If the patch to frame.el is 
> applied, then there is no need to alter the defaults, as the user can 
> customize them if the defaults are wrong, which they will need to do 
> anyway, since the patch to w32fns.c is still not giving the correct results.

Agreed.

-- 
Ralf