Ralf Angeli wrote:
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. Lennart Borgman posted
a link to a mail from Microsoft where they advised against using
LOGPIXELSZ in calculations involving physical sizes on screen.
* Jason Rumney (2006-08-19) writes:
Ralf Angeli wrote:
I provided a patch for w32fns.c the majority of developers were in
Okay, it's been two weeks and nobody has reacted to the last message.
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 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:
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
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
The patch does not seem to be there. But it can be found at this link:
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
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
to this message. I provided that patch (again) together with the
patch for w32fns.c in