These are chat archives for sandialabs/toyplot
locator.Timestampbut it doesn't seem to want to play nice with bar plots.
Extendedtick locator favors putting ticks in “good” (in this case integer) locations. Of course, you’re free to put the edges of your bars anywhere you want (for example: if you’re displaying a histogram where the bin widths vary), in which case the default ticks won’t line-up nicely anymore.
Timestamplocator, which expects the input domain to be Unix Epoch UTC timestamps. So step one will be to explicitly specify the left and right edges of the bars, using timestamps for the periods in question. Looks like you’re already doing this.
Timestampwill choose a “good” granularity and range of ticks to cover the domain, in your case, weekly ticks over a period of a month. It assumes that the tick for a week will be located on the first day of the week, and the tick for a day will be located at midnight. That, plus possible timezone errors if you didn’t convert your bar edges to UTC, would explain the consistent offset between the ticks and your bars. I also don’t recall off the top of my head which day is considered the “first” day of the week, Sunday or Monday. See arrow for details.
Timestampin all sorts of fancy ways, to allow you to specify what part of the week to display, when displaying weeks, which day is the first day, etc. But I think that that would be confusing.
Explicitthat makes it easier for you to label the time periods you want - daily, weekly, etc.
formatparameter in the constructor
countparameter. It seems to work fine since I have a rough idea of how the dates are formatted. However this reminds me of the "horizontal legends" request from a while back - in the end I used a function in PIL (Pillow) which can give a pretty close estimate of the dimensions of text rendered in a specific font. That also seems to work really well for us. It does use PIL though - but that is an (optional) dependency of reportlab already.