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

[rigobert]

Je pense que tu te trompes. Il y a évidemment un lien entre charset et page de code, mais ce n'est certainement pas équivalent:

- par exemple l'id du charset ANSI est 0 alors que la page de code pour l'ANSI (latin) est 1252.
- il y a moins de 20 charsets définis dans le platform SDK alors qu'il y a une centaine de pages de code potentiellement utilisables sous Windows.
- la notion de charset existe en unicode, celle de page de code non.

Enfin, pour répondre à ta question concernant la création de police, utiliser DEFAULT_CHARSET à partir de Windows 2000 est acceptable; sur les OS précédents, mieux vaut éviter :

Windows 95/98/Me: You can use the DEFAULT_CHARSET value to allow the name and size of a font to fully describe the logical font. If the specified font name does not exist, a font from any character set can be substituted for the specified font, so you should use DEFAULT_CHARSET sparingly to avoid unexpected results.

[Hibou57]

Je pense que tu te trompes. Il y a évidemment un lien entre charset et page de code, mais ce n'est certainement pas équivalent:

- par exemple l'id du charset ANSI est 0 alors que la page de code pour l'ANSI (latin) est 1252.
- il y a moins de 20 charsets définis dans le platform SDK alors qu'il y a une centaine de pages de code potentiellement utilisables sous Windows.
- la notion de charset existe en unicode, celle de page de code non.

Enfin, pour répondre à ta question concernant la création de police, utiliser DEFAULT_CHARSET à partir de Windows 2000 est acceptable; sur les OS précédents, mieux vaut éviter :

Peut-être que je me trompe, je vais vérifier quelque choses... mais peut-être aussi qu'on est deux à se tromper (mais pas sur les mêmes point) : le charset ansi ? ... mais tout d'abord les code ansi ne vont que de 0 à 127 (inclus), et le ANSI_CHARSET n'a rien à voir avec cela, puisqu'il permet d'afficher des code de 0 à 255. C'est comme le sont les DEFAULT_CHARSET et OEM_CHARSET, ce sont des valeurs propres à Windows (on le voit bien à leur valeurs particulières).

J'ai exactement cela (fichier d'entête qui ne provient pas du SDK, mais de la FSF, et date de 1996... je n'en connais pas de plus récents de cette source)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#define ANSI_CHARSET	(0)
#define DEFAULT_CHARSET	(1)
#define SYMBOL_CHARSET	(2)
#define SHIFTJIS_CHARSET	(128)
#define HANGEUL_CHARSET	(129)
#define GB2312_CHARSET	(134)
#define CHINESEBIG5_CHARSET	(136)
#define GREEK_CHARSET	(161)
#define TURKISH_CHARSET	(162)
#define HEBREW_CHARSET	(177)
#define ARABIC_CHARSET	(178)
#define BALTIC_CHARSET	(186)
#define RUSSIAN_CHARSET	(204)
#define THAI_CHARSET	(222)
#define EASTEUROPE_CHARSET	(238)
#define OEM_CHARSET	(255)

Les valeurs de SHIFTJIS_CHARSET à EASTEUROPE_CHARSET ne sont pas des pages de code alors ? J'y perd mon latin (sans jeux de mots).

Windows 95/98/Me: You can use the DEFAULT_CHARSET value to allow the name and size of a font to fully describe the logical font. If the specified font name does not exist, a font from any character set can be substituted for the specified font, so you should use DEFAULT_CHARSET sparingly to avoid unexpected results.

Je comprends bien ta citation. Mais elle ne répond pas à la question : y at-il un meilleur moyen que d'utiliser DEFAULT_CHARSET pour utiliser une police unicode ? Ou alors faut-il créer une police pour chaque page de code ? ... mais sa gaspille un peu la mémoire et les resources ça non ? D'autant qu'un police unicode peut répondre à un grand nombre de charset (ou page de code, à préciser)... bon, j'ai bien l'impression qu'il n'existe pas d'autre valeur.

Les implications de ta citation : si la police n'existe pas, alors une police de substitution est employé. Ce que j'en pense, c'est que c'est bien le comportement attendu dans une application digne de ce nom. Un(e) utilisateur(rice) préfère encore une police de substitution plutôt qu'un message d'erreur et aucun résultat. Et le problème ne se pose même pas si le nom de la police est tiré d'une liste des polices disponnible sur le système (ce qui est exactement ce que je fais).

Deuxième implication : l'utilisation de DEFAULT_CHARSET fait que la taille de la police fourni à CreateFont est interprété telle quelle, et non pas comme une taille logique, c'est à dire pas l'unitié, le point, qui est habituellement l'unité pour donne la taille d'une police. C'est bien ce que tu comprend aussi ? En tous cas, ça expliquerait pourquoi quand je spécifie taille 12, j'ai une police de 12 pixels, plus petites en fait que ce que j'obtiens dans un traitement de texte en spécifiant 12.

Troisième conscequence (indirect) : on risque donc de se retrouver avec une taille de police pour laquelle la police n'est normalement pas prévu. Là aussi, il se peut que le problème ne se pose pas si on emploie que des tailles standard supporté par toutes les polices (genre la taille 12).

Un chose m'intrigue, c'est que tout ça me fait penser à un autre flag que l'on peut passer à CreateFont, et qui a exactement la même fonction... bizarre.

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.

Le composant natif de Windows 2000 auquel tu fais référence, qui est Uniscribe, existe aussi en mise à jour des autres Windows (Win9X compris), par l'intermédiaire des mise à jour de Internet Explorer. Par exemple tu peux afficher l'Arabe sur une page Web sous Win9X, alors que ce n'était pas prévu à l'origine. C'est justement grâce à ce composant qui est natif sous Win2000, mais qui peut aussi être installer sur Win9X. Il y a plusieurs versions, chacune supportant plus de script que la précédente. Moi j'ai la troisième ou la quatrième version je crois, celle avec laquelle a été introduit le support du script Arabe.

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 !

Beh, je te rassure, il existe des polices Unicodes libres, et ce sont même justement des polices qui supportent un champ très large d'Unicode, comme par exemple la police CyberBit. Et il existe des polices spécifique libre pour d'autres jeux de caractères, par exemple des police latin/arabe, etc, etc. Le problème qui m'ennuie serait plutôt que les attributs de license des polices ne renseigne jamais rien ... par exemple si je vais dans les propriété de la police Tahoma Unicode, je n'ai aucune information, ... et j'ai entendu de certaines sources que cette police est librement distribuable, et d'autres sources qu'elle ne l'est peut-être pas.... alors je ne sais plus où j'en suis sur ce point (surtout que la police Tahoma est super importante, parce qu'elle est vraiment partout... et ce serait vraiment du importe quoi s'il s'avérait finalement qu'elle n'est pas librement distribuable)

Tiens Rigobert, tu peux trouver des polices ici : Unicode Fonts for Windows computers. Tu as la section « large fonts » pour les polices qui supportent un grand interval d'Unicode, et tu vois toute la variété et le choix que tu as pour tous les autres scripts (généralement ce sont de plus des polices mixtes, qui supportent au moins deux scripts)

@+

P.S. Désolé pour les fautes, je n'ai pas le temps de les corriger tout de suite... je repasserai demain pour ça

[rigobert]

le charset ansi ? ... mais tout d'abord les code ansi ne vont que de 0 à 127 (inclus), et le ANSI_CHARSET n'a rien à voir avec cela, puisqu'il permet d'afficher des code de 0 à 255. C'est comme le sont les DEFAULT_CHARSET et OEM_CHARSET, ce sont des valeurs propres à Windows (on le voit bien à leur valeurs particulières).

Si besoin est, je précise que tout ce que j'ai dit jusqu'à présent est évidemment à placer dans le contexte de Windows et de la terminologie MSDN.

Tu as raison : au sens strict, le charset identifié par la constante ANSI_CHARSET n'est pas exclusivement ansi. D'ailleurs, il suffit de regarder l'interface standard de sélection de police pour s'en convaincre : pour obtenir le charset ANSI_CHARSET sélectionné dans la structure LOGFONT associée, il faut choisir le "script occidental". Cherchez l'erreur !

C'est un exemple parmi d'autres, mais qui montre bien que MSDN, associé au platform SDK, contribue significativement à la confusion ambiante en faisant des raccourcis et pas mal d'abus de langage.

Les valeurs de SHIFTJIS_CHARSET à EASTEUROPE_CHARSET ne sont pas des pages de code alors ? J'y perd mon latin (sans jeux de mots).

cqfd

y at-il un meilleur moyen que d'utiliser DEFAULT_CHARSET pour utiliser une police unicode ? Ou alors faut-il créer une police pour chaque page de code ? ...

Read my lips : il n'y a pas de pages de code en unicode !

On peut AMHA ramener le choix du charset à utiliser pour la création et la sélection d'une police dans une application à 2 cas simples :

1. on sait dans quelle langue l'application est utilisée, auquel cas le charset à utiliser est implicite.

2. on ne le sait pas et dans ce cas on laisse l'utilisateur choisir au travers de l'interface standard. Cela suppose évidemment que l'application soit suffisamment flexible pour afficher correctement toute police choisie.

Les implications de ta citation : si la police n'existe pas, alors une police de substitution est employé. Ce que j'en pense, c'est que c'est bien le comportement attendu dans une application digne de ce nom. Un(e) utilisateur(rice) préfère encore une police de substitution plutôt qu'un message d'erreur et aucun résultat.

La substitution "silencieuse" n'est pas forcément l'idéal : ça dépend quels sont les critères d'acceptation de la police de remplacement. A l'arrivée le résultat obtenu peut être assez différent de ce à quoi on aurait pu s'attendre.
Ce que dit aussi MSDN (et que je n'avais pas repris), c'est que l'interprétation de DEFAULT_CHARSET est en plus différente à partir de Windows 2000.
Voilà, c'est tout ça ce qui me fait dire qu'il vaut mieux éviter d'utiliser cette valeur.

Deuxième implication : l'utilisation de DEFAULT_CHARSET fait que la taille de la police fourni à CreateFont est interprété telle quelle, et non pas comme une taille logique, c'est à dire pas l'unitié, le point, qui est habituellement l'unité pour donne la taille d'une police. C'est bien ce que tu comprend aussi ? En tous cas, ça expliquerait pourquoi quand je spécifie taille 12, j'ai une police de 12 pixels, plus petites en fait que ce que j'obtiens dans un traitement de texte en spécifiant 12.

Ca n'a rien à voir avec le charset !!

Le point et le pixel sont 2 unités différentes.
Le point vient du monde de l'imprimerie et il s'est donc naturellement imposé lorsque celle-ci est entrée dans l'ère informatique.

Pour un mapping écran la fonction CreateFont() prend des pixels comme hauteur.
Pour spécifier des points il faut d'abord les convertir en pixels à l'aide d'une formule ... que j'ai oubliée ... mais qui est facile à retrouver en cherchant un peu !

Le composant natif de Windows 2000 auquel tu fais référence, qui est Uniscribe, existe aussi en mise à jour des autres Windows (Win9X compris), par l'intermédiaire des mise à jour de Internet Explorer. Par exemple tu peux afficher l'Arabe sur une page Web sous Win9X, alors que ce n'était pas prévu à l'origine. C'est justement grâce à ce composant qui est natif sous Win2000, mais qui peut aussi être installer sur Win9X.

Oui. C'est à peu de chose de près ce que j'ai dit, sur un ton plus optimiste !
Le problème étant que rien n'oblige les utilisateurs de Win9x et NT à installer quelque module optionnel que ce soit.
Pose-toi la question de savoir si c'est vraiment à toi d'installer ce genre de composants, si c'est possible techniquement (comment déterminer ce qui manque, ce qui est à jour, ce qui ne l'est pas, comment intégrer les packs M$ à ton pack d'installation etc...), et enfin si tu le peux juridiquement parlant.
A défaut tu pourras toujours dire que c'est pas ta faute mais celle de Bill si ton appli ne marche pas, mais attention, ça peut énerver !

Beh, je te rassure, il existe des polices Unicodes libres, et ce sont même justement des polices qui supportent un champ très large d'Unicode, comme par exemple la police CyberBit.

Il faut se méfier de ce qui est dit "libre". En général ça ne l'est pas pour tout le monde, et en particulier pas pour les applications commerciales. Et je ne parle pas de l'obligation de résultat...
A voir.

[Hibou57]

Read my lips : il n'y a pas de pages de code en unicode !

Pas la peine de crier... je pensais au charset, par l'intermédiaire des CP... vu que les polices sous Win9X sont normalement restreinte à des CP, c'est-à-dire des charset de CP, il faut donner un CP spécial pour les ouvrire à des charset Unicode (je clos sur ce point, mais ta remarque est bonne quand même).

On peut AMHA ramener le choix du charset à utiliser pour la création et la sélection d'une police dans une application à 2 cas simples :

1. on sait dans quelle langue l'application est utilisée, auquel cas le charset à utiliser est implicite.

2. on ne le sait pas et dans ce cas on laisse l'utilisateur choisir au travers de l'interface standard. Cela suppose évidemment que l'application soit suffisamment flexible pour afficher correctement toute police choisie.

Je suis dans un troisième cas : celui du multilingue, avec plusieurs langues affichées à un même instant (au moins deux en tous cas, et même voir plus).

La substitution "silencieuse" n'est pas forcément l'idéal : ça dépend quels sont les critères d'acceptation de la police de remplacement. A l'arrivée le résultat obtenu peut être assez différent de ce à quoi on aurait pu s'attendre.
Ce que dit aussi MSDN (et que je n'avais pas repris), c'est que l'interprétation de DEFAULT_CHARSET est en plus différente à partir de Windows 2000.
Voilà, c'est tout ça ce qui me fait dire qu'il vaut mieux éviter d'utiliser cette valeur.

Oui, d'accord, mais il faut bien se décider pour une solution et en arriver à du concret. Disont alors que DEFAULT_CHARSET et la moins mauvaises des solution alors. Parce d'accord j'ai bien compris que cette solution pose des problème, mais je rappel la question intiale justement : y at-il une autre solution ? Parce que jusque maintenant, malgré les remarques sur le fait que cette solution ne soit pas parfaite, aucune autre n'a été apporté. Et je préfère une solution imparaite, qui a quand même des avantages, plutôt que pas de solution du tout, ce qui pose finalement encore plus de problème (sur ce point aussi, je crois qu'on peut clore... sauf si une alternative meilleur ou au moins aussi bonne fini par se présenter).

Ca n'a rien à voir avec le charset !!

Le point et le pixel sont 2 unités différentes.
Le point vient du monde de l'imprimerie et il s'est donc naturellement imposé lorsque celle-ci est entrée dans l'ère informatique.

Je sais, mais il semble que ce soit un effet de bord... et les parcours tordus qui arrive à une chose avec laquelle le parcours n'aurait normalement pas du mener sont nombreux... ce n'est pas pour rien si la question des effets de bord est si présente dans l'apprentissage du développeement. C'est tordus, mais ce qui est, est.

Pose-toi la question de savoir si c'est vraiment à toi d'installer ce genre de composants, si c'est possible techniquement (comment déterminer ce qui manque, ce qui est à jour, ce qui ne l'est pas, comment intégrer les packs M$ à ton pack d'installation etc...), et enfin si tu le peux juridiquement parlant.

That is one of the biggest questions

A défaut tu pourras toujours dire que c'est pas ta faute mais celle de Bill si ton appli ne marche pas, mais attention, ça peut énerver !

Pour ça rassure toi, je n'ai pas l'intention de m'amuser à ça...

Il faut se méfier de ce qui est dit "libre". En général ça ne l'est pas pour tout le monde, et en particulier pas pour les applications commerciales. Et je ne parle pas de l'obligation de résultat...
A voir.

Il me semble que oui, après un rapide survol... je te donnerai des liens vers les polices correspondantes, si je peux en trouver qui sont absolument fiables, au moins sur la question de la distribution (surtout que je n'ai pas envie de payer une licence de police pour des applications qui seront vendu pour deux cacahuètes... parce que je serai bien loin de rentrer dans mes frais... (tout confondu)... alors payer pour une licence de police, au pretexte que l'application serait commerciale, alors que cette application « commerciale » ne me rapporterait rien du tout.... non, il y a des limites quand même