Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: graph hbar and (xy)common


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: st: graph hbar and (xy)common
Date   Wed, 10 Dec 2003 16:54:39 -0000

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, 
etc., etc. 

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. 

Nick 
n.j.cox@durham.ac.uk 

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 
> surrounding
> 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:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index