Sommaire
Je cherche à faire un langage de description de diagramme/figure qui soit à la fois simple à utiliser et puissant. Dans l'idéal, il serait possible de spécifier des formes simples et de les composer de manière à fabriquer des formes complexes. Sur le moyen terme, il serait possible d'utiliser des sortes de gestionnaire de layout (comme pour les interfaces graphiques) pour ne pas avoir à spécifier la position des formes directement mais de laisser le gestionnaire la calculer. Le but de ce journal est de faire état de mes recherches et de soulever quelques problèmes de conception auxquels je dois faire face.
Modèle de dessin
Pour le modèle de dessin, pas de problème, quasiment toutes les bibliothèques de dessin 2D utilisent le modèle PDF (lui-même hérité du modèle PS). Pour résumer, ce modèle permet de spécifier des formes et des chemins (path) puis, soit de dessiner le contour (stroke), soit de remplir la forme (fill). Diverses propriétés sont associées : la couleur, la largeur de la ligne, la manière de joindre les divers segments (line join), la manière de dessiner le bout des segments (line cap), la manière de remplir les chemins qui se croisent (fill rule), etc. Il est également possible de spécifier des transformations : translation, rotation, homothéties; ou alors directement en passant par une matrice de transformation.
On retrouve ce modèle notamment dans cairo, Skia (made in Google), Qt et certainement d'autres.
Il est donc naturel de s'appuyer sur ce modèle pour définir le langage. Tous les concepts sont déjà présents, le problème vient de la manière de les exprimer.
Premiers pas
J'ai réalisé un premier prototype simple pour me faire une idée. Je me suis inspiré de la syntaxe POV-Ray pour décrire mes objets, notamment les vecteurs et les couleurs. Pour l'instant, quand on veut dessiner une ligne rouge entre les points (10,10) et (30,30), voilà à quoi ça ressemble :
line { <10., 10.>, <30., 30.>
pigment { rgb <1., 0., 0.> }
}
Facile, n'est-ce pas ? De même, quand on veut dessiner un polygone (ici, un triangle) à l'aide d'un chemin, on procède de la manière suivante :
polygon {
path { <10., 10.>
line_to <30., 10.>
line_to <10., 30.>
close
}
}
Il est même possible de définir des variables pour faciliter les réutilisations :
set lw = 3.
set w = 10.
line { <0., 0.>, <w, w>
line_width { lw }
}
line { <w, 0.>, <w, 0.>
line_width { lw }
}
Les problèmes
Alors, où se situent les problèmes ?
Forme relative ou forme absolue
Actuellement, les formes et chemins sont spécifiés de manière absolue, c'est-à-dire que les coordonnées sont décrites de manière absolue. C'est conceptuellement le plus simple, mais je me dis qu'on pourrait faire autrement en spécifiant les formes de manière relative. Par exemple, plutôt que de spécifier une ligne par deux points, elle serait spécifiée par les coordonnées du vecteur (mathématique) correspondant, et par le point de départ du vecteur. Si je reprends mon premier exemple, on aurait quelque chose du genre :
line ( <20., 20.>
at <10., 10.>
}
Idem pour les chemins qui devraient être spécifié en déplacement relatif plutôt qu'absolu :
polygon {
path {
rel_line_to <20., 0.>
rel_line_to <-20., -20.>
close
}
at <10., 10.>
}
C'est plus compliqué à spécifier mais ça pourrait être plus flexible par la suite, quand on va composer les formes. Bref, je me pose encore la question : sur laquelle des deux méthodes miser ?
Contour et remplissage
Le second problème concerne les deux types de dessin qu'on peut faire : le contour d'une forme et le remplissage d'une forme. Actuellement, j'ai deux types d'objets distincts suivant qu'on veut remplir ou dessiner le contour : box (fill) et rectangle (stroke), disc (fill) et circle (stroke), polygon (fill) et polyline (stroke). C'est gênant quand on veut faire les deux à la fois, ça oblige à spécifier deux objets avec les mêmes coordonnées, ou pire avec le même chemin. Même si on imagine qu'il est possible de faire une variable avec un chemin, ça me semble légèrement redondant comme approche.
Dans les bibliothèques existantes, on a plusieurs approches. Pour cairo, on peut spécifier les propriétés, puis le chemin, et ensuite appeler cairo_{fill,stroke}_preserve qui va préserver le chemin pour le réutiliser. Quand on programme, c'est très pratique, mais dans un langage, ça paraît plus compliqué à mettre en œuvre. Dans Skia, le fait qu'on dessine un contour ou un remplissage ou les deux est déterminé par un flag. L'inconvénient, c'est que les propriétés sont partagés, notamment la couleur, donc il est impossible de dessiner un disque rouge avec un contour bleu. Dans Qt, on a le concept de crayon (QPen) et de brosse (QBrush). Grosso-modo, le crayon possède les propriétés pour le contour, et la brosse possède les propriétés pour le remplissage.
L'idée de Qt me plaît assez parce qu'elle divise le nombre d'objets par deux, mais qu'il faut alors spécifier à chaque fois un crayon et une brosse pour chaque objet. Par exemple, si je reprend l'exemple du triangle plus haut et que je veux le remplir de bleu et l'entourer en rouge :
polygon {
path { <10.,10.>
line_to <30., 10.>
line_to <10., 30.>
close
}
brush {
pigment { rgb <0., 1., 0.> }
}
pen {
pigment { rgb <1., 0., 0.> }
}
}
D'où la question : y a-t-il un meilleur moyen de faire ?
Conclusion
J'en suis encore à l'exploration de solutions, et j'aimerais avoir des avis sur les problèmes soulevés, mais également sur la syntaxe. J'entrevois déjà d'autres problèmes, comme la composition des formes (mais là encore, PDF fournit un modèle), ou encore sur les transformations. Mais n'allons pas trop vite.
# Pourquoi ?
Posté par Sylvain Sauvage . Évalué à 10.
Pourquoi ne pas utiliser (ou étendre) un format existant ?
C’est pas comme s’il n’en existait pas déjà plein. (Au hasard, SVG, PGF/TikZ…)
Pouf, nimage
[^] # Re: Pourquoi ?
Posté par fravashyo (site web personnel) . Évalué à 9.
Juste pour ceux qui ne connaîtraient pas, Ditaa est vraiment super :
et pour aller avec : http://www.asciiflow.com
Ça permet de stocker ses diagrammes dans un format simple, textuel.
Et pour l'histoire de réinventer la roue, pourquoi ne pas utiliser Graphviz qui est justement un langage de description de diagrammes : http://graphviz.org/
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 3.
Pour ditaa et asciiflow, on ne peut pas dire que la réutilisabilité soit idéale. Si on veut composer des figures, c'est assez difficile.
Quant à Graphviz, il est orienté graphe. Je l'utilise pour ça, mais là, je veux un peu plus que des graphes.
[^] # Re: Pourquoi ?
Posté par kna . Évalué à 1.
Ou pour ceux qui préfèrent une « application lourde » : http://search.cpan.org/dist/App-Asciio/lib/App/Asciio.pm
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 2.
SVG n'est pas fait pour être édité à la main. Et PGF/TikZ a une courbe d'apprentissage très rude.
[^] # Re: Pourquoi ?
Posté par lolcat . Évalué à 2.
rude, pas forcément. Dès que tu as besoin de faire un peu de géométrie élémentaire dans le plan, c'est assez simple.
[^] # Re: Pourquoi ?
Posté par MCMic (site web personnel) . Évalué à 2.
Pourquoi SVG ne serait pas fait pour être édité à la main?
En quoi cela empêche-t-il de le faire?
Pour l'avoir déjà fait en cours, j'ai tout de suite pensé à SVG quand j'ai vu tes exemples, parce que c'est des trucs que j'ai fait en SVG écrit à la main, un polygone, le remplir ou pas, etc…
Pour moi ce que tu présente là est un sous ensemble de SVG avec une syntaxe qui tire sur le JSON plutôt que le XML, mais à part ça l'idée reste la même.
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 2.
Sur ce que j'ai présenté, OK. Mais je ne compte pas m'arrêter là sinon ça n'aurait aucun intérêt ! Est-ce que SVG permet de définir et réutiliser des variables qui contiennent des objets, des propriétés, des transformations ? Je ne pense pas. Est-ce que SVG permet de créer des fonctions, d'avoir des structures de contrôles ? Avec JS, peut-être, mais ce n'est plus SVG. Est-ce que SVG permet de faire du placement relatif ? Non. Et tout ça, je compte bien l'inclure dans mon langage.
[^] # Re: Pourquoi ?
Posté par MCMic (site web personnel) . Évalué à 3.
Oui, on peut déclarer un objet en lui donnant un nom, et l'invoquer plus bas. Y compris plusieurs fois pour afficher plusieurs fois une même forme. Et à chaque fois on peut faire subir diverses homothétie et autres translations.
Il me semblait qu'on pouvait faire du placement relatif, à vérifier. (dans mes souvenirs, au sein d'un groupe, les coordonnés sont par rapport au groupe et après on bouge le groupe)
Les fonctions et les structures de contrôles je vois pas bien ce que tu veux dire par là. Il y a au moins un support de l'animation dans SVG, je ne me souviens plus de ce qu'il est possible de plus sans JS.
Bref, ça montre au moins que tu n'as pas fait une analyse de l'existant très poussée avant de te lancer dans ton propre projet.
XML étant fait pour être facilement étendu, tu devrais peut-être regarder si ça t'aide pas d'étendre SVG plutôt que de partir de 0.
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 3.
Du coup, j'ai parcouru la norme SVG 1.1.
Je ne savais pas que SVG pouvait faire ça. D'un autre côté, ça ne doit pas être très utilisé par les éditeurs graphiques.
Et puis, il manque quand même des choses assez utiles, comme définir des variables avec des réels, pour éviter d'avoir à répéter des nombres qui ont la même sémantique. Et il n'y a pas d'expression (ou alors, je n'en ai pas vu) permettant de définir un point ou un réel ou un vecteur ou une couleur.
Si je veux afficher 50 carrés disposé en rond, j'aimerais pouvoir le faire dans une boucle for plutôt que de définir 50 carrés. C'est impossible de le faire en SVG nativement. Si je veux une fonction qui renvoie une couleur suivant certains paramètres, je ne peux pas. Etc.
Désolé, je préfère partir de 0. Parce que SVG n'est pas très adapté pour une édition manuelle, comme la plupart des dialectes XML. Et puis je considère que je ne réinvente pas la roue, je pars des mêmes modèles de dessin que SVG, à savoir PostScript (il suffit de voir comment SVG est né pour le comprendre). Toutes les libs vectorielles 2D font pareil et on ne leur dit pas de se baser sur SVG.
[^] # Re: Pourquoi ?
Posté par MCMic (site web personnel) . Évalué à 2.
Hum oui effectivement. Personnellement j'aurai eu tendance à faire ça avec du PHP qui sort du SVG, mais je comprends que ça convienne pas à tout le monde :-D
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 10.
Tiens, je vais en profiter pour pousser un coup de gueule. Parce que je trouve un peu facile de ressortir cette image à chaque fois que quelqu'un propose une variation sur un thème.
Je n'ai pas l'intention de faire un nouveau standard qui surpassera tous les autres, j'ai l'intention de faire un truc qui me plaît, et que je pourrai utiliser parce que j'en ai le besoin et que je n'arrive pas à trouver chaussure à mon pied avec l'existant. C'est comme ça que l'informatique fonctionne depuis le début. Si on avait pas créé de nouveaux outils, on en serait encore à Cobol. Si on ne peut plus rien faire sous prétexte qu'il y a déjà quelque chose d'approchant, ça va vite devenir galère de coder.
Bref, j'ai posé des questions, j'aimerais avoir des réponses. Ceux qui considèrent que ce que je fais est inutile peuvent s'abstenir de commenter et aller sur les nombreux journaux à troll.
[^] # Re: Pourquoi ?
Posté par fravashyo (site web personnel) . Évalué à 9.
Tu as raison de ne pas te restreindre dans ta créativité. Néanmoins je pense qu'il a raison de te proposer d'étendre une syntaxe existante, éprouvée, plutôt que de réinventer la roue.
Il existe des systèmes très performants, développé pendant des dizaines d'années, pour décrire des vecteurs et les afficher. En combien de temps peux-tu espérer les égaler ?
Je connais peu Postscript et Metapost dans le détail, mais ce qu'ils font et comment ils le font ressemble à ce que tu veux développer de ton côté.
D'ailleurs postscript permet d'utiliser de coordonnées relatives et absolues, il faut pouvoir avoir les 2 possibilités, en général les objets sont générés en relatif, et assemblé en absolu (par rapport à une page). Une courte intro à PS :
http://paulbourke.net/dataformats/postscript/
D'ailleurs Metapost génère du PostScript. Asymptote aussi. Graphviz peut le faire également. Je pense que si aucun de ces langages ne te convient, tu pourrais quand même regarder du côté de postscript, ça te ferait sans doute gagner du temps. Et encore plus si tu utilises un langage de plus haut niveau en amont.
Ce qui risque aussi de manquer à ton outil (sauf si c'est pour ton usage exclusif), c'est des outils graphiques pour générer des diagrammes, parce que
je ne trouve pas cela beaucoup plus lisible que du SVG (enfin, si un peu quand même, mais pour se faire une représentation mentale du diagramme, autant le SVG que l'autre me semblent impossibles)
Pour en revenir à Graphviz, c'est utilisé pour réaliser des organigrammes (cf. le logo), pas juste des graph donc c'est en plein dans ce que tu cherches, sauf si tu n'as pas tout expliqué dans les raisons qui te motivent pour créer ce nouvel outil.
Exemple :
http://graphviz.org/Gallery/directed/unix.png
(la source : http://graphviz.org/Gallery/directed/unix.gv.txt)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 3.
Tout à fait. Comme je l'ai dit dans le journal, les API de dessin actuelles sont toutes calqués sur le modèle PDF, lui-même hérité de PostScript. En fait la différence entre PostScript et PDF est que PostScript avait des structures de contrôles (if, for, etc) que PDF n'a pas. Donc quand on transforme un PS en PDF, on se contente d'interpréter le PS et on envoie toutes les commandes de base dans le PDF. La filiation est donc assez naturelle.
Maintenant, le modèle PS a aussi ses limites, ne serait-ce que par sa syntaxe très déroutante. Et étendre PS me semble compliqué.
L'idée, c'est de pouvoir avoir par la suite, des bibliothèques d'objets prédéfinis et de ne manipuler que ces objets avec des opérateurs haut-niveau. Par exemple, imaginons qu'on veut dessiner un réseau de deux machines. On aura un objet
computerqui dessine un petit ordinateur et on écrira quelque chose du genre :C'est vrai que je n'ai pas expliqué l'usage que je veux en avoir. J'ai souvent besoin d'avoir des diagrammes ou des figures pour illustrer mes cours ou mes articles (je suis enseignant-chercheur). J'ai essayé pas mal de choses. Pendant longtemps, j'ai utilisé Dia, ça me convenait assez bien même si ça m'énervait de ne pas, par exemple, pouvoir placer les formes de manière un peu carré naturellement, par exemple avec des espacements identiques entre objets (le seul moyen est de passer par la grille magnétique qui est vraiment de mon point de vue un outil de placement du pauvre). L'avantage de Dia, c'est qu'on peut générer le fichier final qui va bien directement en ligne de commande, mais en revanche, on ne peut pas générer du PDF depuis la ligne de commande, il faut passer par l'export depuis l'interface graphique. J'utilise aussi gnuplot et graphviz quand c'est approprié, et idem, j'aime pouvoir tout piloter depuis la ligne de commande, parce que quand on modifie un diagramme et qu'on a juste à faire
makepour que ça retransforme et recompile tout, c'est quand même pratique.[^] # Re: Pourquoi ?
Posté par lolcat . Évalué à 2. Dernière modification le 14 octobre 2012 à 15:26.
Tikz…
Vu la relative complexité de ce que tu demandes, je te conseille de te pencher sur tikz, qui a un manuel très bien fait. Tout ce que tu demandes est faisable avec tikz, et même, tikz a été fait exactement pour faire ce que tu demandes.
La courbe d'apprentissage est rude, c'est une syntaxe différente de latex, mais ça vaut le coup, plus j'en lis sur tes besoins et plus j'ai l'impression que c'est exactement ce qu'il te faut. De plus, la syntaxe que tu explicites s'approche quand même très fort de tikz, si tu ne connais pas, je pense que c'est l'occasion de t'y intéresser.
[^] # Re: Pourquoi ?
Posté par fravashyo (site web personnel) . Évalué à 2.
Écrire directement en PS n'est effectivement pas forcément très convivial. Je pensais plutôt à utiliser ta syntaxe à toi, si c'est ce qui te convient le mieux, pour la convertir ensuite en PS, car la partie la plus difficile sera l'affichage. Or écrire du PS ce n'est juste "que" de manipuler du texte.
On doit pouvoir afficher n'importe quoi à partir du PS, donc en créant un language qui exportera en PS, ça t'évitera l'étape fastidueuse de la gestion de l'affichage, sauf si le challenge de ce type de développement te motive, ce qui peut être également une bonne raison.
Un peu sur le modèle de la notation musicale ABC, qui peut exporter ensuite en svg ou postscript à partir d'une syntaxe très simple :
http://moinejf.free.fr/example.html
Pour en revenir à graphviz, désolé d'insister, mais il est possible d'y intégrer des formes personnalisées :
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 2.
Heu, pour l'export, je vais tranquillement me reposer sur cairo (je pense) qui a un backend PS, un backend PDF, et aussi des backend pour les principaux systèmes d'affichage (Xlib et XCB pour Linux and co par exemple) ce qui permettra d'avoir une sorte de preview de l'image. De cette manière, je ne m'occupe que du «frontend» et je laisse le «backend» (ce qui correspond à la génération de code pour un compilateur) à cairo qui va me générer les bons formats.
Avec les liens que je vois, on est obligé de passer par un fichier externe. Ou alors, on est limité à la boîte rectangulaire. Du coup, on n'est pas très avancé. Je ne dénigre pas Graphviz hein, je le trouve merveilleux dans son domaine de prédilection et je l'utilise assez souvent pour ça. Je l'ai aussi utilisé pour faire des diagrammes de classes UML, ça marchait à merveille. Mais là, je ne vois pas bien comment être flexible avec Graphviz.
[^] # Re: Pourquoi ?
Posté par Sylvain Sauvage . Évalué à 4.
Susceptible, hein ?
Remarque pourtant que je n’ai pas dit « ça ne sert à rien » ou « ça existe déjà ». J’ai demandé « pourquoi ? ».
Ton journal ne dit pas pourquoi tu veux faire un langage dédié. Tu donnes juste quelques exemples et tu poses quelques questions sur comment inclure deux fonctionnalités (ancrage et encrage).
Comment veux-tu que l’on réponde à ces questions si on ne sait pas à quoi ça va servir ?
Ensuite, je demande pourquoi tu ne te bases sur un format ou langage existant. La problématique d’un langage descriptif de dessin vectoriel a déjà été traitée plusieurs fois. Et les questions que tu exposes ont aussi été traitées par ces formats. En quoi les réponses données ne te vont pas ? Pourquoi ne pas utiliser ce qui existe déjà ? Au moins comme base de réflexion ou d’explication, ou comme substrat (p.ex. en supposant que ton langage pourrait être transformé/compilé (facilement) en un de ces formats) ?
Et ne méprends pas ce que je dis, comme tu l’as déjà si facilement fait avec ta gueulante. Je ne dis pas qu’il ne faut rien inventer, que tout est parfait. Je dis qu’il y a eu des réponses, que ces réponses peuvent avoir des défauts mais que jeter tout ce qui existe sans critique, c’est-à-dire sans étudier les forces et les faiblesses, est une attitude puérile et non constructive.
Et la nimage, en plus d’être une obligation de répétition, est un rappel que simplement se plaindre que ce qui existe n’est pas « assez bien » et pondre un bouzin de plus n’est pas suffisant.
Et, moi aussi, je peux pousser une gueulante, envers tout ceux qui, quand on leur pose une question pour qu’ils approfondissent leur questionnement, pensent immédiatement et sans aucun doute que l’on n’est rien que des méchants vilains qui veulent tuer leur merveilleuse idée dans l’œuf, empêcher toute forme d’innovation et dénier leur fabuleuse créativité.
[^] # Re: Pourquoi ?
Posté par rewind (Mastodon) . Évalué à 2.
J'attendais mieux d'un premier commentaire que trois lignes qu'on retrouve systématiquement, quel que soit la proposition qui est faite.
Et les réponses apportées diffèrent parfois, donc ça montre que rien n'est figé.
Ben c'est tombé sur toi, mais ça ne t'étais pas destiné spécialement.
Qui te dit que je ne l'ai pas fait ? Simplement, je n'ai pas fait d'état de l'art dans ce journal parce que ça ne me semblait pas nécessaire. Mais je pourrais, il suffit de lire une partie de mes réponses et tu auras ta réponse.
Dans ces cas là, écris un peu plus de trois lignes et ta critique sera plus crédible.
[^] # Re: Pourquoi ?
Posté par ahuillet (site web personnel) . Évalué à 2.
Est-ce que tu t'es demandé pourquoi c'était systématiquement le premier commentaire ? C'est parce que la première question qu'on se pose quand quelqu'un présente une idée, un projet, une entreprise, un produit… c'est "quelle est la valeur ajoutée ?" c'est-à-dire "qu'est-ce que ça fait qu'on ne sait pas déjà faire".
Lorsque la réponse n'est pas évidente, c'est normal qu'on pose la question. J'ai lu ton journal en travers et j'ai pensé "SVG" aussi… ça n'a pas l'air très différent. À première vue, on dirait que tu crées un projet pour t'éclater dans ton coin, sans réel apport pour la communauté. C'est louable de ton point de vue mais ce n'est pas étonnant que ça ne suscite pas l'enthousiasme des foules !
[^] # Re: Pourquoi ?
Posté par Octabrain . Évalué à 1.
"Est-ce que tu t'es demandé pourquoi c'était systématiquement le premier commentaire ?"
Parce que c'est drole, que c'est bien vu (et qu'on se prend un +10 sur linuxfr). Tu t'es demandé pourquoi le premier commentaire à une question "où se trouve […] ?" était "DTC" ? Tu trouves que c'est pertinent ? Les images xkcd deviennent assez vite des mèmes sur linuxfr…
# modeste proposition
Posté par Nassara . Évalué à 6.
Personnellement, j'utilise Asymptote avec beaucoup de satisfaction.
C'est un langage de dessin vectoriel qui exporte nativement en postscript ou pdf. Il gère même la 3D.
Voici une petite galerie pour se faire une idée.
[^] # Re: modeste proposition
Posté par rewind (Mastodon) . Évalué à 3.
Asymptote est pas mal. Je crois que je vais le regarder de plus près, ça peut donner des idées.
# Quelques avis en passant
Posté par Paul . Évalué à 5.
Pourquoi pas la possibilité de laisser le choix à l'utilisateur, c'est-à-dire de proposer les deux ? Ça pourrait être un gros plus, par exemple en donnant la possibilité de faire des formes « macro » en relatif, puis de les positionner et rajouter d'autres trucs en absolu. Quelque part c'est un peu comme ça que html/css fonctionne, et c'est pas mal.
Moi aussi, je pense que c'est la meilleure parce que la plus « logique » pour le cerveau humain.
Bof, si un des deux n'est pas spécifié, tu fais comme il semble logique : tu ne le dessines pas.
[^] # Re: Quelques avis en passant
Posté par rewind (Mastodon) . Évalué à 3.
Tout à fait. Mais n'avoir que des forme absolue n'empêche pas ce que tu dis. Une petite tranlation et hop. Il est assez facile de calculer la boîte englobante (bounding box) d'une forme, et donc de déplacer la forme où on souhaite, éventuellement en réajustant la taille. Juste en donnant le point d'arrivée, tout le reste peut être calculé automatiquement.
Merci pour ces retours constructifs.
[^] # Re: Quelques avis en passant
Posté par Paul . Évalué à 3. Dernière modification le 14 octobre 2012 à 09:29.
Là tu me parles du fonctionnement interne du logiciel non ? Moi je m'en tenais à la manière la plus « logique » de l'écrire pour un être humain. Si tu peux à la fois réussir à avoir quelque chose de simple mais complet à écrire d'un côté, et la meilleure implémentation possible pour le rendu de l'autre, surtout ne te prive pas :)
Au passage ne t'en fait pas, ici ça commence toujours par critiquer (dans le sens négatif) voire par insulter avant de devenir constructif. C'est ça de de faire partie d'une « élite » (moi j'appelle ça une « communauté de gros malins »). Mais tu dois en avoir l'habitude, t'es souvent dans le coin.
EDIT : je pensais à un truc à propos de la méthode « Qt ». Elle peut permettre aussi de créer une forme sans la dessiner, puis plus tard de la réutiliser en utilisant au choix brush et/ou pen pour la dessiner.
[^] # Re: Quelques avis en passant
Posté par rewind (Mastodon) . Évalué à 2.
Ben justement, je ne sais pas ce qui est le plus «logique» pour un être humain : relatif ou absolu. Comme ça, je dirais qu'un être humain trouvera plus logique de placer de manière absolue. Mais je peux me tromper. Avoir les deux serait l'idéal, en effet. Je vais peut-être recycler mes formes en double de cette manière. Je ne sais pas encore.
Oui, je connais la maison. Et ça m'exaspère déjà quand ça arrive aux autres ;)
Pour ça, il y a les variables… et POV-Ray qui fournit des super idées. Dans POV-Ray, on peut définir des variables qui contiennent des objets, donc ils ne sont pas dessinés. Ensuite, il y a un objet générique qui permet d'étendre un autre objet qu'on a mis dans une variable. Je compte bien m'en inspirer. Un petit exemple pour comprendre. On veut dessiner deux lignes quasi identiques, une rouge et l'autre un peu plus bas :
On peut d'ailleurs faire pareil avec les modificateurs (propriétés ou transformations) et des modificateurs génériques.
Donc, oui, ça sera possible, et même assez rapidement.
[^] # Re: Quelques avis en passant
Posté par reno . Évalué à 2.
Je ne sais pas s'il y a une manière plus logique, après tout tu peux passer du relatif à l'absolu en faisant du relatif par rapport à l'origine et de l'absolu au relatif en ajoutant une translation, pour moi c'est plus une question de contexte:
-"à la PDF"/Scribus/DTP: tu veux imprimer sur une page dont tu connais la taille un document dont le rendu est le critère principal: en absolu.
-"à la HTML": l'idée est que ton document soit rendu de manière adapté automatiquement à la taille de l'écran utilisé: des objets en relatifs intégrés dans un document.
[^] # Re: Quelques avis en passant
Posté par rewind (Mastodon) . Évalué à 2.
Mon problème, c'est que j'aime bien les deux visions et que j'aimerais que les deux soient bien intégrés l'une par rapport à l'autre, et que je ne suis encore convaincu par aucune solution. Avoir deux syntaxes pour les mêmes objets me paraît bizarre. Avoir une seule syntaxe ne permet pas de distinguer les deux cas facilement.
[^] # Re: Quelques avis en passant
Posté par Zylabon . Évalué à 1.
J'ai jeté un œil et je me retrouvé pris d'un fou rire en lisant la ref card avec le "tri-state boolean". Je ne suis pas particulièrement attaché au tiers exclus, mais la logique classique en a un besoin vital. http://asymptote.sourceforge.net/asyRefCard.pdf
Sinon ça a l'air cool, je cherchais un truc pour faire rapidement des graphes en 3D, je vais peut être essayer ça avant gnuplot.
Please do not feed the trolls
[^] # Re: Quelques avis en passant
Posté par reno . Évalué à 2.
'default' comme nom de troisième valeur c'est curieux en effet, mais à partir du moment ou tu utilise des float qui peuvent retourner NaN, un Not-a-Boolean me parait bien plus logique que la convention arbitraire actuelle.
Ce qui me parait vraiment le plus logique c'est d'avoir une exception plutôt qu'un NaN, mais bon en C on est coincé..
# TikZ
Posté par scand1sk (site web personnel) . Évalué à 2.
Là comme ça, ton truc me fait furieusement penser à la formidable bibliothèque TikZ pour (La)TeX. A mon avis, ça va être délicat de faire aussi bien/mieux.
[^] # Re: TikZ
Posté par rewind (Mastodon) . Évalué à 3.
Comme déjà dit plus haut, TikZ a une courbe d'apprentissage très rude. je l'ai déjà utilisé une fois, en une journée, j'ai à peine réussi à faire trois ronds et 4 traits, ça m'a déprimé. Mon but n'est pas de faire aussi bien ou mieux que TikZ, mais de faire différent, d'explorer éventuellement de nouvelles manière de faire les choses, et peut-être de s'inspirer de quelques fonctionnalités de TikZ (comme le positionnement relatif).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Langages dédiés fonctionnels
Posté par Piezo . Évalué à 9.
Les fonctions d'ordre supérieur des langages fonctionnels sont utiles pour exprimer la composition géométrique.
En Haskell il existe Diagrams qui fait ses rendus en formats vectoriels, et Functional MetaPost qui produit du code MetaPost.
La sémantique intéressante peut être une source d'inspiration, sans forcement se baser sur un langage fonctionnel pur.
[^] # Re: Langages dédiés fonctionnels
Posté par rewind (Mastodon) . Évalué à 2.
Voilà qui répond à une de mes questions : dans Diagrams, ils utilisent des formes relatives. Effectivement, la sémantique est intéressante et je vais regarder ça de plus près. J'avais dans l'idée d'arriver à ce genre d'opérateur (qu'on rencontre aussi dans TikZ). Reste à trouver une syntaxe simple pour l'exprimer.
# Bonne idée
Posté par david guez (site web personnel) . Évalué à 1.
J'avais depuis un moment envie de demarer un tel projet. Pour moi, l'idéal (je sais pas si tu compte le faire) serait d'ajouter la possibilité de définir des animations de ces formes, d'ajouter aussi des boites textes (si ce n'est pas déjà présent) et vive les présentations avec animations en mode 100x plus facile qu'avec powerpoint/impress…
Pour répondre à tes questions pourquoi ne pas introduire par exemple la syntaxe r pour des coordonnées relatives ou a pour des coordonnées absolues.
Bon courage pour tes développements.
Ceci n'est pas une signature
[^] # Re: Bonne idée
Posté par rewind (Mastodon) . Évalué à 2.
En fait, ça fait partie des questions que je me pose : est-ce qu'un fichier correspond à une seule figure ou alors, est-ce qu'un fichier peut produire plusieurs figures ? Je vois des avantages et inconvénients dans les deux approches.
C'est prévu, mais je préfère prendre mon temps sur ce point parce que dès qu'on parle de texte, c'est très vite la galère (les caractères non latins, les fontes, toussa).
# le trait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Concernant le problème de remplissage ou de dessin de trait, pourquoi ne pas avoir uniquement du remplissage ?
Après tout un trait n'est jamais d'épaisseur null, c'est toujours une sorte de rectangle avec un dégradé si il est antialiasé.
Un cercle devient donc un anneau, etc…
Les formes de base auraient bien une épaisseur nulle mais serait invisible sans remplissage. En plus, cela permet d'être plus précis et d'éviter tous les problèmes "moches" des raccords.
"La première sécurité est la liberté"
[^] # Re: le trait
Posté par rewind (Mastodon) . Évalué à 3.
Non, ce n'est pas exactement la même chose. Parce que dans un trait, il y a deux éléments qui sont pris en compte dans le modèle de dessin actuel : la manière dont la jointure entre deux traits consécutifs dans un chemin est dessinée et la manière dont le bout du trait est dessiné. Sans compter le fait qu'on puisse faire des pointillés facilement. Si on considère qu'un trait est un rectangle, on doit réimplémenter ces éléments d'une manière ou d'une autre. Et je n'aborde même pas le cas des traits courbes.
[^] # Re: le trait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu peux toujours faire une sorte de librairy. Les jointures ne peuvent pas être propre en séparant le trait sur lequel tu rajoutes une épaisseurs. En définissant un chemin de rectangle, cela sera plus propre. Pour les courbes, tu peux avoir des primitives d'arc de cercle ou des "splines", de la même façon que tu as des rectangles.
"La première sécurité est la liberté"
[^] # Re: le trait
Posté par rewind (Mastodon) . Évalué à 2.
Il n'y a actuellement aucun problème de rendu avec les jointures. Je te conseille de lancer par exemple la démo Qt4 pathstroke (package
qt4-demosdans Debian) pour te rendre compte des possibilités. Tout est déjà implémenté et de bien belle manière, donc inutile de refaire ce travail à mon sens.[^] # Re: le trait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Concernant les pointillé j'ai en tête le comportement de mon tomtom, il s'agit de 3D vectoriel, mais les pointillés sont générés comme pour un dessin, et cela créait des mouvements aléatoires moches, qui n'ont pas de sens.
"La première sécurité est la liberté"
[^] # Re: le trait
Posté par reno . Évalué à 2.
Il me semble qu'avec X, il y a le mode 'ligne' ou tu as des lignes d'épaisseur 1 pixel:
avantage: c'est plus rapide.
inconvénient: le rendu peut varier beaucoup d'un écran à l'autre maintenant qu'il y a (enfin) des écran avec un haut DPI.
donc cela ne devrait pas être le mode par défaut, juste une optimisation possible.
[^] # Re: le trait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mes lignes à moi sont invisible, juste un moyen de définir des formes. Seul le remplissage est visible, ainsi il est précisément défini dans tous les cas. C'est beaucoup plus facile à coder d'avoir un seul moyen de dessin que 2. J'imagine même que l'on doit pouvoir utiliser une seul primitive comme des polynômes, au lieu d'avoir des lignes, des arcs de cercles et autres.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.