Is GDI+ PageUnit Supposed to be Accurate?

[Charles Law]

If I draw a rectangle, 6 inches by 2 inches, on a user control with a
PageUnit of Inches, I get a rectangle of 7 by 2.2 inches.

Is this what people would expect? I would have hoped that it was at least
scaled consistently.

Charles

[Frank Hileman]

Hello Charles,

I suppose you found RotateAt?

Regarding DPI, in Windows it is considered a user-defined setting and not a
property of the system. So it has nothing to do with true DPI, which can
only be determined by having the user run a calibration program, measuring
and entering the true length and height, which you then use to compute
compensating scale factors. For this compensation I would use a
transformation and not PageScale. The compensation would be the last
transformation in your pipeline.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

"Charles Law" <bl***@nowhere. com> wrote in message
news:uf******** ******@TK2MSFTN GP15.phx.gbl...

Hi Scott

I have been playing again, and now have something that takes two radii and
an angle, and draws a filled arc in the position I require. I think that
the rotation does not work as I thought because the centre of rotation is
the origin, and not the centre of my arcs. This makes sense, but does not
help me much.

I have seen Bob's web site, and he observes that transformations are, at
best, not intuitive to follow. It strikes me that GDI+ is very powerful,
but it is all things to all people, and therefore frequently requires
quite a lot of work to make it do what is wanted. Perhaps this another
area where Microsoft could provide more examples/samples to get people
started. Just a thought.

Charles
"Scott McChesney" <sc************ *********@us.ar my.mil> wrote in message
news:us******** ******@TK2MSFTN GP10.phx.gbl...

Well - you're getting into areas where my knowledge is a little fuzzy.
Perhaps Bob Powell or Frank Hilleman will chime in here - they are much
more adept in these areas than I. But given the nature of pixels to
physical measurements, taking into account the monitor resolution, screen
size, type, and manufacturer's quirks, I'm not sure how close you'll be
able to get.

- Scott

"Charles Law" <bl***@nowhere. com> wrote in message
news:uC******** ******@TK2MSFTN GP12.phx.gbl...

Is it of vital importance that 200mm is 200mm (and not 195)?

It's not critical for its own sake, but I had hoped to provide a zoom
for the elements that are being drawn by using ScaleTransform. If the x
and y scale factors are the same then the object being zoomed changes
its aspect ratio as it is enlarged, and it is very obvious. With no rule
to follow and no point of reference I can't zoom the object
proportionally.

Here's an example; I have abandoned changing PageUnit, and am leaving it
set to the default (pixels), because it seems to be more trouble than
it's worth. I draw a rectangle of 200 by 200. This equates to

64 x 60 mm

Applying a scale transform of (2, 2) the new measurement is

125 x 118 mm

This is actually a scale of 1.95/1.96, which I suppose is close enough,
but it's not 2. Anyway, I shall persevere.

Thanks for the replies.

Charles
"Scott McChesney" <sc************ *********@us.ar my.mil> wrote in message
news:uv******** ******@TK2MSFTN GP12.phx.gbl...
It's my understanding that, no matter what your monitor is set at, GDI+
in .NET will return 96 DPI for any Graphics object created from the
screen. So querying the Graphics object's DPI settings won't get you
anywhere - they will say 96, and your math still won't be right.
That's why I said you should use the Windows API (via Interop) to get
the physical dimensions (and any DPI that GDI might tell you, which
could - but is not likely to - be different.)

I would guess the errors in scaling are related to rounding, so you may
not be able to get an exact solution that fits all cases. Is it of
vital importance that 200mm is 200mm (and not 195)? I realize that may
be a dumb question, but we might not be able to get you there from
here...

- Scott

"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
> Hi Charles,
>
> In my opinion is the answer in the question and the answer Fergus
> gave?
>
> Never done, however it sound reasonable for me.
>
> Cor
>

[Charles Law]

Hi Frank

I didn't, actually, but I will certainly take a look at it. I think I won't
go to the extent of measuring on-screen to calibrate, but just try to find a
way to ensure that when I do scale an object it retains its aspect ratio.
The most reliable way to do this seems to be to stick with units of pixel,
and not use millimetres or inches.

Charles
"Frank Hileman" <fr******@no.sp amming.prodiges oftware.com> wrote in message
news:ue******** ******@TK2MSFTN GP14.phx.gbl...

Hello Charles,

I suppose you found RotateAt?

Regarding DPI, in Windows it is considered a user-defined setting and not
a property of the system. So it has nothing to do with true DPI, which can
only be determined by having the user run a calibration program, measuring
and entering the true length and height, which you then use to compute
compensating scale factors. For this compensation I would use a
transformation and not PageScale. The compensation would be the last
transformation in your pipeline.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

"Charles Law" <bl***@nowhere. com> wrote in message
news:uf******** ******@TK2MSFTN GP15.phx.gbl...

Hi Scott

I have been playing again, and now have something that takes two radii
and an angle, and draws a filled arc in the position I require. I think
that the rotation does not work as I thought because the centre of
rotation is the origin, and not the centre of my arcs. This makes sense,
but does not help me much.

I have seen Bob's web site, and he observes that transformations are, at
best, not intuitive to follow. It strikes me that GDI+ is very powerful,
but it is all things to all people, and therefore frequently requires
quite a lot of work to make it do what is wanted. Perhaps this another
area where Microsoft could provide more examples/samples to get people
started. Just a thought.

Charles
"Scott McChesney" <sc************ *********@us.ar my.mil> wrote in message
news:us******** ******@TK2MSFTN GP10.phx.gbl...

Well - you're getting into areas where my knowledge is a little fuzzy.
Perhaps Bob Powell or Frank Hilleman will chime in here - they are much
more adept in these areas than I. But given the nature of pixels to
physical measurements, taking into account the monitor resolution,
screen size, type, and manufacturer's quirks, I'm not sure how close
you'll be able to get.

- Scott

"Charles Law" <bl***@nowhere. com> wrote in message
news:uC******** ******@TK2MSFTN GP12.phx.gbl...
> Is it of vital importance that 200mm is 200mm (and not 195)?

It's not critical for its own sake, but I had hoped to provide a zoom
for the elements that are being drawn by using ScaleTransform. If the x
and y scale factors are the same then the object being zoomed changes
its aspect ratio as it is enlarged, and it is very obvious. With no
rule to follow and no point of reference I can't zoom the object
proportionally.

Here's an example; I have abandoned changing PageUnit, and am leaving
it set to the default (pixels), because it seems to be more trouble
than it's worth. I draw a rectangle of 200 by 200. This equates to

64 x 60 mm

Applying a scale transform of (2, 2) the new measurement is

125 x 118 mm

This is actually a scale of 1.95/1.96, which I suppose is close enough,
but it's not 2. Anyway, I shall persevere.

Thanks for the replies.

Charles
"Scott McChesney" <sc************ *********@us.ar my.mil> wrote in
message news:uv******** ******@TK2MSFTN GP12.phx.gbl...
> It's my understanding that, no matter what your monitor is set at,
> GDI+ in .NET will return 96 DPI for any Graphics object created from
> the screen. So querying the Graphics object's DPI settings won't get
> you anywhere - they will say 96, and your math still won't be right.
> That's why I said you should use the Windows API (via Interop) to get
> the physical dimensions (and any DPI that GDI might tell you, which
> could - but is not likely to - be different.)
>
> I would guess the errors in scaling are related to rounding, so you
> may not be able to get an exact solution that fits all cases. Is it
> of vital importance that 200mm is 200mm (and not 195)? I realize that
> may be a dumb question, but we might not be able to get you there from
> here...
>
> - Scott
>
> "Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
> news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
>> Hi Charles,
>>
>> In my opinion is the answer in the question and the answer Fergus
>> gave?
>>
>> Never done, however it sound reasonable for me.
>>
>> Cor
>>
>
>

[Bob Powell [MVP]]

Rotations are always about the origin. If you use some trick to shift the
origin to the center of your object then that's ok. If you rotate without
being aware of the origin the object usually disappears and is not seen
again for some time.

Think of quadrants. The normal view of a window shows the lower-right
quadrant of the actual drawing surface. A point at 100,100 is rotated about
a point that is -100,-100 from it's real position.

RotateAt actually translates the drawing surface by -x and -y before
rotation and then translates back +x and +y afterwards.

I tend not to use RoteteAt because it puts a hidden step into the equation
that I don't like to think about. I most often explicitly translate back to
the origin, rotate, possibly scale, and then translate back once again.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Charles Law" <bl***@nowhere. com> wrote in message
news:uf******** ******@TK2MSFTN GP15.phx.gbl...

Hi Scott

I have been playing again, and now have something that takes two radii and
an angle, and draws a filled arc in the position I require. I think that
the rotation does not work as I thought because the centre of rotation is
the origin, and not the centre of my arcs. This makes sense, but does not
help me much.

I have seen Bob's web site, and he observes that transformations are, at
best, not intuitive to follow. It strikes me that GDI+ is very powerful,
but it is all things to all people, and therefore frequently requires
quite a lot of work to make it do what is wanted. Perhaps this another
area where Microsoft could provide more examples/samples to get people
started. Just a thought.

Charles
"Scott McChesney" <sc************ *********@us.ar my.mil> wrote in message
news:us******** ******@TK2MSFTN GP10.phx.gbl...

Well - you're getting into areas where my knowledge is a little fuzzy.
Perhaps Bob Powell or Frank Hilleman will chime in here - they are much
more adept in these areas than I. But given the nature of pixels to
physical measurements, taking into account the monitor resolution, screen
size, type, and manufacturer's quirks, I'm not sure how close you'll be
able to get.

- Scott

"Charles Law" <bl***@nowhere. com> wrote in message
news:uC******** ******@TK2MSFTN GP12.phx.gbl...

Is it of vital importance that 200mm is 200mm (and not 195)?

It's not critical for its own sake, but I had hoped to provide a zoom
for the elements that are being drawn by using ScaleTransform. If the x
and y scale factors are the same then the object being zoomed changes
its aspect ratio as it is enlarged, and it is very obvious. With no rule
to follow and no point of reference I can't zoom the object
proportionally.

Here's an example; I have abandoned changing PageUnit, and am leaving it
set to the default (pixels), because it seems to be more trouble than
it's worth. I draw a rectangle of 200 by 200. This equates to

64 x 60 mm

Applying a scale transform of (2, 2) the new measurement is

125 x 118 mm

This is actually a scale of 1.95/1.96, which I suppose is close enough,
but it's not 2. Anyway, I shall persevere.

Thanks for the replies.

Charles
"Scott McChesney" <sc************ *********@us.ar my.mil> wrote in message
news:uv******** ******@TK2MSFTN GP12.phx.gbl...
It's my understanding that, no matter what your monitor is set at, GDI+
in .NET will return 96 DPI for any Graphics object created from the
screen. So querying the Graphics object's DPI settings won't get you
anywhere - they will say 96, and your math still won't be right.
That's why I said you should use the Windows API (via Interop) to get
the physical dimensions (and any DPI that GDI might tell you, which
could - but is not likely to - be different.)

I would guess the errors in scaling are related to rounding, so you may
not be able to get an exact solution that fits all cases. Is it of
vital importance that 200mm is 200mm (and not 195)? I realize that may
be a dumb question, but we might not be able to get you there from
here...

- Scott

"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
> Hi Charles,
>
> In my opinion is the answer in the question and the answer Fergus
> gave?
>
> Never done, however it sound reasonable for me.
>
> Cor
>