Sketch va adopter un nouveau format de fichier ouvert
L’éditeur vectoriel Sketch va changer son format de fichier avec la version 43 qui sortira dans les prochaines semaines. Pour l’utilisateur, rien ne devrait changer, si ce n’est qu’il devra créer une nouvelle copie de ses documents sauvegardés dans l’ancien format pour les convertir. Ce changement est très important néanmoins, puisque le nouveau format est ouvert et accessible à tous.
Sous la surface, Sketch exploitera désormais le JSON, un standard que n’importe quelle app pourra lire et écrire. Un fichier Sketch sera en fait une archive qui regroupe les images et du texte pour décrire chaque élément qui compose le document. Puisqu’il s’agit d’un outil vectoriel, tous les éléments peuvent être décrits par une série de coordonnées et de vecteurs. De fait, l’information peut facilement être mémorisée sous une forme textuelle et ouverte.
Ce changement devrait garantir aux utilisateurs de Sketch une pérennité à toute épreuve. Le format sera documenté et n’importe quel concurrent pourra alors ouvrir et convertir les documents dans un autre format. D’autres usages sont à prévoir, par exemple des scripts capables de générer des fichiers à partir de paramètres. Dans un cas plus concret, un module comme Teleport permet déjà de copier le design d’un site dans l’éditeur vectoriel, mais il nécessite de passer par Sketch. Une version pourrait être exécutée côté serveur pour générer le fichier sans passer par le Mac.
Sketch 43 est d’ores et déjà disponible sous la forme d’une bêta publique que vous pouvez essayer gratuitement avant la finalisation. Une licence est vendue 115 € la première année et pour continuer à bénéficier des mises à jour par la suite, il faut la renouveler pour 69 $ (65 €) HT.
@ fte : « XML aurait été un meilleur choix technique en tout points »
Pas en tous, non. Il est tout aussi foireux — voire bien plus — que JSON pour le côté « format texte entraînant une lourdeur de code source, de temps et d’espace lorsqu’il s’agit de lire ces fichiers ».
« mais il échoue sur un point essentiel : XML n'est pas cool. JSON, pour beaucoup, ce sera OK cool bidouillons un truc vite fait et on verra. »
La bidouille rapide, sans même nécessairement parser l’intégralité du fichier, semble effectivement être ce que les développeurs de Sketch veulent offrir comme possibilité. Il est clair que du JSON est bien plus adapté à ça que du XML.
« J'aurais aussi écarté XML à leur place... »
Moi aussi. S’il avait fallu se frapper la lourdeur du XML, autant définir un format binaire propre et bien plus efficace.
@BeePotato
Tu sous-estimes XML. Il y a tellement de librairies permettant des lectures partielles, de l'edit in place, etc. XML n'a pas beaucoup de désavantages par rapport à un fichier binaire structuré. Le parsing est plus lent, mais pas tant que ça. Dans le cas de Sketch, l'argument est sans intérêt.
Quant à la taille des fichiers et l'occupation mémoire, ce n'est pas non plus un problème. Zip existe sur disque, des parsers stream existent depuis aussi longtemps que XML existe, et on vit une époque où la mémoire se mesure en multi-gigabytes...
Anyway, JSON ne se comporte pas mieux.
@ fte : « Tu sous-estimes XML. »
Je ne sous-estime rien du tout.
Je connais tout ce que tu cites, et je trouve que c’est très lourd par rapport à l’écriture de fonctions d’entrée/sortie d’un format binaire tout bête conçu sur mesure pour la tâche.
« Anyway, JSON ne se comporte pas mieux. »
C’est bien ce que j’ai dit.
Mais il présente au moins, comme on l’a dit avant, l’avantage de la « bidouillabilité facile », ce qui peut représenter un argument justifiant autant de lourdeur si ce besoin de bidouillabilité existe réellement (et manifestement, les auteurs de Sketch ont reçu des retours indiquant qu’il existe).
@BeePotato
Un format n'est jamais tout bête. Même binaire. Trop bête et tu es emmerdé à chaque révision. Pas bête et tu es aussi emmerdé à chaque révision. Des tas de codes de migration à écrire et maintenir...
XML a résolu tout ça grâce à un écosystème de librairies énorme.
"Il y a une librairie pour ça."
Enfin, loin de moi l'idée de jeter des fleurs à XML, je déteste XML. Cordialement. Il a des qualités cependant, même s'il est haïssable.
J'aime bien SQLite comme point de départ pour ma part. Enfin voilà.
@ vince29 : « Si sketch a déjà un filtre d'import svg ce sont déjà des problématiques que l'application rencontre déjà de toutes façons. »
Pas du tout !
En import, les développeurs sont certes confrontés au problème du support incomplet du SVG. Mais comme c’est juste une fonction d’import d’un format étranger, les utilisateurs ne sont pas surpris que ce soit imparfait et que la conversion vers le format natif ne soit qu’approximative. Chose qu’en revanche on ne pardonne pas quand ce format est annoncé comme le format natif de l’application.
Et surtout, chose beaucoup plus importante : comme format d’export, l’usage du SVG est beaucoup plus simple. Il se retrouve utilisé juste pour avoir un rendu figé de l’image, alors que s’il était le format natif de l’application il faudrait trouver comment y caser toutes les informations nécessaire au travail sur le document. Ce n’est vraiment pas le même effort de développement.
« Ensuite rien n'oblige l'éditeur à implémenter l'intégralité de la norme SVG. Il peut dire décider que sont logiciel ne supporte qu'un subset de svg qu'il définira lui-même (cf SVG vs Tiny SVG vs basic SVG). »
Ce n’est pas ce que tu proposais : tu parlais d’utiliser le SVG.
Se limiter à un sous-ensemble, ça revient à dire qu’on n’utilise pas le format SVG comme format de travail, mais juste un format dérivé, abusivement présenté comme étant « le SVG ».
Et on laisse ainsi ses utilisateurs confrontés aux risque de se retrouver avec un de leurs documents Sketch illisible par Sketch, parce qu’il sera passé entretemps par un autre éditeur de SVG, qui à l’enregistrement ne se sera pas limité au sous-ensemble de la norme géré par Sketch. C’est un réel plaisir pour l’utilisateur qui pensait profiter du confort d’avoir plusieurs logiciels reposant sur le même format, de se rendre compte qu’en fait il n’en est rien. :-)
C’est un peu comme si Apple décidait de faire du format Word le format de travail de Pages. On aurait vite des surprises en faisant un cycle Word → Pages → Word sur le même document.
@BeePotato :
Ah bon, Sketch est développé en JavaScript ?
@ marc_os : « Ah bon, Sketch est développé en JavaScript ? »
??
Je n’ai écrit ça nulle part, et je n’ai pas non plus écrit quoi que ce soit qui le laisserait sous-entendre.
Pourrais-tu nous éclairer sur la raison de cette question bizarre et décalée ?
Parce qu'il pense que JSON est encore attaché à Javascript (alors qu'en fait cela vient de Java, d'ailleurs).
Comme je l'ai dit plus haut, c'est très loin d'être le cas, l'usage hyper répandu de JSON fait qu'on trouve le support de cette représentation textuelle de données structurées dans pratiquement tous les langages utilisés de nos jours.
JavaScript Object Notation aucun rapport avec java.
Qu'est-ce qu'il faut pas lire !
Où as-tu vu de l'XML « utilisé comme format interne » ?
Faudrait que tu te renseignes sur ce qu'est un parser !!
Parce qu'à la différence de l'XML, un format JSON peut être facilement utilisé pour stocker à plat les données structurées d'un format interne. C'est dans ce sens que j'ai tenté (mais échoué, @BePotato ayant bien mieux réussi à l'expliquer) de souligner qu'utiliser un format XML, à grammaire SVG ou pas, pour la persistance était moins facile et efficace sans pour autant apporter la garantie d'un format de document totalement standard pour autant.
Ici, le format n'est clairement pas standard.
Il est seulement "ouvert", et avec une techno qui permet à l'éditeur de très facilement le gérer et aux développeurs tiers d'exploiter.
Plus généralement, ce qui manque c'est un standard universel de "conteneur document" , avec une partie standardisée pour permettre l'introspection, la prévisualisation ou les conversion de format éventuellement avec perte dans des formats les plus usuels (image, texte, son, vidéo...) et une partie spécifique.
On y vient ceci dit petit à petit, les docx, odt et ici futur .sketch par exemple adoptent ce type d'approche d'un conteneur compressé contenant différents fichiers organisés à l'intérieur de manière plus ou moins universelle ou, du moins, pseudo-intuitives.
bref un zip avec
un fichier coeur en xml (svg)
un répertoire qui contient les ressources (images)
un mimetype à la racine pour indiquer que l'archive est un fichier sketch (qui est une spécialisation de svg)
une preview au format png
comme odt, docx, epub...
et voilà un format de fichier lisible par tous les navigateurs (pour peu que tu le dézippes avant)
@ vince29 : « et voilà un format de fichier lisible par tous les navigateurs (pour peu que tu le dézippes avant) »
J’aime bien ce « lisible à condition de le convertir avant ». :-)
T'as encore de la mauvaise foi à revendre ? Je vais en prendre un peu.
@ vince29 : « T'as encore de la mauvaise foi à revendre ? »
Tout plein ! :-)
Surtout que j’ai pu en mettre de côté en n’en utilisant pas jusque là. Mais toi, je comprends que tu puisses te retrouver à court. ;-)
@vince29
> comme odt, docx, epub...
Similaire.
Pour que cela soit un beau jour vraiment "comme", il faut un standard de conteneur de document avec une organisation dans ce conteneur permettant l'introspection et l'extraction de suffisamment d'information pour faire des rendus du contenus dans quelques formats simples mais beaucoup plus universels.
Y compris texte, pour l'indexation et la recherche facile sur les textes contenus dans un dessin ou un enregistrement audio/vidéo par exemple...
@ byte_order : « l'extraction de suffisamment d'information pour faire des rendus du contenus dans quelques formats simples mais beaucoup plus universels. »
Sauf que ça, c’est un principe impossible à appliquer de manière universelle à tous les formats de données. Quelques types de données se prêtent à l’extraction d’information juste sur la base de descripteurs passifs, mais pour beaucoup d’autres il faut nécessairement un bout de code.
Alors bien sûr, on pourrait aussi rêver de modules Spotlight et QuickLook universels, multi-plateformes… mais je pense que ça restera longtemps encore un rêve.
En attendant, on peut se contenter de documenter au mieux chaque format de fichier, en se disant que si quelqu’un est suffisamment intéressé il développera le module qui va bien pour l’OS qu’il utilise. :-)
> Alors bien sûr, on pourrait aussi rêver de modules Spotlight et QuickLook universels,
> multi-plateformes… mais je pense que ça restera longtemps encore un rêve.
Un boulot de d'extraction de prévisualisation / conversion à la portée d'un Web service, avec des clients "natifs" dans chaque plateforme, j'en rêve.
ben
une preview sous forme d'un png
un mimetype à la racine pour identifier la contenu de l'archive
un XML comme format pivot avec du Dublincore pour les metas auteurs
(qui se suffit à lui-même ou bien qui référence d'autres xml si le format est organisé en "pages")
un répertoire medias pour les fichiers binaires dans des formats standards
bref comme sketch mais avec du xml (s'il veut faire comme les grands (odt,docx,epub))
@ vince29 :
Sauf que tout ça, ça ne répond pas au rêve exprimé par byte_order :
• Permettre l’extraction de suffisamment d’information pour faire un rendu dans des formats « simples » et classiques ⇒ ça n’est pas le cas, on a juste un rendu précalculé en PNG (dont on espère qu’il sera bien mis à jour par tous les logiciels manipulant le document, ce qui va du coup à l’encontre de l’idée de la bidouillabilité facile — c’est un problème aussi présent dans le nouveau format de Sketch).
• Permettre d’extraire le texte pertinent pour une indexation permettant ensuite des recherches efficaces.
Mais c’est assez normal que çe n’y réponde pas, ces critères relevant effectivement du domaine du rêve. :-)
svg + dublincore
@ vince29 :
Rien à voir avec ce dont parlait byte_order.
bou png pas beau moi je veux le vrai document en vectoriel => svg
moi je veux indexer des metas et du texte => xml + dublincore.
@ vince29 :
Le commentaire de byte_order élargissait le débat au delà du cadre des images vectorielles (il citait notamment l’exemple de l’indexation textuelle du contenu de document audio/vidéo).
D’où le fait que ton « SVG + Dublin Core » n’avait (et n’a toujours) rien à voir avec ce dont il parlait dans ce commentaire.
Pour l'indexation audio video il y a mpeg 7 depuis 15 ans mais personne ne l'utilise.
Pour "relier" des ressources et organiser l'information il y a le RDF + ontology (dont dublincore standardise les balises évidentes).
Sinon le format qui a le plus de sens c'est le zip avec
ressources binaires dans des formats bien maitrisés
xml décrivant ton document final
preview (png)
marqueur avec le mimetype du composite
Perso je convertis les formats images 2d (PS, XCF) en un format perso qui est un zip avec les layers + xml pour décrire l'organisation des layers.
Comme openraster mais bien mieux pensé ( : ) ) et qui supporte les filtres dynamiques.
Si je publie la version dézippée sur un serveur, tous les navigateurs peuvent afficher l'image.
Si le navigateur supporte javascript, même pas besoin de dézipper et tu peux dynamiquement ajouter/masquer des layers ou modifier les filtres ce qu'à ma connaissance aucun plugin web pour PS n'est capable de faire (déjà que les simples plugins de visualisation que j'ai trouvé sont de simple bidouille (aller/retours serveurs ou nécessitant que PS soit installé)
Alors certes le support de PS n'est pas complet (formatage de texte, quelques filtres non implémentés) et il y a quelques limitations (espaces colorimétriques convertis en rgb) mais :
format lisible par tous navigateurs;
support du svn;
scriptable sans photoshop (ajouter/supprimer/renommer/réorganiser les layers, modifier le texte, remplir avec des dégradés...)
Désolé pas de preview publique de l'outil : )
Pages