From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ralf Angeli Newsgroups: gmane.emacs.devel Subject: Re: display-mm-width return value off on Windows Date: Sun, 20 Aug 2006 10:19:34 +0200 Message-ID: <87y7tj4y5l.fsf@neutrino.caeruleus.net> References: <44E73CD6.80207@gnu.org> <874pw86284.fsf@neutrino.caeruleus.net> <44E79204.9030505@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1156062042 24795 80.91.229.2 (20 Aug 2006 08:20:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2006 08:20:42 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 10:20:40 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 1GEiXu-0001fp-Kz for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2006 10:20:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GEiXt-0006Yl-DN for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2006 04:20:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GEiX1-0006Il-Lt for emacs-devel@gnu.org; Sun, 20 Aug 2006 04:19:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GEiWz-0006Hf-BO for emacs-devel@gnu.org; Sun, 20 Aug 2006 04:19:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GEiWz-0006HQ-59 for emacs-devel@gnu.org; Sun, 20 Aug 2006 04:19:41 -0400 Original-Received: from [212.227.126.183] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GEie4-0001qF-Al; Sun, 20 Aug 2006 04:27:00 -0400 Original-Received: from [84.165.62.232] (helo=neutrino.caeruleus.net) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GEiWv0hTo-00032b; Sun, 20 Aug 2006 10:19:37 +0200 Original-To: Jason Rumney In-Reply-To: <44E79204.9030505@gnu.org> (Jason Rumney's message of "Sat, 19 Aug 2006 23:34:44 +0100") X-Provags-ID: kundenserver.de abuse@kundenserver.de login:abf9ffac21f8345504ac40c53d3b40ba 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:58540 Archived-At: * 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: ,----[ ] | 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" () 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 >> . > 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 >> . >> > 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