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

[Scott McChesney]

GDI+ says all monitors are 96 DPI, but not all of them are. That may be
causing what you're seeing. Your measurements would seem to be outside of
that "margin for error" - an extra inch? - but it's the only thing I know of
that would cause the differential.

I have heard of people managing this by drawing a line a certain number of
pixels and asking the user to provide the measurement of said line. From
there - assuming you work entirely in inches (or whatever unit of measure
you choose to have them use) - you could do your own translation of physical
dimensions to pixels. You would have to have them measure in both
directions, and drawing "off the axes" might be tough, but it could be
workable.

I believe you can query the monitor through the Windows API and Interop, but
even if you get the true physical dimensions, I don't think you'll have much
luck making a transformation in GDI+ that will work for you.

HTH

- Scott

"Charles Law" <bl***@nowhere.com> wrote in message
news:O5**************@TK2MSFTNGP14.phx.gbl...

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

[Cor Ligthert [MVP]]

Charles,

The answer you got did remind me what another Englishman once wrote in this
newsgroup.

See the complete thread (although it is only important until the first
answer)
http://groups.google.com/group/micro...4af837e33f202d

(I am waiting)

:-)))

I hope this helps,

Cor

[Charles Law]

Hi Scott

Thanks for the reply. I have tried measuring a "standard" rectangle of 100
by 100 mm, and scaling the graphics object with ScaleTransform, and this
corrects the standard rectangle dimensions. However, when I double the size
of the rectangle, the new width is only 195 mm instead of 200 mm. It would
seem that the transformation/scaling is not linear, which makes it
impossible to scale anything correctly.

Charles
"Scott McChesney" <sc*********************@us.army.mil> wrote in message
news:e7**************@TK2MSFTNGP15.phx.gbl...

GDI+ says all monitors are 96 DPI, but not all of them are. That may be
causing what you're seeing. Your measurements would seem to be outside of
that "margin for error" - an extra inch? - but it's the only thing I know
of that would cause the differential.

I have heard of people managing this by drawing a line a certain number of
pixels and asking the user to provide the measurement of said line. From
there - assuming you work entirely in inches (or whatever unit of measure
you choose to have them use) - you could do your own translation of
physical dimensions to pixels. You would have to have them measure in
both directions, and drawing "off the axes" might be tough, but it could
be workable.

I believe you can query the monitor through the Windows API and Interop,
but even if you get the true physical dimensions, I don't think you'll
have much luck making a transformation in GDI+ that will work for you.

HTH

- Scott

"Charles Law" <bl***@nowhere.com> wrote in message
news:O5**************@TK2MSFTNGP14.phx.gbl...

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

[Charles Law]

Hi Cor

Ah yes ... Fergus, dear chap. Where is he now?

I am trying to find a way to scale things reliably, but as I mentioned in my
other reply, the scaling does not appear to be linear.

Any ideas?

Charles
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Charles,

The answer you got did remind me what another Englishman once wrote in
this newsgroup.

See the complete thread (although it is only important until the first
answer)
http://groups.google.com/group/micro...4af837e33f202d

(I am waiting)

:-)))

I hope this helps,

Cor

[Cor Ligthert [MVP]]

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

[Scott McChesney]

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****************@TK2MSFTNGP10.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]

> 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.army.mil> wrote in message
news:uv**************@TK2MSFTNGP12.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****************@TK2MSFTNGP10.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

[Scott McChesney]

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**************@TK2MSFTNGP12.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.army.mil> wrote in message
news:uv**************@TK2MSFTNGP12.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****************@TK2MSFTNGP10.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 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.army.mil> wrote in message
news:us**************@TK2MSFTNGP10.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**************@TK2MSFTNGP12.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.army.mil> wrote in message
news:uv**************@TK2MSFTNGP12.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****************@TK2MSFTNGP10.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

[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**************@TK2MSFTNGP15.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.army.mil> wrote in message
news:us**************@TK2MSFTNGP10.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**************@TK2MSFTNGP12.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.army.mil> wrote in message
news:uv**************@TK2MSFTNGP12.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****************@TK2MSFTNGP10.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.spamming.prodigesoftware.com> wrote in message
news:ue**************@TK2MSFTNGP14.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**************@TK2MSFTNGP15.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.army.mil> wrote in message
news:us**************@TK2MSFTNGP10.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**************@TK2MSFTNGP12.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.army.mil> wrote in
message news:uv**************@TK2MSFTNGP12.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****************@TK2MSFTNGP10.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**************@TK2MSFTNGP15.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.army.mil> wrote in message
news:us**************@TK2MSFTNGP10.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**************@TK2MSFTNGP12.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.army.mil> wrote in message
news:uv**************@TK2MSFTNGP12.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****************@TK2MSFTNGP10.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
>