Problème affichage attributed string dans un UILabel

Kubernan

Bonjour,



J'ai un problème d'affichage d'un attributed string dans un label appartement à  une cell à  hauteur variable. Il arrive que, lorsque le texte est tronqué, le retour ligne - \n - prévu dans le string initial n'est pas pris en compte à  l'affichage.



Voici un exemple du problème :

Kubernan

Ah tiens, il semble qu'en spécifiant le line break à  Word Wrap pour le UILabel j'obtienne un résultat satisfaisant (?).

AliGator

Tu as essayé de faire vraiment des paragraphes, et plus particulièrement d'appliquer ton lineBreakMode à  tous tes paragraphes de ton texte via un NSParagraphStyle plutôt que via le label ?

Kubernan

'AliGator' a écrit:

Tu as essayé de faire vraiment des paragraphes, et plus particulièrement d'appliquer ton lineBreakMode à  tous tes paragraphes de ton texte via un NSParagraphStyle plutôt que via le label ?

J'y ai pensé mais je n'ai pas tenté (je pensais pouvoir m'en passer). Je vais voir ça du coup. Merci !

Si cela fonctionne ça va grandement me simplifier certaines cell (plus qu'un seul label) et le calcul de leur hauteur.

AliGator

Ceci dit ce genre de soucis ne m'étonne qu'à  moitié, vu comment j'ai galéré quand j'ai implémenté OHAttributedLabel à  l'époque (ma classe date pourtant d'iOS 4 ! Mais la problématique n'a pas changé depuis), vu que les troncatures de lignes et paragraphe c'est un peu le boxon à  gérer lors du layout avec CoreText... du moins moi je ne les gère pas pour du multiligne car CoreText déconne quand on commence à  le faire (mais il y a une suggestion de workaround dans l'issue #3 de mon GitHub, qui ne résout pas tout mais bidouille pour le cas le plus commun)

Kubernan

'AliGator' a écrit:

Ceci dit ce genre de soucis ne m'étonne qu'à  moitié, vu comment j'ai galéré quand j'ai implémenté OHAttributedLabel à  l'époque (ma classe date pourtant d'iOS 4 ! Mais la problématique n'a pas changé depuis), vu que les troncatures de lignes et paragraphe c'est un peu le boxon à  gérer lors du layout avec CoreText... du moins moi je ne les gère pas pour du multiligne car CoreText déconne quand on commence à  le faire (mais il y a une suggestion de workaround dans l'issue #3 de mon GitHub, qui ne résout pas tout mais bidouille pour le cas le plus commun)

Oh purée le travail de fou que tu as fait avec OHAttributedLabel !



CoreText je ne connais pas tant que ça. J'ai un vague souvenir d'avoir lu quelque part dans la doc (mais je ne retrouve pas où) une certaine incompatibilité avec UIKit (c'est peut être le "boxon" ton tu parles) ainsi qu'un problème de gestion de kern qui ne garantissait pas le retour ligne. Un truc comme ça.

Je pensais que tout était résolu depuis.



Je vais poursuivre mes tests.

AliGator

Tu veux dire que tu ne connaissais pas OHAttributedLabel ? Pourtant c'est une de mes fiertés, très connue sur le web et très suivie sur GitHub /wink.png' class='bbc_emoticon' alt=';)' /> (Par exemple quand j'ai été embauché dans ma boite actuelle j'ai eu la surprise de la retrouver utilisée partout dans les projets qu'ils avaient faits avant que j'arrive ^^) Y'a même des gens de la communauté qui ont rajouté ma classe -- ainsi qu'OHHTTPStubs -- au fameux CocoaPods pour moi, sans que je demande, donc limite à  faire la pub pour moi ^^



D'ailleurs même si tu n'utilises pas le composant OHAttributedLabel (si ton application n'est que iOS6 only et donc que tu peux directement utiliser UILabel maintenant pour afficher ton NSAttributedString par exemple), rien ne t'empêche d'utiliser ma catégorie "NSAttributedStrings+Attributes" qui rajoute plein de méthodes de commodité pour construire tes attributedString, mais également mes OHASMarkupParsers (par exemple OHASBasicMarkupParser) pour construire tes attributedString complexes en seulement une ou 2 lignes, en utilisant du markup dans ton texte pour indiquer le formattage. Je te laisse regarder ma démo pour voir comment ça peut être utile.

Mais si tu fais ça attention en effet aux attributs pour lesquels Apple a malencontreusement réutilisé le même nom entre CoreText et UIKit alors que les 2 n'attendent pas le même type... cf l'issue #89 sur mon GitHub expliquant ce bug Apple.



Donc pour en revenir au problème initial, l'incompatibilité avec UIKit que tu as lue c'est sans doute sur les polices ? Les polices CoreText et UIKit n'étant pas exactement pareilles même si en général il y a une correspondance pour la plupart, mais surtout dans une NSAttributedString quand tu affectes une polices à  une portion de texte, tu affectes le même attribut (NSFontAttributeName de mémoire) que ce soit pour utiliser ton NSAttributedString avec CoreText ou UIKit, saut que CoreText attend que tu mettes pour cet attribut une CTFontRef et l'interprète comme tel, alors que UIKit attend une UIFont.

J'en parle dans une de mes rares issue encore ouvertes sur ce projet (et elle fait partie de celles indiquées comme "Apple Bug" justement...)

Kubernan

Hééé non je ne connaissais pas OHAttributedLabel (pas taper). Mais je vais l'utiliser car là  je ne m'en sors pas (ce n'est pas mieux avec paragraphe) ! Leur méthode [url="file:///Users/kubernan/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.AppleiOS6.1.iOSLibrary.docset/Contents/Resources/Documents/documentation/UIKit/Reference/NSAttributedString_UIKit_Additions/Reference/Reference.html#//apple_ref/occ/instm/NSAttributedString/boundingRectWithSize:options:context:"]boundingRectWithSize:options:context:[/url] semble également souffrir d'un bug (soupçon confirmé par mes recherches google ; bug noté fin janvier 2013).



Apple ne connaissait pas OHAttributedLabel non plus visiblement /huh.gif' class='bbc_emoticon' alt='???' />



Merci pour ton aide !