Je ne vois pas ce que tu entends par "caractères qui ne peuvent pas être précomposés" ; s'ils ne peuvent être précomposés, ils ne peuvent être présentés sous forme d'un seul glyphe, si ?
Sans vouloir être pompeux, j'ai fait pas mal de tests cette nuit, et je pense que mes deux bouts de codes de la fin de la page précédentent gèrent tous les cas d'inversion de glyphes  <br />
Maintenant, faut voir ce que ça donne avec les trucs qui s'écrivent de droite à gauche, c'est sûr, et traiter le cas ; mais ils ne sont pas considérés comme glyphes... C'est sûr qu'il y a des cas où "inverser" ne veut rien dire (en Arabe par exemple...)
faut-il utiliser la représentation interne (utilisée par Apple)
Je tiens à contester ceci... On ne sait absolument rien de la représentation interne utilisée par Apple, -length et -characterAtIndex: sont des méthodes primitives permettant à toutes les méthodes définies dans l'interface NSString de fonctionner normalement avec n'importe laquelle de ses sous-classes. Mais absolument rien n'empêche Apple ou tout autre implémentateur de redéfinir les méthodes secondaires dans les sous-classes pour les adapter à leurs sous-classes, d'ailleurs Apple le conseille pour certaines méthodes. Donc rien n'empêche Apple, par exemple, d'utiliser un tableau de valeurs sur 32 bits et de compter les cases dont les 16 bits de poids fort sont à zéro comme un seul unichar et les autres comme étant 2 unichar. Tu peux même te faire une structure à la con contenant 2 unichar et retourner le nombre d'unichars "significatifs".
Les seuls recommandations d'Apple sur l'implémentation, c'est que la NSString ne stocke qu'un groupe de caractères et leur nombre. C'est-à -dire que dans une sous-classe de NSString tu ne vas pas indiquer la couleur du texte ou la police par exemple, mais à part ça tu fais ce que tu veux pour stocker ta chaà®ne de caractères.
C'est une supposition, compte tenu des contraintes d'optimisation de NSString. Je les vois mal utiliser une représentation interne en UTF-8 et sortir de l'UTF-16 quand on demande "getCharacters"Â
L'idée m'est venue d'aller voir la référence de CFString ; ben elle est plus aboutie que la doc de NSString  :o
CFString has two primitive functions, CFStringGetLength and CFStringGetCharacterAtIndex, that provide the basis for all other functions in its interface. The CFStringGetLength function returns the total number (in terms of UTF-16 code pairs) of characters in the string. The CFStringGetCharacterAtIndex function gives access to each character in the string by index, with index values starting at 0.
Par ailleurs, cette fonction est très intéressante : "CFStringGetCharactersPtr"
Return Value A pointer to a buffer of Unicode character, or NULL if the internal storage of theString does not allow this to be returned efficiently.
Discussion This function either returns the requested pointer immediately, with no memory allocations and no copying, or it returns NULL. If the latter is the result, call an alternative function such as CFStringGetCharacters function to extract the characters.
Whether or not this function returns a valid pointer or NULL depends on many factors, all of which depend on how the string was created and its properties. In addition, the function result might change between different releases and on different platforms. So do not count on receiving a non-NULL result from this function under any circumstances (except when the object is created with CFStringCreateMutableWithExternalCharactersNoCopy).
Si ça ne cause aucune allocation mémoire, mais que ça peut poser problème avec des "NoCopy", c'est que c'est forcément la représentation interne de CFString (et donc de NSString) Â ;)
[Edit] Je pourrais améliorer ma fonction d'inversion du coup avec ça, mais pas le courage (et dangereux pour les "NoCopy")
Il dit pas que ça pose un problème avec des NoCopy. Il dit que si la chaà®ne de caractères a été créé à partir de CFStringCreateMutableWithExternalCharactersNoCopy() tu es sûr que la fonction CFStringGetCharactersPtr() retournera un pointeur non-NULL et à fortiori il s'agira du pointeur qui a été passé à la première fonction. Mais tu as différente représentation interne, tu as la représentation sous forme de C-String et aussi sous forme de Pascal-String...
Il dit pas que ça pose un problème avec des NoCopy. Il dit que si la chaà®ne de caractères a été créé à partir de CFStringCreateMutableWithExternalCharactersNoCopy() tu es sûr que la fonction CFStringGetCharactersPtr() retournera un pointeur non-NULL et à fortiori il s'agira du pointeur qui a été passé à la première fonction.
Non, c'est moi qui suppose que ça pose problème avec des "noCopy" ; il y a une fonction "CFStringCreateWithBytesNoCopy" ; c'est une représentation externe, donc c'est sûr que là la représentation interne sera un pointeur opaque vers l'extérieur et un encodage ; sans copie, il ne passera pas le truc dans sa propre représentation interne UTF-16, et ne pourra répondre que "NULL" à "CFStringGetCharactersPtr".
Mais tu as différente représentation interne, tu as la représentation sous forme de C-String et aussi sous forme de Pascal-String...
Tu pinailles là , je parle de la représentation interne classique, c'est à dire justement quand "CFStringGetCharactersPtr" ne renvoie pas "NULL", ce qui est le cas la plupart du tempsÂ
Sinon, je peux faire un test dans ma fonction ; si elle renvoie NULL -> "error : too complex" (enfin de toute façon, dans ma fonction il y a copie, et conversion si ce n'est pas en représentation classique...)
Le truc c'est qu'en utilisant -stringWithString: il copie non seulement la chaà®ne de caractères mais aussi sa représentation. Donc à priori il n'y a pas de représentation "classique". ;D
Le truc c'est qu'en utilisant -stringWithString: il copie non seulement la chaà®ne de caractères mais aussi sa représentation. Donc à priori il n'y a pas de représentation "classique". ;D
Ouais, j'ai enlevé l'histoire de "stringWithString" ; c'est surtout que ça ne sert à rien, puisque j'utilise "getCharacters" de NSString et pas "CFStringGetCharactersPtr" de CFString
Et à priori "getCharacters" ne rate jamais (donc il doit faire la conversion en cas de représentation "exotique" on va dire puisque t'aimes pas "classique").
N'empêche que le fait que "CFStringGetCharactersPtr" n'alloue pas de mémoire prouve bien que "en général", il y a une représentation UTF-16 en interne, non ?
Je ne vois pas ce que tu entends par "caractères qui ne peuvent pas être précomposés" ; s'ils ne peuvent être précomposés, ils ne peuvent être présentés sous forme d'un seul glyphe, si ?
Ben si justement. Il y a certains caractères qui sont déjà existants sous leur forme précomposée dans la table des glyphes unicodes. C'est le cas par exemple de é è à ê etc. Mais ce n'est pas le cas de tous. C'est expliqué par exemple dans la norme ici : regarde la figure 5, le caractère "d" qui a 2 diacritiques (un point au dessus et un point en dessous) n'a pas de forme précomposée se représentant sous la forme d'un unique caractère : la forme NFC nécessite quand même 2 caractères pour la représenter. Et du coup, si tu inverses l'ordre des caractères de ta chaà®ne ainsi, le non-caractère/signe diacritique se retrouvera de l'autre côté lors de ton inversion et sera appliqué au glyphe d'à côté et non au "d" auquel il était appliqué à l'origine. Et c'est encore pire pour le cas du "q" auquel on adjoint un ou deux points (au dessus/en dessous). Pour celui-là il n'y a aucune forme précomposée existante. Donc [tt][str precomposedStringWithCanonicalMapping][/tt] ne fait que transformer les formes décomposées des caractères représentés dans la chaà®ne en leur version précomposée... pour les caractères pour lesquels cette forme est disponible !! Mais ce n'est pas le cas de tous les caractères. C'est d'ailleurs le but de la forme décomposée : à l'origine l'idée d'Unicode c'est d'exprimer séparément le caractère de base et son ou ses signes diacritiques appliqués, pour pouvoir gérer toutes les possibilités. Mais après comme il y a beaucoup de caractères à diacritiques qui sont souvent utilisés dans beaucoup de langues, comme le "é" ou le "à " en français, pour certains ils ont créé une forme précomposée... mais ils ne pouvaient pas prévoir tous les cas et toutes les formes précomposées non plus
Si tu fais une chaà®ne de caractères à partir d'un encodage spécifique ou à partir de caractères ASCII < 127 ce qui est tout à fait possible notamment en anglais, tu recevras un pointeur NULL. ;D
Le truc c'est qu'en utilisant -stringWithString: il copie non seulement la chaà®ne de caractères mais aussi sa représentation. Donc à priori il n'y a pas de représentation "classique". ;D
Si tu fais une chaà®ne de caractères à partir d'un encodage spécifique ou à partir de caractères ASCII < 127 ce qui est tout à fait possible notamment en anglais, tu recevras un pointeur NULL.  ;D
ça il faudra me le prouver (Parce que mes tests démontrent le contraire :P)
Donc [tt][str precomposedStringWithCanonicalMapping][/tt] ne fait que transformer les formes décomposées des caractères représentés dans la chaà®ne en leur version précomposée... pour les caractères pour lesquels cette forme est disponible !! Mais ce n'est pas le cas de tous les caractères. C'est d'ailleurs le but de la forme décomposée : à l'origine l'idée d'Unicode c'est d'exprimer séparément le caractère de base et son ou ses signes diacritiques appliqués, pour pouvoir gérer toutes les possibilités. Mais après comme il y a beaucoup de caractères à diacritiques qui sont souvent utilisés dans beaucoup de langues, comme le "é" ou le "à " en français, pour certains ils ont créé une forme précomposée... mais ils ne pouvaient pas prévoir tous les cas et toutes les formes précomposées non plus
OK, je commence à comprendre et c'est fort intéressant ! Mais dans ce cas, si il est représenté en forme précomposée sous la forme 0071 0323 0307, comment peut-on savoir au final si c'est le caractère q avec un point au-dessus et un point en-dessous, ou le caractère q suivi du caractère point en-dessous, suivi du caractère point au-dessus, ou même le caractère q avec un point en-dessous suivi du caractère point au-dessus ? (cas concret, comment un éditeur saura-t-il comment l'afficher !) ça reste LA zone d'ombre pour moi ???
Le truc c'est qu'en utilisant -stringWithString: il copie non seulement la chaà®ne de caractères mais aussi sa représentation. Donc à priori il n'y a pas de représentation "classique". ;D
2007-12-13 14:22:44.525 ReverseString[23933] ceci est une cString<br />2007-12-13 14:22:44.528 ReverseString[23933] 0x0<br />2007-12-13 14:22:44.529 ReverseString[23933] ceci est une cString<br />2007-12-13 14:22:44.529 ReverseString[23933] 0x304790
Alors, quid d'une représentation "classique" ? ;D
Bah disons que chez moi... Ton code me donne que des pointeurs NULL, alors soit c'est parce que je suis sous Leopard et toi sous Tiger et qu'ils ont largement modifier l'implémentation... Soit bah c'est bizarre.
OK, je vais essayer sous Leopard... ça m'étonne quand même qu'ils aient tout cassé la mécanique bien rôdée de CFString ???
Au fait, sous Tiger avec CFString, les encodages UTF-16 et UTF-32 que t'as donné au dessus existent déjà :P Comme quoi, CoreFoundation a toujours une longueur d'avance sur Foundataion !
Comme quoi, CoreFoundation a toujours une longueur d'avance sur Foundataion !
Normal, on dirait qu'Apple est réticent à modifier trop rapidement les bases de Cocoa, alors que pour les outils dont il est et a toujours été propriétaire comme les Cores, ils semblent moins frileux. ;D
Après tout, dans Core Graphics ont trouve des courbe de Bézier avec deux points de contrôle mais aussi un seul point alors que dans NSBezierPath il n'y a que celles avec 2 points de contrôle.
Je suis en tests sous Leopard, et tu as raison... "CFStringGetCharactersPtr" renvoie "NULL" dans la plupart des cas (même pour une string @";" ou "stringWithString") ; en fait, je n'ai pas trouvé de cas où il ne renvoyait pas "NULL".
J'ai également testé la copie de représentation interne :
2007-12-13 14:57:43.074 ReverseString[349] ceci est une cString<br />2007-12-13 14:57:43.074 ReverseString[349] ceci est une cString<br />2007-12-13 14:57:43.074 ReverseString[349] ceci<br />2007-12-13 14:57:43.074 ReverseString[349] ceci est une cString
Bingo...
Donc apparemment, pour je ne sais quelle raison obscure, ils ont cassé avec Leopard leur représentation interne UTF-16 pour une représentation pointeur opaque + encoding
ça a peut-être certains avantages, mais ça rend "getCharacters" beaucoup moins optimisé en tout cas. ??? (et au passage, ça détruit le code de tous ceux qui ont à leurs risques et périls utilisé "CFStringGetCharactersPtr", qui fonctionnait quasiment tout le temps hors cas "NoCopy" ;D)
Après tout, dans Core Graphics ont trouve des courbe de Bézier avec deux points de contrôle mais aussi un seul point alors que dans NSBezierPath il n'y a que celles avec 2 points de contrôle.
Et surtout dans CoreGraphics on peut dessiner à la fois le contour et l'intérieur, ce qu'on ne peut pas avec NSBezierPath... La loose :P (enfin je dis ça... ça a peut-être changé dans Leopard)
Après tout, dans Core Graphics ont trouve des courbe de Bézier avec deux points de contrôle mais aussi un seul point alors que dans NSBezierPath il n'y a que celles avec 2 points de contrôle.
Et surtout dans CoreGraphics on peut dessiner à la fois le contour et l'intérieur, ce qu'on ne peut pas avec NSBezierPath... La loose :P (enfin je dis ça... ça a peut-être changé dans Leopard)
Non ça n'a pas changé Mais bon ce sont juste deux appels différents, au final c'est toujours la même chose.
Après tout, dans Core Graphics ont trouve des courbe de Bézier avec deux points de contrôle mais aussi un seul point alors que dans NSBezierPath il n'y a que celles avec 2 points de contrôle.
Et surtout dans CoreGraphics on peut dessiner à la fois le contour et l'intérieur, ce qu'on ne peut pas avec NSBezierPath... La loose :P (enfin je dis ça... ça a peut-être changé dans Leopard)
Non ça n'a pas changé Mais bon ce sont juste deux appels différents, au final c'est toujours la même chose.
Ah ben non, on y perd vachement en performances quand même Il faut recalculer le contour deux fois avec Cocoa, et une seule fois avec CoreGraphics (enfin si leur truc est bien foutu bien sûr...) !
OK, je commence à comprendre et c'est fort intéressant ! Mais dans ce cas, si il est représenté en forme précomposée sous la forme 0071 0323 0307, comment peut-on savoir au final si c'est le caractère q avec un point au-dessus et un point en-dessous, ou le caractère q suivi du caractère point en-dessous, suivi du caractère point au-dessus, ou même le caractère q avec un point en-dessous suivi du caractère point au-dessus ? (cas concret, comment un éditeur saura-t-il comment l'afficher !) ça reste LA zone d'ombre pour moi ???
Ben c'est pas compliqué, il existe un "empty character" en unicode spécialement pour ça.
[*]Si tu veux un q avec un point au dessus et un en dessous, tu mets juste la suite de codepoints "q","point au dessus","point en dessous". [*]Si tu veux un qu avec un point au dessus, suivi d'un caractère constitué uniquement d'un point en dessous (qui normalement est un caractère de diacritique à appliquer à un caractère mais bon), tu mets juste la suite de code points "q","point au dessus","empty","point en dessous". --> Au rendu, il va voir que "q" est suivi d'un non-caractère diacritique "point au dessus" (et donc l'appliquer au glyphe), et ensuite on a fini le glyphe (car le caractère/codepoint suivant n'est pas un signe diacritique) et on reprend donc avec un 2e glyphe, qui se trouve être un glyphe "vide" (un peu comme le caractère "espace", limite), auquel on applique la diacritique "point en dessous".
De plus, je ne sais pas si c'est le cas pour tous les signes diacritiques ou pas, mais il existe souvent plusieurs variantes d'un même glyphe. Voir ce doc officiel : le caractère "accent circonflexe" a ainsi par exemple la variante 0x005E (circonflex accent) et 0x02C6 (modifier letter circonflex accent)... Donc encore une autre façon d'écrire les cas dont tu parles, permettant d'indiquer une diacritique sur aucun caractère au lieu de l'appliquer au caractère précédent.
OK... Du coup, c'est pas géré par la police, mais directement à l'affichage en superposant les caractères ? Je ferai des essais chez moi de mon script d'inversion sur ton "q pointé"
Hé, ho, je te permets pas ! Et puis d'abord mon q n'est pas simplement pointé, mais il a deux belles rondeurs :P (il pointe à la fois en haut et en bas)
Concernant les diacritiques combinatoires (le fait de pouvoir composer un symbole par concaténation d'un caractère et d'un signe diacritique dans la norme unicode), je vous renvoie sur ce post. Ici ça causait du caractère â, qui, en utf8, était possible d'écrire de 2 manières : une sur 2 octets, l'autre sur 3 !
Ouais Ce que j'avais pas compris c'est que les signes diacritiques étaient différents des signes équivalents et qu'on ne pouvait les utiliser seuls... Par exemple, pour l'accent aà¯gu : - Le signe : 0x00B4 - Le signe diacritique : 0x0301
En gros, tout ce qui est entre 0x0300 et 0x036F doit être précédé d'un autre caractère ; et quand on tombe sur un, on se décale pas avant d'afficher
Merci à AliGator, j'ai tout compris maintenant (ce qui ne m'empêchera pas de tester l'inversion de son "q doublement pointé tout en rondeurs") ;D
Réponses
Je ne vois pas ce que tu entends par "caractères qui ne peuvent pas être précomposés" ; s'ils ne peuvent être précomposés, ils ne peuvent être présentés sous forme d'un seul glyphe, si ?
Sans vouloir être pompeux, j'ai fait pas mal de tests cette nuit, et je pense que mes deux bouts de codes de la fin de la page précédentent gèrent tous les cas d'inversion de glyphes Â
Maintenant, faut voir ce que ça donne avec les trucs qui s'écrivent de droite à gauche, c'est sûr, et traiter le cas ; mais ils ne sont pas considérés comme glyphes...Â
C'est sûr qu'il y a des cas où "inverser" ne veut rien dire (en Arabe par exemple...)
Je tiens à contester ceci... On ne sait absolument rien de la représentation interne utilisée par Apple, -length et -characterAtIndex: sont des méthodes primitives permettant à toutes les méthodes définies dans l'interface NSString de fonctionner normalement avec n'importe laquelle de ses sous-classes.
Mais absolument rien n'empêche Apple ou tout autre implémentateur de redéfinir les méthodes secondaires dans les sous-classes pour les adapter à leurs sous-classes, d'ailleurs Apple le conseille pour certaines méthodes.
Donc rien n'empêche Apple, par exemple, d'utiliser un tableau de valeurs sur 32 bits et de compter les cases dont les 16 bits de poids fort sont à zéro comme un seul unichar et les autres comme étant 2 unichar.
Tu peux même te faire une structure à la con contenant 2 unichar et retourner le nombre d'unichars "significatifs".
Les seuls recommandations d'Apple sur l'implémentation, c'est que la NSString ne stocke qu'un groupe de caractères et leur nombre. C'est-à -dire que dans une sous-classe de NSString tu ne vas pas indiquer la couleur du texte ou la police par exemple, mais à part ça tu fais ce que tu veux pour stocker ta chaà®ne de caractères.
Je les vois mal utiliser une représentation interne en UTF-8 et sortir de l'UTF-16 quand on demande "getCharacters"Â
Par ailleurs, cette fonction est très intéressante : "CFStringGetCharactersPtr"
Si ça ne cause aucune allocation mémoire, mais que ça peut poser problème avec des "NoCopy", c'est que c'est forcément la représentation interne de CFString (et donc de NSString) Â ;)
[Edit] Je pourrais améliorer ma fonction d'inversion du coup avec ça, mais pas le courage (et dangereux pour les "NoCopy")
Il dit que si la chaà®ne de caractères a été créé à partir de CFStringCreateMutableWithExternalCharactersNoCopy() tu es sûr que la fonction CFStringGetCharactersPtr() retournera un pointeur non-NULL et à fortiori il s'agira du pointeur qui a été passé à la première fonction.
Mais tu as différente représentation interne, tu as la représentation sous forme de C-String et aussi sous forme de Pascal-String...
Non, c'est moi qui suppose que ça pose problème avec des "noCopy" ; il y a une fonction "CFStringCreateWithBytesNoCopy" ; c'est une représentation externe, donc c'est sûr que là la représentation interne sera un pointeur opaque vers l'extérieur et un encodage ; sans copie, il ne passera pas le truc dans sa propre représentation interne UTF-16, et ne pourra répondre que "NULL" à "CFStringGetCharactersPtr".
Tu pinailles là , je parle de la représentation interne classique, c'est à dire justement quand "CFStringGetCharactersPtr" ne renvoie pas "NULL", ce qui est le cas la plupart du tempsÂ
Sinon, je peux faire un test dans ma fonction ; si elle renvoie NULL -> "error : too complex"
(enfin de toute façon, dans ma fonction il y a copie, et conversion si ce n'est pas en représentation classique...)
Pour les cString, il y a NSSimpleCString :P
Ouais, j'ai enlevé l'histoire de "stringWithString" ; c'est surtout que ça ne sert à rien, puisque j'utilise "getCharacters" de NSString et pas "CFStringGetCharactersPtr" de CFString
Et à priori "getCharacters" ne rate jamaisÂ
N'empêche que le fait que "CFStringGetCharactersPtr" n'alloue pas de mémoire prouve bien que "en général", il y a une représentation UTF-16 en interne, non ?
Il y a certains caractères qui sont déjà existants sous leur forme précomposée dans la table des glyphes unicodes. C'est le cas par exemple de é è à ê etc.
Mais ce n'est pas le cas de tous. C'est expliqué par exemple dans la norme ici : regarde la figure 5, le caractère "d" qui a 2 diacritiques (un point au dessus et un point en dessous) n'a pas de forme précomposée se représentant sous la forme d'un unique caractère : la forme NFC nécessite quand même 2 caractères pour la représenter. Et du coup, si tu inverses l'ordre des caractères de ta chaà®ne ainsi, le non-caractère/signe diacritique se retrouvera de l'autre côté lors de ton inversion et sera appliqué au glyphe d'à côté et non au "d" auquel il était appliqué à l'origine.
Et c'est encore pire pour le cas du "q" auquel on adjoint un ou deux points (au dessus/en dessous). Pour celui-là il n'y a aucune forme précomposée existante.
Donc [tt][str precomposedStringWithCanonicalMapping][/tt] ne fait que transformer les formes décomposées des caractères représentés dans la chaà®ne en leur version précomposée... pour les caractères pour lesquels cette forme est disponible !! Mais ce n'est pas le cas de tous les caractères. C'est d'ailleurs le but de la forme décomposée : à l'origine l'idée d'Unicode c'est d'exprimer séparément le caractère de base et son ou ses signes diacritiques appliqués, pour pouvoir gérer toutes les possibilités. Mais après comme il y a beaucoup de caractères à diacritiques qui sont souvent utilisés dans beaucoup de langues, comme le "é" ou le "à " en français, pour certains ils ont créé une forme précomposée... mais ils ne pouvaient pas prévoir tous les cas et toutes les formes précomposées non plus
Si tu fais une chaà®ne de caractères à partir d'un encodage spécifique ou à partir de caractères ASCII < 127 ce qui est tout à fait possible notamment en anglais, tu recevras un pointeur NULL. ;D
Il ne semblerait pas
Alors, quid d'une représentation "classique" ? ;D
ça il faudra me le prouverÂ
(Parce que mes tests démontrent le contraire :P)
OK, je commence à comprendre et c'est fort intéressant !
Mais dans ce cas, si il est représenté en forme précomposée sous la forme 0071 0323 0307, comment peut-on savoir au final si c'est le caractère q avec un point au-dessus et un point en-dessous, ou le caractère q suivi du caractère point en-dessous, suivi du caractère point au-dessus, ou même le caractère q avec un point en-dessous suivi du caractère point au-dessus ? (cas concret, comment un éditeur saura-t-il comment l'afficher !)
ça reste LA zone d'ombre pour moi ???
Bah disons que chez moi... Ton code me donne que des pointeurs NULL, alors soit c'est parce que je suis sous Leopard et toi sous Tiger et qu'ils ont largement modifier l'implémentation... Soit bah c'est bizarre.
ça m'étonne quand même qu'ils aient tout cassé la mécanique bien rôdée de CFString ???
Au fait, sous Tiger avec CFString, les encodages UTF-16 et UTF-32 que t'as donné au dessus existent déjà :P
Comme quoi, CoreFoundation a toujours une longueur d'avance sur Foundataion !
Normal, on dirait qu'Apple est réticent à modifier trop rapidement les bases de Cocoa, alors que pour les outils dont il est et a toujours été propriétaire comme les Cores, ils semblent moins frileux. ;D
Après tout, dans Core Graphics ont trouve des courbe de Bézier avec deux points de contrôle mais aussi un seul point alors que dans NSBezierPath il n'y a que celles avec 2 points de contrôle.
J'ai également testé la copie de représentation interne :
Et le résultat est conforme à tes attentes
Retour sous Tiger pour tester le même code, mais je connais déjà le résultat, la représentation ne sera pas copiée à priori...
Bingo...
Donc apparemment, pour je ne sais quelle raison obscure, ils ont cassé avec Leopard leur représentation interne UTF-16 pour une représentation pointeur opaque + encoding
ça a peut-être certains avantages, mais ça rend "getCharacters" beaucoup moins optimisé en tout cas. ???
(et au passage, ça détruit le code de tous ceux qui ont à leurs risques et périls utilisé "CFStringGetCharactersPtr", qui fonctionnait quasiment tout le temps hors cas "NoCopy"Â ;D)
Et surtout dans CoreGraphics on peut dessiner à la fois le contour et l'intérieur, ce qu'on ne peut pas avec NSBezierPath... La loose :P
(enfin je dis ça... ça a peut-être changé dans Leopard)
Non ça n'a pas changé
Ah ben non, on y perd vachement en performances quand mêmeÂ
[*]Si tu veux un q avec un point au dessus et un en dessous, tu mets juste la suite de codepoints "q","point au dessus","point en dessous".
[*]Si tu veux un qu avec un point au dessus, suivi d'un caractère constitué uniquement d'un point en dessous (qui normalement est un caractère de diacritique à appliquer à un caractère mais bon), tu mets juste la suite de code points "q","point au dessus","empty","point en dessous".
--> Au rendu, il va voir que "q" est suivi d'un non-caractère diacritique "point au dessus" (et donc l'appliquer au glyphe), et ensuite on a fini le glyphe (car le caractère/codepoint suivant n'est pas un signe diacritique) et on reprend donc avec un 2e glyphe, qui se trouve être un glyphe "vide" (un peu comme le caractère "espace", limite), auquel on applique la diacritique "point en dessous".
De plus, je ne sais pas si c'est le cas pour tous les signes diacritiques ou pas, mais il existe souvent plusieurs variantes d'un même glyphe. Voir ce doc officiel : le caractère "accent circonflexe" a ainsi par exemple la variante 0x005E (circonflex accent) et 0x02C6 (modifier letter circonflex accent)... Donc encore une autre façon d'écrire les cas dont tu parles, permettant d'indiquer une diacritique sur aucun caractère au lieu de l'appliquer au caractère précédent.
Je ferai des essais chez moi de mon script d'inversion sur ton "q pointé"
Et puis d'abord mon q n'est pas simplement pointé, mais il a deux belles rondeurs :P (il pointe à la fois en haut et en bas)
Hum...
Ici ça causait du caractère â, qui, en utf8, était possible d'écrire de 2 manières : une sur 2 octets, l'autre sur 3 !
.
Ce que j'avais pas compris c'est que les signes diacritiques étaient différents des signes équivalents et qu'on ne pouvait les utiliser seuls...
Par exemple, pour l'accent aà¯gu :
- Le signe : 0x00B4
- Le signe diacritique : 0x0301
En gros, tout ce qui est entre 0x0300 et 0x036F doit être précédé d'un autre caractère ; et quand on tombe sur un, on se décale pas avant d'afficher
Merci à AliGator, j'ai tout compris maintenant
I'm screwed !
Même plus besoin de passer en precomposé canonique :P