Długo szukaliśmy sensownej biblioteki, która pozwoli nam narysować prosty wykres kołowy, nie zajmuje pół mega i w trakcie działania nie uruchamia zewnętrznego konwertera PostScriptu. Idealny kandydat powinien do tego mieć sensowne API.
W końcu znudziło mi się szukanie i siadłem do klawiatury. Przypomniałem sobie o świetnej bibliotece libchart, której używamy w Wego CMS i postanowiłem ją odtworzyć w Pythonie.
Powyżej widać efekt 3 godzin mojej pracy. Kod do działania wymaga Python Imaging Library i jest objęty licencją LGPL.
Pobierz ze strony projektu i podziękuj firmie ITS Ltd. za jego sfinansowanie ;). Wersja 0.0.1 oferuje tylko wykresy kołowe, pozostałe typy pojawią się w miarę potrzeb naszych klientów.
by kodz
06 cze 2007 at 12:44
sprawdz xml/swf charts jeszcze.
by Patrys
06 cze 2007 at 12:47
Nie zamierzam uzywać Flasha do wykresów i tłumaczyć klientom, dlaczego na którymś komputerze się nie pokazują (flashblock / adblock / brak flasha). Poza tym, wykresów flashowych nie osadzę sobie z poziomu Pythona w PDF.
by Crash
06 cze 2007 at 13:14
Jakby były bardziej webdwazerowe jeszcze, lol ;D
by sit0
06 cze 2007 at 13:37
@Patrys: ty nie zamierzasz, ale ostatecznie na stronie i tak wyląduje pewnie xml/swf chart z maani.us (bo ma antyaliasing i się animuje, a to podoba sie end-userom ;) — twoja biblioteka przyda się(*) do wyczesanych wydruków, gdzie nie da się osadzić flasha, zresztą gadaliśmy o tym wczoraj. Co prawda wciąż nie wiem, kto potrzebowałby w tym projekcie drukowanych wykresów (a czy w ogóle miałyby sens to inna kwestia), ale i tak dostarczamy klientom pdf. Zważywszy masową klientelę, friki które by to chciały się znajdą.
Pogadaj z Lukiem o google gears (wprowadziłem go w temat wstępnie), jeśli uda nam się to przepchnąć przed release 1.0 to będzie przełom w aplikacjach tego typu ;)
(*) — odpuście sobie polemikę, to jest wypowiedź związana z dość napiętym projektem który realizujemy.
by byte
06 cze 2007 at 14:05
A tak zagaję przy okazji… 10p ma jakąś awarię od tygodnia?
by Patrys
06 cze 2007 at 14:08
byte:
Ma awarię, wygląda na to, że jeden skrypt PHP zdycha bez żadnego komunikatu w momencie wywoływania XML RPC. Ja za to od 1. marca nie mam dostępu do internetu w domu.
by Lukasz Horodecki
06 cze 2007 at 14:29
No prawie ładne, tylko żeby takie poszarpane te wykresy nie były…
by jpc
06 cze 2007 at 14:43
Właśnie, trochę AA brakuje. Może pycairo zamiast PIL?
by Sebastian
06 cze 2007 at 18:49
A tak w ogóle to dlaczego zdecydowaliście sie na Pythona + Django, a nie np na Railsy?
by Patrys
06 cze 2007 at 18:53
Sebastian:
Z wszystkich języków, jakie znam, Python leży mi najbardziej (chociaż czasem zdarza mi się użyć podświadomie składni Rubiego i potem się dziwię, że nie działa).
by Sebastian
06 cze 2007 at 20:00
Rozumiem, tak pytam bo właśnie szukam czegoś czym mógłym zastąpić php
i waham sie właśnie miedzy ruby (railsy) i pythonem (djanogo). Wiem ze Ty kiedyś robiłeś w php. Jakieś obserwacje po przejsciu na pythona?
Faktycznie dużo lepiej/szybciej się pisze?
by x
06 cze 2007 at 21:19
http://www.mps.mpg.de/dislin/
by jpc
07 cze 2007 at 13:15
Ale DISLIN jest paskudny. ;]
by sprae
07 cze 2007 at 14:38
Ja też optowałbym za cairo, szczególnie że takie rozwiązania wyglądają tam estetyczniej dzieki aa.
by Brut[all]
08 cze 2007 at 12:31
W PIL’u można to wygladzić, tworząc początkową grafikę o większych rozmiarach, a potem resamplując ją z AA do wyjściowej. Ale takie rozmiarowanie w PIL’u zżera trochę mocy.
by jpc
08 cze 2007 at 21:53
Brut[all]: Zdaje się też, że ta metoda nie zadziała najlepiej dla tekstu (ale ok dla grafiki), więc trzeba by opisy dokładać po skalowaniu.
by Brut[all]
11 cze 2007 at 00:49
”)…) więc trzeba by opisy dokładać po skalowaniu.”
Co chyba nie jest wielkim problemem.
Oczywiście nie jest też chyba dla nikogo żadną tajemnicą, że to rozwiązanie bardzo na około i generalnie do dupy :-)
by jpc
11 cze 2007 at 10:49
Eeee… AA poprzez oversampling jest całkiem niezłym pomysłem i dla grafiki działą dość dobrze. :)
by L Grad
12 cze 2007 at 10:40
Mi sie sama idea podoba. Ktos kiedys powiedzial, ze Rzym (czy Krakow jak kto woli) wasn’t built in one day. Stad zdecydowanie za wczesnie by porownywac to z czymkolwiek, jednak… ilosc projektow w jakich potrzebna jest takowa biblioteka moze przyczynic sie do jej rozwoju :-)
Pingback
by Python: libchart 0.0.3 at Room 303
21 cze 2007 at 20:42
[…] pojawiła się obiecana potrzeba i tak powstała trzecia wersja biblioteki do generowania wykresów. Tym razem nie wymaga PIL i […]