[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: Documentation on scheme-files available yet?
Ernest Berkhout <email@example.com> asks what has happened to
documentation on scheme files,
> Searching for a description of the format of the Stata8 scheme files
> on Statalist I did not find anything. The only contribution that
> comes close is one of Vince Wiggins dated April 8, 2003 in which he
> announced such documentation "within 3 weeks". Is it yet available
> already but did I miss it, or was Vince maybe a bit too optimistic?
Vince was too optimistic.
In drafting the documentation, and with an eye toward questions I had been
asked about graphics, it became clear that the capabilities of the scheme
files should be expanded. Unfortunately, that means making some hard
decisions and additions to a large number of files, and what was a relatively
small project became a medium-size project, and that meant it had no longer
fit in the window I had open.
Just so there is no concern, the additions will be completely compatible with
the syntax of graphics. So, any graph commands in do-files will continue to
produce the same graphs. I am fairly confident that the additions will be
backward compatible with existing scheme files, so that the brave souls who
have ventured into writing scheme files will still be able to use those
schemes. At most they would need to make minor tweaks.
Documenting schemes is still very much on my list and is very high on that
list. I am not, however, going to predict exactly when you can expect that
documentation, not that you would believe me if I did.
Ernest goes on to ask,
> The reason I ask for this is because I came across two problems when
> I tried to make my own scheme (based on the Economist-scheme). In
> case the documentation is not yet available, does anyone out here on
> the list maybe have a guideline for me?
Let me take a stab at Ernest's specific questions. I will take the 2nd
question first, because it can be handled from the scheme.
> PROBLEM 2:
> I also fail to discover what setting I should use in the scheme file
> to produce small sized legends by default, as one does by specifying
> "legend( size (small) )". I fiddled around with
> gsize legend_key_xsize 6
> gsize legend_key_ysize medium
> but that didn't seem to do the trick. Do I have to look somewhere else?
Close. The legend_key_xsize and legend_key_ysize entries affect the size of
the key's "symbol", a color swatch for bars or areas, or an actual symbol for
scatters. In the latter case, the _xsize is ignored because a symbol of given
height has a predefined width.
To affect the text size for the key's label we set the -gsize key_label-
entry. So, what Ernest wants to specify in his scheme-file is something like
gsize key_label small
or, if he wants finer control
gsize key_label 3
If Ernest wants to also have smaller symbols, and possibly affect the overall
height of the key's "symbol"/label pair, he may want to retain his setting for
the -gsize legend_key_ysize-.
> PROBLEM 1:
> I like to have a default gridline on the topvalue of axis, like one
> would specify separately as "ylabel(, gmax)". My data values range
> from 4-15, but I extended the axis scale manually by adding:
> yscale(r(0 20))
> Gridlines are plotted at yvalues of 5, 10 & 15, but not at 20.
> Of course it would be possible to manually specify "ylabel( 5 10 15
> 20)" but that would only be an adhoc solution for this particular
> problem, whereas it is more elegant to have a more comprehensive
> solution. Is this possible?
This is not something that can be controlled from a scheme. Schemes control
how things that are drawn on a graph look, not what is drawn on the graph.
Note that yscale() affects the range of the graph without changing the axis
and it is the axis ticks that determine where the gridlines are drawn. If
Ernest wants gridlines at points where the ticks are NOT labeled, he could add
minor ticks and ask that grid lines be drawn for these ticks. For his
example we could specify the option,
ymtick(0 20, grid gmin gmax)
Ernest may still want to specify options to remove the ticks drawn by
ymtick(), or this could be controlled form the scheme so that minor ticks have
no lengths. Specifically,
gsize minortick zero
* For searches and help try: