Bibliothèques pour charger du SVG
colas_
Membre
J'ai cru un instant qu'il y avait un nouveau framework pour loader les SVG... et j'étais content !
Car pour l'instant, parmi ce qui existe (SVGKit, PocketSVG, SVGImage, UIImage+SVG) aucun ne m'a convaincu. En fait, je n'arrive à en faire marcher aucun avec des petits .svg créés par illustartor
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je te rejoins Colas2, je n'ai pas été convaincu non plus par ces frameworks.
En fait, ça fait des années que je me tâte à faire la mienne, et à chaque fois, je me dis que ce sera dans le prochain iOS...
Vous attendez quoi de ces bibliothèque ?
@Céroce, en gros, ces bibliothèques ne marchent pas !!!! Celle que j'ai testée le plus, c'est SVGKit... et elle semble mal maintenue, très compliquée... et je n'ai pas réussi à la faire marcher. J'ai testé vite fait les autres et aucune n'a marché (avec mes .svg, qui sont simples en plus). J'ai moi aussi espéré qu'Apple intègre cette fonctionnalité au SDK. Mais en fait, ça limiterait quand même son utilisation aux nouveaux iOS.
@Geoffrey : plutôt que créer des images avec illustrator et ensuite faire plein de versions bitmap (avec @2x, @3x, etc.), ce serait plus simple d'ajouter un .svg à l'appli et de créer des UIImage pour les différentes tailles attendues. Voilà ce que j'en attends.
S'il y a des gens intéressés ici, on pourrait se partager la tâche de tester plus à fond ces frameworks... peut-être que je suis allé trop vite dans mes tests.
HUmmm, je vais surement dire un truc hyper débile. Mais moi, je convertis tous mes fichiers sous illustrator en PDF. Et je les mets dans le Image.xcassets et dans le panel, je dis que je veux des images de types "vectors et bitmaps". Du coup ça m'évite de faire 3 formats.
Je pensais que c'était une bonne solution mais je préfère passer pour un débile que de faire une mauvais "practice" !
ça ne résout qu'un problème, celui de la création.
Reste celui de la taille de l'application...
@MarcoDah ça ne marche que pour iOS 8, non ?
@Céroce: Effectivement, le plus gros problème est celui de la taille de l'application. Mais je n'utilise cette méthode pour ainsi dire que pour les icône dans mon appli. Le reste je n'ai pas trouvé la bonne solution ... J'ai presque fini toute la partie graphique et mon application fait environ 12 Mo Brut.
@colas : A vérifier. Je suis pour l'instant effectivement en train de développer pour iOS8. ( Je me casse la tête pour la rétrocompatibilité )
A vérifier pour iOS7 !
Ils ont fait le même principe pour les Size Class qui sont apparues avec Xcode6/iOS8 mais tu peux les utiliser même si tu cibles iOS7 et dans ce cas il régénère à la compilation des fichiers séparés "~iPhone"/"~iPad"/... tout seul pour toi.
Donc sur le même modèle ça ne m'étonnerait pas du tout que par exemple le format PDF soit supporté (et donc inclus directement dans l'IPA tel quel) nativement par iOS8 et que si tu cibles iOS7 rien ne t'empêche de mettre des PDF dans ton AssetsCatalog et Xcode se débrouillerait à la compilation pour générer des PNG pour avoir un IPA retrocompatible iOS7...
A confirmer avec des vrais tests évidemment.
Après test, ça ne marche ni sous iOS7, ni sous iOS8 !
Pour le montrer, j'ai créé un fichier .pdf de très petite taille et je demande à iOS de l'afficher en grand. Résultat:
En + quand je regarde le look dans Interface Builder l'image apparaà®t toute pixelisée, mais dès que je lance l'appli sur le simulateur iOS7 par exemple, elle apparaà®t au contraire bien lisse. Donc moi j'aurais plutôt tendance à dire que ça marche bien au contraire, non ?
Moi quand j'ouvre ton projet tel quel et que je le lance sur sim iPad Air iOS7 :
- l'ImageView dans laquelle tu as mis l'image "Check" via IB s'affiche comme attendu et correctement lissée / agrandie vectoriellement sans pixelisation
- Les imageViews dans lesquelles tu n'as pas mis d'image via IB mais que tu affectes l'image par le code ont au Runtime une frame de (0,0,0,0), même après le viewDidAppear " Je sais pas trop pourquoi elles ont cette frame remise à zéro et pas celle fixée dans IB (j'ai pas cherché à creuser la raison), mais du coup forcément je ne vois pas leur contenu, et ce n'est pas parce que le chargement de l'image par le code ne marche pas mais juste parce que l'imageViewdans laquelle tu les affiches n'est pas visible à l'écran, du coup.
J'ai trouvé étonnant aussi que dans ton AssetsCatalog tu aies glissé le PDF dans un slot prévu pour une image Bitmap ! En effet je sais pas chez toi, mais moi dans mon Xcode quand j'ouvre ton projet et affiche le Images.xcassets, je vois les 3 cases "1x", "2x", "3x", et ton image de checkbox dans la case "1x" alors que les 2 autres cases sont vides. Sauf que cette configuration 1x/2x/3x c'est justement pour quand tu fournis des images Bitmap ! Si tu veux mettre une image vectorielle dans ton Assets Catalog, il faut sélectionner une configuration "Vectoriel", configuration qui du coup n'a qu'une case " dédiée pour le fichier vectoriel " et pas les 3 cases 1x/2x/3x. Sinon ça n'a pas trop de sens de mettre ton PDF plutôt dans 1x que dans 2x ou 3x
[EDIT]Bon si je met une Background Color à tes 3 UIImageViews, en fait c'est vrai que ça ressort un peu + et montre qu'en fait c'est qd mm un peu pixelisé et pas aussi lisse que ça devrait donner si c'était effectivement un agrandissement vectoriel.
A creuser quand même, car ta démo n'avait pas forcément tous les critères pour faire une conclusion définitive (mauvaise sélection de type d'Asset, etc), et ton PDF a une taille de référence assez petite. Je suis sûr que si on change la taille du canvas de ton PDF (67.4x52.18 points d'après Aperçu.app) pour en mettre une bien plus grande, ça résoudrait le problème. Car un PDF, contrairement a un SVG, contient dans ses méta-données la taille à laquelle il est sensé être rendu.
Et du coup je pense que Xcode génère finalement encore des assets Bitmap (c'est à dire que fournir le PDF dans ton Assets Catalog plutôt que les PNG permet juste de ne pas avoir à créer les PNG toi-même, et de laisser Xcode générer 3 fichiers PNG (dont la dimension en points est celle indiqué dans les meta-data du PDF) à partir du PDF que tu lui as fourni. Donc ça n'embarque pas la version vectorielle dans l'appli, mais régénère une version Bitmap à partir de la version vectorielle lors de la compilation
Non, non, je crois vraiment que ça ne marche pas !!
En fait, oui, c'est lissé mais c'est une version bitmap du pdf qui est lissée (à mon avis). Ce n'est pas l'image .pdf qui est rendue à la bonne définition.
Pour t'en convaincre, j'ai encore agrandi la UIImageView pour que l'effet soit plus flagrant. À côté, dans la photo d'écran, je mets un aperçu du fichier .pdf
+1 je ne connaissais pas les "configurations vectorielles". J'ai just glissé le pdf dans le cassets et j'ai pas cherché plus loins. Sinon, oui bizarre pour les UIImageView de frame nulle.
Je reteste avec ton indication ;-)
Merci !
EDIT
Bizarre, même avec ton indication, ça ne marche pas Voici mes settings.
Du coup il faut que le PDF que tu fais glisser ait comme dimensions indiquées dans ses méta-data la taille en points que tu veux (autrement dit la taille pour le référentiel @1x)
Donc en conclusion, effectivement il n'y a toujours pas de support du format vectoriel au runtime dans iOS.
Après si vous avez des svg, Paintcode transforme le SVG directement en code Objective-C (peut être Swift aussi). Bon ca rajoute une étape.
PaintCode 2.1 produit du code Swift, mais coûte quand même 99,99 $ ..
Et après vous pouvez faire varier la taille avec CGContextScaleCTM.
@FKDEV, c'est comme ça que tu fais ? Tu utilise Paint Code ?
Je commence tout juste à l'utiliser.
Je prends des icônes existants (parce que je ne sais pas bien dessiner).
Je les importe dans Paintcode, les redimensionne un peu.
Après je copie le code dans la méthode drawRect d'une classe dérivée de UIView et j'ajuste la taille avec CGContextScaleCTM. Je peux facilement changer la couleur en modifiant le UIColor.
Avant j'utilisais pixelmator pour modifier des icônes en png. Le redimensionnement n'était pas toujours très bon (pas vectoriel) et je ne retrouvais jamais la fonction pour changer la couleur des traits (je ne dois pas avoir la logique des designers).
Salut,
Concernant les lib SVG, j'utilise personnellement SVGKit.
Alors oui, elle est un peu naze, oui, ils ont du mal à intégrer CocoaPod mais au final, une fois ces étapes un peu dures à passer, elle fonctionne.
Et elle apporte en plus le support des animations. Chaque groupe (group id dans le svg) est transformé en un layer dont l'identifiant est l'identifiant de ce groupe. Du coup, on peut facilement sélectionner et animer ces layer.
Je n'ai rien trouvé de mieux jusqu'à présent.
Alors Céroce, si tu veux t'y coller, je te conseille de forker au moins leur parseur (car ils gèrent un sacré paquet d'objets). Ou alors carrément leur projet et le mettre d'équerre
Et c'est guerre mieux côté Android... Y a qques lib qui gèrent le svg mais aucune ne gère les animations a priori... Bref, le svg est pas franchement l'ami des mobiles
Certes ça ne lit pas les fichiers SVG, mais juste le PDF, et il faut charger les images par code " vu que ce n'est pas nativement supporté par Interface Builder.
Mais ça permet au moins d'utiliser des images vectorielles dans vos projets Xcode.
PS : @colas2 je me suis permis de réutiliser ton check.pdf dans mon projet démo
@Ali : super !!! Merci beaucoup pour ce super pod ;-) J'y avais pensé car j'ai déjà des classes qui transforment les PDF en UIView, mais c'est toi qui l'as fait !
Que penses-tu d'une amélioration (que je pourrais faire) : prendre un UIColors en argument dans l'init pour colorer le pdf (utile surtout si le pdf de départ est monochrome) ? Je pourrai faire une pull request si tu penses que c'est une amélioration ok.
La dernière fois que j'ai forké un projet pour changer quelques ligne de code, ça avait créé le bazar à cause des fichiers de Xcode (.project et tout le bazar). Et du coup ça avait été un peu galère.
Sachant qu'une fois ton projet forké, je vais vraisemblablement coder à partir de ton projet "example", y a-t-il une méthode à suivre ?
Merci de tes conseils ! Je profite d'ajouter cette fonctionnalité à cette classe pour m'entraà®ner à forker !
Colas
Par contre je me disais que je vais peut-être revoir l'API. Genre faire une classe OHPDFImage qui encapsule une OHPDFPage et gère le NSCache, et du coup inclus une propriété UIColor ou mieux, une ColorMap, et possède les methodes pour la transformer en UIImage.
La catégorie de UIImage ne serait qu'un wrapper pour la méthode la plus courante (nom du PDF et size du rendu) et pour les modes plus avancés tu passerais par OHPDFImage.
OK, du coup je vais t'attendre ;-)
Au cas où ! (je ne connais pas les ColorMap) : voilà une méthode pour changer la couleur d'une UIImage.
1) manque de décision
Un bon exemple: pour les rotations, elles peuvent être exprimées en degrés, en radians et en grades. C'est totalement idiot: il fallait choisir les degrés, qui sont plus faciles à lire pour un humain et sont donc utilisés dans les logiciels graphiques et qui auraient aussi plus de sens dans un format XML. Si jamais le logiciel d'édition fonctionnait avec un autre format interne, il aurait effectué la conversion.
Au lieu de cela, les parseurs doivent gérer les trois unités de mesure.
2) trop de fonctionnalités
La plupart sont assez inutiles; certaines sont utiles mais assez mal implémentées par tous les parseurs de toute façon.
Cette spec ressemble tout à fait à toutes les specs du W3C: comme personne ne peut choisir, on met tout dedans, et les gens qui conçoivent les navigateurs web se débrouillent pour tout implémenter.
Donc, que SVG Kit reconnaisse plein de balises, on s'en moque. Ce qu'il faut, c'est d'abord interpréter de façon fiable les 20% de balises qui servent le plus; et là , on est capable d'afficher les SVG pondus par la plupart des softs. Et comment on fait du soft fiable ? En faisant des tests. Et automatisés, c'est mieux.
Par ailleurs, je crois que la principale fonction demandée est d'abord de pouvoir utiliser le rendu final pour remplacer les PNG. Donc accéder à l'arbre des objets me paraà®t très secondaire.
ça peut être pas mal quand même. Imagine tu as un svg avec deux calques et tu veux pouvoir créer 3 UIImage avec :
-> une image avec les deux calques visibles
-> une image avec le calque 1
-> une image avec le calque 2
ça permettrait par exemple d'avoir des images avec des badges jolis et bien placés, etc.
Le format PDF est + standard, son parsing est intégré à Cocoa, et donc au final c'est assez simple à implémenter, comme le montre mon pod OHPDFImage.
Ou alors Apple crée un nouveau format qui remplace le SVG, qui est classe, accompagné d'un logiciel type illustrator ou sketch (avec éventuellement avec une fonction qui transforme le dessin en code) et qui est reconnu par le SDK.