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.
Un editeur majeur responsable et honnete et qui considere son impact sur l'environnement informatique.
Attendons quelques temps pour voir (Microsoft avait bien promis un vrai format ouvert...), mais a priori il y a de quoi applaudir cette initiative.
@C1rc3@0rc
Microsoft n'a aucun intérêt à utiliser dès formats ouverts. La preuve : le RTF.
@C1rc3@0rc
Honnête ? Je ne suis pas d'accord du tout avec cette affirmation sachant que l'éditeur s'arrange par tous les moyens pour que l'utilisateur soit obligé de passer régulièrement à la caisse.
Cela semble d'ailleurs être le principal moteur des mises à jour.
@Domsware
Sketch n'est pas un abonnement contrairement à la Creative Cloud ou à Office 365... Chaque tranche de 99$ permet d'étendre les mises à jour pour un an ! C'est très honnête et tout à fait normal
@Mrleblanc101
Et mises à jour qui apportent quoi ? Un changement de format qui va de facto amener une incompatibilité et obliger à mettre à jour et à passer à la caisse ?
Je suis utilisateur de Sketch depuis les toutes premières versions et à ce titre je pense avoir un bon angle de vue sur la situation. Ce logiciel tout formidable qu'il est comporte un nombre de lacunes et de bugs importants qui ne sont jamais corrigés et qui perdurent de mise à jour en mise à jour. Chaque nouveauté apporte son lot important de bugs qui ne sont en partie résolus que plusieurs versions après. Autrement exprimé les sorties sont incomplètes et non fonctionnelles et cela met plusieurs versions à se résorber. Et bien entendu à chaque version nouvelle l'utilisateur a le droit au discours des nouveautés alors qu'il s'agit de corrections de bugs.
Et pourtant régulièrement il faut payer. Depuis la sortie de l'AppStore qu'a-t-il eu de nouveau ? À part un changement de modèle économique dont le seul objectif est une augmentation des prix ?
Au final leur système est un abonnement qui ne veut pas se nommer comme tel. "Chaque tranche de 99$ permet d'étendre les mises à jour pour un an ! " : c'est du baratin pour dire un abonnement de 99 $ valable 1 an et payé une fois pour toute au début. Un abonnement qui donne surtout droit à la sortie de correctifs.
Sketch 2 c'était 24 € en 2012. Sketch 3, 70 € en 2014. Maintenant c'est 99 € par an. Avec incompatibilité assuré de version en version. À la limite cela peut se comprendre pour un logiciel indispensable et surtout de qualité. Et Sketch n'est ni l'un ni l'autre.
Avant Sketch cet éditeur avait déjà un outil de création vectorielle qu'il a tout bonnement laissé tomber. Pour ressortir un autre, Sketch.
Donc honnête ne colle absolument pas à cet éditeur pour moi qui est à ranger dans le même panier que ceux que tu cites : Adobe et Microsoft.
Je préfère largement Affinity Designer pour le coup.
Sketch est un logiciel de niche.
Il est très performant pour répondre à des besoins particuliers (en gros design d'UI, c'est pas tout le monde tous les jours)
Pour un usage occasionnel, Affinity designer (très puissant lui aussi) suffit très largement !
@Mrleblanc101
$99/an, ça ressemble à un abonnement, ça en a l'odeur, la couleur, les bénéfices, une partie au moins des désavantages, la fin des mises à jour et du support si on ne paie plus son abonnement, pardon, ses mises à jour.
Du coup j'ai beaucoup de mal à comprendre ce qui te gêne dans une formule officiellement nommée abonnement. Le nom ? Ou que si tu résilies l'abonnement le logiciel arrête de fonctionner ? C'est un soucis, c'est très juste. D'un autre côté, avec des mises à jour régulières, sans suivi, il y a un moment où reprendre une mise à jour implique de racheter une licence pleine. Ça peut aussi être un soucis. À moins que le tarif de mise à jour soit identique au tarif plein, auquel cas on est vraiment sans une politique d'abonnement nommé politiquement correct.
Bref.
Si je ne trompe pas, pour 9€ par mois on peut avoir Illustrator plus un accès de quelques Gigas au cloud Adobe plus un accès à leurs Fonts plus un accès à Behance. C'est un abonnement certe mais du coup ton argument de 99€ pour un an de màj ne tient pas.
@C1rc3@0rc
En grossière approximation en lisant la press release, oui. Applaudissons.
Les clients savent la réalité derrière la press release. C'est une petite entreprise livrant un logiciel de niche hautement spécialisé vendu sur abonnement déguisé en licence perpétuelle.
Honnête ou pas ? J'en sais rien, je m'en fiche, c'est leur gagne-pain et ils doivent en vivre. Libre à nous d'acheter ou non.
Mais de parler d'écologie informatique ou je ne sais quel bullshit c'est très mal connaître ce logiciel et ses bugs et cycles de mise à jour. Les devs de Sketch font du bon boulot, mais ils n'ont de très très loin pas la puissance de feu de Serif, Adobe ou Microsoft puisque tu en parles.
On peut ensuite discuter de la pertinence d'employer JSON comme format. C'est une autre question. C'est surtout très facile. Pertinent, ah ah, "moins".
> On peut ensuite discuter de la pertinence d'employer JSON comme format.
> C'est une autre question. C'est surtout très facile. Pertinent, ah ah, "moins".
En même temps y'a pas 36 syntaxes "normalisées" qui disposent de parsers natifs dans plusieurs technologies et langages largement utilisées partout. XML est nettement plus lourd à lire correctement et surtout à convertir en langage objet, les yaml-like ne sont guère différents du JSON mais sans l'aspect normalisée et unifiée.
Mais surtout, avoir un format de document reposant sur du JSON, cela aide beaucoup pour proposer l'accès à ces documents depuis des navigateurs Web. Et stocker ces documents dans des bases de données de type Document, donc à proposer (et préparer à migrer vers) un service cloud de ces documents. Ou de la recherche puissante de documents (elasticsearch anyone?)
Les accès mobiles ont déplacé les lignes. Les données doivent pouvoir être facilement accessibles et manipulables depuis des plateformes de type et de capacité largement différentes. Internet est devenu omniprésent, et ses technologies y sont pour beaucoup. En tant que développeur ont peut le regretter ou pas, mais les utilisateurs, eux, veulent pouvoir travailler sur les mêmes documents depuis des plateformes multiples, ils en ont assez d'être bloquer par les limites de telle plateforme, à commencer par la longueur du câble d'alimentation, son poids, etc.
Bravo !
« 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. »
C'est partiellement vrai, on peut très bien importer une image bitmap dans Sketch.
@tekikou
Sauf que les nombres flottants encodés en texte et base 10 n'ont pas de directe représentation binaire native aux processeurs. Donc il y a des approximations de conversion.
C'est con pour un logiciel vectoriel qui se veut précis. Tu sauves et rouvre ton fichier, les points se sont déplacés un chouia. Génial. Si c'est bien codé, les approximations sont balancées, si c'est pas super bien codé, il y a déplacement à chaque sauvegarde. Une sorte de compression destructive, sauf que c'est une expansion destructive.
@ fte : « Sauf que les nombres flottants encodés en texte et base 10 n'ont pas de directe représentation binaire native aux processeurs. Donc il y a des approximations de conversion. »
Certes, mais ils ne sont pas obligés d’utiliser une représentation en base 10.
Cependant, je trouve moi aussi ridicule cette manie d’utiliser un format texte pour encoder des données pour lesquelles un format binaire serait bien plus adapté. Ou comment gonfler la taille des fichiers et ralentir leur lecture/écriture sans aucun gain réel.
C’est malheureusement une mode de plus en plus répandue.
@BeePotato
Ils ne sont pas obligés en effet. Sauf que ce n'est plus du JSON dans ce cas. Or ils annoncent JSON. Donc ils sont obligés.
@ fte
Si tu dis vrai, de l'XML aurait donc été préférable !
@ fte : « Ils ne sont pas obligés en effet. Sauf que ce n'est plus du JSON dans ce cas. »
Ah. Je le croyais moins con sur ce coup, le JSON. C’est vraiment limité, ce format (ce qui ne fait que renforcer l’opinion que j’exprimais plus haut au sujet de la pertinence de l’usage de tels formats textuels).
Mais peut-être qu’ils n’utilisent pas de flottants dans Sketch. :-)
(Sérieusement, ce n’est pas inimaginable.)
@BeePotato
Si, c'est imaginable si les coordonnées sont exprimées en points ou "pixels". Vu que l'édition se fait au départ à l'écran, il est facilement imaginable que l'unité de mesure soit le pixel ! On aurait donc des valeurs numériques entières pour les représenter, ce qui du coup règlerait le problème.
Je dirais même plus, il serait logique que l'unité de mesure soit le pixel, car sa conversion en cm ou inch ou quoique ce soit d'autre est arbitraire !
@ marc_os : « Si, c'est imaginable si les coordonnées sont exprimées en points ou "pixels". »
C’est bien pour ça que je disais que ce n’était pas inimaginable. ;-)
J’en suis resté à Sketch 2, donc je ne sais pas comment c’est dans la version actuelle. Mais dans la version 2, les coordonnées sont des nombres entiers.
Cependant, il n’y a pas que les coordonnées comme valeurs numériques : les épaisseurs de traits, par exemple, sont des nombres à virgule. Idem pour les tailles de caractères. Il est toutefois imaginable qu’il ne s’agisse pas de flottants mais de nombres à virgule fixe.
@ BeePotato
J'avais pas capté la double négation...
@marc_os
Et dans le cas où on bosse pour l'impression ou autre support nécessitant des mesures en métrique? Le pixel ne doit surtout pas être l'unité de mesure, simplement l'unité de représentation à l'écran. Si je dois bosser sous Illustrator en métrique et précisément je ne me fie pas au points affichés à l'écran et repositionne mes sommets grâce à des coordonnées métriques précises. Donc utiliser le pixel comme unité de mesure pour du vecto ne serait judicieux que si la finalité est d'utiliser le résultat sur un écran, comme des interfaces par exemple.
Il faut aussi éviter d'utiliser point et pixel pour exprimer la même chose car ça ne l'est pas.
@marc_os
C'est en effet envisageable que le logiciel n'utilise que des coordonnées pixel.
Sauf qu'il propose des bézier. Donc des vecteurs, possiblement en coordonnées pixel, et des points de contrôle, et sauf à fortement handicaper les bézier, je doute fortement que leurs coordonnées soient au pixel.
@BePotato
> Cependant, je trouve moi aussi ridicule cette manie d’utiliser un format texte pour encoder
> des données pour lesquelles un format binaire serait bien plus adapté.
> Ou comment gonfler la taille des fichiers
Tout le contenu du dossier-document est zippé. C'est du binaire compressé sur le disque.
Et comme une bonne partie des JSON vont avoir des répétitions de valeurs, il est même permis de penser que c'est plus compact au final, l'entropie globale étant meilleure.
> et ralentir leur lecture/écriture sans aucun gain réel.
Ben si, la lecture (et l'écriture) est possible par quiconque sans devoir connaitre les détails d’implémentation d'un format binaire.
Dans 30 ans, il est plus probable qu'on sache toujours reconnaitre un fichier compressé Zip et accéder à son contenu que de reconnaître un format propriétaire binaire utilisé pendant une dizaine d'année mais disparu depuis longtemps.
Un fichier zip contenant des fichiers texte a infiniment plus de chance d’être encore exploitable dans 30 ans que le format binaire PSD de Photoshop.
Le gain n'est pas nul.
Il est temps de penser en terme d'archivage numérique aussi, nos documents ne sont pas destinés à mourir fatalement en même temps que l'outil qui a permis de les créer.
@ byte_order : « Ben si, la lecture (et l'écriture) est possible par quiconque sans devoir connaitre les détails d’implémentation d'un format binaire. »
Par quiconque ? Non.
Par quelqu’un qui connaît les détails de ce que signifient les diverses clés et comment interpréter les valeurs associées — en gros, quelqu’un qui a accès à la documentation du format, quoi. Mais dans ce cas, il pourrait tout aussi bien avoir accès à la documentation du format binaire. :-)
Bon, ok, je ne vais pas être de mauvaise foi : le JSON présente l’avantage d’encoder au moins l’organisation des données en tableaux et dictionnaires sans avoir besoin de documentation, et si les noms des clés sont bien choisis on peut espérer commencer à deviner ce que chaque petit bout représente. C’est effectivement bien plus facile à décrypter qu’un format binaire compact (surtout dans le cadre d’un format de description d’image), mais ça reste de la recherche archéologique, un travail de fourmi.
Certaines personnes ici semblent persuadées que parce que ça dit JSON (ou si ça disait XML), ça y est, c’est « standard », c’est magique et n’importe quel logiciel sachant lire du JSON est capable d’afficher une image Sketch enregistrée à ce format — ne leur donnons pas l’idée que c’est vrai.
« Dans 30 ans, il est plus probable qu'on sache toujours reconnaitre un fichier compressé Zip et accéder à son contenu que de reconnaître un format propriétaire binaire utilisé pendant une dizaine d'année mais disparu depuis longtemps. »
Accéder à son contenu textuel, oui, mais il faudra tout de même faire la recherche archéologique dont j’ai parlé ci-dessus avant de savoir quoi faire avec ce contenu.
« Il est temps de penser en terme d'archivage numérique aussi, nos documents ne sont pas destinés à mourir fatalement en même temps que l'outil qui a permis de les créer. »
Boarf. Il faut relativiser ce besoin d’archivage : l’information la plus importante n’est généralement pas tout le fouilli du format de travail, mais ce que ce fouilli a permis de produire. Dans le cas présent, l’information de valeur (surtout pour dans trente ans ou plus) est dans les images générées et exportées à des formats bien connus, et non dans le contenu des documents Sketch eux-mêmes.
Cela dit, même si je trouve ce gain assez négligeable dans le cas des documents Sketch, je trouve cet argument assez intéressant. Merci.
Y'a quand même un caractère auto-descriptif d'une représentation textuelle plutôt que binaire, caractère qui rencontre évidement des limites (genre offuscation des noms des champs, mais alors là c'est carrément de l'hypocrisie de parler "d'ouverture" du format de document) mais nettement moins qu'un format binaire.
Le format porte en lui même un lexique qui, bien qu'incomplet, sera appréciégrandement des futurs archéologues numériques. Pour un format binaire obscure, le rapprochement avec un rendu dans un format connu sera leur quête de la pierre de Rosette. ^^
> Dans le cas présent, l’information de valeur (surtout pour dans trente ans ou plus) est
> dans les images générées et exportées à des formats bien connus,
> et non dans le contenu des documents Sketch eux-mêmes.
Vous partez du postulat que quelqu'un aura pris conscience de l'intérêt d'archiver l'information dans un format bien connu et fait l'effort de l'exporter depuis son format natif.
Je suis plus pessimiste sur ce point, je pense qu'une majorité de ce qui est archivé l'est dans son format le plus évident, celui qui n'impose pas des coûts supplémentaires pour son archivage : le format par défaut. Celui justement qui a le plus de chance d'être obscure et instable dans le temps...
Il suffit de voir le nombre de documents archivés par de grandes entreprises au format Word ou Powerpoint 2000, 97 voir antérieures plutôt qu'au format PDF pour s'en convaincre.
Bon, dans le cas de Sketch, il est trop tôt pour savoir s'il deviendra l'objet d'archivage à forte valeur. Mais ce n'est pas quand il sera trop tard qu'il faudra penser à sa accès à très long terme.
L'éternel débat des compromis court terme vs long terme...
@ byte_order : « Y'a quand même un caractère auto-descriptif d'une représentation textuelle plutôt que binaire »
Oui, c’est ce que j’ai reconnu (peut-être pas bien clairement) dans mon commentaire précédent (mais pour chipoter, je dirais que ce n’est pas lié à une représentation textuelle, mais plutôt à une représentation clé-valeur avec des clés textuelles — on peut avoir une représentation textuelle n’utilisant pas ce principe et restant du coup très obscure).
Cependant ce que j’y ai fait remarquer, c’est que plutôt que de description, il convient de parler d’indices fournis par les clés et la structure. C’est tout de même très loin d’être auto-descriptif, à part dans le cas de formats triviaux (et même avec un truc aussi classique qu’un image vectorielle, on n’est plus vraiment dans le trivial).
« caractère qui rencontre évidement des limites (genre offuscation des noms des champs »
Même sans offuscation, le rôle de chaque champ n’est pas forcément clair sans documentation.
« Vous partez du postulat que quelqu'un aura pris conscience de l'intérêt d'archiver l'information dans un format bien connu et fait l'effort de l'exporter depuis son format natif. »
Non, je ne suis pas si optimiste ! :-)
En fait, je ne suis même pas assez optimiste pour imaginer qu’il y aura un effort conscient d’archivage.
Mais le format de travail de Sketch sert majoritairement à deux choses : produire une image, qui sera donc exportée dans un format standard (vectoriel ou bitmap) pour être diffusée, ou créer un prototype d’interface utilisateur, qui servira à produire une implémentation réelle de cette interface dans une application.
On est donc face à un cas où l’export dans un autre format, plus largement lisible et diffusé (et du coup « auto-archivé » grâce à cette diffusion), est quasi-systématique. D’où le faible besoin d’assurer une lisibilité à long terme du format de travail, qui n’est finalement que l’équivalent d’une feuille de brouillon (même pas un cahier, qui a l’avantage de présenter un historique ; juste une feuille) et qui ne sera que rarement archivé.
On n’est pas là dans le même cas que pour les fichiers Word des années 90, dont la finalité était principalement d’être imprimés, puis envoyés tels quels par email, bien plus que d’être exportés en PDF.
json est à la mode depuis un certain temps. Mais l'xml permet de décrire la même chose.
cf. http://www.json.org/xml.html
L'avantage de json c'est qu'il soit un format qui permet de traduire rapidement une description textuelle en une structure de données javascript.
Mais qu'est-ce qu'on en a à faire vu que “Sketch is built exclusively for the Mac” ?
Un format xml ou plist aurait tout aussi bien fait l'affaire et aurait pu faciliter pour le coup vraiment l'écriture d'App tierces sur Mac (si c'est vraiment une motivation pour le changement de format) car il existe des API qui font la même chose que javascript avec le json, à savoir traduire directement des fichiers plist en structures de données (NSDictionnary).
Edit: Je viens de lire un commentaire où on parlait sites web. Oui, json est le format "naturel" pour sérialiser des données issues de code javascript. Mais non, json n'est pas obligatoire, il existe de bons parser XML pour javascript, vu quand même que javascript est utilisé essentiellement au départ pour gérer des pages web décrites en ... XML ! (XHTML est du XML).
https://www.w3schools.com/xml/xml_parser.asp
> Mais qu'est-ce qu'on en a à faire vu que “Sketch is built exclusively for the Mac” ?
Ben p'tet que justement ils ont changé d'avis sur ce point, et que du coup la portabilité du format du document au delà des seuls technos propres au Mac leur importe désormais ?...
EDIT:
d'ailleurs ils donnent quelques justifications pour ce nouveau format :
"Sketch 43 will introduce a new file format, designed to allow better integration with third party services and external tools. It will allow developers to access document information in an easier way, without having to use SketchTool. This opens new possibilities for inspecting Sketch documents in non-macOS platforms."
[...]
Here are some ideas for things you can try to do with the documents:
editing page and layer names by editing the JSON
running bitmaps through ImageOptim to compress them
run text diffs using version control systems
run visual diffs using previews + version control systems
integrating previews for .sketch documents on your server-side apps
use server-side tools to generate a dynamic .sketch document
…
"
---- http://sketchplugins.com/d/87-new-file-format-in-sketch-43
En clair, y'a une demande de manipulation de fichiers sketchs en dehors de la seule plateforme Mac. Ouvrir le format y répond rapidement et facilement. Sketch est p'tet "builtin exclusively for the Mac", mais que les documents Sketch, eux, le soient aussi semble limiter artificiellement certains usages de leur logiciel par leurs clients, actuels et potentiels.
> il existe des API qui font la même chose que javascript avec le json,
C'est pareil pour le JSON, qui s'est étendu bien au delà de Java et Javascript depuis longtemps.
Le XML a de moins en moins la côte dans les projets autour de moi, en partie parce que son avantage théorique sur les autres formats, le support d'un schéma de validation, est rarement utilisé en pratique, et que le parsing ou la génération de XML est légèrement plus imposant en raison d'une syntaxe plus complexe à gérer.
Sans parler de sa verbosité légendaire. La conversion quasi automatique d'un JSON en objet dans pleins de langagse est bien plus facile que devoir activer un parser XML et faire du XPATH ou, pire, du SAX pour extraire les données qui vous intéresse dans l'ordre où vous en avez besoin. La sérialisation JSON <-> objet est la killer feature que l'XML n'a jamais su proposé de manière simple et unifiée.
Nul doute qu'un jour un autre format supplantera à son tour le JSON.
A noter qu'il existe des versions binaires de JSON (BSON, MsgPack par exemple), mais l'absence de standard de facto et de besoins réellement massifs d'être plus compacte au prix d'une facilité de lecture réduite fait qu'aucun n'émerge réellement.
svg aurait été plus logique
@ vince29
Tout à fait !
Mais le SVG c'est du XML... pas à la mode.
Et on aurait pu en profiter directement, vu que des applications le gérant existent déjà, comme par exemple OmniGraffle.
Donc les soucis d'ouverture pour motiver l’utilisation du JSON, ça me fait bien rigoler comme pseudo argument - à la mode encore une fois.
Il semblerait donc bien que la mode soit LA motivation des développeurs de Sketch (en justifiant au passage de faire passer les utilisateurs à la caisse).
D'ailleurs au sujet de Sketch, Apple fournit depuis une éternité parmis tous ses exemples de code un projet d'application dénommé... Sketch. Je me suis toujours demandé si les développeurs du Sketch payant s'étaient basés sur le code de l'application d'Apple portant le même nom.
Quelqu'un sait-il ?
Sketch propose déja l'import/l'export au format SVG. Mais certaines fonctionnalités subissent des conversions, parce qu'en interne Sketch a certaines fonctionnalités qui ne sont pas directement et simplement exprimables en SVG (ou d'autres formats, d'ailleurs).
Là on parle du format "natif". Actuellement, c'est une base sqlite avec des meta-données et des gros morceaux de Blob bien opaques dedans.
Les métadonnées *et* les Blobs vont être exprimés au format JSON. C'est déjà mieux que la situation antérieure, et cela n'ampute nullement la possibilité d'exporter ou d'importer du SVG pour autant.
@ vince29 : « svg aurait été plus logique »
Non, il ne serait pas pratique d’utiliser un tel format comme format de travail de l’application (c’est ce dont on parle ici, comme l’a déjà rappelé byte_order).
Assurer un bon import/export SVG, c’est une bonne chose et c’est très utile, mais ce n’est en rien comparable comme effort avec le fait de s’enchaîner au SVG comme format de travail.
@ BeePotato
Tu n'apportes aucun argument contre le SVG.
Tu pourrais tout aussi bien écrire exactement la même chose en remplaçant SVG par JSON !
SVG c'est de l'XML, mais c'est surtout un format de "rendu" d'images vectorielles. Il n'a pas été conçu pour permettre des modifications dynamiques très fréquentes (en temps réel par exemple lors d'un tracé à la main levée). JSON non plus d'ailleurs, il n'y a très probablement pas de texte JSON modifié en temps réel ni relu en temps réel dans la prochaine version de Sketch, juste un export/import par défaut qui utilise ce format pour la persistence !
Manipuler un document XML en temps réel comme format interne d'un moteur de composition vectoriel, c'est nettement plus coûteux que de manipuler directement des objets dans votre langage de programmation et d'exporter tout ou partie de ces objets sous forme sérialisé dans un Blob d'une base sqlite3 ou, bientôt, dans un bundle de fichiers json.
L'export vous n'avez pas besoin de le faire en temps réel.
Les modifications et la lecture pour le rendu, si.
Par ailleurs, la syntaxe SVG n'est pas flexible a souhait, une grammaire est définit, on ne peut donc pas lui faire exprimer tout et n'importe quoi, sauf à devoir tout coder ce qui rentre pas dans la grammaire imposée dans des champs metadonnées qui, ironiquement, va rendre votre fichier réellement exploitable complètement que par le logiciel qui connait leur sens codé, le votre.
Un format à la syntaxe sans grammaire imposée, lui, le permet facilement, et sans recourir à des morceaux de blob habillés en metadata obscure. Et la sérialisation d'objet de langage de programmation est nettement plus simple également.
C'est pas par hasard si json est plus à "la mode" que xml de nos jours. Les développeurs choisissent eux aussi, quand ils le peuvent, les meilleurs outils correspondant à leur besoin. Force est de constaté qu'ils choisissent moins qu'avant XML pour faire tout et n'importe quoi comme fut un temps fort heureusement révolu (XML a connu aussi un phénomène de mode lui aussi, les fichiers de configuration en XML nécessitant un parser lourd de plusieurs dizaine de ko pour simplement lire 4 malheureuses variables noyées dans 8 niveaux de balises, y'en a eu des paquets...).
Ils ne choisissent pas plus Json quand il s'agit d'avoir un format compact et sécurisé par exemple, protobuf et similaire ayant plus la côte sur ce plan.
Et encore une fois, le web 2.0 pousse le json, qui pousse à son tour le support de json dans les langages utilisés cotés serveurs et clients web. Du coup, la sérialisation d'objet est quasi native partout. Ce qui n'est pas le cas avec l'xml, et encore moins avec SVG, qui impose le respect d'un schéma de grammaire imposé , en plus.
Sauf erreur de ma part il ne s'agit pas d'exposer un fichier pour faire de la modification en temps réel mais juste de choisir un format privilégié pour l'import/export par défaut donc je ne vois pas ce que viennent faire les modifications dynamiques dans l'histoire.
Ensuite si la grammaire SVG est définie il n'en reste pas moins possible de rajouter ses propres extensions. Inkscape rajoute dans le svg la configuration de l'utilisateur (niveau de zoom, la position des guides...) les calques, des notions de liens entre les items et bien d'autres choses tout en produisant un svg valide.
SVG qui peut immédiatement être visualisé dans un navigateur sans avoir besoin de plugin ni quoi que ce soit.
Ce qui ne sera pas le cas avec ce nouveau format exotique.
@ vince29 : « Sauf erreur de ma part il ne s'agit pas d'exposer un fichier pour faire de la modification en temps réel »
Tout à fait. Le passage de byte_order sur l’usage du XML comme format interne n’était pas pertinent.
« mais juste de choisir un format privilégié pour l'import/export par défaut »
Pas pour l’import/export. Comme format de travail, celui dans lequel se fait l’enregistrement des fichiers.
« Ensuite si la grammaire SVG est définie il n'en reste pas moins possible de rajouter ses propres extensions. Inkscape rajoute dans le svg la configuration de l'utilisateur (niveau de zoom, la position des guides...) les calques, des notions de liens entre les items et bien d'autres choses tout en produisant un svg valide. »
… ce qui revient à définir un nouveau format. Si Sketch adoptait cette approche, le format de travail dans ce cas ne serait pas le SVG, mais un nouveau format « Sketch SVG ».
Format qui présenterait l’avantage de pouvoir être affiché par n’importe quel logiciel compatible SVG.
Qui présenterait l’avantage aussi de pouvoir être partiellement édité par n’importe quel éditeur de SVG.
Mais qui présenterait le défaut d’être détérioré par une telle édition, le fichier étant silencieusement converti du format « Sketch SVG » au format SVG simple (ou à une variante type « Inkscape SVG »), avec perte d’information au passage faisant qu’il ne s’agit plus d’un fichier de travail Sketch.
C’est un problème classique de l’utilisation d’un format standard en stockant une partie non standard dans les métadonnées.
On a vu, un peu dans le même genre, des logiciels tenter d’utiliser le PDF comme format de travail, en enregistrant dans les commentaires la partie les concernant. L’avantage en termes d’affichage des documents de tous les côtés est évident, mais le risque de perdre des données du document l’est aussi.
@BeePotato :
Ouais, l'avantage du JSON de Sketch c'est de être lisible par _aucune_ application existante.
Au lieu d'utiliser un standard, ils veulent en imposer un, le leur !
@ marc_os : « Ouais, l'avantage du JSON de Sketch c'est de être lisible par _aucune_ application existante. »
Pour un format de travail, c’est effectivement un avantage. Mais tu ne sembles pas près de t’en rendre compte.
« Au lieu d'utiliser un standard, ils veulent en imposer un, le leur ! »
Je ne vois pas où ils essayent d’imposer quoi que ce soit — et je ne vois pas comment ils pourraient espérer arriver à imposer quoi que ce soit.
Ils proposent, ce qui est bien différent.
Et il n’apparaît nulle part la notion de standard dans cette proposition. Il n’y a pas que les standards, dans la vie. On peut fort bien se contenter d’avoir quelques outils capables de manipuler ce format, pour servir le petit écosystème de Sketch et de ses utilisateurs.
Pourquoi donc quitter la réalité et cette petite sphère d’utilisation pour se laisser aller à la folie des grandeurs en parlant de standard ?
@vince29
> Sauf erreur de ma part il ne s'agit pas d'exposer un fichier pour faire de la modification
> en temps réel mais juste de choisir un format privilégié pour l'import/export par
> défaut donc je ne vois pas ce que viennent faire les modifications dynamiques
> dans l'histoire
En temps réel, non. Dynamique, et par des outils externes, peut-être bien que si :
"If you edit any asset or JSON, and then put them back into the ZIP file, Sketch will read those changes back."
"use server-side tools to generate a dynamic .sketch document"
---- http://sketchplugins.com/d/87-new-file-format-in-sketch-43
Il semble que Sketch 43 est capable de détecter les modifications apportées à un document par des outils tiers et le relire dynamiquement. Ce qui ouvre des possibilités qui nécessitait avant de développer un plugin qui ne pouvait tourner que sur un mac, alors que la demande pour pouvoir le faire depuis des plateformes serveurs semble non négligeable...
@ byte_order : « Il semble que Sketch 43 est capable de détecter les modifications apportées à un document par des outils tiers et le relire dynamiquement. »
Quand on lit ces passages dans leur contexte, on voit qu’il n’y a rien qui indique un comportement dynamique (c’est-à-dire une détection par Sketch d’une modification tierce d’un document actuellement ouvert dans l’application, entraînant une relecture et… et quoi, au fait, si le document a été entretemps édité dans Sketch et non enregistré ?).
Ça parle juste du fait qu’on peut dézipper les documents à ce format, bidouiller leur JSON, puis rezipper le tout avant de le faire rouvrir par Sketch, qui devrait arriver à en faire quelque chose si on n’a pas trop fait n’importe quoi dans le JSON.
Bref, cette explication porte sur la facilité d’édition de ces documents en dehors de Sketch, mais parler d’un usage dynamique pour les documents ouverts.
Il y a un échange dans les commentaires de ce post qui semble pourtant l'indiquer dans un test, signalant d'ailleurs que ce rechargement peut amener à une alerte à l'utilisateur comme quoi le document a été modifiée par une application tierce alors que les modifications ont été prise en compte par l'application.
Sachant que la démarche vise également à répondre à des besoins que le développement de plugin ne permet pas, à savoir sans devoir/pouvoir le faire *depuis* un Mac exécutant Sketch, et que le SDK de ces plugins permet déjà ce type de dynamisme (puisqu'en pratique c'est du binding avec les interfaces internes de Sketch), je ne serais pas surpris que cela soit possible.
Mais j'ai pu aussi me méprendre, en effet.
@ byte_order : « Il y a un échange dans les commentaires de ce post qui semble pourtant l'indiquer dans un test, signalant d'ailleurs que ce rechargement peut amener à une alerte à l'utilisateur comme quoi le document a été modifiée par une application tierce alors que les modifications ont été prise en compte par l’application. »
Ce commentaire indique au contraire que si on modifie de façon externe un document en cours d’édition dans Sketch, ce dernier refuse d’enregistrer le document, parce qu’il a été modifié par ailleurs.
Mais il ne le relit pas, et il n’y a aucune mention d’une détection dynamique de la modification du fichier (c’est juste au moment où on essaye d’enregistrer, après une heure de boulot, qu’on voit qu’on ne peut pas ;-) ).
En revanche, il indique comment il a, par script, forcé Sketch à relire le nouveau contenu du document (perdant évidemment ce qui aurait pu être modifié via Sketch depuis le dernier enregistrement).
Ça ne va pas dans le sens du fonctionnement que tu évoquais, et ça me paraît bien normal (cf. ci-dessous).
« Sachant que la démarche vise également à répondre à des besoins que le développement de plugin ne permet pas, à savoir sans devoir/pouvoir le faire *depuis* un Mac exécutant Sketch, et que le SDK de ces plugins permet déjà ce type de dynamisme (puisqu'en pratique c'est du binding avec les interfaces internes de Sketch), je ne serais pas surpris que cela soit possible. »
Ben justement, comme tu le dis, cette démarche n’est pas du tout là pour faire ce que permettent les plugins (modifier un document ouvert dans Sketch), mais pour faire du traitement (ou de la génération) de documents Sketch totalement en dehors de ce dernier, sur d’autres machines qui n’ont pas besoin d’être des Mac.
Pour la modification « en live » pendant que le document est ouvert dans Sketch, il y a déjà l’approche par plugin, qui permet de le faire proprement, en tenant Sketch au courant de l’évolution de l’état interne du document.
Ah, au temps pour moi alors.
@ marc_os : « Tu n'apportes aucun argument contre le SVG. »
Ben si. Tu n’as pas compris mon argument, c’est tout.
Sans doute parce que je n’ai pas fait l’effort de le détailler (du coup, il ne paraît probablement pas évident si on ne s’intéresse pas un peu au développement et à la lecture de divers formats de fichiers), désolé.
« Tu pourrais tout aussi bien écrire exactement la même chose en remplaçant SVG par JSON ! »
Absolument pas, vu que JSON, contrairement à SVG, n’est pas un format de fichier d’images vectorielles — et pas non plus un format de fichier tout court —, mais juste une méthode générique d’encodage de données structurées.
Les développeurs peuvent donc utiliser la notation JSON pour enregistrer les données qu’ils veulent, organisées comme ils le veulent, pour coller à la logique interne de l’application. Alors que le format SVG leur imposerait des contraintes sur le type de données et la façon de les organiser dans le fichier, ce qui implique un effort de « traduction » d’un modèle à l’autre — et rien ne nous dit que le SVG permette de représenter l’intégralité de ce que Sketch conserve comme données dans son format de travail.
En sens inverse, à la lecture, l’adoption du format SVG comme format de travail de l’application imposerait de gérer le fait que le SVG permet, si je ne m’abuse, de représenter plus de choses que le type de données que produit et manipule Sketch. Que faire dans ce cas ? Refuser d’ouvrir les fichiers qui contiennent des données non manipulables par Sketch ? Les ouvrir, mais perdre une partie des données ?
Et bien sûr, ça imposerait aussi de suivre les évolutions du format SVG, histoire de rester compatible avec les nouvelles versions — que ces évolutions collent avec ce que les développeurs de Sketch souhaitaient pour leur application ou non.
Non, vraiment, décider d’adopter pour son application un format de fichier qu’on ne maîtrise pas, ce n’est jamais facile (à moins qu’il ne s’agisse d’un format simple et figé, mais c’est rare).
En revanche, décider d’utiliser la notation JSON au sein de son format de fichier maison, ça n’impose que très peu de contraintes (à part cette histoire de représentation des flottants).
J’espère que tu comprends mieux la différence, maintenant.
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.
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).
Les logiciels qui supportent le full svg pourront ouvrir le doc.
@vince29
Sur le fond, je pense que tu n'as pas tord. SVG aurait pu servir de point de départ.
Mais les points que souleve Bee sont justes.
On est dans le cas classique ou en théorie il n'y a pas de différence entre théorie et pratique mais en pratique, il y en a. En théorie SVG conviendrait. En pratique, non. Pas sans une dose importante d'emmerdes.
Je pense que le choix qui a été fait montre quelle direction ils suivent. Ils veulent que les fichiers soient utilisables facilement partout, facilement parsables, facilement échangeables, résistants aux transferts web de toute nature... Ils visent l'interopérabilité sans douleur.
XML aurait été un meilleur choix technique en tout points, 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. XML ça aurait plutôt donné eerk quelle horreur j'y touche pas sauf si on me force. Accueille les visiteurs avec une tranche de cake ou une tarte dans la gueule et vois la différence. C'est une réalité.
Je pense que ce seul argument suffit à disqualifier SVG et tout XML. J'aurais aussi écarté XML à leur place...
@fte :
Ok, tu confirmes ce que je disais : le seul avantage de JSON c'est d'être « cool », d'être donc à la mode quoi.
@marc_os
C'est rapidement dit. Le réel avantage, découlant de la coolitude, est que la porte est ouverte aux bidouilles faciles.
J'aurais dit, moi, que le lien causal est l'inverse : la coolitude découle de ce réel avantage.
@ byte_order : « J'aurais dit, moi, que le lien causal est l'inverse : la coolitude découle de ce réel avantage. »
Tout à fait d’accord avec cette hypothèse.
Pouvoir aller facilement modifier certaines choses (et éventuellement tout casser) dans le fichier sans même avoir à parser son contenu, c’est bien ce qui rend cool ce format Plis… euh… JSON. ;-)
Pages