font support

13 views
Skip to first unread message

Simon Ilyushchenko

unread,
Jun 2, 2009, 5:29:41 PM6/2/09
to py...@googlegroups.com
Hi,

Pycha works very well for my needs, but one thing I can't fix with Python hacking is font selection. I generate bar charts on a Linux system, and even though I'm telling pycha to use 11 pt Arial, the resulting font is not very Arial-ish compared to the browser fonts (I guess FF on Linux uses FreeType fonts). See attached file for an example.

I realize that pycha uses Cairo whose docs describe a bunch of font-related API, but I'm not really familiar with font hacking, so I don't see an easy way out. Is there a way to use the same fonts as FF? Or can I do something simple like turn on antialiasing to generate better results?

Thanks,
Simon
1990_Aggregate_GHGs_AUS_total.png

Lorenzo Gil Sanchez

unread,
Jun 6, 2009, 2:44:32 PM6/6/09
to py...@googlegroups.com
Hi Simon,

as you already said, this is more a Cairo question than a Pycha one,
even if this is the right place to ask it as you are having problems
with Pycha. I recommend you to fill an issue in Pycha ticket system so
we can work it out your problem and don't forget about it. Frankly, I
just don't know right now how to load a custom ttf file in Cairo.

Best regards,

Lorenzo

2009/6/2 Simon Ilyushchenko <sim...@gmail.com>:

Simon Ilyushchenko

unread,
Jun 16, 2009, 2:53:54 PM6/16/09
to py...@googlegroups.com
Lorenzo,

Thanks for the response. I've filed http://bitbucket.org/lgs/pycha/issue/4/better-font-support

I have made a few changes to pycha code to generate the exact bar charts that I wanted: callbacks to format bar and tick labels, slightly different offsets for bar labels, tuning of tick placement and an option for not hiding bars with small values. What's a good way to try to incorporate them back? Can I send you an svn diff?

Thanks,
Simon

Lorenzo Gil Sanchez

unread,
Jun 16, 2009, 5:35:38 PM6/16/09
to py...@googlegroups.com
Hi Simon,

thanks for the bug report. I'll try to take a deeper look at it as soon as I can.

About your changes you can do any of this (from best to worse):

  - Clone the repository with Mercurial, apply your changes and ask me for a pull using Bitbucket
  - Split your diff in funcional pieces so I can review them independently and merge them into the main repository
  - Just pass me your big-fat-diff :-)

The easier to review your changes, the sooner you'll get feedback from me.

Best regards and thanks for your interest!

Lorenzo

2009/6/16 Simon Ilyushchenko <sim...@gmail.com>

Simon Ilyushchenko

unread,
Jun 26, 2009, 2:08:55 AM6/26/09
to py...@googlegroups.com
Lorenzo,

On Tue, Jun 16, 2009 at 2:35 PM, Lorenzo Gil Sanchez <lorenzo.g...@gmail.com> wrote:
Hi Simon,

thanks for the bug report. I'll try to take a deeper look at it as soon as I can.

About your changes you can do any of this (from best to worse):

Here's my Merc repository with changes to bar.py and chart.py applied: http://www.simonf.com/mercurial/pycha/. Let me know what you think. 

I've made all additions optional, so by default all charts would keep the old behavior , except for adding of the "round(,prec)" call for the "self.options.axis.y.interval > 0" case in chart.py for consistency with the next branch "self.options.axis.y.tickCount > 0". However, for this and other changes, I'm happy to apply them any way you want - I just want them to be committed.

Thanks,
Simon

Lorenzo Gil Sanchez

unread,
Jul 2, 2009, 5:21:46 PM7/2/09
to py...@googlegroups.com
Hi Simon,

I have pulled your changes and review them. They look pretty good but
there is something else I'd like to ask you: it would be great if you
can add an example to the examples directory that use your features.
Specially I'd like to see examples of the renderExpr option.

Best regard,

Lorenzo

2009/6/26 Simon Ilyushchenko <sim...@gmail.com>:

Lorenzo Gil Sanchez

unread,
Jul 12, 2009, 2:56:06 PM7/12/09
to py...@googlegroups.com
Hey Simon,

I've finished reviewing your patch. Some comments:

- The renderExpr option is very useful in the yval option group but
it is redundant in the axis.y option group because you can simulate
the same behaviour using the axis.y.ticks option. I think you already
know this because that's how you make it in your example file.
- I changed the snapToLeft option name to snapToOrigin and made it
work for Vertical Bars too. It's a little bit more generic this way.
- I don't think you need the keepLabelsInside option since the
snapToOrigin and inside options have a similar use.

Other than at and with small stylish changes I have integrated your
changes into the main repository. Thanks a lot for your contribution!

Best regards,

Lorenzo

2009/7/3 Simon (Vsevolod) Ilyushchenko <sim...@simonf.com>:
>
> Lorenzo,
> Here you
> go: http://www.simonf.com/mercurial/pycha/examples/custombarchart.py
> The generated image is http://www.simonf.com/pycha/custombarchart.png
> I've used several of the new features to illustrate them.
> Simon
>
> On Thu, Jul 2, 2009 at 2:21 PM, Lorenzo Gil Sanchez

Simon Ilyushchenko

unread,
Jul 14, 2009, 2:39:03 AM7/14/09
to py...@googlegroups.com
Thanks, Lorenzo!

On Sun, Jul 12, 2009 at 11:56 AM, Lorenzo Gil
Sanchez<lorenzo.g...@gmail.com> wrote:
>
> Hey Simon,
>
> I've finished reviewing your patch. Some comments:
>
>  - The renderExpr option is very useful in the yval option group but
> it is redundant in the axis.y option group because you can simulate
> the same behaviour using the axis.y.ticks option. I think you already
> know this because that's how you make it in your example file.
>  - I changed the snapToLeft option name to snapToOrigin and made it
> work for Vertical Bars too. It's a little bit more generic this way.
>  - I don't think you need the keepLabelsInside option since the
> snapToOrigin and inside options have a similar use.

Actually, my option is confusingly named - it should be
keepTicksInside. The 'inside' option is indeed working well for
labels, but there is no way to keep the ticks inside the image area -
I just tried running with the latest version of pycha and saw this
problem again. Please reevaluate.

Thanks,
Simon

Reply all
Reply to author
Forward
0 new messages