display-mm-width return value off on Windows

display-mm-width return value off on Windows

[Ralf Angeli]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Windows the return values of `display-mm-width' and
`display-mm-height' don't really reflect the screen width and height
in millimeters.  I attached a patch which yields more realistic
results.

In my case:

                   display-mm-*   display-mm-*
        Real size  without patch  with patch
Width   285mm      370            279
Height  215mm      277            203

For a preview-latex user who originally reported the problem:

                   display-mm-*   display-mm-*
        Real size  without patch  with patch
Width   330mm      320            305
Height  207mm      240            203

The original report described that images generated by preview-latex
(which uses `display-mm-{width,height}' for that matter) are distorted
horizontally (see bug report at
<URL:http://permalink.gmane.org/gmane.emacs.auctex.bugs/673>).  In my
case these images were too small compared to the font size (see bug
report with screenshot at
<URL:http://permalink.gmane.org/gmane.emacs.auctex.bugs/449>).  With
the patch applied both of these problems get better.

-- 
Ralf

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1257 bytes --]

Index: w32fns.c
===================================================================
RCS file: /sources/emacs/emacs/src/w32fns.c,v
retrieving revision 1.271
diff -c -r1.271 w32fns.c
--- w32fns.c	30 Jun 2006 13:40:21 -0000	1.271
+++ w32fns.c	6 Jul 2006 17:47:53 -0000
@@ -6502,15 +6502,16 @@
 {
   struct w32_display_info *dpyinfo = check_x_display_info (display);
   HDC hdc;
-  int cap;
+  int height;
 
   hdc = GetDC (dpyinfo->root_window);
 
-  cap = GetDeviceCaps (hdc, VERTSIZE);
+  height = round (GetDeviceCaps (hdc, VERTRES)
+		  / GetDeviceCaps (hdc, LOGPIXELSY) * 25.4);
 
   ReleaseDC (dpyinfo->root_window, hdc);
 
-  return make_number (cap);
+  return make_number (height);
 }
 
 DEFUN ("x-display-mm-width", Fx_display_mm_width, Sx_display_mm_width, 0, 1, 0,
@@ -6524,15 +6525,16 @@
   struct w32_display_info *dpyinfo = check_x_display_info (display);
 
   HDC hdc;
-  int cap;
+  int width;
 
   hdc = GetDC (dpyinfo->root_window);
 
-  cap = GetDeviceCaps (hdc, HORZSIZE);
+  width = round (GetDeviceCaps (hdc, HORZRES)
+		 / GetDeviceCaps (hdc, LOGPIXELSX) * 25.4);
 
   ReleaseDC (dpyinfo->root_window, hdc);
 
-  return make_number (cap);
+  return make_number (width);
 }
 
 DEFUN ("x-display-backing-store", Fx_display_backing_store,

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Thu, 06 Jul 2006 19:50:26 +0200
> 
> On Windows the return values of `display-mm-width' and
> `display-mm-height' don't really reflect the screen width and height
> in millimeters.  I attached a patch which yields more realistic
> results.

Thanks.

> In my case:
> 
>                    display-mm-*   display-mm-*
>         Real size  without patch  with patch
> Width   285mm      370            279
> Height  215mm      277            203
> 
> For a preview-latex user who originally reported the problem:
> 
>                    display-mm-*   display-mm-*
>         Real size  without patch  with patch
> Width   330mm      320            305
> Height  207mm      240            203

That is still not a very good approximation, is it?

> -  cap = GetDeviceCaps (hdc, VERTSIZE);
> +  height = round (GetDeviceCaps (hdc, VERTRES)
> +		  / GetDeviceCaps (hdc, LOGPIXELSY) * 25.4);

What is this magic constant 25.4?  I think we at least should use a
single macro instead of having the literal constant scattered across
the sources.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> Date: Thu, 06 Jul 2006 19:50:26 +0200
>> 
>> On Windows the return values of `display-mm-width' and
>> `display-mm-height' don't really reflect the screen width and height
>> in millimeters.  I attached a patch which yields more realistic
>> results.
>
> Thanks.
>
>> In my case:
>> 
>>                    display-mm-*   display-mm-*
>>         Real size  without patch  with patch
>> Width   285mm      370            279
>> Height  215mm      277            203
>> 
>> For a preview-latex user who originally reported the problem:
>> 
>>                    display-mm-*   display-mm-*
>>         Real size  without patch  with patch
>> Width   330mm      320            305
>> Height  207mm      240            203
>
> That is still not a very good approximation, is it?
>
>> -  cap = GetDeviceCaps (hdc, VERTSIZE);
>> +  height = round (GetDeviceCaps (hdc, VERTRES)
>> +		  / GetDeviceCaps (hdc, LOGPIXELSY) * 25.4);
>
> What is this magic constant 25.4?  I think we at least should use a
> single macro instead of having the literal constant scattered across
> the sources.

Millimeters per inch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Ralf Angeli]

* Eli Zaretskii (2006-07-06) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> 
>>                    display-mm-*   display-mm-*
>>         Real size  without patch  with patch
>> Width   330mm      320            305
>> Height  207mm      240            203
>
> That is still not a very good approximation, is it?

The values are more accurate than before.  With the change Jason
suggested they might improve even more.  If I find time I'll ask the
user who originally reported the problem to check a version of Emacs
with the change applied.

>> -  cap = GetDeviceCaps (hdc, VERTSIZE);
>> +  height = round (GetDeviceCaps (hdc, VERTRES)
>> +		  / GetDeviceCaps (hdc, LOGPIXELSY) * 25.4);
>
> What is this magic constant 25.4?

As David wrote: millimeters per inch

-- 
Ralf

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Fri, 07 Jul 2006 07:56:31 +0200
> 
> * Eli Zaretskii (2006-07-06) writes:
> 
> >> From: Ralf Angeli <angeli@caeruleus.net>
> >> 
> >>                    display-mm-*   display-mm-*
> >>         Real size  without patch  with patch
> >> Width   330mm      320            305
> >> Height  207mm      240            203
> >
> > That is still not a very good approximation, is it?
> 
> The values are more accurate than before.

Not enough, if you ask me.

Do you have some unusual settings for the display?  Maybe that is the
reason why you get skewed numbers; as you see from my other mail, on
my system I get very good results with the current code.

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Fri, 07 Jul 2006 07:56:31 +0200
> 
> * Eli Zaretskii (2006-07-06) writes:
> 
> >> From: Ralf Angeli <angeli@caeruleus.net>
> >> 
> >>                    display-mm-*   display-mm-*
> >>         Real size  without patch  with patch
> >> Width   330mm      320            305
> >> Height  207mm      240            203
> >
> > That is still not a very good approximation, is it?
> 
> The values are more accurate than before.

Not enough, if you ask me.

Do you have some unusual settings for the display, or maybe an unusual
display configuration (like more than a single monitor)?  Maybe that
is the reason why you get skewed numbers; as you see from my other
mail, on my system I get very good results with the current code.

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

[Lennart Borgman]

Eli Zaretskii wrote:
>> From: Ralf Angeli <angeli@caeruleus.net>
>> Date: Fri, 07 Jul 2006 07:56:31 +0200
>>
>> * Eli Zaretskii (2006-07-06) writes:
>>
>>     
>>>> From: Ralf Angeli <angeli@caeruleus.net>
>>>>
>>>>                    display-mm-*   display-mm-*
>>>>         Real size  without patch  with patch
>>>> Width   330mm      320            305
>>>> Height  207mm      240            203
>>>>         
>>> That is still not a very good approximation, is it?
>>>       
>> The values are more accurate than before.
>>     
>
> Not enough, if you ask me.
>
> Do you have some unusual settings for the display, or maybe an unusual
> display configuration (like more than a single monitor)?  Maybe that
> is the reason why you get skewed numbers; as you see from my other
> mail, on my system I get very good results with the current code.
>   
I did some googling. I believe the answer here is interesting:

    
http://groups.google.com/groups/search?q=getdevicecaps+%22inches%2C+milimeters%22

James (who seems to be from MS) says that the device driver may return 
faulty results. So why not stay with the simple supported way (ie 
HORZSIZE etc)?

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

[Ralf Angeli]

* Eli Zaretskii (2006-07-07) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> Date: Fri, 07 Jul 2006 07:56:31 +0200
>> 
>> * Eli Zaretskii (2006-07-06) writes:
>> 
>> >> From: Ralf Angeli <angeli@caeruleus.net>
>> >> 
>> >>                    display-mm-*   display-mm-*
>> >>         Real size  without patch  with patch
>> >> Width   330mm      320            305
>> >> Height  207mm      240            203
>> >
>> > That is still not a very good approximation, is it?
>> 
>> The values are more accurate than before.
>
> Not enough, if you ask me.

After moving the multiplication with 25.4 to the front it got better.

Anyway, I am quite surprised that the values returned by the current
code in CVS are so accurate in your case.  Have you tried if the
values are comparably accurate with your setup with the patch applied?

> Do you have some unusual settings for the display, or maybe an unusual
> display configuration (like more than a single monitor)?  Maybe that
> is the reason why you get skewed numbers; as you see from my other
> mail, on my system I get very good results with the current code.

I don't have any special settings.  This is a 14 inch LCD panel on a
notebook with a resolution of 1400x1050 pixels I am working on.  The
user who reported the issue on the AUCTeX list wrote that he is using
a display device with 1680x1050 which might be an LCD panel on a
notebook as well.  Maybe that is the problem.

-- 
Ralf

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Jul 2006 18:54:11 +0200
> 
> I don't have any special settings.  This is a 14 inch LCD panel on a
> notebook with a resolution of 1400x1050 pixels I am working on.  The
> user who reported the issue on the AUCTeX list wrote that he is using
> a display device with 1680x1050 which might be an LCD panel on a
> notebook as well.  Maybe that is the problem.

Yes, perhaps LCD displays are the reason.  Can people please try and
report the results?

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

[Lennart Borgman]

Eli Zaretskii wrote:
>> From: Ralf Angeli <angeli@caeruleus.net>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 07 Jul 2006 18:54:11 +0200
>>
>> I don't have any special settings.  This is a 14 inch LCD panel on a
>> notebook with a resolution of 1400x1050 pixels I am working on.  The
>> user who reported the issue on the AUCTeX list wrote that he is using
>> a display device with 1680x1050 which might be an LCD panel on a
>> notebook as well.  Maybe that is the problem.
>>     
>
> Yes, perhaps LCD displays are the reason.  Can people please try and
> report the results?
>   
Is there any reason to believe the result should be correct? As I 
pointed out in a previous message the information does not seem to be 
available to the display driver.

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

[Eli Zaretskii]

> Date: Sat, 08 Jul 2006 15:23:45 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Ralf Angeli <angeli@caeruleus.net>,  emacs-devel@gnu.org
> 
> Is there any reason to believe the result should be correct? As I 
> pointed out in a previous message the information does not seem to be 
> available to the display driver.

It's quite clear that Windows does know something about the display
dimensions, otherwise they wouldn't be giving us this API.

And the result is quite close to the truth on my system.  Are they
wrong on yours?

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

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Is there any reason to believe the result should be correct? As I
> pointed out in a previous message the information does not seem to be
> available to the display driver.

Built in LCDs in notebooks and LCD panels connected via digital
connectors are able to report details about the monitor back to the
video drivers/OS, though I am not sure whether manufacturers always
report accurate information, or whether Windows uses the information.

Monitors connected via analog connectors are not able to report this
information, and Windows seems to always guess 320 as the width, and
the height is reported as consistent with the width:height ratio
assuming square pixels.

I have tried the following:

1024x768 built in 15.1" notebook LCD reports 320x240
1440x900 built in 14.1" widescreen notebook LCD reports 320x200
1280x1024 analog connected 19" monitor reports 320x256

But using LOGPIXELSX/LOGPIXELSY is not going to be any more accurate
than what monitors report, or Windows makes up, since it is based on a
dpi setting that is user configurable, defaulting to 96dpi, and AFAIK
for screen devices square pixels are assumed (LOGPIXELSX==LOGPIXELSY),
so if your monitor has non-square pixels and reports a size to the
OS, then that size (or the aspect ratio associated with it) is more
likely to be accurate than a calculation involving LOGPIXELSX/LOGPIXELSY.

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

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>> Is there any reason to believe the result should be correct? As I
>> pointed out in a previous message the information does not seem to be
>> available to the display driver.
>
> Built in LCDs in notebooks and LCD panels connected via digital
> connectors are able to report details about the monitor back to the
> video drivers/OS, though I am not sure whether manufacturers always
> report accurate information, or whether Windows uses the information.
>
> Monitors connected via analog connectors are not able to report this
> information,

I thought that's what the DDC protocols are for, that are supported by
"Plug&Play" monitors.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jason Rumney]

David Kastrup <dak@gnu.org> writes:

> I thought that's what the DDC protocols are for, that are supported by
> "Plug&Play" monitors.

You're right, DDC is supported for analog monitors also. So I wonder
why 320mm was reported as the width for all 3 of my monitors. It is
about right for the 15.1" and 14.1" widescreen, but the 19" should be
closer to 400mm.

In case anyone wants to investigate why the numbers are off (is
Windows using what the monitor reports?), there's a program to read
the data from the monitor independantly of the OS/video drivers here:

http://john.fremlin.de/programs/linux/read-edid/

It fails on my laptop with the 15.1" display when run from Windows XP,
however.

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

[Ralf Angeli]

* Jason Rumney (2006-07-09) writes:

> You're right, DDC is supported for analog monitors also. So I wonder
> why 320mm was reported as the width for all 3 of my monitors. It is
> about right for the 15.1" and 14.1" widescreen, but the 19" should be
> closer to 400mm.

I guess we won't find out on a non-free system where we cannot look at
the code.

> In case anyone wants to investigate why the numbers are off (is
> Windows using what the monitor reports?), there's a program to read
> the data from the monitor independantly of the OS/video drivers here:
>
> http://john.fremlin.de/programs/linux/read-edid/
>
> It fails on my laptop with the 15.1" display when run from Windows XP,
> however.

I didn't install read-edid, but xdpyinfo run on GNU/Linux reports
wrong values for my notebook: 474x356mm  That's why I normally set the
correct value in xorg.conf with the DisplaySize directive.

-- 
Ralf

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

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Jason Rumney (2006-07-09) writes:
>
>> You're right, DDC is supported for analog monitors also. So I wonder
>> why 320mm was reported as the width for all 3 of my monitors. It is
>> about right for the 15.1" and 14.1" widescreen, but the 19" should be
>> closer to 400mm.
>
> I guess we won't find out on a non-free system where we cannot look
> at the code.

Well, the log files for the X server here at least tell the story
about what has been detected.  Maybe there is some record like that
available for Windows Systems too, somewhere?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Ralf Angeli]

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

> But using LOGPIXELSX/LOGPIXELSY is not going to be any more accurate
> than what monitors report, or Windows makes up, since it is based on a
> dpi setting that is user configurable, defaulting to 96dpi,

If `GetDeviceCaps (hdc, HORSIZE)' always assumes a fixed DPI value
that would explain why the values are so inaccurate especially on
displays with a high DPI value.  In that case I think it makes sense
to use the DPI value when calculating the size (as my patch does) and
assume that the user set it to a value matching her monitor.

As a last resort we could provide user options (in Emacs) for setting
the correct size of the screen which will be used as return values for
`display-mm-{width,height}'.

-- 
Ralf

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

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Jason Rumney (2006-07-08) writes:
>
>> But using LOGPIXELSX/LOGPIXELSY is not going to be any more
>> accurate than what monitors report, or Windows makes up, since it
>> is based on a dpi setting that is user configurable, defaulting to
>> 96dpi,
>
> If `GetDeviceCaps (hdc, HORSIZE)' always assumes a fixed DPI value
> that would explain why the values are so inaccurate especially on
> displays with a high DPI value.  In that case I think it makes sense
> to use the DPI value when calculating the size (as my patch does)
> and assume that the user set it to a value matching her monitor.

The reason this makes sense is that this is how the font size is
determined (the ratio between pixels and point size of a font), and if
one wants to match the dimensions of graphics to a font, one should
use the same algorithm.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>,  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 09 Jul 2006 09:41:53 +0200
> 
> If `GetDeviceCaps (hdc, HORSIZE)' always assumes a fixed DPI value
> that would explain why the values are so inaccurate especially on
> displays with a high DPI value.  In that case I think it makes sense
> to use the DPI value when calculating the size (as my patch does) and
> assume that the user set it to a value matching her monitor.
> 
> As a last resort we could provide user options (in Emacs) for setting
> the correct size of the screen which will be used as return values for
> `display-mm-{width,height}'.

Sounds like a good plan to me.

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

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>,  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Sun, 09 Jul 2006 09:41:53 +0200
>> 
>> If `GetDeviceCaps (hdc, HORSIZE)' always assumes a fixed DPI value
>> that would explain why the values are so inaccurate especially on
>> displays with a high DPI value.  In that case I think it makes sense
>> to use the DPI value when calculating the size (as my patch does) and
>> assume that the user set it to a value matching her monitor.
>> 
>> As a last resort we could provide user options (in Emacs) for setting
>> the correct size of the screen which will be used as return values for
>> `display-mm-{width,height}'.
>
> Sounds like a good plan to me.

I have had problems on X too (where the drivers provide wrong DPI
values), so the following piece of code in xdisp.c fails to DTRT:

#ifdef HAVE_WINDOW_SYSTEM
	      if (FRAME_WINDOW_P (it->f)
		  && (ppi = (width_p
			     ? FRAME_X_DISPLAY_INFO (it->f)->resx
			     : FRAME_X_DISPLAY_INFO (it->f)->resy),
		      ppi > 0))
		return OK_PIXELS (ppi / pixels);
#endif


So I tried to do fix that (in a way similar to the one proposed for
display-mm-*) some time ago, but didn't complete it, as it wasn't
really clear what had to be done.

First of all, it had to be done per-display (at least X supports
multiple display),

Secondly, it was not clear to me whether this problem was specific
to X, but I guessed it was not, so changes had to be done for
all platforms (as it involved added stuff to "display-info".)

Last, but not least, it was unclear what other parts of the code
would also need changes -- e.g. display-mm-* -- which would have
to be reworked to not just use some X-macro like WidthMMOfScreen.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> So I tried to do fix that (in a way similar to the one proposed for
> display-mm-*) some time ago, but didn't complete it, as it wasn't
> really clear what had to be done.
>
> First of all, it had to be done per-display (at least X supports
> multiple display),
>
> Secondly, it was not clear to me whether this problem was specific
> to X, but I guessed it was not, so changes had to be done for
> all platforms (as it involved added stuff to "display-info".)
>
> Last, but not least, it was unclear what other parts of the code
> would also need changes -- e.g. display-mm-* -- which would have
> to be reworked to not just use some X-macro like WidthMMOfScreen.

Whatever solution is chosen in the end: it is important that the same
algorithm is used for converting point size of fonts into pixel size
and vice versa.

preview-latex needs to guess how many pixels a given font will occupy
on the screen in order to create graphics matching in size.  And the
font sizes are returned in points, namely physical dimensions.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jason Rumney]

David Kastrup wrote:
> storm@cua.dk (Kim F. Storm) writes:
>
>   
>> So I tried to do fix that (in a way similar to the one proposed for
>> display-mm-*) some time ago, but didn't complete it, as it wasn't
>> really clear what had to be done.
>>
>> First of all, it had to be done per-display (at least X supports
>> multiple display),
>>
>> Secondly, it was not clear to me whether this problem was specific
>> to X, but I guessed it was not, so changes had to be done for
>> all platforms (as it involved added stuff to "display-info".)
>>
>> Last, but not least, it was unclear what other parts of the code
>> would also need changes -- e.g. display-mm-* -- which would have
>> to be reworked to not just use some X-macro like WidthMMOfScreen.
>>     
>
> Whatever solution is chosen in the end: it is important that the same
> algorithm is used for converting point size of fonts into pixel size
> and vice versa.
>
> preview-latex needs to guess how many pixels a given font will occupy
> on the screen in order to create graphics matching in size.  And the
> font sizes are returned in points, namely physical dimensions
At least on Windows, point sizes for fonts are based on user 
configuration, not the actual physical size of the monitor.
So I don't think you should be using display-mm-* for calculating sizes 
you expect to be relative to fonts anyway.
Why not use the pixel size of the font? Surely that will be more 
accurate for the purpose you want.

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

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>>
>> Whatever solution is chosen in the end: it is important that the same
>> algorithm is used for converting point size of fonts into pixel size
>> and vice versa.
>>
>> preview-latex needs to guess how many pixels a given font will occupy
>> on the screen in order to create graphics matching in size.  And the
>> font sizes are returned in points, namely physical dimensions
> At least on Windows, point sizes for fonts are based on user
> configuration, not the actual physical size of the monitor.
> So I don't think you should be using display-mm-* for calculating
> sizes you expect to be relative to fonts anyway.
> Why not use the pixel size of the font? Surely that will be more
> accurate for the purpose you want.

It is not available.  We are talking about the design size of a font
here, not the line spacing (the latter could be deduced from frame
pixel height and stuff): the _design_ size of the default font needs
to get matched to the design size of the TeX constructs made into
bitmaps.

The only face-attribute we have available here is

`:height'
     Either the font height, an integer in units of 1/10 point, a
     floating point number specifying the amount by which to scale the
     height of any underlying face, or a function, which is called with
     the old height (from the underlying face), and should return the
     new height.

Of course, after resolving the font specification, an integer in units
of 1/10 point is the ultimate result.

And we need to recast this value into pixels, then let bitmaps be
generated that occupy _that_ number of pixels for the default design
size of the _TeX_ document.

When this is done, the design size of the default font of Emacs and of
the default font of the TeX document are _matched_, expressed in the
number of screen pixels.

And for that it is necessary that Emacs and/or Windows convert the
points to pixels in a predictable way, and the display geometry is the
only pointer we have for that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jason Rumney]

David Kastrup wrote:
> And for that it is necessary that Emacs and/or Windows convert the
> points to pixels in a predictable way, and the display geometry is the
> only pointer we have for that.
>   

 Windows does not use the display geometry to convert points to pixels 
when it displays fonts. It uses the display geometry to decide whether 
to default to 96dpi or 120dpi (where i is a "logical inch" in Microsoft 
terminology, not necessarily a physical inch), then uses the dpi setting 
(which can be further customized by the user) to do its conversion 
between points and pixels, while continuing to report the physical size 
of the monitor in the functions that manage that.

I guess display-pixels-per-inch should report the dpi setting from the 
OS. Currently it seems to be hardcoded as 72.0, and the user needs to 
manually change it to match reality. At least on Windows, it is possible 
to read the system settings to get a more accurate value, but even if 
this is not possible on other window systems, 96.0 might be a better 
default these days.

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

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> And for that it is necessary that Emacs and/or Windows convert the
>> points to pixels in a predictable way, and the display geometry is
>> the only pointer we have for that.
>>   
>
> Windows does not use the display geometry to convert points to
> pixels when it displays fonts. It uses the display geometry to
> decide whether to default to 96dpi or 120dpi (where i is a "logical
> inch" in Microsoft terminology, not necessarily a physical inch),
> then uses the dpi setting (which can be further customized by the
> user) to do its conversion between points and pixels, while
> continuing to report the physical size of the monitor in the
> functions that manage that.

What fun.

> I guess display-pixels-per-inch should report the dpi setting from
> the OS. Currently it seems to be hardcoded as 72.0, and the user
> needs to manually change it to match reality. At least on Windows,
> it is possible to read the system settings to get a more accurate
> value, but even if this is not possible on other window systems,
> 96.0 might be a better default these days.

Sigh.  At least on X11, we had no problems reported concerning the
size as far as I remember (except for XEmacs, but the place to rant
about that is elsewhere), and indeed, the usual X11 servers have a
consistent idea about the dpi, and Emacs seems to fetch and use it.
This need not match reality (depending on the monitor), but it seems
to apply everywhere, and thus leads to consistent results.  With
MacOSX, I am not quite sure.  I think we got rid of the worst trouble.

I really think that Windows at the moment is the worst offender.  If
we could get its idea of dpi consistent with its point/pixel
conversion, this would be quite beneficial.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> Cc: Ralf Angeli <angeli@caeruleus.net>,  lennart.borgman.073@student.lu.se,
> 	  emacs-devel@gnu.org,  jasonr@gnu.org
> From: storm@cua.dk (Kim F. Storm)
> Date: Mon, 10 Jul 2006 12:30:24 +0200
> 
> First of all, it had to be done per-display (at least X supports
> multiple display),

The API supports that: display-mm-width accepts an argument, the name
of a particular display.

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

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Ralf Angeli <angeli@caeruleus.net>,  lennart.borgman.073@student.lu.se,
>> 	  emacs-devel@gnu.org,  jasonr@gnu.org
>> From: storm@cua.dk (Kim F. Storm)
>> Date: Mon, 10 Jul 2006 12:30:24 +0200
>> 
>> First of all, it had to be done per-display (at least X supports
>> multiple display),
>
> The API supports that: display-mm-width accepts an argument, the name
> of a particular display.

That wasn't the problem I had in mind -- it was to find a consistent
way for the user to specify the resolution for a specific display.

E.g. something like

(x-set-display-resolution RESX RESY &optional DISPLAY)

will work, but that only works if DISPLAY uniquely identifies
a specific physical VDU.

I would rather have it be defined with defcustom.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Cc: Ralf Angeli <angeli@caeruleus.net>,  lennart.borgman.073@student.lu.se,
>>> 	  emacs-devel@gnu.org,  jasonr@gnu.org
>>> From: storm@cua.dk (Kim F. Storm)
>>> Date: Mon, 10 Jul 2006 12:30:24 +0200
>>> 
>>> First of all, it had to be done per-display (at least X supports
>>> multiple display),
>>
>> The API supports that: display-mm-width accepts an argument, the
>> name of a particular display.
>
> That wasn't the problem I had in mind -- it was to find a consistent
> way for the user to specify the resolution for a specific display.
>
> E.g. something like
>
> (x-set-display-resolution RESX RESY &optional DISPLAY)
>
> will work, but that only works if DISPLAY uniquely identifies
> a specific physical VDU.
>
> I would rather have it be defined with defcustom.

I think that's the wrong way.  One should rather tell the user how to
set this inside of his operating system instead of fudging around in
Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Ralf Angeli]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

* Eli Zaretskii (2006-07-09) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> 
>> If `GetDeviceCaps (hdc, HORSIZE)' always assumes a fixed DPI value
>> that would explain why the values are so inaccurate especially on
>> displays with a high DPI value.  In that case I think it makes sense
>> to use the DPI value when calculating the size (as my patch does) and
>> assume that the user set it to a value matching her monitor.
>> 
>> As a last resort we could provide user options (in Emacs) for setting
>> the correct size of the screen which will be used as return values for
>> `display-mm-{width,height}'.
>
> Sounds like a good plan to me.

Here are change log entries and patches to achieve that:

2006-07-11  Ralf Angeli  <angeli@caeruleus.net>

	* frame.el (display-mm-height): New variable.
	(display-mm-height): Use it.
	(display-mm-width): New variable.
	(display-mm-width): Use it.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: frame.el.patch --]
[-- Type: text/x-patch, Size: 1839 bytes --]

Index: frame.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/frame.el,v
retrieving revision 1.236
diff -u -r1.236 frame.el
--- frame.el	25 Mar 2006 07:40:18 -0000	1.236
+++ frame.el	11 Jul 2006 18:40:03 -0000
@@ -1081,17 +1081,35 @@
      (t
       (frame-width (if (framep display) display (selected-frame)))))))
 
+(defcustom display-mm-height nil
+  "Height of display in millimeters.
+If non-nil, used as return value for function `display-mm-height'."
+  :version "22.1"
+  :type 'integer
+  :group 'frames)
+
 (defun display-mm-height (&optional display)
   "Return the height of DISPLAY's screen in millimeters.
-If the information is unavailable, value is nil."
-  (and (memq (framep-on-display display) '(x w32 mac))
-       (x-display-mm-height display)))
+If the information is unavailable, value is nil.  Return value of
+variable `display-mm-height' if set."
+  (or display-mm-height
+      (and (memq (framep-on-display display) '(x w32 mac))
+	   (x-display-mm-height display))))
+
+(defcustom display-mm-width nil
+  "Width of display in millimeters.
+If non-nil, used as return value for function `display-mm-width'."
+  :version "22.1"
+  :type 'integer
+  :group 'frames)
 
 (defun display-mm-width (&optional display)
   "Return the width of DISPLAY's screen in millimeters.
-If the information is unavailable, value is nil."
-  (and (memq (framep-on-display display) '(x w32 mac))
-       (x-display-mm-width display)))
+If the information is unavailable, value is nil.  Return value of
+variable `display-mm-width' if set."
+  (or display-mm-width
+      (and (memq (framep-on-display display) '(x w32 mac))
+	   (x-display-mm-width display))))
 
 (defun display-backing-store (&optional display)
   "Return the backing store capability of DISPLAY's screen.

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]


2006-07-11  Ralf Angeli  <angeli@caeruleus.net>

	* w32fns.c (Fx_display_mm_height, Fx_display_mm_width): Calculate
	size of display by means of size in pixels and number of pixels
	per inch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: w32fns.c.patch --]
[-- Type: text/x-patch, Size: 1258 bytes --]

Index: w32fns.c
===================================================================
RCS file: /sources/emacs/emacs/src/w32fns.c,v
retrieving revision 1.271
diff -u -r1.271 w32fns.c
--- w32fns.c	30 Jun 2006 13:40:21 -0000	1.271
+++ w32fns.c	11 Jul 2006 18:38:37 -0000
@@ -6502,15 +6502,16 @@
 {
   struct w32_display_info *dpyinfo = check_x_display_info (display);
   HDC hdc;
-  int cap;
+  int height;
 
   hdc = GetDC (dpyinfo->root_window);
 
-  cap = GetDeviceCaps (hdc, VERTSIZE);
+  height = round (25.4 * GetDeviceCaps (hdc, VERTRES)
+		  / GetDeviceCaps (hdc, LOGPIXELSY));
 
   ReleaseDC (dpyinfo->root_window, hdc);
 
-  return make_number (cap);
+  return make_number (height);
 }
 
 DEFUN ("x-display-mm-width", Fx_display_mm_width, Sx_display_mm_width, 0, 1, 0,
@@ -6524,15 +6525,16 @@
   struct w32_display_info *dpyinfo = check_x_display_info (display);
 
   HDC hdc;
-  int cap;
+  int width;
 
   hdc = GetDC (dpyinfo->root_window);
 
-  cap = GetDeviceCaps (hdc, HORZSIZE);
+  width = round (25.4 * GetDeviceCaps (hdc, HORZRES)
+		 / GetDeviceCaps (hdc, LOGPIXELSX));
 
   ReleaseDC (dpyinfo->root_window, hdc);
 
-  return make_number (cap);
+  return make_number (width);
 }
 
 DEFUN ("x-display-backing-store", Fx_display_backing_store,

[-- Attachment #5: Type: text/plain, Size: 10 bytes --]


-- 
Ralf

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Kim F. Storm]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Eli Zaretskii (2006-07-09) writes:
>
>>> As a last resort we could provide user options (in Emacs) for setting
>>> the correct size of the screen which will be used as return values for
>>> `display-mm-{width,height}'.
>>
>> Sounds like a good plan to me.
>
> Here are change log entries and patches to achieve that:
>
> 2006-07-11  Ralf Angeli  <angeli@caeruleus.net>
>
> 	* frame.el (display-mm-height): New variable.
> 	(display-mm-height): Use it.
> 	(display-mm-width): New variable.
> 	(display-mm-width): Use it.

This change makes things worse if you have multiple displays.

As I said previously, a change would have to be able to 
specify values "per-display", e.g. using an alist with
elements (display . (width height))

But it still doesn't fix other problems related to the
OS providing incorrect size/resolution values for a display
(that requires changes on C level too).


> 2006-07-11  Ralf Angeli  <angeli@caeruleus.net>
>
> 	* w32fns.c (Fx_display_mm_height, Fx_display_mm_width): Calculate
> 	size of display by means of size in pixels and number of pixels
> 	per inch.

This change may be good by itself -- install it if nobody objects in a
few days.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    >> As a last resort we could provide user options (in Emacs) for setting
    >> the correct size of the screen which will be used as return values for
    >> `display-mm-{width,height}'.
    >
    > Sounds like a good plan to me.

    Here are change log entries and patches to achieve that:

This approach has a problem: it assumes there is just one display (or
that all displays have the same size).  The right way to do this is to
let the user specify the size of each display individually.  It could
be done with a frame parameter.

Please redo it that way.

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

[Ralf Angeli]

* Richard Stallman (2006-07-12) writes:

> This approach has a problem: it assumes there is just one display (or
> that all displays have the same size).  The right way to do this is to
> let the user specify the size of each display individually.  It could
> be done with a frame parameter.

Okay.  Would it then suffice to pick an arbitrary frame on the display
given as the argument of `display-mm-width' and check the parameter of
that frame?  That could be done with something like

(let ((frame-list (frames-on-display-list display)))
  (when frame-list
    (frame-parameter (car frame-list) 'display-mm-width)))

assuming the frame parameter is called `display-mm-width'.

-- 
Ralf

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

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Richard Stallman (2006-07-12) writes:
>
>> This approach has a problem: it assumes there is just one display
>> (or that all displays have the same size).  The right way to do
>> this is to let the user specify the size of each display
>> individually.  It could be done with a frame parameter.
>
> Okay.  Would it then suffice to pick an arbitrary frame on the
> display given as the argument of `display-mm-width' and check the
> parameter of that frame?  That could be done with something like
>
> (let ((frame-list (frames-on-display-list display)))
>   (when frame-list
>     (frame-parameter (car frame-list) 'display-mm-width)))
>
> assuming the frame parameter is called `display-mm-width'.

Hm.  I read:

(info "(elisp) Multiple Displays")

       A few Lisp variables are "terminal-local"; that is, they have a
    separate binding for each terminal.  The binding in effect at any time
    is the one for the terminal that the currently selected frame belongs
    to.  These variables include `default-minibuffer-frame',
    `defining-kbd-macro', `last-kbd-macro', and `system-key-alist'.  They
    are always terminal-local, and can never be buffer-local (*note
    Buffer-Local Variables::) or frame-local.

Would that not be a case for a terminal-local variable?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

    Would that not be a case for a terminal-local variable?

I don't think it is worth a local variable
for something that is accessed so rarely.

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

[Stefan Monnier]

> (info "(elisp) Multiple Displays")

>        A few Lisp variables are "terminal-local"; that is, they have a
>     separate binding for each terminal.  The binding in effect at any time
>     is the one for the terminal that the currently selected frame belongs
>     to.  These variables include `default-minibuffer-frame',
>     `defining-kbd-macro', `last-kbd-macro', and `system-key-alist'.  They
>     are always terminal-local, and can never be buffer-local (*note
>     Buffer-Local Variables::) or frame-local.

> Would that not be a case for a terminal-local variable?

It sounds attractive (the idea of adding a frame-local parameter for it
doesn't seem too appealing since it implies the possibility of returning
different results for different frames of the same display).

Tho I'm not sure what would happen with multi-head configs.


        Stefan

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

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (info "(elisp) Multiple Displays")
>
>>        A few Lisp variables are "terminal-local"; that is, they have a
>>     separate binding for each terminal.  The binding in effect at any time
>>     is the one for the terminal that the currently selected frame belongs
>>     to.  These variables include `default-minibuffer-frame',
>>     `defining-kbd-macro', `last-kbd-macro', and `system-key-alist'.  They
>>     are always terminal-local, and can never be buffer-local (*note
>>     Buffer-Local Variables::) or frame-local.
>
>> Would that not be a case for a terminal-local variable?
>
> It sounds attractive (the idea of adding a frame-local parameter for it
> doesn't seem too appealing since it implies the possibility of returning
> different results for different frames of the same display).
>
> Tho I'm not sure what would happen with multi-head configs.

Doesn't multi-head imply multi-display for Emacs?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stefan Monnier]

>>> (info "(elisp) Multiple Displays")
>> 
>>> A few Lisp variables are "terminal-local"; that is, they have a
>>> separate binding for each terminal.  The binding in effect at any time
>>> is the one for the terminal that the currently selected frame belongs
>>> to.  These variables include `default-minibuffer-frame',
>>> `defining-kbd-macro', `last-kbd-macro', and `system-key-alist'.  They
>>> are always terminal-local, and can never be buffer-local (*note
>>> Buffer-Local Variables::) or frame-local.
>> 
>>> Would that not be a case for a terminal-local variable?
>> 
>> It sounds attractive (the idea of adding a frame-local parameter for it
>> doesn't seem too appealing since it implies the possibility of returning
>> different results for different frames of the same display).
>> 
>> Tho I'm not sure what would happen with multi-head configs.

> Doesn't multi-head imply multi-display for Emacs?

It probably depends on the setup (I guess most recent multihead configs use
Xinerama so Emacs should be completely oblivious, but in other cases it may
be separate displays but with a single keyboard, now whether that means
a single (Emacs) terminal or not, I don't know).


        Stefan

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

[Ralf Angeli]

* Stefan Monnier (2006-07-14) writes:

>>>> Would that not be a case for a terminal-local variable?
>>> 
>>> It sounds attractive (the idea of adding a frame-local parameter for it
>>> doesn't seem too appealing since it implies the possibility of returning
>>> different results for different frames of the same display).
>>> 
>>> Tho I'm not sure what would happen with multi-head configs.
>
>> Doesn't multi-head imply multi-display for Emacs?
>
> It probably depends on the setup (I guess most recent multihead configs use
> Xinerama so Emacs should be completely oblivious, but in other cases it may
> be separate displays but with a single keyboard, now whether that means
> a single (Emacs) terminal or not, I don't know).

The info node pointed out by David says it does:

,----[ (info "(elisp)Multiple Displays") ]
|    A single X server can handle more than one screen.  A display name
| `HOST:SERVER.SCREEN' has three parts; the last part specifies the
| screen number for a given server.  When you use two screens belonging
| to one server, Emacs knows by the similarity in their names that they
| share a single keyboard, and it treats them as a single terminal.
`----

So one rather needs screen-dependent or display-dependent values for
screen width and height.  (Obviously.)  A pragmatic way for specifying
this would be an alist with (DISPLAY . LENGTH) elements as suggested
by Kim (assuming display is equivalent to screen).

-- 
Ralf

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

[Ralf Angeli]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

* Ralf Angeli (2006-07-16) writes:

> So one rather needs screen-dependent or display-dependent values for
> screen width and height.  (Obviously.)  A pragmatic way for specifying
> this would be an alist with (DISPLAY . LENGTH) elements as suggested
> by Kim (assuming display is equivalent to screen).

Here is a patch implementing that approach.  I can provide an change
log entry once this is settled.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2308 bytes --]

*** frame.el	06 Apr 2006 19:46:36 +0200	1.236
--- frame.el	16 Jul 2006 18:16:16 +0200	
***************
*** 1081,1097 ****
       (t
        (frame-width (if (framep display) display (selected-frame)))))))
  
  (defun display-mm-height (&optional display)
    "Return the height of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (and (memq (framep-on-display display) '(x w32 mac))
!        (x-display-mm-height display)))
  
  (defun display-mm-width (&optional display)
    "Return the width of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (and (memq (framep-on-display display) '(x w32 mac))
!        (x-display-mm-width display)))
  
  (defun display-backing-store (&optional display)
    "Return the backing store capability of DISPLAY's screen.
--- 1081,1115 ----
       (t
        (frame-width (if (framep display) display (selected-frame)))))))
  
+ (defcustom display-mm-dimensions-alist nil
+   "Alist for specifying screen dimensions in millimeters.
+ Each element of the alist has the form (display . (width . height)),
+ e.g. (\":0.0\" . (287 . 215)).
+ 
+ The dimensions will be used for `display-mm-height' and
+ `display-mm-width' if defined for the respective display."
+   :version "22.1"
+   :type '(alist :key-type (string :tag "Display")
+ 		:value-type (cons :tag "Dimensions"
+ 				  (integer :tag "Width")
+ 				  (integer :tag "Height")))
+   :group 'frames)
+ 
  (defun display-mm-height (&optional display)
    "Return the height of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (or (cddr (assoc (or display (frame-parameter nil 'display))
! 		   display-mm-dimensions-alist))
!       (and (memq (framep-on-display display) '(x w32 mac))
! 	   (x-display-mm-height display))))
  
  (defun display-mm-width (&optional display)
    "Return the width of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (or (cadr (assoc (or display (frame-parameter nil 'display))
! 		   display-mm-dimensions-alist))
!       (and (memq (framep-on-display display) '(x w32 mac))
! 	   (x-display-mm-width display))))
  
  (defun display-backing-store (&optional display)
    "Return the backing store capability of DISPLAY's screen.

[-- Attachment #3: Type: text/plain, Size: 360 bytes --]


Does somebody have a multi-screen setup for testing this patch?  With
my local X server `(display-screens)' returns (":0.0").  I assume an
additional screen would show up as ":0.1" in that list.  But I don't
know about Windows and Mac OS.  On Windows `(display-screens)' returns
("") and I am wondering what would show up with a multi-screen setup.

-- 
Ralf

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Richard Stallman]

    Okay.  Would it then suffice to pick an arbitrary frame on the display
    given as the argument of `display-mm-width' and check the parameter of
    that frame?  That could be done with something like

    (let ((frame-list (frames-on-display-list display)))
      (when frame-list
	(frame-parameter (car frame-list) 'display-mm-width)))

    assuming the frame parameter is called `display-mm-width'.

That would work, if whatever sets that parameter sets it for
all the frames on the display.

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

[Jan Djärv]

Jason Rumney skrev:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
>> Is there any reason to believe the result should be correct? As I
>> pointed out in a previous message the information does not seem to be
>> available to the display driver.
> 
> Built in LCDs in notebooks and LCD panels connected via digital
> connectors are able to report details about the monitor back to the
> video drivers/OS, though I am not sure whether manufacturers always
> report accurate information, or whether Windows uses the information.
> 
> Monitors connected via analog connectors are not able to report this
> information, and Windows seems to always guess 320 as the width, and
> the height is reported as consistent with the width:height ratio
> assuming square pixels.

Monitors with analog connectors can report EDID, but I don't know if 
width/height is in EDID.  My analog connected monitor reports incorrect EDID 
all the time (i.e. wrong hsync freq).

	Jan D.

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

[Robert J. Chassell]

    Yes, perhaps LCD displays are the reason.  Can people please try and
    report the results?

On a display that is 304 mm wide,

    (display-mm-width)  --> 542

However, my resolution is ~135 dots/in or ~5.3 dots/mm.  (My display
is 1600 dots wide.)

Were I to have a resolution of 75 dots/in or ~2.95 dots/mm then a
display width of 542 would give me very nearly 1600 dots, which is how
many on my display.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

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

[Jason Rumney]

Ralf Angeli <angeli@caeruleus.net> writes:

> -  cap = GetDeviceCaps (hdc, VERTSIZE);
> +  height = round (GetDeviceCaps (hdc, VERTRES)
> +		  / GetDeviceCaps (hdc, LOGPIXELSY) * 25.4);

> -  cap = GetDeviceCaps (hdc, HORZSIZE);
> +  width = round (GetDeviceCaps (hdc, HORZRES)
> +		 / GetDeviceCaps (hdc, LOGPIXELSX) * 25.4);

Do these get any more accurate if you move the multiplication to
before the division?

   cap = round (25.4 * GetDeviceCaps (hdc, VERTRES)
                / GetDeviceCaps (hdc, LOGPIXELSY));


If so, it might be worth changing. Otherwise, the results look just as
broken as what we have now. You may have found two cases where the
results were closer, but it does not follow that they will always be
so if they are still wildly inaccurate.

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

[Lennart Borgman]

Jason Rumney wrote:
> Ralf Angeli <angeli@caeruleus.net> writes:
>
>   
>> -  cap = GetDeviceCaps (hdc, VERTSIZE);
>> +  height = round (GetDeviceCaps (hdc, VERTRES)
>> +		  / GetDeviceCaps (hdc, LOGPIXELSY) * 25.4);
>>     
>
>   
>> -  cap = GetDeviceCaps (hdc, HORZSIZE);
>> +  width = round (GetDeviceCaps (hdc, HORZRES)
>> +		 / GetDeviceCaps (hdc, LOGPIXELSX) * 25.4);
>>     
>
> Do these get any more accurate if you move the multiplication to
> before the division?
>
>    cap = round (25.4 * GetDeviceCaps (hdc, VERTRES)
>                 / GetDeviceCaps (hdc, LOGPIXELSY));
>
>
> If so, it might be worth changing. Otherwise, the results look just as
> broken as what we have now. You may have found two cases where the
> results were closer, but it does not follow that they will always be
> so if they are still wildly inaccurate.
>   
MS documentation for GetDeviceCaps says:

    HORZSIZE     Width, in millimeters, of the physical screen.
    VERTSIZE     Height, in millimeters, of the physical screen.

Should we really try to compensate for bugs in device drivers?

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

[Ralf Angeli]

* Jason Rumney (2006-07-07) writes:

> Ralf Angeli <angeli@caeruleus.net> writes:
>
>> -  cap = GetDeviceCaps (hdc, VERTSIZE);
>> +  height = round (GetDeviceCaps (hdc, VERTRES)
>> +		  / GetDeviceCaps (hdc, LOGPIXELSY) * 25.4);
>
>> -  cap = GetDeviceCaps (hdc, HORZSIZE);
>> +  width = round (GetDeviceCaps (hdc, HORZRES)
>> +		 / GetDeviceCaps (hdc, LOGPIXELSX) * 25.4);
>
> Do these get any more accurate if you move the multiplication to
> before the division?

Then I get 296 for the width and 222 for the height.  Here are the
values from my other mail for reference:

|                    display-mm-*   display-mm-*
|         Real size  without patch  with patch
| Width   285mm      370            279
| Height  215mm      277            203
| 

> If so, it might be worth changing. Otherwise, the results look just as
> broken as what we have now.

At least for the two cases at hand the change yields better results
than before.  They are closer to the real values and e.g. for the
other user better match the screens aspect ratio.

> You may have found two cases where the
> results were closer, but it does not follow that they will always be
> so if they are still wildly inaccurate.

It might be worth gathering more data points.

-- 
Ralf

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Fri, 07 Jul 2006 07:50:08 +0200
> 
> It might be worth gathering more data points.

Here's my data points (with the original code):

    |         Real size  display-mm-*
    | Width   324mm      320
    | Height  241mm      240

That's pretty close.

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

[Ralf Angeli]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

* Ralf Angeli (2006-07-06) writes:

> On Windows the return values of `display-mm-width' and
> `display-mm-height' don't really reflect the screen width and height
> in millimeters.

Meanwhile we got another bug report on the AUCTeX list related to this
issue.

I provided a patch for w32fns.c the majority of developers were in
favor of but which hasn't been checked into CVS and a patch for
frame.el about which I haven't got feedback.  I am adding them to this
mail again with updated change log entries for reference:

2006-08-05  Ralf Angeli  <angeli@caeruleus.net>

	* w32fns.c (Fx_display_mm_height, Fx_display_mm_width): Calculate
	size of display by means of size in pixels and number of pixels
	per inch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: w32fns.c.patch --]
[-- Type: text/x-patch, Size: 1256 bytes --]

Index: w32fns.c
===================================================================
RCS file: /sources/emacs/emacs/src/w32fns.c,v
retrieving revision 1.275
diff -u -r1.275 w32fns.c
--- w32fns.c	4 Aug 2006 17:21:21 -0000	1.275
+++ w32fns.c	5 Aug 2006 14:37:37 -0000
@@ -6537,15 +6537,16 @@
 {
   struct w32_display_info *dpyinfo = check_x_display_info (display);
   HDC hdc;
-  int cap;
+  int height;
 
   hdc = GetDC (dpyinfo->root_window);
 
-  cap = GetDeviceCaps (hdc, VERTSIZE);
+  height = round (25.4 * GetDeviceCaps (hdc, VERTRES)
+		  / GetDeviceCaps (hdc, LOGPIXELSY));
 
   ReleaseDC (dpyinfo->root_window, hdc);
 
-  return make_number (cap);
+  return make_number (height);
 }
 
 DEFUN ("x-display-mm-width", Fx_display_mm_width, Sx_display_mm_width, 0, 1, 0,
@@ -6559,15 +6560,16 @@
   struct w32_display_info *dpyinfo = check_x_display_info (display);
 
   HDC hdc;
-  int cap;
+  int width;
 
   hdc = GetDC (dpyinfo->root_window);
 
-  cap = GetDeviceCaps (hdc, HORZSIZE);
+  width = round (25.4 * GetDeviceCaps (hdc, HORZRES)
+		 / GetDeviceCaps (hdc, LOGPIXELSX));
 
   ReleaseDC (dpyinfo->root_window, hdc);
 
-  return make_number (cap);
+  return make_number (width);
 }
 
 DEFUN ("x-display-backing-store", Fx_display_backing_store,

[-- Attachment #3: Type: text/plain, Size: 156 bytes --]


2006-08-05  Ralf Angeli  <angeli@caeruleus.net>

	* frame.el (display-mm-dimensions-alist): New variable.
	(display-mm-height, display-mm-width): Use it.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: frame.el.patch --]
[-- Type: text/x-patch, Size: 1900 bytes --]

Index: frame.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/frame.el,v
retrieving revision 1.237
diff -u -r1.237 frame.el
--- frame.el	21 Jul 2006 07:42:52 -0000	1.237
+++ frame.el	5 Aug 2006 14:36:20 -0000
@@ -1083,17 +1083,35 @@
      (t
       (frame-width (if (framep display) display (selected-frame)))))))
 
+(defcustom display-mm-dimensions-alist nil
+  "Alist for specifying screen dimensions in millimeters.
+Each element of the alist has the form (display . (width . height)),
+e.g. (\":0.0\" . (287 . 215)).
+
+The dimensions will be used for `display-mm-height' and
+`display-mm-width' if defined for the respective display."
+  :version "22.1"
+  :type '(alist :key-type (string :tag "Display")
+		:value-type (cons :tag "Dimensions"
+				  (integer :tag "Width")
+				  (integer :tag "Height")))
+  :group 'frames)
+
 (defun display-mm-height (&optional display)
   "Return the height of DISPLAY's screen in millimeters.
 If the information is unavailable, value is nil."
-  (and (memq (framep-on-display display) '(x w32 mac))
-       (x-display-mm-height display)))
+  (or (cddr (assoc (or display (frame-parameter nil 'display))
+		   display-mm-dimensions-alist))
+      (and (memq (framep-on-display display) '(x w32 mac))
+	   (x-display-mm-height display))))
 
 (defun display-mm-width (&optional display)
   "Return the width of DISPLAY's screen in millimeters.
 If the information is unavailable, value is nil."
-  (and (memq (framep-on-display display) '(x w32 mac))
-       (x-display-mm-width display)))
+  (or (cadr (assoc (or display (frame-parameter nil 'display))
+		   display-mm-dimensions-alist))
+      (and (memq (framep-on-display display) '(x w32 mac))
+	   (x-display-mm-width display))))
 
 (defun display-backing-store (&optional display)
   "Return the backing store capability of DISPLAY's screen.

[-- Attachment #5: Type: text/plain, Size: 232 bytes --]


Could somebody please apply at least one of them or tell me what to
change in order for them to get accepted?  I am planning to upload a
new precompiled version of Emacs for Windows to alpha.gnu.org once
this is settled.

-- 
Ralf

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Ralf Angeli]

* Ralf Angeli (2006-08-05) writes:

> * Ralf Angeli (2006-07-06) writes:
>
>> On Windows the return values of `display-mm-width' and
>> `display-mm-height' don't really reflect the screen width and height
>> in millimeters.
>
> Meanwhile we got another bug report on the AUCTeX list related to this
> issue.
>
> I provided a patch for w32fns.c the majority of developers were in
> favor of but which hasn't been checked into CVS and a patch for
> frame.el about which I haven't got feedback.  I am adding them to this
> mail again with updated change log entries for reference:
[...]
> Could somebody please apply at least one of them or tell me what to
> change in order for them to get accepted?  I am planning to upload a
> new precompiled version of Emacs for Windows to alpha.gnu.org once
> this is settled.

Okay, it's been two weeks and nobody has reacted to the last message.
What do I have to do to get a reaction?  Does using a familiar phrase
help?  Something like "Would someone please DTRT and ack?"

-- 
Ralf

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

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Ralf Angeli (2006-08-05) writes:
>
>> * Ralf Angeli (2006-07-06) writes:
>>
>>> On Windows the return values of `display-mm-width' and
>>> `display-mm-height' don't really reflect the screen width and height
>>> in millimeters.
>>
>> Meanwhile we got another bug report on the AUCTeX list related to this
>> issue.
>>
>> I provided a patch for w32fns.c [...]
>
> [...]
>> Could somebody please apply at least one of them or tell me what to
>> change in order for them to get accepted?  I am planning to upload a
>> new precompiled version of Emacs for Windows to alpha.gnu.org once
>> this is settled.
>
> Okay, it's been two weeks and nobody has reacted to the last
> message.  What do I have to do to get a reaction?  Does using a
> familiar phrase help?  Something like "Would someone please DTRT and
> ack?"

The person checking a change in has some sort of responsibility not to
goof up which means he would want to know as well as the patch
contributor whether this thing works.  If things go wrong, he will
need to fix it.

You have signed papers for Emacs, you already have an account at
Savannah and working actively with CVS, you know how to discuss
changes on the list.  I think it would be easiest for all involved
parties if you just got yourself CVS write access and checked changes
like that in yourself.

So "would someone please DTRT and ack" would in my book mean something
like Eli or Kim putting you on the developer list and get this over.

I have not followed the discussion about the Windows screen dimensions
and am completely out of my technical depth here, but I would want it
fixed for the sake of AUCTeX.

I'd feel uncomfortable checking it in myself, but I don't feel
uncomfortable recommending you as a developer, if that is ok with you.
It really saves trouble for all involved parties in the long run.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jason Rumney]

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.

In response to the objections to your original patch (which gave 
improved but still incorrect results on one machine, different but just 
as incorrect results on another, and according to the documentation for 
the system calls involved could likely give worse results in many 
circumstances), you produced a patch to allow the user to fix up 
incorrect display size/dpi settings, but others pointed out that users 
of multiple displays could be worse off with such a patch. So have you 
given up on that and returned to trying to get your original patch accepted?

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

[Ralf Angeli]

* 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.

> In response to the objections to your original patch (which gave 
> improved but still incorrect results on one machine, different but just 
> as incorrect results on another,

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

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.

> and according to the documentation for 
> the system calls involved could likely give worse results in many 
> circumstances), you produced a patch to allow the user to fix up 
> incorrect display size/dpi settings, but others pointed out that users 
> of multiple displays could be worse off with such a patch. So have you 
> given up on that and returned to trying to get your original patch accepted?

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>.  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>.

-- 
Ralf

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

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 2831 bytes --]

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.



[-- Attachment #1.2: Type: text/html, Size: 4116 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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:j1CRp$MJBHA.264@cppssbbsa01.microsoft.com> ]
| 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/e9drj1$bk9$1@sea.gmane.org>.
> 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/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.

Agreed.

-- 
Ralf

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sun, 20 Aug 2006 10:19:34 +0200
> Cc: emacs-devel@gnu.org
> 
> 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.

Me too.  In fact, I'd oppose to modify the current code, unless we
have a sufficient number of reports which clearly indicate that the
proposed solution is significantly better than the existing code.
Given the evident lack of any theoretical argument in favor, I think
good statistics is the only way to make a sound decision.

So please ask more people, perhaps on help-emacs-windows, to try the
new code and report results with both old and new versions.

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

[Lennart Borgman]

Eli Zaretskii wrote:
>> From: Ralf Angeli <angeli@caeruleus.net>
>> Date: Sun, 20 Aug 2006 10:19:34 +0200
>> Cc: emacs-devel@gnu.org
>>
>> 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.
>>     
>
> Me too.  In fact, I'd oppose to modify the current code, unless we
> have a sufficient number of reports which clearly indicate that the
> proposed solution is significantly better than the existing code.
> Given the evident lack of any theoretical argument in favor, I think
> good statistics is the only way to make a sound decision.
>   
Is it not clear from this discussions that the only way to surely get 
accurate sizes in this case is that the user specifies them?

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

[Eli Zaretskii]

> Date: Mon, 21 Aug 2006 11:17:17 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Ralf Angeli <angeli@caeruleus.net>,  emacs-devel@gnu.org, 
>  jasonr@gnu.org
> 
> Is it not clear from this discussions that the only way to surely get 
> accurate sizes in this case is that the user specifies them?

Most users will not specify that.  In fact, I'm sure many don't even
know how to find out the values, or what parts of the display are
affected by this.

It's an obscure issue, so let's not try solving it hastily, which
would perhaps be appropriate if it affected many users in some grave
way.

In other words, waiting a bit for user reports to come in doesn't
sound like a bad thing to me.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 21 Aug 2006 11:17:17 +0200
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC: Ralf Angeli <angeli@caeruleus.net>,  emacs-devel@gnu.org, 
>>  jasonr@gnu.org
>> 
>> Is it not clear from this discussions that the only way to surely get 
>> accurate sizes in this case is that the user specifies them?
>
> Most users will not specify that.  In fact, I'm sure many don't even
> know how to find out the values, or what parts of the display are
> affected by this.
>
> It's an obscure issue, so let's not try solving it hastily, which
> would perhaps be appropriate if it affected many users in some grave
> way.
>
> In other words, waiting a bit for user reports to come in doesn't
> sound like a bad thing to me.

For me, getting the actual dimensions correct are a secondary concern.
The most important concern is to be able to judge a font size in
pixels.  _That_ is important to get the relative sizes for
point-specified fonts and pixel-specified graphics into proper
relation.  The rest is icing on the cake.  If people want to have
geometrically correct 1:1 displays, they'll specify missing dimensions
if necessary.

But the display geometries are our only pointer to getting the
point/pixel relation coherent for fonts, so when in doubt, we should
rather err in the same manner Windows selects its fonts rather than
get it correct in opposition to all other applications and in
particular the font selection.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jason Rumney]

David Kastrup wrote:
> But the display geometries are our only pointer to getting the
> point/pixel relation coherent for fonts, so when in doubt, we should
> rather err in the same manner Windows selects its fonts rather than
> get it correct in opposition to all other applications and in
> particular the font selection.
>   
How about calculating the font size yourself in the same way you 
calculate image size, and specifying that in pixels to be consistent 
with the images you are generating?
That seems to me to be the only way to get consistency, since the screen 
geometry is not used by the OS in to calculate font sizes (even on X 
AFAICT).

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

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> But the display geometries are our only pointer to getting the
>> point/pixel relation coherent for fonts, so when in doubt, we should
>> rather err in the same manner Windows selects its fonts rather than
>> get it correct in opposition to all other applications and in
>> particular the font selection.
>>   
> How about calculating the font size yourself in the same way you
> calculate image size, and specifying that in pixels to be consistent
> with the images you are generating?

It is not the business of an application like AUCTeX to mess with the
font selection of the user.

> That seems to me to be the only way to get consistency, since the
> screen geometry is not used by the OS in to calculate font sizes
> (even on X AFAICT).

We had no problems on X so far IIRC.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Mon, 21 Aug 2006 11:17:17 +0200
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC: Ralf Angeli <angeli@caeruleus.net>,  emacs-devel@gnu.org, 
>>  jasonr@gnu.org
>>
>> Is it not clear from this discussions that the only way to surely get 
>> accurate sizes in this case is that the user specifies them?
>>     
>
> Most users will not specify that.  In fact, I'm sure many don't even
> know how to find out the values, or what parts of the display are
> affected by this.
>   
Why not tell them in the manual then?

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

[Eli Zaretskii]

> Date: Mon, 21 Aug 2006 12:43:27 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  angeli@caeruleus.net,  jasonr@gnu.org,  emacs-devel@gnu.org
> 
> Why not tell them in the manual then?

I don't mind (although Richard might), but let's not be as naive as
think that mentioning this in the manual will really increase the
population of users who know about the issue and set the dimensions.

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

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Mon, 21 Aug 2006 12:43:27 +0200
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC:  angeli@caeruleus.net,  jasonr@gnu.org,  emacs-devel@gnu.org
>>
>> Why not tell them in the manual then?
>>     
>
> I don't mind (although Richard might), but let's not be as naive as
> think that mentioning this in the manual will really increase the
> population of users who know about the issue and set the dimensions.
>   
I am the naive and optimistic kind. (Sometimes it hurts, sometimes it is 
good...) If we tell this issue is written about in the manual I think 
more will know.

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

[Ralf Angeli]

* Eli Zaretskii (2006-08-21) writes:

> Me too.  In fact, I'd oppose to modify the current code, unless we
> have a sufficient number of reports which clearly indicate that the
> proposed solution is significantly better than the existing code.
> Given the evident lack of any theoretical argument in favor, I think
> good statistics is the only way to make a sound decision.
>
> So please ask more people,

What does `display-mm-width' and `display-mm-height' return in _your_
case with the patch applied? (c;  Maybe other people involved in this
thread and using Windows could report return values with the thread
applied as well.

> perhaps on help-emacs-windows, to try the
> new code and report results with both old and new versions.

There probably won't be many people around compiling Emacs themselves.
I could do the next upload of a precompiled Emacs to alpha.gnu.org
with the patch applied and ask people to compare output of that
version with the prior one.

-- 
Ralf

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

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Cc: jasonr@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 21 Aug 2006 21:22:48 +0200
> 
> What does `display-mm-width' and `display-mm-height' return in _your_
> case with the patch applied?

I didn't apply it, since the current code returns very accurate
results.  I can try later, but I'm traveling now, so it won't be for
another week or so.

Btw, on a laptop I use to type this, running Windows XP SP1, both
functions return nil (meaning the information is unavailable).  What
is the possible reasons for this, and would your suggested change fix
them?

> I could do the next upload of a precompiled Emacs to alpha.gnu.org
> with the patch applied and ask people to compare output of that
> version with the prior one.

It's a good idea, but perhaps make a binary with both versions (under
slightly different names) to make such testing easier.

Thanks.

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

[Ralf Angeli]

* Eli Zaretskii (2006-08-22) writes:

> Btw, on a laptop I use to type this, running Windows XP SP1, both
> functions return nil (meaning the information is unavailable).  What
> is the possible reasons for this, and would your suggested change fix
> them?

Without knowing where and how this fails I don't have an answer to
your question about the reason.  The change to frame.el would
certainly be a change fixing this.  I am currently extending it a bit
to allow the user to specify a default value for all displays not
matching provided display names.  I'll post it later today.

-- 
Ralf

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

[Ralf Angeli]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

* Ralf Angeli (2006-08-22) writes:

> The change to frame.el would
> certainly be a change fixing this.  I am currently extending it a bit
> to allow the user to specify a default value for all displays not
> matching provided display names.  I'll post it later today.

You can find it attached.  Here is a change log entry:

2006-08-22  Ralf Angeli  <angeli@caeruleus.net>

	* frame.el (display-mm-dimensions-alist): New variable.
	(display-mm-height, display-mm-width): Use it.

-- 
Ralf

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2781 bytes --]

Index: frame.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
retrieving revision 1.238
diff -u -r1.238 frame.el
*** frame.el	20 Aug 2006 14:43:29 -0000	1.238
--- frame.el	22 Aug 2006 19:02:11 -0000
***************
*** 1083,1099 ****
       (t
        (frame-width (if (framep display) display (selected-frame)))))))
  
  (defun display-mm-height (&optional display)
    "Return the height of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (and (memq (framep-on-display display) '(x w32 mac))
!        (x-display-mm-height display)))
  
  (defun display-mm-width (&optional display)
    "Return the width of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (and (memq (framep-on-display display) '(x w32 mac))
!        (x-display-mm-width display)))
  
  (defun display-backing-store (&optional display)
    "Return the backing store capability of DISPLAY's screen.
--- 1083,1124 ----
       (t
        (frame-width (if (framep display) display (selected-frame)))))))
  
+ (defcustom display-mm-dimensions-alist nil
+   "Alist for specifying screen dimensions in millimeters.
+ Each element of the alist has the form (display . (width . height)),
+ e.g. (\":0.0\" . (287 . 215)).
+ 
+ The dimensions will be used for `display-mm-height' and
+ `display-mm-width' if defined for the respective display.
+ 
+ If there is an element with the special value t as display
+ indicator, it will be used for all displays not explicitely
+ specified."
+   :version "22.1"
+   :type '(alist :key-type (choice (string :tag "Display name")
+ 				  (const :tag "Default" t))
+ 		:value-type (cons :tag "Dimensions"
+ 				  (integer :tag "Width")
+ 				  (integer :tag "Height")))
+   :group 'frames)
+ 
  (defun display-mm-height (&optional display)
    "Return the height of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (or (cddr (assoc (or display (frame-parameter nil 'display))
! 		   display-mm-dimensions-alist))
!       (cddr (assoc t display-mm-dimensions-alist))
!       (and (memq (framep-on-display display) '(x w32 mac))
! 	   (x-display-mm-height display))))
  
  (defun display-mm-width (&optional display)
    "Return the width of DISPLAY's screen in millimeters.
  If the information is unavailable, value is nil."
!   (or (cadr (assoc (or display (frame-parameter nil 'display))
! 		   display-mm-dimensions-alist))
!       (cadr (assoc t display-mm-dimensions-alist))
!       (and (memq (framep-on-display display) '(x w32 mac))
! 	   (x-display-mm-width display))))
  
  (defun display-backing-store (&optional display)
    "Return the backing store capability of DISPLAY's screen.

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Kim F. Storm]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Ralf Angeli (2006-08-22) writes:
>
>> The change to frame.el would
>> certainly be a change fixing this.  I am currently extending it a bit
>> to allow the user to specify a default value for all displays not
>> matching provided display names.  I'll post it later today.
>
> You can find it attached.  Here is a change log entry:
>
> 2006-08-22  Ralf Angeli  <angeli@caeruleus.net>
>
> 	* frame.el (display-mm-dimensions-alist): New variable.
> 	(display-mm-height, display-mm-width): Use it.

Looks good to me.

One question: 

Should they really return the default value with for emacs -nw ?
Or nil as before?


>
> -- 
> Ralf
>
> Index: frame.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
> retrieving revision 1.238
> diff -u -r1.238 frame.el
> *** frame.el	20 Aug 2006 14:43:29 -0000	1.238
> --- frame.el	22 Aug 2006 19:02:11 -0000
> ***************
> *** 1083,1099 ****
>        (t
>         (frame-width (if (framep display) display (selected-frame)))))))
>   
>   (defun display-mm-height (&optional display)
>     "Return the height of DISPLAY's screen in millimeters.
>   If the information is unavailable, value is nil."
> !   (and (memq (framep-on-display display) '(x w32 mac))
> !        (x-display-mm-height display)))
>   
>   (defun display-mm-width (&optional display)
>     "Return the width of DISPLAY's screen in millimeters.
>   If the information is unavailable, value is nil."
> !   (and (memq (framep-on-display display) '(x w32 mac))
> !        (x-display-mm-width display)))
>   
>   (defun display-backing-store (&optional display)
>     "Return the backing store capability of DISPLAY's screen.
> --- 1083,1124 ----
>        (t
>         (frame-width (if (framep display) display (selected-frame)))))))
>   
> + (defcustom display-mm-dimensions-alist nil
> +   "Alist for specifying screen dimensions in millimeters.
> + Each element of the alist has the form (display . (width . height)),
> + e.g. (\":0.0\" . (287 . 215)).
> + 
> + The dimensions will be used for `display-mm-height' and
> + `display-mm-width' if defined for the respective display.
> + 
> + If there is an element with the special value t as display
> + indicator, it will be used for all displays not explicitely
> + specified."
> +   :version "22.1"
> +   :type '(alist :key-type (choice (string :tag "Display name")
> + 				  (const :tag "Default" t))
> + 		:value-type (cons :tag "Dimensions"
> + 				  (integer :tag "Width")
> + 				  (integer :tag "Height")))
> +   :group 'frames)
> + 
>   (defun display-mm-height (&optional display)
>     "Return the height of DISPLAY's screen in millimeters.
>   If the information is unavailable, value is nil."
> !   (or (cddr (assoc (or display (frame-parameter nil 'display))
> ! 		   display-mm-dimensions-alist))
> !       (cddr (assoc t display-mm-dimensions-alist))
> !       (and (memq (framep-on-display display) '(x w32 mac))
> ! 	   (x-display-mm-height display))))
>   
>   (defun display-mm-width (&optional display)
>     "Return the width of DISPLAY's screen in millimeters.
>   If the information is unavailable, value is nil."
> !   (or (cadr (assoc (or display (frame-parameter nil 'display))
> ! 		   display-mm-dimensions-alist))
> !       (cadr (assoc t display-mm-dimensions-alist))
> !       (and (memq (framep-on-display display) '(x w32 mac))
> ! 	   (x-display-mm-width display))))
>   
>   (defun display-backing-store (&optional display)
>     "Return the backing store capability of DISPLAY's screen.
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Ralf Angeli]

* Kim F. Storm (2006-08-22) writes:

> Ralf Angeli <angeli@caeruleus.net> writes:
>
>> 	* frame.el (display-mm-dimensions-alist): New variable.
>> 	(display-mm-height, display-mm-width): Use it.
>
> Looks good to me.
>
> One question: 
>
> Should they really return the default value with for emacs -nw ?
> Or nil as before?

Thanks for spotting this.  I think it should return nil.  More
specifically: If display-mm-* is called without an argument it should
return nil if the display the current frame is located on is not a
graphical one.  If display-mm-* is called with an argument it should
return nil if the target display is unavailable or not a graphical
one.  I can change the patch accordingly ...

-- 
Ralf

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

[Kim F. Storm]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Kim F. Storm (2006-08-22) writes:
>
>> Ralf Angeli <angeli@caeruleus.net> writes:
>>
>>> 	* frame.el (display-mm-dimensions-alist): New variable.
>>> 	(display-mm-height, display-mm-width): Use it.
>>
>> Looks good to me.
>>
>> One question: 
>>
>> Should they really return the default value with for emacs -nw ?
>> Or nil as before?
>
> Thanks for spotting this.  I think it should return nil.  More
> specifically: If display-mm-* is called without an argument it should
> return nil if the display the current frame is located on is not a
> graphical one.  If display-mm-* is called with an argument it should
> return nil if the target display is unavailable or not a graphical
> one.  I can change the patch accordingly ...

Pls. do.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Ralf Angeli]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

* Kim F. Storm (2006-08-24) writes:

> Ralf Angeli <angeli@caeruleus.net> writes:
>
>> Thanks for spotting this.  I think it should return nil.  More
>> specifically: If display-mm-* is called without an argument it should
>> return nil if the display the current frame is located on is not a
>> graphical one.  If display-mm-* is called with an argument it should
>> return nil if the target display is unavailable or not a graphical
>> one.  I can change the patch accordingly ...
>
> Pls. do.

You can find the updated patch attached.  The change log entry posted
before is still valid.

-- 
Ralf

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2078 bytes --]

Index: frame.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
retrieving revision 1.238
diff -u -r1.238 frame.el
--- frame.el	20 Aug 2006 14:43:29 -0000	1.238
+++ frame.el	24 Aug 2006 16:13:09 -0000
@@ -1083,17 +1083,42 @@
      (t
       (frame-width (if (framep display) display (selected-frame)))))))
 
+(defcustom display-mm-dimensions-alist nil
+  "Alist for specifying screen dimensions in millimeters.
+Each element of the alist has the form (display . (width . height)),
+e.g. (\":0.0\" . (287 . 215)).
+
+The dimensions will be used for `display-mm-height' and
+`display-mm-width' if defined for the respective display.
+
+If there is an element with the special value t as display
+indicator, it will be used for all graphical displays not
+explicitely specified."
+  :version "22.1"
+  :type '(alist :key-type (choice (string :tag "Display name")
+				  (const :tag "Default" t))
+		:value-type (cons :tag "Dimensions"
+				  (integer :tag "Width")
+				  (integer :tag "Height")))
+  :group 'frames)
+
 (defun display-mm-height (&optional display)
   "Return the height of DISPLAY's screen in millimeters.
 If the information is unavailable, value is nil."
   (and (memq (framep-on-display display) '(x w32 mac))
-       (x-display-mm-height display)))
+       (or (cddr (assoc (or display (frame-parameter nil 'display))
+			display-mm-dimensions-alist))
+	   (cddr (assoc t display-mm-dimensions-alist))
+	   (x-display-mm-height display))))
 
 (defun display-mm-width (&optional display)
   "Return the width of DISPLAY's screen in millimeters.
 If the information is unavailable, value is nil."
   (and (memq (framep-on-display display) '(x w32 mac))
-       (x-display-mm-width display)))
+       (or (cadr (assoc (or display (frame-parameter nil 'display))
+			display-mm-dimensions-alist))
+	   (cadr (assoc t display-mm-dimensions-alist))
+	   (x-display-mm-width display))))
 
 (defun display-backing-store (&optional display)
   "Return the backing store capability of DISPLAY's screen.

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Kim F. Storm]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Kim F. Storm (2006-08-24) writes:
>
>> Ralf Angeli <angeli@caeruleus.net> writes:
>>
>>> Thanks for spotting this.  I think it should return nil.  More
>>> specifically: If display-mm-* is called without an argument it should
>>> return nil if the display the current frame is located on is not a
>>> graphical one.  If display-mm-* is called with an argument it should
>>> return nil if the target display is unavailable or not a graphical
>>> one.  I can change the patch accordingly ...
>>
>> Pls. do.
>
> You can find the updated patch attached.  The change log entry posted
> before is still valid.

I think this patch is ok.  I recommend installing it.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Ralf Angeli]

* Kim F. Storm (2006-08-24) writes:

> Ralf Angeli <angeli@caeruleus.net> writes:
>
>> You can find the updated patch attached.  The change log entry posted
>> before is still valid.
>
> I think this patch is ok.  I recommend installing it.

You talkin' to me?  Because I don't have no CVS write access. (c;

-- 
Ralf

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

[Kim F. Storm]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Kim F. Storm (2006-08-24) writes:
>
>> Ralf Angeli <angeli@caeruleus.net> writes:
>>
>>> You can find the updated patch attached.  The change log entry posted
>>> before is still valid.
>>
>> I think this patch is ok.  I recommend installing it.
>
> You talkin' to me?  Because I don't have no CVS write access. (c;

I was asking for the others who participated in the discussion so far
to speak up if they have strong objections against this patch -- otherwise
I will install it in a few days.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Jason Rumney]

Ralf Angeli wrote:
> What does `display-mm-width' and `display-mm-height' return in _your_
> case with the patch applied? (c;  Maybe other people involved in this
> thread and using Windows could report return values with the thread
> applied as well.
>   

        Measured           Current Code       Proposed Patch
Width   303                320                370
Height  190                200                238

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

[Ralf Angeli]

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

>         Measured           Current Code       Proposed Patch
> Width   303                320                370
> Height  190                200                238

What is the DPI value you set in Windows' preferences and what is the
real DPI value of the display device?

-- 
Ralf

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

[Jason Rumney]

Ralf Angeli wrote:
> What is the DPI value you set in Windows' preferences and what is the
> real DPI value of the display device?
>   
It is set to the default: 96dpi. The display is 1400x900 pixels, 
whatever that works out to.

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

[Ralf Angeli]

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

> Ralf Angeli wrote:
>> What is the DPI value you set in Windows' preferences and what is the
>> real DPI value of the display device?
>>   
> It is set to the default: 96dpi. The display is 1400x900 pixels, 
> whatever that works out to.

With a width of 303mm and a height of 190mm that's roughly 120dpi.
Are the return values more realistic if you set this DPI value?

-- 
Ralf

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

[Robert J. Chassell]

    ... in other cases it may be separate displays but with a single
    keyboard, now whether that means a single (Emacs) terminal or not,
    I don't know

In 1994, RMS wrote `make-frame-on-display', which enables you to
connect to another X display.  Frames in the different displays can
show windows with the same or different buffers.  I have used the
command.  It works fine.

The command is documented in the Emacs Manual,  (emacs)Multiple Displays

However, I do not know anything about Microsoft operating systems.
They do not run X to create windows.  Maybe they lack the capability
or maybe they do have it and the Emacs Manual is wrong.  (The email
message did not say whether it was about one of the Microsoft
operating systems or an X operating system or all.  The documentation
specifically refers to X.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc