Re: Graph package, etc.

[Ed Frank]

Jeff wrote, in reply to my comments about Graph:


> (1) Separate sizes for text and symbols.  Since the
>     symbolsize option controls symbol sizes only,
>     Graph has this.  So I'm not quite sure where
>     the problem is here, perhaps I need to explain
>     something more clearly?  I have not written at
>     length about changing object sizes, there is just
>     the example in Section 6 ("-2p @Font @Graph").

Ah, now that I've stared at the appendix longer, I understand. Maybe.
The problem is the sentence on p.7, "More precisely, the @Graph symbol
also has a symbolsize option, whose value is the default symbol size
for the @Data symbols it encloses; and its default value is 0.15 ft."
This confused me because the example being discussed has symbolsize as
an option to @Data, and I thought you were saying that the @Graph
symbolsize was being overridden by the symbolsize command in @Data.  I
think what you mean is that symbolsize is a property of @Graph that is
inherited by all of the @Data, (the small print in the appendix :-)
but each @Data can override this with its private symbolsize, and this
has no effect on other @Data's.

> (5) Multiple axes.  I haven't mentioned it, but my
>     idea of how to get this is to overstrike two
>     graphs:
> 
>       @Graph { ... }
>       &0io
>       @Graph { ... }
> 
>     I should say so in the documentation, and I could
>     pretty it up so that &0io is written in a more
>     mnemonic way: @OverStrike, say.  There is some
>     inconvenience in doing it this way: you have to
>     give explicit xmin and xmax values, and if you
>     change the size you have to change both.  But it's
>     also very simple, you don't have to think about
>     multiple coordinate systems ever.  At present there
>     is no way to draw ticks and labels along the right
>     or top edges, but that's not a big problem.

Will overstriking work if you want multiple X axes at the bottom, a
labeled X axis at the top, and similar games with Y, all in the same
graph?  Sometimes you make a graph that has a small axis in the body
of the plot at an angle to give scale to a feature, perhaps in
separate units.  For these reasons, I like the idea of an axis plus
labels and ticks being an object that can be placed.  I've only
glanced at the code, so I don't know if this is consistent with
your design.  Actually, you frequently see "postage stamp" graphs
that are two graph frames abutted, say vertically, that have separate
Y-axes but a common X axis, e.g.,

     3 ..........................
        .                       .
     2 ..                       .
        .          *    *   *   .
        .     * *               .
     1 .. *                     .
        .                       .
        .........................
        .                       .
    30 .. +   +                 .
        .       +               .
    20 ..          +            .
        .           +           .
    10 ..            ++         .
        .               +++     .
        .........................
        .       .       .       .

                X axis

You can also abut horizontally, or make matrices.  I wonder if the
idea of the frame plus data as an object that can be abutted to
another to form a new object (of calcuable size) would help solve this
problem.


> (6) Filled regions sounds like a good idea which I
>     hadn't thought of at all.  Now that I do think
>     about it, I've seen quite a few graphs with
>     filled regions which look very good.

One mistake that other programs make to be wary of: a fill frequently
extends to the axis where it overwrites the tick marks (assume that
someone adds the ability to have tick marks face into the frame rather
than out of the frame).  I think greyscale for fills and histogram
bars goes a very long way toward a final product (instead of color).

> (7) I'm surprised by Ed's description of the histogram
>     format he needs, I don't think I've ever seen them
>     like that.  It raises the general question of how
>     to cope with everyone's specialized requirements.

It's useful when you are plotting the data from a 1024-channel
analyzer rather than grades, or any time there are many bins.

>     This is Graph's other great weakness:  it provides
>     just a fixed set of styles, whereas the GRAP program
>     that comes with troff is much more programmable (on
>     the other hand, you have to be a programmer to use
>     GRAP in that way).  Variable bin widths are there
>     right now.

As long as the design survives these thought experiments that we're
doing so that people can extend the program without gutting it, I
think this is perfectly fine.

        -Ed

-------------------------------------------------------------------------------
Ed Frank                                             Department of Physics     
Office:  (215)898-5979                               University of Pennsylvania
address@hidden                          Philadelphia, PA  USA