Bibliothèques pour charger du SVG

2»

Réponses

  • CéroceCéroce Membre, Modérateur

    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.
  • AliGatorAliGator Membre, Modérateur
    décembre 2014 modifié #33
    OHPDFImage v2.0.1

    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.
  • colas_colas_ Membre
    décembre 2014 modifié #34

    @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 ?


  • AliGatorAliGator Membre, Modérateur
    décembre 2014 modifié #35
    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 :D
  • LeChatNoirLeChatNoir Membre, Modérateur

    Bouuuuhhh. Qu'on le jette aux lions  ;D


  • AliGatorAliGator Membre, Modérateur
    Toi tu cherches à  ce qu'on appelle Alf :D


  • Bouuuuhhh. Qu'on le jette aux lions  ;D




    c'est un chrétien ?



  • Toi tu cherches à  ce qu'on appelle Alf :D




     


    J'arrive !!!


     


    Il est où mon repas favori ?  8--)

  • LeChatNoirLeChatNoir Membre, Modérateur
    décembre 2014 modifié #40

    ppppfffffchchhhhhiiiitttt




  • 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.

  • AliGatorAliGator Membre, Modérateur
    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.
  • AliGatorAliGator Membre, Modérateur
    Le côté support de @IBDesignable est sympa.
     
    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
Connectez-vous ou Inscrivez-vous pour répondre.