Text Objects Different Size
QUESTION: I have an IDLgrView with several IDLgrText objects displayed in it. The text objects use an IDLgrFont object with a particular font size. When I display the view in an IDL graphics window object (IDLgrWindow), all looks as I expect it to. But when I display the very same view in an IDLgrBuffer object, all of the text objects are modified and appear smaller than they are in the graphics window object. I have been very careful to set the dimensions of the IDLgrWindow and IDLgrBuffer objects to the same values. Here is an example of what I mean.
|The image on the left shows the text in the IDLgrBuffer, and the image on the right shows the same text on my display.|
What can I do to make sure the text objects have the same size in both display objects?
ANSWER: Thanks to Rick Towler, Mike Galloy and Karl Shultz on the IDL Newsgroup for collaborating on this answer. Karl had the most complete answer, so I'll let him explain it in his own words.
I think the size descrepancy has to do with the default resolution of the IDLgrBuffer device.
Recall that an IDLgrBuffer is not a physical device. Since there is no piece of hardware for it to query, it simply sets its RESOLUTION property to 72 DPI as a somewhat arbitrary, but reasonable, default value. Since this property is writable, you can change it.
An IDLgrWindow can query the hardware [see below] and figure out how big a pixel is (i.e., its resolution). It then sets its RESOLUTION property accordingly to communicate the value to the application; it cannot be changed.
If text is to be drawn at a specific physical size (e.g., 12 points or 12/72 inches), then the object needs to know the size of a pixel in order to draw something of a specific size. On a 72 DPI device, a 12- point font would occupy 12 pixels in height. Of course, this is the size of the entire "box" for the glyph; this does not mean that all glyphs are 12 pixels tall.
You can specify coordinates in Object Graphics using inches and centimeters, right? If Object Graphicsis going to draw a line 1 inch long, it had better know the size of pixels on the device so it knows how many to draw to make an inch.
Many displays, and especially Macintosh displays, are 96 DPI, so there will be a 4/3 scale factor difference between the font size on those displays and the default IDLgrBuffer. That is, in fact, what you are seeing.
The way to fix this is to query the RESOLUTION from the IDLgrWindow that you want to match up with the IDLgrBuffer and set the IDLgrBuffer's RESOLUTION property to match. This will be better than scaling the font size with some fixed value. It will also work with displays that have different resolutions than the ones used to compute this fixed scale factor. Other things in Object Graphics (for example, line widths) use the RESOLUTION property, too, and will be affected similarly.
Rick and Mike alerted us to one way to determine the resolotuion of your monitor (or monitors!) by using the IDLsysMonitorInfo object, like this.
monitor = Obj_New('IDLsysMonitorInfo') resolution = monitor -> GetResolutions() Obj_Destroy, monitor
Each row of the resolution variable will contain the X and Y resolutions of your monitors. If you have a single monitor, there will be one row of information. If you are using two monitors, you will have two rows of information, and so on. The resolution of each monitor might be different. You will need to select the resolution of the monitor you will be displaying your graphics window on. Use the proper resolution to set the resolution of your IDL buffer object.
bufferObject -> SetProperty, RESOLUTION=resolution[*,0]
Or, more specifically, if your monitor is at 96 DPI, you can set your IDLgrBuffer resolution like this. Note that the resolution is normally expressed in centimeters per pixel, not inches per pixel, although this will typically depend on what UNITS keyword you have in effect.
bufferObject -> SetProperty, RESOLUTION=[2.54, 2.54]/96.0
Version of IDL used to prepare this article: IDL 7.1.
Copyright © 2009 David W. Fanning
Written 28 February 2009
Last Updated 2 December 2009