Problème affichage attributed string dans un UILabel
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 :
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 :
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
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.
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.
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...)
Apple ne connaissait pas OHAttributedLabel non plus visiblement /huh.gif' class='bbc_emoticon' alt='???' />
Merci pour ton aide !