[Perl Module] SVG graphics - RFC

[Juup]

Request for Comment

Er is voor Perl geen goede module om grafieken te maken. Nu ben ik zelf een module aan het maken die grafieken in het SVG formaat (Scalable Vector Graphics, van w3.org) kan maken. Je stopt er een paar arrays met x- en y-waarden in en hij maakt er een grafiek van, zoals oa ook gnuplot dat doet. Hij komt ook in CPAN maar voor dat het allemaal zover is zou ik graag wat commentaar / ideen voor verbetering van jullie willen. Om dt te gebruiken heb je wel een svg viewer nodig bv van Adobe.

Kijk dan eens op http://pearlshed.nl/cgi-bin/graph.svg

De source van de module en een progje dat het gebruikt:
http://pearlshed.nl/SVGGraph.pm
http://pearlshed.nl/graph.svg <- rechtermuis, save as...

Alles is nog alpha dus ook de interface kan (en zal) nog wijzigen.

[Killemov]

Ziet er uit als 'een standaard grafiekje' en dat is helemaal goed.

[tomato]

Over je code heb ik zo direct niet veel op te merken, maar heb je misschien dit over het hoofd gezien

En waarom gebruik je geen XML::* modules, maar bouw je de XML 'met de hand' in strings op?

[Juup]

Op dinsdag 09 juli 2002 23:05 schreef tomato het volgende:
Over je code heb ik zo direct niet veel op te merken, maar heb je misschien dit over het hoofd gezien

En waarom gebruik je geen XML::* modules, maar bouw je de XML 'met de hand' in strings op?

Die modules bieden erg weinig voordelen. Ik heb er even vluchtig naar gekeken maar grafiekjes zijn vrij specifiek en er gemakkelijk met de hand erin te zetten. Het kan natuurlijk wel.
Meer specifiek: die modulen bieden een "perl manier" om met xml resp. svg om te gaan. In dit stadium wil ik alle controle over m'n output.

Bedankt voor je commentaar.

[mbravenboer]

Jaaap: Meer specifiek: die modulen bieden een "perl manier" om met xml resp. svg om te gaan. In dit stadium wil ik alle controle over m'n output.

Een XML library beperkt je als het goed is helemaal niet. Je bouwt daarmee juist XML op door informatie te verschaffen over de inhoud van het XML document. Je hoeft je hierdoor niet met serializatie details bezig te houden als escaping en well-formedness. Als je een XML library gebruikt is je output gegarandeerd well-formed en dat is goed.

Ik kwam vandaag dit stukje tegen over XML generatie, waar dit idee terugkomt:

http://www.javazoom.net/services/newsletter/xmlgeneration.html

[Juup]

Op dinsdag 09 juli 2002 23:48 schreef mbravenboer het volgende:
Een XML library beperkt je als het goed is helemaal niet. Je bouwt daarmee juist XML op door informatie te verschaffen over de inhoud van het XML document. Je hoeft je hierdoor niet met serializatie details bezig te houden als escaping en well-formedness. Als je een XML library gebruikt is je output gegarandeerd well-formed en dat is goed.

Ik kwam vandaag dit stukje tegen over XML generatie, waar dit idee terugkomt:

http://www.javazoom.net/services/newsletter/xmlgeneration.html

Dus ik ben de "XML novice developer". Okee ze hebben een punt maar toch. Als er dan iets verkeerd gedispllayed zou worden zou het ook nog aan die XML modules kunnen liggen. Misschien converteer ik het later naar XML:: dingen.

[mbravenboer]

Jaaap: Dus ik ben de "XML novice developer".

Tja, je bent nooit te oud om te leren moet je maar denken .

Als er dan iets verkeerd gedispllayed zou worden zou het ook nog aan die XML modules kunnen liggen.

Het voordeel van een apart component is dat je dan een nieuwe versie kan downloaden waar dit waarschijnlijk in gefixed is . De kans is overigens wel erg klein dat een stabiele XML lib zo'n fout zou maken.

[tomato]

De bekende XML libs voor Perl wordt erg veel gebruikt en worden al heel erg lang als zeer stabiel beschouwd. Daar zul je dus niet veel foutjes meer in vinden.

Het grote voordeel is dat je op die manier absoluut gegarandeerd bent van een well-formed XML document en dat is meestal erg belangrijk.

[raptorix]

Als het voor webcontent is zou je ook eventueel kunnen denken over flash/java als output, van de week vond een collega van mij een schitterend java ding wat perfect werkte, daarnaast zijn er voor flash ook goede alternatieven

[Juup]

Op donderdag 11 juli 2002 02:18 schreef raptorix het volgende:
Als het voor webcontent is zou je ook eventueel kunnen denken over flash/java als output, van de week vond een collega van mij een schitterend java ding wat perfect werkte, daarnaast zijn er voor flash ook goede alternatieven

Flash zou een optie kunnen zijn. Java niet. Ik heb er nog niet naar gezocht maar weet iemand hoe je flash maakt? Ik zal eens bij macromedia kijken. Of is dat een gesloten formaat?

[Juup]

Oh nog wat, hij staat nu in cpan.
En zodra ik een goede namespace heb (misschien SVG::Graph) komt ie daar ook onder te staan.

http://www.cpan.org/authors/id/T/TE/TEUN/

[Bart B]

Wat denk je van APACHE met PHP en de GD-libaries Kun je ook gebruiken om plaatjes te genereren.

[edit] AU... knijp mezelf ff Wakker

Ah... Ow... Wel leuk. Maar waarom geen PHP en GD? SVG wordt nog niet universeel ondersteund
sry voor brak kommentaar van mijn kant

[Juup]

Op donderdag 11 juli 2002 23:17 schreef Bart B het volgende:
Wat denk je van APACHE met PHP en de GD-libaries Kun je ook gebruiken om plaatjes te genereren.

Ehh.. ik probeer niet de indruk te wekken dat ik op zoek ben naar manieren om een plaatje te displayen.

Dit is niets meer dan een lightweight module om grafieken te tekenen in het svg formaat.

[raptorix]

Uhm Jaaap de flash grafiekjes die ik gezien heb werken juist zo dat ze een webfile in lezen en met die data als het ware een grafiek tekenen, de flash zelf verandert in principe niet, kan natuurlijk wel maar dan maak je je zelf nogal moeilijk.

[Juup]

Op donderdag 11 juli 2002 23:28 schreef raptorix het volgende:
Uhm Jaaap de flash grafiekjes die ik gezien heb werken juist zo dat ze een webfile in lezen en met die data als het ware een grafiek tekenen, de flash zelf verandert in principe niet, kan natuurlijk wel maar dan maak je je zelf nogal moeilijk.

Okee maar dit gaa buiten de scoop van mijn module.

[mbravenboer]

Apache heeft trouwens tijden een platform-onafhankelijke plugin, geschreven in Java, om SVG op te nemen in je web-pagina. Het is dan dus wel een Java Applet. Misschien dat je daar nog iets mee kan: de implementatie schijnt vrij aardig te zijn.

Batik dus .
Ook kan Batik SVG omzetten naar PNG en dergelijke.

Via FOP kan je ook SVG gebruiken in een XML document om het daarna via XSL Formatting Objects te rendereren naar bijvoorbeeld PDF.

[Soultaker]

Op vrijdag 12 juli 2002 00:50 schreef mbravenboer het volgende:
Ook kan Batik SVG omzetten naar PNG en dergelijke.

Dat elimineert het nut van SVG natuurlijk een beetje, aangezien 'ie dan alsnog moet gaan rasterizen.

Ik vind het trouwens niet echt een optie maar een vereiste om van bestaande, beproefde libraries gebruik te maken, als deze voorhanden zijn. Dat betekent dat je in ieder geval je XML data op zou moeten bouwen met behulp van de bijbehorende Perl module. Of de SVG module volwassen genoeg is om van dienst te zijn, zou ik niet weten, maar de kans is zeker aanwezig.

Ik krijg het vermoeden dat je bij het opzetten van dit project niet eens hebt gekeken of sommige componenten al bestonden. De kracht van Perl (en eigenlijk elke 'krachtige' programmeertaal) is het feit dat voor de meest krankzinnige dingen goede modules bestaan, zodat je niet elke keer het wiel opnieuw hoeft uit te vinden.

Als iedereen zijn eigen XML generator schrijft en er komt ooit een aanpassing in de XML specificatie, moet iedereen zijn generator aanpassen (aangenomen dat die allemaal onafhankelijk van elkaar correct werken). Met een standaardlibrary beperk je de invloed van zo'n wijziging tot een enkele module.

[mbravenboer]

Soultaker: Dat elimineert het nut van SVG natuurlijk een beetje, aangezien 'ie dan alsnog moet gaan rasterizen.

Inderdaad, het is ook maar 1 van de vele opties van Batik, waarbij ik deze alleen maar in het bijzonder noemde omdat PNG vaak sexy wordt gevonden .

Batik heeft ook gewoon een viewer bijvoorbeeld, die je kan integreren in Java applicaties, waardoor je dus gewoon SVG graphics kan opnenem in je applicatie. Ook FOP heeft zo'n component, waardoor je dus mooi opgemaakte stuff in de applicatie kan opnemen. Ziet er erg yummie uit .

Ik vind het trouwens niet echt een optie maar een vereiste om van bestaande, beproefde libraries gebruik te maken, als deze voorhanden zijn.

Hierbij (en bij alle voordelen die je noemde) moet ik me volledig aansluiten .

[Juup]

In het algemeen zou ik je ook gelijk moeten geven wat betreft het gebruik van andere modules.

Alleen heb ik het hier niet gedaan omdat het hier zo onnodig is (de browser/svg plugin controleert de validiteit van m'n xml) en omdat ik niet wil dat de gebruiker allerlei extra 'rommel' moet installeren (vind ik vervelend) en omdat het meer resources gebruikt (modules in geheugen laden) en omdat het ZO SUPER SIMPEL is om wat svg code weg te schrijven.

Mensen doen te moeilijk over xml. Gebruik jij een aparte module als je iets in een csv file wegschrijft? (comma separated values - file)