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.
"Plus standard", je n'irais pas jusque-là , mais c'est surtout que le parsing est fait pour nous. Et les fichiers PDF sont souvent assez lourds.
J'avais essayé de rendre des SVG grâce à une webview pour la même raison: le parsing est fait pour nous. Malheureusement, c'était très lent et on ne pouvait pas avoir de fond transparent.
Cette nouvelle version change un peu l'API pour la rendre un peu plus structurée et permettant + de flexibilité sur le rendu de l'image (via une classe OHVectorImage intermédiaire).
Cette version permet entre autres de choisir une tintColor pour l'image vectorielle, pour ainsi utiliser le PDF comme un masque plutôt qu'une image et re-colorer l'image d'origine avec une nouvelle couleur.
Heu disons que ce n'est pas forcément une bonne pratique à suivre ^^
Ca sert à m'éviter de re-déclarer la @property nativeSize en "readwrite" dans le .m juste pour pouvoir écrire "vImage.nativeSize = ...". Au lieu de ça, je triche et j'accède directement à la variable d'instance "_nativeSize" de l'objet OHVectorImage. Ce que j'ai le droit de faire uniquement parce que je suis dans le code de la classe OHVectorImage, sinon je n'aurais pas accès à l'API et la structure interne de cette classe.
J'avoue que j'aurais mieux fait, soit de re-déclarer la propriété nativeSize en "readwrite", et d'écrire "vImage.nativeSize = ...", soit de ne pas l'affecter à cet endroit du code et plutôt implémenter le getter moi-même "-(CGSize)nativeSize" pour qu'il calcule et retourne la mediaBox à chaque fois. Donc c'est de l'optimisation parce que je sais ce que je fais, mais ce n'est pas forcément un exemple à suivre
Ca sert à m'éviter de re-déclarer la @property nativeSize en "readwrite" dans le .m juste pour pouvoir écrire "vImage.nativeSize = ...".
J'ai pris le réflexe de toujours mettre en contrepartie d'une @property readonly dans .h une @property readwrite dans le .m (dans la Class Extension) " sauf dans le cas où la @property readonly n'est pas backupée par une iVar.
D'habitude c'est ce que je fais aussi mais quand je manipule du CoreFoundation et des CFType opaques j'ai encore quelques habitudes du C qui restent.
Disons que là en fait ce que je ferais habituellement c'est de créer une methode d'instance initWithPageRef: qui utiliserais l'ivar directement (normale pour une methode d'init, une des rares exceptions où on utilise l'ivar en direct), et le constructeur de commodité pageWithPageRef: ne ferait qu'appeler alloc+initWithPageRef:
Du coup pas besoin de @property(readwrite) car le seul endroit où j'écris dans la propriété c'est dans le init, et pas besoin de "->" car je suis déjà dans la methode d'instance.
Inconvénient, pour l'utiliser il faut embarquer la lib sous forme de framework. Ce qui veut dire un Deployment Target de iOS8.0 minimum (et pas encore de support de CocoaPods, mais on est en plein dessus, c'est imminent). Mais bon faudra bien y passer un jour et ça serait bête de se passer de ce @IBDesignable ;-)
---
En attendant, j'ai publié une nouvelle version de ma lib, qui ajoute le support des ombres portées, de la recoloration de l'image vectorielle, des insets, le support de NSCopying, et la correction d'un bug remonté par Colas
Réponses
J'avais essayé de rendre des SVG grâce à une webview pour la même raison: le parsing est fait pour nous. Malheureusement, c'était très lent et on ne pouvait pas avoir de fond transparent.
Cette nouvelle version change un peu l'API pour la rendre un peu plus structurée et permettant + de flexibilité sur le rendu de l'image (via une classe OHVectorImage intermédiaire).
Cette version permet entre autres de choisir une tintColor pour l'image vectorielle, pour ainsi utiliser le PDF comme un masque plutôt qu'une image et re-colorer l'image d'origine avec une nouvelle couleur.
@Ali : merci, je vais étudier le code ;-)
Je vois que tu utilises la commande `->` dans vImage->_nativeSize = pdfPage.mediaBox.size; que je n'utilise jamais. ça sert à quoi ?
Ca sert à m'éviter de re-déclarer la @property nativeSize en "readwrite" dans le .m juste pour pouvoir écrire "vImage.nativeSize = ...". Au lieu de ça, je triche et j'accède directement à la variable d'instance "_nativeSize" de l'objet OHVectorImage. Ce que j'ai le droit de faire uniquement parce que je suis dans le code de la classe OHVectorImage, sinon je n'aurais pas accès à l'API et la structure interne de cette classe.
J'avoue que j'aurais mieux fait, soit de re-déclarer la propriété nativeSize en "readwrite", et d'écrire "vImage.nativeSize = ...", soit de ne pas l'affecter à cet endroit du code et plutôt implémenter le getter moi-même "-(CGSize)nativeSize" pour qu'il calcule et retourne la mediaBox à chaque fois. Donc c'est de l'optimisation parce que je sais ce que je fais, mais ce n'est pas forcément un exemple à suivre
Bouuuuhhh. Qu'on le jette aux lions ;D
c'est un chrétien ?
J'arrive !!!
Il est où mon repas favori ? 8--)
ppppfffffchchhhhhiiiitttt
J'ai pris le réflexe de toujours mettre en contrepartie d'une @property readonly dans .h une @property readwrite dans le .m (dans la Class Extension) " sauf dans le cas où la @property readonly n'est pas backupée par une iVar.
Disons que là en fait ce que je ferais habituellement c'est de créer une methode d'instance initWithPageRef: qui utiliserais l'ivar directement (normale pour une methode d'init, une des rares exceptions où on utilise l'ivar en direct), et le constructeur de commodité pageWithPageRef: ne ferait qu'appeler alloc+initWithPageRef:
Du coup pas besoin de @property(readwrite) car le seul endroit où j'écris dans la propriété c'est dans le init, et pas besoin de "->" car je suis déjà dans la methode d'instance.
Je sais pas ce que ca vaut mais j'ai vu ca ce matin : https://maniacdev.com/2014/12/open-source-ios-library-for-displaying-svg-image-assets-with-support-for-interface-builder
Inconvénient, pour l'utiliser il faut embarquer la lib sous forme de framework. Ce qui veut dire un Deployment Target de iOS8.0 minimum (et pas encore de support de CocoaPods, mais on est en plein dessus, c'est imminent). Mais bon faudra bien y passer un jour et ça serait bête de se passer de ce @IBDesignable ;-)
---
En attendant, j'ai publié une nouvelle version de ma lib, qui ajoute le support des ombres portées, de la recoloration de l'image vectorielle, des insets, le support de NSCopying, et la correction d'un bug remonté par Colas
OHPDFImage v3.1.1