camelot-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Camelot-discuss] Bindings librsvg


From: Sven Luther
Subject: Re: [Camelot-discuss] Bindings librsvg
Date: Wed, 12 Feb 2003 11:25:32 +0100
User-agent: Mutt/1.5.3i

On Wed, Feb 12, 2003 at 11:14:48AM +0100, Olivier Andrieu wrote:
>  > En fait, j'avais oublier le USE_RSVG, mais meme avec cela, il ne savait
>  > pas comment compiler le .cmi. J'ai rajouter :
>  > 
>  > ------------
>  > --- lablgtk2-0.alpha.20030210b/src/Makefile     2003-02-12 
> 10:41:43.000000000 +0100
>  > +++ ../lablgtk2/src/Makefile    2003-02-12 09:13:19.000000000 +0100
>  > @@ -212,6 +228,15 @@
>  >  xml_lexer.ml: xml_lexer.mll
>  >         ocamllex xml_lexer.mll
>  >  
>  > +rsvg.cmo: rsvg.ml rsvg.cmi
>  > +       $(COMPILER) rsvg.ml
>  > +
>  > +rsvg.cmi: rsvg.mli
>  > +       $(COMPILER) rsvg.mli
>  > +
>  > +rsvg.cmx: rsvg.ml rsvg.cmi
>  > +       $(COMPOPT) rsvg.ml
>  > +
>  >  varcc: varcc.cmo
>  >         $(LINKER) -o $@ $<
>  >         rm -f *_tags.h *_tags.c
>  > ------------
>  > 
>  > A src/Makefile.
> 
> Pas besoin. Il fallait faire un `make depend' pour mettre à jour le
> fichier de dépendances.

Mmm, je vais voir cela.

>  > >  > 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. 
>  > > 
>  > > Oui, je m'en suis rendu compte après. Mais ça marche bien avec le
>  > > toplevel : labkgtk2 rsvg.ml truc.svg
>  > > 
>  > >  > De plus, le rsvg resultant segfault, mais j'ai pas encore pus voir
>  > >  > pourquoi.
>  > > 
>  > > Chez-moi-ça-marche. Tu as pensé à linker gtkInit.cmo ?
>  > 
>  > Non, j'avais oublier, et en plus, il faut le mettre avant rvsg2.ml
> 
> Oui, mais c'est comme n'importe quel programme qui utilise lablgtk.

Oui.

quoique c'est dommage qu'on puisse pas reutiliser le nom pour l'exemple
aussi.

Est-ce que tu soumet le patch a Jacques, ou alors est-ce que tu veut que
je le fasse ?

>  > > Je comprends pas bien pourquoi vous vou prenez la tête à ce sujet
>  > > alors qu'on a déjà camlzip qui fait déjà tout ça il me semble.
>  > 
>  > Mmm, oui, effectivement, quoi que j'ai jamais reellement reussit a faire
>  > marcher camlzip. 
> 
> J'ai jamais essayé...

Mmm, je jetterai un coup d'oeil a l'occasion.

>  > Tu pense qu'on pourrait simplement stocker les images svg dans une
>  > archive camlzip, et les recuperer suivant le nom, ajouter de
>  > nouvelles images, en supprimer, etc. On aurrait meme pas besoin de
>  > fichiers .svgz alors. Cela serait plus simple effectivement.
> 
> oui. Et on n'a pas vraiment besoin d'ajouter ou supprimer les images :
> l'archive zip est juste un moyen commode de distribuer les fichier de
> données mais on la construirait avec les outils habituels (zip).

Mais on ne peut utiliser que des .zip, pas des archives .gz.

Mmm, n'y avait-il pas un probleme de brevet en ce qui concerne les .zip ?
Si c'est le cas, peut-etre vaut-il mieux s'en passer.

En fait, on a le choix entre :

  o utiliser zip de camlzip, possible problemes de brevet, et on
  n'utilise alors que des .svg.

  o utiliser gzip de camlzip, et soit tar, soit un moyen ad-hoc pour
  concatener les fichiers .svg.

  o on utilise un moyen ad-hoc pour concatener les fichiers .svg, et on
  peut alors utiliser libgsf et le support gz de librsvg pour lire a la
  fois des .svg et des .svgz.

Ceci dis, l'avantage de la troisieme solution c'est de pouvoir lire du
disque directement les donnees gziper, et de produire les bitmaps a
partir de ceux-ci, ce qui economise de la memoire (quoique on la reperde
peut-etre dans librsvg lors du rendu).

Amicalement,

Sven Luther




reply via email to

[Prev in Thread] Current Thread [Next in Thread]