Re: [PyX-devel] Re: [PyX-user] bar chart x-axis custom labels

[Andre W. <wo...@us...>]

Hi Pieter,

On 03.02.05, pieter claassen wrote:
> A few questions if I may (this might be answered earlier in the list, so
> tell me to stop if that is the case):

I think we've never distributed that kind of knowledge. Some things
are described (more or less) at various places, but let me just give
some answers to your questions right away ...

> 1. How does pyx make use of TeX? What is the integration and purpose of
> the integration?

PyX starts a (La)TeX instance as soon as it needs to typeset some
text. PyX can't typeset text without TeX, so the purpose of the TeX
integration is to be able to insert text into the output.

PyX typesets the requested text in a box, analyses the box extents and
writes the box content into TeX's dvifile on a separate page for each
box. Later on it can read the information from that page and insert
the appropriate PostScript code into the output.

> 2. What is the basic idea behind the library design? I can see from the
> documentation the basic workflow, but what about the underlying principles
> for the implementation?

Well, PyX is just a collection of usefull stuff:

  - a canvas to paint on
  - paths with various features (splitting, intersection, etc.)
  - decorators which assign stroke or fill operations (and other
    things) to paths
  - attributes for the stroke or fill operations (like colors etc.)
  - deformers to modify paths (like transformations)
  - graphs built on top of that features

Graphs themselfs are constructed out of various components:

  - graph.graph takes care about the geometric arragement
  - graph.data contains classes to define graph data (by reading from
    a file or calculating it from a function etc.)
  - graph.style contains graph styles (lines, symbols, etc.)
  - graph.key to create graph keys
  - axis for the conversion of data values to graph coordinates (graph
    coordinates are fixed to the interval 0..1)

The axis are build out of various components themself:

  - graph.axis.axis does the conversion and global bookkeeping
  - graph.axis.tick are ticks to be placed on axes
  - graph.axis.parter calculates ticks for a given axis range
  - graph.axis.texter creates the label text to be placed at the ticks
  - graph.axis.painter paints the whole axis

May I've missed the one or the other, but that's the basic technology.
The idea is to plug everything together to make it working ... ;-)

> As to labels and tics: This I think is a difficult subject because in many
> libraries it is not an easy subject and the implementor requires a
> significant amount of knowledge to do anything other than use defaults. To
> make it more user friendly, I have the following suggestions (and will
> help implement where I can)
> 1. To develop a number of use-cases and appropriate examples for manual
> overried that include:

We intent to use examples for that. Those are complete usecases and
they work as functional tests for us. That's why we try to keep
comprehensive examples out of the manual ...

> 1.1. Example of no labels on all types graphs

Several possibilities here: The most easiest variant would be to just
suppress the painting of the labels. Set the labelattrs of the painter
to None ... that's it. You could also create parters which place ticks
at the axis, but no labels.

> 1.2. Example of manual labels on all types of graphs

Set the parter to None and use manualticks.

> 1.3. ...

There will be answers to that too ... ;-)

> 2. Would it be possible to provide a manual override parameter to all axis
> that allows users to provide a list of values or [[value,label],..] that
> will then be converted to chart-coordinates and plotted at value location
> on the axis? This would provide ultimate flexibility.

manualticks does that. But you can also use the axispos methods to get
positions at the axis and do whatever you want:

    ...
    g.dolayout()
    x, y = g.axespos["x"].tickpos(100)
    g.text(x, y, "here we are")

Note that a specialized painter would be able to do such things as
well and by that you can plug-in your needs into the graph design.
I.e. the solution as shown above will almost always be total crap,
although it might look as the most easiest and simplest way to get
your needs done in the first. But its only the most simplest way if
you need it only a single time. As soon as you want to use this twice,
a painter will save you time ...

> I have been thinking about a first set of requirements for the histogram
> class and here is my stab at them.
> 
> REQUIRED
> 1. To plot steps like gnuplot.

This is absolutely trivial to implement, but my concerns are, that you
need to adjust the data to what's needed by the plotting system and
not vice versa ...

> 2. To plot multiple series on a graph.

Use several plot commands on a graph or use a list of data in a single
plot command.

> 3. To provide manual overrides on the x-axis.

manualticks will do ...

> 4. To cater for both continuous as well as discreet x-values (this again
> is a little unclear but I can imagine that not all statistical sampling
> would be agains continues values)

Well, there are continous variables and those which aren't.
Non-continuous variables are for example "Germany", "US", "Japan",
"Russia" ... to be used on a bar graph. Continous variables are
numbers. Sure you can use integer numbers as discrete variables, but
that's almost always a misuse. Also times and dates are usually
continuous variables, although, in some usecases days of months or
such are used as discrete variables.

A histogram should be build on continous variables. I don't think its
worth a discussion ...

BTW: you can use continous and bar-graph axes in the same graph. PyX
is able to handle an arbitrary number of axes for each graph
dimension.

> DESIRED
> 1. To provide the facility to swap axis (this I cannot justify, but can
> imagine that it would be valuable.

Definitely. A graph style should never take into account the axis
names and the ordering of the different axis dimensions. A graph style
does not know anything about the graph layout ... and then x and y
axes are exchangeable in the style without any additional efforts ...

> http://en.wikipedia.org/wiki/Histogram

Nice idea to look into the wikipedia. It exactly shows the whole
problem of a histogram: To fully describe a histogram, you need three
informations per data point: a position, a width and a hight. The only
problem is, that typically you do not have all the three informations
kept in a data file. Thats why I don't know how to implement such a
style. That's all. So we're back on my original question: What data
should we start with?


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/