Re: IDLgrWindow vs. IDLgrBuffer, font-rendering difference [message #68875] |
Mon, 30 November 2009 20:37 |
M. Katz
Messages: 69 Registered: May 2005
|
Member |
|
|
Karl, you're absolutely right! Thank you.
Using GetProperty on newly created IDLgrWindow and IDLgrBuffer
objects, you can see that they have different resolutions on Mac, but
the same resolution on Windows. So now to make the two objects match
their respective font sizes, I can note the default resolution for the
IDLgrWindow, and then set the RESOLUTION keyword when the IDLgrBuffer
is created.
-M.
|
|
|
Re: IDLgrWindow vs. IDLgrBuffer, font-rendering difference [message #68889 is a reply to message #68875] |
Mon, 30 November 2009 08:47  |
Karl[1]
Messages: 79 Registered: October 2005
|
Member |
|
|
On Nov 30, 9:41 am, David Fanning <n...@dfanning.com> wrote:
> M. Katz writes:
>> On Mac OS X I'm using 1.45 as the scaling factor (i.e. I make the
>> IDLgrBuffer fonts larger by 1.45x to match IDLgrWindow). I have not
>> tested Windows, but David says they match.
>
> What has ITTVIS had to say about this? I was on their
> web page this morning looking for news, but didn't find
> anything in the Tech Tips. I'm never sure, though, if this
> is because there is nothing there or because their hapless
> search engine is still inept. In any case "IDLgrBuffer"
> or "buffer" or "object graphics" didn't turn anything
> up.
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
I think it 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 and figure out how big a pixel
is (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 OG is 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.
The first post to this thread mentioned a 4/3 scale factor. Many
displays are 96 DPI, which explains that ratio. Perhaps the 1.45
comes from Apple display hardware.
It seems to me that the smart 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 should 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 like line widths use the RESOLUTION
property, as well as things specified in inches or centimeters.
It's been awhile and I'm not sure that this is right. But the docs
seem to support the concept. See the reference pages for IDLgrBuffer.
Karl
|
|
|
Re: IDLgrWindow vs. IDLgrBuffer, font-rendering difference [message #68891 is a reply to message #68889] |
Mon, 30 November 2009 07:41  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
M. Katz writes:
> On Mac OS X I'm using 1.45 as the scaling factor (i.e. I make the
> IDLgrBuffer fonts larger by 1.45x to match IDLgrWindow). I have not
> tested Windows, but David says they match.
What has ITTVIS had to say about this? I was on their
web page this morning looking for news, but didn't find
anything in the Tech Tips. I'm never sure, though, if this
is because there is nothing there or because their hapless
search engine is still inept. In any case "IDLgrBuffer"
or "buffer" or "object graphics" didn't turn anything
up.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
Re: IDLgrWindow vs. IDLgrBuffer, font-rendering difference [message #68892 is a reply to message #68891] |
Mon, 30 November 2009 07:07  |
natha
Messages: 482 Registered: October 2007
|
Senior Member |
|
|
On Nov 30, 10:00 am, "M. Katz" <MKatz...@yahoo.com> wrote:
> On Mac OS X I'm using 1.45 as the scaling factor (i.e. I make the
> IDLgrBuffer fonts larger by 1.45x to match IDLgrWindow). I have not
> tested Windows, but David says they match.
>
> Nata, what OS are you using?
LINUX FEEDORA ! The scaling factor is also 1.45
|
|
|
|
|
Re: IDLgrWindow vs. IDLgrBuffer, font-rendering difference [message #68900 is a reply to message #68896] |
Sat, 28 November 2009 09:33  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
M. Katz writes:
> Has anyone noticed or found a solution for the peculiar font-size
> inconsistency between IDLgrWindow and IDLgrBuffer that occurs with
> RECOMPUTE_DIMENSIONS=2? When I draw an IDLgrAxis to the window or to
> the buffer, the font-size in the buffer is smaller by about 1.33x.
>
> The only way to guarantee consistency between Window and Buffer is to
> set RECOMPUTE_DIMENSIONS=0, but then I cannot stretch the axes without
> distorting the fonts or re-drawing them entirely.
I don't see this in IDL 7.1 for Windows. The two outputs
look identical to me, except for the fact that minor
tick marks are missing in the axis created in the buffer.
But the fonts are absolutely identical.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|