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.
sprawdz xml/swf charts jeszcze.
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.
Jakby były bardziej webdwazerowe jeszcze, lol ;D
@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.
A tak zagaję przy okazji… 10p ma jakąś awarię od tygodnia?
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.
No prawie ładne, tylko żeby takie poszarpane te wykresy nie były…
Właśnie, trochę AA brakuje. Może pycairo zamiast PIL?
A tak w ogóle to dlaczego zdecydowaliście sie na Pythona + Django, a nie np na Railsy?
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).
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?
http://www.mps.mpg.de/dislin/
Ale DISLIN jest paskudny. ;]
Ja też optowałbym za cairo, szczególnie że takie rozwiązania wyglądają tam estetyczniej dzieki aa.
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.
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.
“)…) 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 :-)
Eeee… AA poprzez oversampling jest całkiem niezłym pomysłem i dla grafiki działą dość dobrze. :)
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 :-)