So, bar() does what I need. There is still one somewhat
> weird thing, however: barh() (as the barv() I wrote based
> on barh()) works with the *centers* of the bars
> (y-coordinates for barh(), x-coordinates for barv())
> whereas bar() expects the *left* x-coordinates of the
> bars in its first argument. This is not a drama, but a
> bit inconsistent.
Yes, this is a historical artifact. bar was implemented first (and
wrong) and the coords represented left rather than center. barh came
along later and decided rather than follow bar's mistake lead (a
foolish consistency and all that), it would do it right and bar could
be fixed later in a way that hopefully preserves backward
compatibility (eg an rc param and a warning) for a while.
This would all be fairly trivial except table is based on bar, and the
table layout is pretty complex. I "fixed" bar but broke table, and
seeing no easy fix, unrolled the changes to bar. And that is where I
left this problem last time I looked.
Would you mind filing a bug report on the sf site, with example code
that shows the different behaviors of bar and barv, including a link
to this discussion.