dcharts -- library for creating charts

71 views
Skip to first unread message

shahn

unread,
Mar 25, 2013, 1:41:52 PM3/25/13
to diagrams...@googlegroups.com
Hi all!

We at zerobuzz needed a library to create charts. We didn't find anything on hackage that suited our needs so we started developing our own. It's called dcharts, it's based on diagrams, it's open-source and it's available here:

http://patch-tag.com/r/mf/dcharts

dcharts only supports two types of diagrams at the moment: barcharts and bubblecharts.

We wrote this library on the fly to fit our needs. Also it is
in a very early stage. This means that there are bugs and missing features. Some of the defeciencies have a low priority for us because they don't matter in our usecase. See our TODO-file for an incomplete list:

https://patch-tag.com/r/mf/dcharts/wiki/TODO

Despite its early stage I thought it would be useful to announce the project here and gather some feedback. So, any comments?

One thing that I find particularly interesting is the question of how to do layouting with diagrams. The way it is done currently in dcharts feels quite hacky, but I am unsure how to do it better. So any comments on that would be especially welcome.

Oh, probably some example images are in order:

http://imgur.com/JqbgHRK
http://imgur.com/wpCFeLl

Cheers,
Sönke

Felipe Almeida Lessa

unread,
Mar 25, 2013, 1:58:13 PM3/25/13
to shahn, diagrams-discuss list
Hey, Sönke!

Without having looked at the code but only at the samples (GitHub has
made me lazier :]), I'd like to say that it looks very nice! I'm also
happy to see that you're still able to work with Haskell and give back
to the community =D.

Cheers,
> --
> You received this message because you are subscribed to the Google Groups
> "diagrams-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to diagrams-discu...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Felipe.

Brent Yorgey

unread,
Mar 25, 2013, 3:20:40 PM3/25/13
to diagrams...@googlegroups.com
Cool, thanks for sharing!

On Mon, Mar 25, 2013 at 10:41:52AM -0700, shahn wrote:
>
> One thing that I find particularly interesting is the question of how to do
> layouting with diagrams. The way it is done currently in dcharts feels
> quite hacky, but I am unsure how to do it better. So any comments on that
> would be especially welcome.

Hmm, can you say a bit about the way it is currently done in dcharts,
at a high level? Actually, that's not super important, what I'm
really interested to know is what sorts of operations you want to be
able to do, regardless of how they are actually accomplished?

I think layout is certainly one of those things which we need to think
about more carefully. In particular, it's not yet clear to me whether
nice layout combinators can be provided as a library on top of
diagrams, or whether there need to be changes to diagrams itself to be
able to better support this sort of thing.

-Brent

Carter Schonwald

unread,
Mar 25, 2013, 4:44:00 PM3/25/13
to diagrams...@googlegroups.com
@byorgey,

you're absolutely right about it being unclear wrt how to do layout nice, (hopefully i have some helpful opinions on that real soon)

@shahn: 
nice job! I like the multi dimensional nature of your bubble charts! I'm taking a different approach to plotting / data vis that I should be making available mid-late april


Sönke Hahn

unread,
Mar 26, 2013, 7:04:20 AM3/26/13
to diagrams...@googlegroups.com
On 03/25/2013 08:20 PM, Brent Yorgey wrote:
> Hmm, can you say a bit about the way it is currently done in dcharts,
> at a high level? Actually, that's not super important, what I'm
> really interested to know is what sorts of operations you want to be
> able to do, regardless of how they are actually accomplished?

In our case we want to give the image a certain structure, e.g.:

title === (chartBody ||| legend)

Then we want to give certain layouting constraints, e.g.:
- the chartBody should take up 80% of the height and 70% of the width
- the complete image should have an aspect ratio of (4 : 3)
- we want to have padding spaces of 2% between the rendered elements and
between the elements and the image edges

There are lots of other kinds of constraints that might make sense in
some situations:

- An element might need to force an aspect ratio (or even size) for
itself.
- An element might need to know its aspect ratio (that was
chosen during layouting) to be able to render itself properly.
(Layouting of course would ideally know the sizes of all elements in
advance leading to cyclic dependencies.)
- Elements may have size minima (or maxima).

I am sure there other constraints you could come up with.

You asked which operations I would like to be able to perform and I am
aware that I didn't answer that question, as I am unsure myself. I hope
I have given some useful insights nonetheless.

(One very special requirement that we had for bubblecharts was this: the
chart itself and the size legend cannot be scaled arbitrarily during
layouting because, well, the sizes of the bubbles in the size legend
have to correspond to the sizes of the bubbles in the chart. But this is
a very special case and I don't expect some generic layouting operations
to account for something like this.)
signature.asc

Sönke Hahn

unread,
Mar 26, 2013, 7:06:09 AM3/26/13
to diagrams...@googlegroups.com
On 03/25/2013 09:44 PM, Carter Schonwald wrote:
> @shahn:
> nice job! I like the multi dimensional nature of your bubble charts! I'm
> taking a different approach to plotting / data vis that I should be
> making available mid-late april

I'm looking forward to that.


signature.asc

Tim Docker

unread,
Mar 26, 2013, 7:52:27 AM3/26/13
to diagrams...@googlegroups.com, Sönke Hahn
It's interesting to compare this with my existing chart library (http://dockerz.net/twd/HaskellCharts). In a typical chart we work out

- the size of the title block according to the actually text to be shown and the title font
- the size of the axes according to the axes labels, tick labels and the repective fonts

then the plot area gets whatever is left. There's also some logic to reduce the number of axes ticks if the label text ends up overlapping.
This all means that (within reason), you can change fonts or labels etc and still automatically get reasonable charts.

This seems to work better than percentages - for example you want the title block to take up just enough space to fit the actual text, not an arbitrary % of the total space.

Internally this is done with composable rendering elements, which are based upon rectangular grids and simplistic bounding boxes, not the clever envelope approach used by diagrams.

Tim

Sönke Hahn

unread,
Mar 26, 2013, 8:48:04 AM3/26/13
to Tim Docker, diagrams...@googlegroups.com
On 03/26/2013 12:52 PM, Tim Docker wrote:
> It's interesting to compare this with my existing chart library (http://dockerz.net/twd/HaskellCharts). In a typical chart we work out
>
> - the size of the title block according to the actually text to be shown and the title font
> - the size of the axes according to the axes labels, tick labels and the repective fonts
>
> then the plot area gets whatever is left. There's also some logic to reduce the number of axes ticks if the label text ends up overlapping.
> This all means that (within reason), you can change fonts or labels etc and still automatically get reasonable charts.

That's very interesting. What are ticks? The lines in the grid in the
background of the plot?

>
> This seems to work better than percentages - for example you want the title block to take up just enough space to fit the actual text, not an arbitrary % of the total space.

Well, I think there are two approaches to this, both legitimate:

1) Thinking in absolute sizes. You know what size the resulting image
should have and you know the font size. Layouting can give the plot the
remaining space. (If I understand correctly this is what HaskellCharts
does.)

2) Thinking in ratios. You don't care what size the image ends up having
when being rendered. You just want the title to take up a reasonable
amount of the image. In that case percentages are needed.

Ideally, layouting operations would allow both approaches.

> Internally this is done with composable rendering elements, which are based upon rectangular grids and simplistic bounding boxes, not the clever envelope approach used by diagrams.

Yes, for 2D-layouting the sophisticated enveloping is not (or seldomly?)
needed.
signature.asc

Tim Docker

unread,
Mar 26, 2013, 9:10:40 AM3/26/13
to "Sönke Hahn", diagrams...@googlegroups.com

On 26/03/2013, at 11:48 PM, "Sönke Hahn" <soenk...@gmail.com> wrote:

>
> Well, I think there are two approaches to this, both legitimate:
>
> 1) Thinking in absolute sizes. You know what size the resulting image
> should have and you know the font size. Layouting can give the plot the
> remaining space. (If I understand correctly this is what HaskellCharts
> does.)
>
> 2) Thinking in ratios. You don't care what size the image ends up having
> when being rendered. You just want the title to take up a reasonable
> amount of the image. In that case percentages are needed.
>
> Ideally, layouting operations would allow both approaches.
>

Yes, you probably want both approaches, but in my experience the first is more often required. When a user resizes a chart window they generally want the plot area to change in size, with the rendered size (and allocated space) of the title should stay the same.

Tim

Brent Yorgey

unread,
Mar 26, 2013, 10:20:30 AM3/26/13
to diagrams...@googlegroups.com
On Tue, Mar 26, 2013 at 12:04:20PM +0100, S�nke Hahn wrote:
> On 03/25/2013 08:20 PM, Brent Yorgey wrote:
> > Hmm, can you say a bit about the way it is currently done in dcharts,
> > at a high level? Actually, that's not super important, what I'm
> > really interested to know is what sorts of operations you want to be
> > able to do, regardless of how they are actually accomplished?
>
> In our case we want to give the image a certain structure, e.g.:
>
> title === (chartBody ||| legend)
>
> Then we want to give certain layouting constraints, e.g.:
> - the chartBody should take up 80% of the height and 70% of the width
> - the complete image should have an aspect ratio of (4 : 3)
> - we want to have padding spaces of 2% between the rendered elements and
> between the elements and the image edges
>
> There are lots of other kinds of constraints that might make sense in
> some situations:
>
> - An element might need to force an aspect ratio (or even size) for
> itself.
> - An element might need to know its aspect ratio (that was
> chosen during layouting) to be able to render itself properly.
> (Layouting of course would ideally know the sizes of all elements in
> advance leading to cyclic dependencies.)
> - Elements may have size minima (or maxima).
>
> I am sure there other constraints you could come up with.

Ah, thanks, this is very helpful! So I guess there are two possible
approaches I can see. The first is to build a library for doing
layout on top of diagrams -- e.g. have a type for "layout elements"
which contains

* some layout/size constraints, e.g. min/max dimensions, absolute
size, etc.
* a function of type (aspect ratio -> Diagram) or (size -> Diagram)
(to support things which need to know their size in order to
decide how to render).

There would then be a solver which actually does the layout ---
assigning all the elements absolute sizes, generating the appropriate The
benefits of this approach are (1) it could be made generic and used
for layout of things other than just diagrams. (2) it doesn't require
making big changes to diagrams itself.

The downside is that it might end up duplicating some logic already in
diagrams. So the second approach would be to extend diagrams to
themselves inherently have these layout/size constraints. This would
be a lot more invasive and would require much more careful thought
about the right design and API.

Personally I think the best approach would be to start with layout as
a separate library. Perhaps along the way we will discover that to do
things properly it really needs to be integrated into diagrams --- but
in that case we will already have a lot more experience + ideas about
the proper design.

In either case, this sounds like a good GSoC project! =)

-Brent

Luc TAESCH

unread,
Mar 26, 2013, 11:02:56 AM3/26/13
to diagrams...@googlegroups.com
>Personally I think the best approach would be to start with layout as a separate library

I will state something obvious, however lateral thinking cross domains :

1/ the pattern of separating content - layout ( engine) - template ( style)= layout languages  is quite well established now in typesetting / text 
like css- html - ( template) - markdown
( or docbook - docbook stylesheets.. etc) ( Latex / style/ renderers..)

2/ one can imagine having several layout languages and engines, depending on purpose and preferences, and performance. it would then be possible to have competitive layout engines and lib of layout. ( a fractal view of what exist already in diagrams , somewhat)

--------------
Luc
Envoyé avec Sparrow

Le mardi 26 mars 2013 à 15:20, Brent Yorgey a écrit :

Reply all
Reply to author
Forward
0 new messages