I did this for now

getCurve().getSymbol().setModelWidth(1);
Window.alert("width unit :" + getCurve().getSymbol().getWidth());

 but I believe there must be a better way.

Never considered this problem before; thats a clever solution for it, thanks for
sharing it.

Another approach I think should work (have not tried it yet) is:

xPxPerModelUnit =  getXChartSize()/(getXAxis().getAxisMax() - getXAxis().getAxisMin());

yPxPerModelUnit =  getYChartSize()/(getYAxis().getAxisMax() - getYAxis().getAxisMin());

y2PxPerModelUnit =  getYChartSize()/(getY2Axis().getAxisMax() -
getY2Axis().getAxisMin());

As far as setting is concerned: you set the model to px mapping implcitly by setting
min/max of each axis, and the pixel width/height as a whole. I don't like to provide
multiple avenues for setting something (it can get confusing) but there are
exceptions to every rule.

Methods for getting the pixels per model unit are not problematical in this way, and
are easier to add, too.

Before I read your issue, I never considered that anyone would need to do this kind
of thing via GChart; my tacit assumption was everyone would just use model
coordinates for everything, think in terms of model coordinates, etc. and let GChart
handle the "to px" mapping for you. 

I'd consider adding such features to the GChart API but I'd need to be able to
understand better why you need to translate from model units back to pixels. If it's
a very rare kind of thing only a few people need to do, adding convenience methods
may not be a good idea. On the other hand... so more detail about your usage
scenario, esp. if you think its likely to be a fairly common one, would help.

Marking as "WontFix". Will change it if you come back with a convincing, reasonably
likely to be fairly common, usage scenario, that justifies new convenience methods
for this.

John

 I need to insert my chart (which is N pies) into a fixed width div.

 So I use this to get my div width which is in px

RootPanel.get("divid").getOffsetWidth();

 Plus, some of the characteristics of the pies (e.g. Radius) come from the host 
page in px also. When the host page is generated my server script can not know 
anything about the model unit.

 To figure out how many pie graphs I can fit horizontally into my width I do some 
basic calculations involving the Radius and the Width. Eventually I need to set the 
chart size and draw those N pies in several rows fitting the given width.

 So either I need to translate width and R into units and then do my calculations 
or the other way around. In either case I need a translation mechanism.

 The one you suggested should suffice, thanks.

-Alexey

 Actually I take it back. I just double checked my host page. My Radius is coming 
not in px but in model units. Which means I can not do the calculation unless I 
translate it into px. And I can not do setChartSize(divWidth, divHeight) + your 
method to get px/munit ration because Height is a result of my calculations and 
should be computed before I do setChartSize.

 Kind of chicken and egg problem.

 I guess if I change my model and make my server side script generate a host page
with radius in px I can use your suggested method.

 What is the benefit of using model units instead of px?
What does model unit give me really?

John, your suggested method does not work because getXAxis().getAxisMin()
returns infinity and getXAxis().getAxisMax() returns -infinity.

Sorry. It should work if you explicitly set the min/max axis limits before doing it.
Give that a try.

Not sure, but it sounds to me like in your example you might be better off just using
pixels for everything. To equate the model units with pixels, just explicitly set
(min, max) to (0, xChartSize) and (0, yChartSize). You might try flipping that last
spec to (yChartSize, 0) if you prefer to use traditional computer graphic coordinates
rather than Cartesian coordinates.

In other words, in your case, the pixels ARE the model units.

In general, model units allow you to work with units that make sense for your data
set (you can use temperature in degrees F rather than pixels, etc.). For pie charts,
where you are just using the x,y to position the center of the pie, there is less of
an advantage. Sometimes, even for pie charts, it may be more convenient to use model
units if you need to resize the chart. For example, you could use model units that
went from 0 to 100 (hence you could specify location of pie centers in percentages)
and independently scale the overall plot area size up or down by setting xChartSize
and yChartSize while maintaining the same relative (percentage, in this case)
positions and sizes. 

But in your example, since you already have all the specs in pixels, just make you
model units the same as the pixels.

BTW, many would prefer a series of stacked bar charts to N pies...and it's certainly
faster to render in GChart.

John

BTW, You're saying for scaling up/down my whole chart it is enough to use xChartSize
and yChartSize? It is a useful tip. I thought I'd have to remove/redraw all the symbols.

Glad that was helpful. 

Yes, that's right...sort of. There are quite a few exceptions:

First, it's only the plot area, not "the entire chart" (the title, footnotes, axis
labels, legend, etc. are obviously not impacted by xChartSize and yChartSize, given
how they are defined) that can be scaled up or down in this way. 

Also note that if you really want graphical elements to scale, you must use model
units to define their width/height, not pixel units. 

Also note that spacing and thickness settings can only be defined in pixels and thus
won't scale, either (usually that's better for most charts, but strictly speaking is
isn't scaling up or down the whole chart, as IE7's zoom feature tries to do).

Finally, note that the sizes of annotations are not impacted by xChartSize and
yChartSize--it's usually the font-size that defines your typical annotation size.

So, with all these caveats, it's a far cry from "scale up or down the whole chart",
Still, it does work like that for some charts, and for others it's close enough.
Probably easiest to just try it with your chart.

John

I actually implemented these methods in response to another request. Took me that
second request to realize the importance of this. Methods, of the axis class,
modelToClient, clientToModel, and a few others, are coming out soon in 2.41

Thanks for requesting this in the first place!

John

(No comment was entered for this change.)

See the first section of the 2.41 release notes (available via a link from
the home page) for a description of the getMouseCoordinate, clientToModel,
and modelToClient methods that address this issue.

By sharing your ideas you have materially improved GChart. Please pass
along similarly useful stuff you notice as you use GChart.

John