From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: display-mm-width return value off on Windows Date: Sat, 19 Aug 2006 23:34:44 +0100 Message-ID: <44E79204.9030505@gnu.org> References: <44E73CD6.80207@gnu.org> <874pw86284.fsf@neutrino.caeruleus.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0283023453==" X-Trace: sea.gmane.org 1156026934 25529 80.91.229.2 (19 Aug 2006 22:35:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 19 Aug 2006 22:35:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 00:35:33 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GEZPg-0003fk-0i for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2006 00:35:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GEZPf-0007aK-Ct for ged-emacs-devel@m.gmane.org; Sat, 19 Aug 2006 18:35:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GEZPS-0007Za-4A for emacs-devel@gnu.org; Sat, 19 Aug 2006 18:35:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GEZPP-0007ZO-Kw for emacs-devel@gnu.org; Sat, 19 Aug 2006 18:35:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GEZPP-0007ZL-ER for emacs-devel@gnu.org; Sat, 19 Aug 2006 18:35:15 -0400 Original-Received: from [213.86.207.50] (helo=exchange.integrasp.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GEZWQ-0000RI-SF for emacs-devel@gnu.org; Sat, 19 Aug 2006 18:42:31 -0400 Original-Received: from [10.0.0.32] (localhost [127.0.0.1]) by exchange.integrasp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NMA8FLHL; Sat, 19 Aug 2006 23:26:16 +0100 Original-Received: from 83.67.23.108 ([83.67.23.108] helo=[10.0.0.32]) by ASSP-nospam; 19 Aug 2006 23:26:14 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 Original-To: Ralf Angeli In-Reply-To: <874pw86284.fsf@neutrino.caeruleus.net> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58528 Archived-At: This is a multi-part message in MIME format. --===============0283023453== Content-Type: multipart/alternative; boundary="------------040606060400020902090907" This is a multi-part message in MIME format. --------------040606060400020902090907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ralf Angeli wrote: > * Jason Rumney (2006-08-19) writes: > > >> Ralf Angeli wrote: >> >>>> I provided a patch for w32fns.c the majority of developers were in >>>> favor of >>>> >>> 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 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. > 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. > 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? > 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 > . The patch does not seem to be there. But it can be found at this link: http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00755.html > Nobody replied > to this message. I provided that patch (again) together with the > patch for w32fns.c 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 results. --------------040606060400020902090907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ralf Angeli wrote: 
* Jason Rumney (2006-08-19) writes:

  
Ralf Angeli wrote:
    
I provided a patch for w32fns.c the majority of developers were in
favor of
        
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 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.


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.

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?

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/e9drj1$bk9$1@sea.gmane.org>.
The patch does not seem to be there. But it can be found at this link:

http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00755.html

  Nobody replied
to this message.  I provided that patch (again) together with the
patch for w32fns.c in
<URL:http://mid.gmane.org/eb2b77$3ih$2@sea.gmane.org>.
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.


--------------040606060400020902090907-- --===============0283023453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============0283023453==--