Outils graphiques

Grammaires

J’ai utilisé plusieurs applications et toutes m’étonnent par leur syntaxe. Dans celles que je connais, on fournit à chaque fois le canvas (le support, la page) et puis on appelle des méthodes du support pour tracer des objets graphiques. Mais dans le monde concret le crayon ne fait pas partie de la page et encore moins ce qu’on peut faire avec le crayon. Ceci m’amène à imaginer la grammaire idéale d’une application graphique:

La grammaire idéale

Il me semble que la meilleure solution se serait de pouvoir commencer par poser une instance d’une classe représentant la page (donc en quelque sorte la surface) sur laquelle on va construire des formes:

page = Page("nom_du_fichier", dimensions)

Puis, on va créer des instances de formes, par exemple

rect = Rectangle(epaisseur, ... autres caractéristiques ...)
ligne = Ligne(epaisseur, ... autres caractéristiques ...)

puis on construit des rectangles et des lignes pour de bon:

r1 = rect.evt(dx1, dy1)
r2 = rect.evt(dx2, dy2)
....
l1 = ligne.evt(dxN, dyN)
...

dx, dy indiquent les dimensions. Alors on peut insérer ces formes dans la page aux coordonnées x, y

page.place(x1, y1, r1)
page.place(x2, y2, r2)
...

et à la fin, on sauve le résultat:

page.close()

Comme ce genre de division du travail n’est pas respecté, les concepteurs sont obligés d’émettre des mises en garde comme c’est le cas avec ReportLab:

Also, remember that no canvas state is preserved across page breaks, and
the save restore mechanism does not work across page breaks.

et on trouve des instructions comme:

canvas.setLineWidth(5)

ce qui me stupéfie: quelle est la largeur de ligne d’une page ?

Conversions de formats

Utiliser Inkscape

D’après la man page de inkscape on peut faire, entre autres, des conversions en les formats PNG, PS, EPS, PDF:

inkscape [options] FILENAME.svg

  -e, --export-png=FILENAME
  -P, --export-ps=FILENAME
  -E, --export-eps=FILENAME
  -A, --export-pdf=FILENAME