(et ensuite les m=EAmes op=E9rations pour s'arr=EAter au caract=E8re nul)=
Pas de chance, comme r=E9sultat, j'ai =E7a :
Times New Roman : 0 (ansi)
Times New Roman CE : 2 (symbol)
Times New Roman CYR : 2 (symbol)
Times New Roman Greek : 1 (defaultcharacter)
Times New Roman TUR : 1 (defaultcharacter)
Times New Roman Baltic : 1 (defaultcharacter)
En r=E9sum=E9, aucun rapport avec la question.
Pour =EAtre bien s=FBr que nous parlons de la m=EAme chose : le nom de la=
=20
police sans rien derri=E8re, correspond au script d'Europe Occidentale.=20
Avec le suffixe CE, nous avons la m=EAme police dans le script d'Europe=20
Centrale. Avec le suffixe CYR, pour cyrillique, si je me rappelle bien=20
on s'adresse aux Russes (et on =E9vite soigneusement de proposer =E7a par=
=20
d=E9faut, par exemple, en Tch=E9quie). Avec le suffixe TUR, il s'agit du =
script turc. Et Baltic ... vous devinez.
Je ne mets pas la main sur la sauvegarde de ce que j'ai fait il y a=20
quelques ann=E9es, alors il faut que je le refasse. Apparemment, je ne li=
s=20
pas la valeur au bon endroit, quelqu'un pourrait-il me remettre dans le=20
droit chemin ?
Aussi bien, peut-=EAtre dois-je simplement conserver le suffixe derri=E8r=
e=20
le nom de la police ? J'ai bien l'impression que =E7a va =EAtre =E7a, mai=
s ce=20
que j'ai recueilli dans FontScript, alors, c'est quoi ?
S'il s'agit du contrôle ListView (associé à ListImage), tu peux le remplacer par un ListBox ou un ComboBox, mais tu perdras l'image associée à la fonte (TT : True Type, ou Fonte Imprimante). Une autre option beaucoup plus lourde consiste à utiliser le contrôle ListView présent dans ComCtl32.dll (qui fait partie d l'O.S.). L'ocx ne fait que l'encapsuler :
<http://btmtz.mvps.org/listview/>
Mais là, y'a du sport ;-)
Effectivement, on dirait qu'il y a là de la matière intéressante, à condition d'être prêt à passer plus de cinq minutes dessus.
Mais je me suis un peu trompé. Le lien précité donne des exemples intéressants, notamment sur le Drag and Drop, Mais utilise tout de même l'ocx.
Je peux juste te dire que chez moi, il y a 4 fontes Hangul :
Ah, ben là, je bosse pour un client qui commence à faire un gros commerce avec la Corée, mais sur les postes normalisés de la boîte, il n'y a pas encore de police de cette catégorie. ça va peut-être leur faire un truc à ajouter.
Cela étant, à chacun son boulot, je leur développe une base, et ils se débrouillent pour disposer des bonnes polices là où ils en ont besoin :)
De toute manière, installer les polices coréennes sur les postes en France n'a de sens que si les Français sont en mesure de lire la langue correspondante, et il ne semble pas que ce soit massivement le cas, les échanges se font plutôt en Anglais.
J'ignore d'ailleurs si quelqu'un a une idée bien précise du protocole de validation pour ce qui concerne le support des polices asiatiques. Je soupçonne d'ailleurs qu'il serait de bon goût que j'avance des propositions dans ce domaine. Si quelqu'un a une idée en la matière, ça peut aider, même si j'ignore aujourd'hui ce qu'en fera le client.
En fait, quand je parles de 4 polices, il s'agit d'un seul fichier .ttf, c'est une fonte internationale. Voir ici les standards Unicode :
Ils ont été mis en place dans le but de remplacer les pages de code, et doivent permettre d'afficher toutes les langues. Ici google news en coréen, et en arabe :
<http://cjoint.com/?lqxesfMmfb>
on pourrait auss bien bien demander : Japon, Taiwan ou Israel, mais aussi bien sûr français ou anglais.
Mais il y a peut être d'autres manières de procéder.
-- Cordialement,
Jacques.
Bonjour Gloops,
Gloops a écrit :
[...]
[pb intégration ocx]
S'il s'agit du contrôle ListView (associé à ListImage), tu peux le
remplacer par un ListBox ou un ComboBox, mais tu perdras l'image
associée à la fonte (TT : True Type, ou Fonte Imprimante). Une autre
option beaucoup plus lourde consiste à utiliser le contrôle ListView
présent dans ComCtl32.dll (qui fait partie d l'O.S.). L'ocx ne fait que
l'encapsuler :
<http://btmtz.mvps.org/listview/>
Mais là, y'a du sport ;-)
Effectivement, on dirait qu'il y a là de la matière intéressante, à
condition d'être prêt à passer plus de cinq minutes dessus.
Mais je me suis un peu trompé. Le lien précité donne des exemples
intéressants, notamment sur le Drag and Drop, Mais utilise tout de même
l'ocx.
Je peux juste te dire que chez moi, il y a 4 fontes Hangul :
Ah, ben là, je bosse pour un client qui commence à faire un gros
commerce avec la Corée, mais sur les postes normalisés de la boîte, il
n'y a pas encore de police de cette catégorie. ça va peut-être leur
faire un truc à ajouter.
Cela étant, à chacun son boulot, je leur développe une base, et ils se
débrouillent pour disposer des bonnes polices là où ils en ont besoin :)
De toute manière, installer les polices coréennes sur les postes en
France n'a de sens que si les Français sont en mesure de lire la langue
correspondante, et il ne semble pas que ce soit massivement le cas, les
échanges se font plutôt en Anglais.
J'ignore d'ailleurs si quelqu'un a une idée bien précise du protocole de
validation pour ce qui concerne le support des polices asiatiques. Je
soupçonne d'ailleurs qu'il serait de bon goût que j'avance des
propositions dans ce domaine. Si quelqu'un a une idée en la matière, ça
peut aider, même si j'ignore aujourd'hui ce qu'en fera le client.
En fait, quand je parles de 4 polices, il s'agit d'un seul fichier .ttf,
c'est une fonte internationale. Voir ici les standards Unicode :
Ils ont été mis en place dans le but de remplacer les pages de code, et
doivent permettre d'afficher toutes les langues. Ici google news en
coréen, et en arabe :
<http://cjoint.com/?lqxesfMmfb>
on pourrait auss bien bien demander : Japon, Taiwan ou Israel, mais
aussi bien sûr français ou anglais.
Mais il y a peut être d'autres manières de procéder.
S'il s'agit du contrôle ListView (associé à ListImage), tu peux le remplacer par un ListBox ou un ComboBox, mais tu perdras l'image associée à la fonte (TT : True Type, ou Fonte Imprimante). Une autre option beaucoup plus lourde consiste à utiliser le contrôle ListView présent dans ComCtl32.dll (qui fait partie d l'O.S.). L'ocx ne fait que l'encapsuler :
<http://btmtz.mvps.org/listview/>
Mais là, y'a du sport ;-)
Effectivement, on dirait qu'il y a là de la matière intéressante, à condition d'être prêt à passer plus de cinq minutes dessus.
Mais je me suis un peu trompé. Le lien précité donne des exemples intéressants, notamment sur le Drag and Drop, Mais utilise tout de même l'ocx.
Je peux juste te dire que chez moi, il y a 4 fontes Hangul :
Ah, ben là, je bosse pour un client qui commence à faire un gros commerce avec la Corée, mais sur les postes normalisés de la boîte, il n'y a pas encore de police de cette catégorie. ça va peut-être leur faire un truc à ajouter.
Cela étant, à chacun son boulot, je leur développe une base, et ils se débrouillent pour disposer des bonnes polices là où ils en ont besoin :)
De toute manière, installer les polices coréennes sur les postes en France n'a de sens que si les Français sont en mesure de lire la langue correspondante, et il ne semble pas que ce soit massivement le cas, les échanges se font plutôt en Anglais.
J'ignore d'ailleurs si quelqu'un a une idée bien précise du protocole de validation pour ce qui concerne le support des polices asiatiques. Je soupçonne d'ailleurs qu'il serait de bon goût que j'avance des propositions dans ce domaine. Si quelqu'un a une idée en la matière, ça peut aider, même si j'ignore aujourd'hui ce qu'en fera le client.
En fait, quand je parles de 4 polices, il s'agit d'un seul fichier .ttf, c'est une fonte internationale. Voir ici les standards Unicode :
Ils ont été mis en place dans le but de remplacer les pages de code, et doivent permettre d'afficher toutes les langues. Ici google news en coréen, et en arabe :
<http://cjoint.com/?lqxesfMmfb>
on pourrait auss bien bien demander : Japon, Taiwan ou Israel, mais aussi bien sûr français ou anglais.
Mais il y a peut être d'autres manières de procéder.
