[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
RE: st: graph hbar and (xy)common
I sign up to the irritation here, and I vote for
coherent, well-designed displays every time, as
everyone would, but I can't follow Allan in his certainty.
There are perhaps about three people in StataCorp
who can address this authoritatively; the rest of
us can swap guesses based on whatever experience
we have. Mine includes a certain amount of poking
around with Stata graphs, but doesn't include
any deep class stuff with the new graphics.
In broad terms:
You can write graphics programs giving users,
in principle and in practice, complete control over exactly
where everything goes. Indeed, Stata has one -- and Allan
knows this, because he's done some programming with it --
and it is called -gph-. The problem with -gph- is that if you
want that control, you can have it, but you
really get (almost) all the responsibility, and have
to re-create all sorts of stuff you would otherwise
take the granted, to do say with titles, labels, legends,
The new graphics is just not written that way at
all. It is designed in a completely different
manner, and designed to protect users from the need
to worry about the low-level stuff as far as possible.
There is plenty of scope, of course, for worrying
about medium- and high-level stuff. Or, to put it
more positively, the new graphics provides all sorts
of handles that users want that just did not exist
before Stata 8 (other than through -gph-).
And mutual ignorance on the part of the different
graph elements is not a misfeature; it's key
to how things are done.
However, and here's the crunch:
Once you start changing the design by introducing
options to fix things in absolute coordinates
as well, it's my guess that's way beyond "not
difficult"; it's out of the question in terms
of the resulting complexities for programmers,
and ultimately for users.
R. Allan Reese
> I agree. I have reported this problem to Statacorp. The plotting
> region is determined by the shape and size of labels in the
> graph region. Just fixing the format of labels does not
> correct this,
> since the label mechanism determines the length according
> to the value
> and then draws it left-justified. Commands that happen to
> align the
> axes if the label values are the same for each graph will
> fail if, say,
> one graph label has an extra digit or a minus sign.
> This is very irritating. It seems clear to me that the expected
> operation of "graph combine" in a column or row should be
> to align the
> axes. Arrays with the axes higgledy-piggledy just look
> poor. Visually
> aligning the axes on a screen does not guarantee they are
> aligned to
> printer precision and is impractical for other than one-off tasks.
> What is needed is a graph-region-option to fix the origin
> in absolute
> coordinates. Not difficult.
* For searches and help try: