Discussion :

[Hibou57]

Kicou la Cie.

Avec une API Win9X/Me, je veux utiliser TextOutW (DrawTextW et ExTextOutW ne fonctionnent pas sous Win9X, donc seul TextOutW peut être utilisé), qui permet dessiner une chaîne Unicode (restreinte au BMP, API Win9X oblige).

Comme la police selectionnée par défaut dans les contextes de périphériques (DC) ne permet pas l'affichage de text Unicode, je prépart une police de caractère appropriée. La chaîne pouvant être multilingue (i.e. non reductible à une page de code unique), je me pose des questions sur la page de code à spécifier lors de la création de la police de caractère, qui est une police Unicode. J'ai entendu dire qu'il existe une pseudo page de code pour Unicode, mais j'ai oublié quel est ce code numérique. Et même si je le retrouve, je ne sais pas si je pourrais l'utiliser sous Win9X (parce que je ne sais pas si les polices Unicode sont identifiées comme telle par spécification ce code dans le fichier de police). J'utilise donc la valeur DEFAULT_CHARSET, qui me semble au premier abord la solution la plus immédiate (mais est-ce la meilleur solution... je l'ignore, et c'est justement l'objet de la question qui vient).

J'ai testé, et l'affichage fonctionne (mais sans gestion des scripts complexes bien sûre, qui sont affichés caractère par caractère, sans ligature). Pourtant la documentation de l'API Win95 dit qu'il est déconseillé d'utiliser cette valeur pour la propriété fdwCharSet (il est dit que l'affichage pourrait ne pas toujours être celui souhaité). Mais je ne vois pourtant pas d'autre(s) solution(s) pouvant s'appliquer à une police destinée à afficher du texte multilingue.

I n'y a pas de page de code pour Unicode dans les entêtes de l'API Win95. Pourtant Unicode était connu, et si une pseudo page de code Unicode existe, il n'est peut-être pas impossible qu'elle soit reconnue par l'API Win9X.

L'affichage fonctionne (même s'il n'y a pas des gestion des scripts complexes.. ce que je prévois quand même de faire pour ma librairie), et je pose donc surtout la question pour trouver la meilleur solution (s'il existe une meilleure solution).

Merci pour tous vos conseils si vous en avez.

[Médinoc]

Il n'y a pas de vrai unicode sous Windows 9x : La Microsoft Layer for Unicode (MSLU) ne fait que mapper vers les fonctions non-unicode.
Il y a eu un thread là-dessus il y a un moment...

[Hibou57]

Il n'y a pas de vrai unicode sous Windows 9x : La Microsoft Layer for Unicode (MSLU) ne fait que mapper vers les fonctions non-unicode.
Il y a eu un thread là-dessus il y a un moment...

Je sais, c'est même moi qui l'ai mené ce thread...

Cependant, je précise bien dans ce topic (celui-ci, pas l'autre), que TextOutW fonctionne bien pour les chaînes Unicode (je ne parle pas du support général, comme avec RegisterClassW dont il était question dans l'autre topic).

... pitié, ça marche, ne m'invente pas un problème qui n'existe pas

Par contre, erratum : j'ai indiqué par erreur que l'on peut employer également DrawTextW et ExTextOutW... mais sous Win9X, seul TextOutW a une implémentation Unicode. Je corrige donc le post initial, mais je précise ici pour ceux/celles qui aurait malheureusement déjà lu cette indication erronée.

En fait, Médinoc, certaines fonctions Unicode sont implémentées dès Windows 95... mais seulement certaines, et leur utilisation ne se fait pas toujours très naturellement.

[rigobert]

Je pense que tu confonds charset et page de code.

L'intérêt principal d'unicode est justement de s'affranchir des problèmes de pages de code (qui n'existent théoriquement plus dans ce contexte).
Ce qui n'est pas le cas du charset, qui est lui une espèce de sous-catégorie de police, indépendamment d'unicode.

Quoiqu'il en soit, il n'y a à ma connaissance aucune gestion globale satisfaisante des scripts complexes avant Windows 2000 ; sur les OS précédents, l'existant fonctionne tant bien que mal à coups de patches, addons et autres polices optionnelles, avec plein d'exceptions et de spécificités.
Ajouter encore à cela des considérations juridiques spécifiques (royalties) si une application est livrée avec des polices destinées à pallier un manque éventuel sur la plateforme cible.
Bref, de quoi passer de longues nuits blanches à s'arracher les cheveux !

[Médinoc]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Je pense que tu confonds charset et page de code.

L'intérêt principal d'unicode est justement de s'affranchir des problèmes de pages de code (qui n'existent théoriquement plus dans ce contexte).
Ce qui n'est pas le cas du charset, qui est lui une espèce de sous-catégorie de police, indépendamment d'unicode.

Je pense que cette confusion vient d'HTML et Cie.

[Hibou57]

Par définition, une page de code défini un charset, et sous des OS comme Win95, les deux termes sont interchangeables (mais c'est vrai que dans ce cas c'est un abus de langage).

Je profite de vos commentaires pour rebondir vers la question initiale : avec l'argument fdwCharSet (oui, c'est bien CharSet) de CreateFont, la meilleure solution pour faire référence au charset d'Unicode, est-elle bien de l'assigné à DEFAULT_CHARSET (les constantes de charset de l'API Windows étant en fait des identificateurs de page de code ), ou y at-il une autre valeur qui fait explicitement référence au charset de tout Unicode (ou au BMP) ?

Voili-voilou