Re: [Camelot-discuss] Bindings librsvg

[Sven Luther]

On Tue, Feb 11, 2003 at 11:44:37PM +0100, Olivier Andrieu wrote:
Content-Description: message body and .signature
> Hop, voilà les nouveaux bindings et la version pour lablgtk2.

Mmm, la version debian de librsvg ne semble pas avoir le support gzip
par defaut, je suis en train de voir ce qu'il en est avec le
mainteneur. J'ai donc modifier ocamlrsvg de maniere a avoir un switch
GZ_SUPPORT, comme dans le patch attache. Mmm, HAS_GZ_SUPPORT serait peut
etre mieux.

BTW, jerome, qu'en est-il du CVS de camelot ? Pourrait tu creer un
module ocamlrsvg et faire un checkin du travail d'Olivier et peut-etre
creer un deuxieme module tetris, ou pouvons nous faire cela nous meme.

Sinon, pour la version lablgtk2, j'ai dus apporter quelques modifs au
patch, car a part rsvg.mli, rien n'etait installe et j'ai fait la meme
chose avec HAS_GZ_SUPPORT, quoi que ce soit une version qui ne contienne
pas rsvg_handle_new_gz, mais l'include y etait.

Ceci dis, c'est pas une idee cool d'appeler l'exemple rsvg.ml et
d'appeler le module pareil, cela confond ocaml lorsque j'essaye de
compiler. De plus, le rsvg resultant segfault, mais j'ai pas encore pus
voir pourquoi.

En tout cas, c'est genial que tu ai pus continuer le travail que j'avais
commencer et en faire de vrai binding de qualite.

BTW2, en ce qui concerne les archives d'images SVG, on pourrait imaginer
un format du genre :

  <marqueur><table><bloc><bloc>...

ou le marqueur serait la chaine : "SVGA0001" (images svg, a pour
archives, 0001 pour la version), et la table est juste un bloc speciale
contenant une table des images contenus dans l'archive.

chaque bloc est du type :

  <type><taille><donnees>

ou type est : T (pour table), S (pour image svg) ou G (pour image svgz,
donc comprime). La taille est la taille des donnees et les donnees sont
soit l'image svg, soit la version comprimer svgz.

On peut alors lire ces fichiers en les ouvrants, reconaissant le
marqueur, puis pour chaque bloc de donnee (excepte le premier, plus la
dessus apres) on lit de la position courrante a la position courante +
la taille, et on passe le tout a rsvg_render, avec l'argument optionel
gz mis si necessaire.

Pour la table, il s'agit en fait simplement d'une table indiquant le
debut et la fin d'un bloc. Ou simplement le debut du bloc, vu que l'on
peut retrouver la taille en accedant au bloc.

On peut imaginer d'optimiser cela en mettant la table a la fin (plus
facile pour rajouter des images) et en ajoutant des noms a chaque image.

Ce format, similaire a ce que Jerome proposait il me semble, permetrait
egalement de lire des fichiers sans taille, tout simplement, le premier
ou le dernier bloc serait vide (ou de type Z).

Ceci dis, on peut aussi imaginer de faire la meme chose avec un format a
base de XML.

Qu'en pensez vous ?

Amicalement,

Sven Luther