Graph package, etc.

[Jeff Kingston]

Thanks to Ed Frank for his comments on Graph.  Here
is my response.  As usual, comments are very welcome.

(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").

(2) Arbitrary objects in captions.  Yes, the appendix
    makes clear that this is so, and I can and will
    mention it in the body of the document, since
    Ed has raised it.
    
    Graph's great weakness is that you can't have
    arbitrary Lout objects inside the @Data symbol
    (say, in the points option), nor as axis labels
    (in the xticks and yticks options), hence the
    need for the objects option.  Not ideal, but
    seems inevitable.

(3) Encapsulation is no problem.  Basser Lout has
    a -EPS command line flag which causes its output
    to be produced in the form of a PostScript EPS
    file.  In this case the input would need to be
    something like

        @SysInclude { ft }
        @SysInclude { graph }

        { Times Roman 12p } @Font
        { 1.2fx adjust } @Break
        @Graph
        {
           ...
        }

    The DocumentLayout package would just get in
    the way, sticking in margins and page numbers
    and stuff.  The whole document here consists
    of one rectangle containing the graph.

(4) Clipping the y ticks and labels.  This is
    certainly feasible; I'll have to think about it.
    Ideally Lout should know the true width, but
    that is regrettably impossible since it's not
    known until print time.  There is also the
    hidecaptions and centring issue to consider.

(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.

(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.  Arbitrary
    intersections sounds like trouble, but the basic
    feature is easy and you get unions for free by
    doing it to two sets of data.  So I think I will
    add this feature.  I should really add colour as
    well, but this must wait until I've added colour
    to Basser Lout (will be done in the next release).

(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.
    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.

I see that people are ganging up against me on the matter
of white space.  Certainly it would not be hard to add a
TeX-like space munching style to the style information,
alongside the font, paragraph breaking, and hyphenation
style information.  But how would you get two spaces
between sentences then?  If the answer is to define .
to be "." &2s and similarly for ! and ? (quite feasible),
you get two spaces after Mr. too.  I don't think this is
a good design at all, I think it's unnecessarily complicated
and means that the user has to learn things about how to
deal with the exceptional cases.  Of course, TeX users have
already learned these things, but the rest of us don't want
to.  Prove me wrong about this if you can!

Jeff Kingston