Filtrer les polices de symboles

Sylvain Collange

06/01/2006 à 14:15

AMcD a écrit :

Sylvain Collange wrote:

(*) Avis du chantre de la normalisation : Unicode ne dit rien sur la
représentation des glyphes, donc si un créateur de police décide de
représenter les A par des flèches et les B par des smileys c'est son
problème.

Oui. Mon ironie venait de là. Aucune norme n'empêchera quelqu'un de faire
comme il l'entend. Surtout un grand éditeur très riche qui, si les standards
ne lui conviennent pas, alors les ignorera et utilisera les siens.

> Malheureusement, au détriment d'une simplicité et uniformisation
> générale, c'est vrai.

D'accord sur le principe.

Mais "si les standards ne lui conviennent pas", c'est donc que le
standard était mauvais, donc soit la norme s'adapte pour suivre
l'éditeur, soit elle disparait par darwinisme et est remplacée par le
standard plus ou moins propriétaire de l'éditeur.

Et en ce qui concerne Microsoft, le problème ne se pose ni pour C++ (ils
ont investi beaucoup pour le respect de la norme dernièrement) ni pour
Unicode (c'est un des principaux membres du consortium).

Pour rajouter une couche sur mon antipathie des normes, je dirai que si rien
n'est prévu pour imposer des règles sur le sglyphes, ben c'est que la norme
est mal faite. Une vraie norme, à mon sens, se doit d'être indétournable.

Attends, déjà quand tu vois tous les problèmes politiques que ça pose de
savoir si tel caractère utilisé dans deux langues différentes est bien
le même, tu imagines si Unicode se mettait à imposer des règles sur
l'esthétique des glyphes?...

D'ailleurs si un créateur de police a le droit d'afficher les B comme
des smileys, toi tu n'as pas le droit d'écrire B en pensant obtenir un
smiley. Ce que dit Unicode c'est que un B ça reste un B, quelle que soit
la façon dont tu le représente.

Les polices avec le flag SYMBOL_CHARSET c'est différent, elles datent
d'avant Unicode (ou sont faites par des gens qui n'en ont jamais entendu
parler). Très bon exemple des conséquences d'une absence totale de norme
correcte.

Tout au moins, offrir des avantages tels qu'il est absolument idiot de ne
pas en profiter et donc, qu'il serait idiot de ne pas suivre.

Et Unicode ne correspond pas à cette description?

--
Sylvain

AMcD a écrit :

Sylvain Collange wrote:

(*) Avis du chantre de la normalisation : Unicode ne dit rien sur la
représentation des glyphes, donc si un créateur de police décide de
représenter les A par des flèches et les B par des smileys c'est son
problème.

Oui. Mon ironie venait de là. Aucune norme n'empêchera quelqu'un de faire
comme il l'entend. Surtout un grand éditeur très riche qui, si les standards
ne lui conviennent pas, alors les ignorera et utilisera les siens.

> Malheureusement, au détriment d'une simplicité et uniformisation
> générale, c'est vrai.

D'accord sur le principe.

Mais "si les standards ne lui conviennent pas", c'est donc que le
standard était mauvais, donc soit la norme s'adapte pour suivre
l'éditeur, soit elle disparait par darwinisme et est remplacée par le
standard plus ou moins propriétaire de l'éditeur.

Et en ce qui concerne Microsoft, le problème ne se pose ni pour C++ (ils
ont investi beaucoup pour le respect de la norme dernièrement) ni pour
Unicode (c'est un des principaux membres du consortium).

Pour rajouter une couche sur mon antipathie des normes, je dirai que si rien
n'est prévu pour imposer des règles sur le sglyphes, ben c'est que la norme
est mal faite. Une vraie norme, à mon sens, se doit d'être indétournable.

Attends, déjà quand tu vois tous les problèmes politiques que ça pose de
savoir si tel caractère utilisé dans deux langues différentes est bien
le même, tu imagines si Unicode se mettait à imposer des règles sur
l'esthétique des glyphes?...

D'ailleurs si un créateur de police a le droit d'afficher les B comme
des smileys, toi tu n'as pas le droit d'écrire B en pensant obtenir un
smiley. Ce que dit Unicode c'est que un B ça reste un B, quelle que soit
la façon dont tu le représente.

Les polices avec le flag SYMBOL_CHARSET c'est différent, elles datent
d'avant Unicode (ou sont faites par des gens qui n'en ont jamais entendu
parler). Très bon exemple des conséquences d'une absence totale de norme
correcte.

Tout au moins, offrir des avantages tels qu'il est absolument idiot de ne
pas en profiter et donc, qu'il serait idiot de ne pas suivre.

Et Unicode ne correspond pas à cette description?

--
Sylvain

Vous avez filtré cet utilisateur ! Consultez son message

AMcD a écrit :

Sylvain Collange wrote:

(*) Avis du chantre de la normalisation : Unicode ne dit rien sur la
représentation des glyphes, donc si un créateur de police décide de
représenter les A par des flèches et les B par des smileys c'est son
problème.

Oui. Mon ironie venait de là. Aucune norme n'empêchera quelqu'un de faire
comme il l'entend. Surtout un grand éditeur très riche qui, si les standards
ne lui conviennent pas, alors les ignorera et utilisera les siens.

> Malheureusement, au détriment d'une simplicité et uniformisation
> générale, c'est vrai.

D'accord sur le principe.

Mais "si les standards ne lui conviennent pas", c'est donc que le
standard était mauvais, donc soit la norme s'adapte pour suivre
l'éditeur, soit elle disparait par darwinisme et est remplacée par le
standard plus ou moins propriétaire de l'éditeur.

Et en ce qui concerne Microsoft, le problème ne se pose ni pour C++ (ils
ont investi beaucoup pour le respect de la norme dernièrement) ni pour
Unicode (c'est un des principaux membres du consortium).

Pour rajouter une couche sur mon antipathie des normes, je dirai que si rien
n'est prévu pour imposer des règles sur le sglyphes, ben c'est que la norme
est mal faite. Une vraie norme, à mon sens, se doit d'être indétournable.

Attends, déjà quand tu vois tous les problèmes politiques que ça pose de
savoir si tel caractère utilisé dans deux langues différentes est bien
le même, tu imagines si Unicode se mettait à imposer des règles sur
l'esthétique des glyphes?...

D'ailleurs si un créateur de police a le droit d'afficher les B comme
des smileys, toi tu n'as pas le droit d'écrire B en pensant obtenir un
smiley. Ce que dit Unicode c'est que un B ça reste un B, quelle que soit
la façon dont tu le représente.

Les polices avec le flag SYMBOL_CHARSET c'est différent, elles datent
d'avant Unicode (ou sont faites par des gens qui n'en ont jamais entendu
parler). Très bon exemple des conséquences d'une absence totale de norme
correcte.

Tout au moins, offrir des avantages tels qu'il est absolument idiot de ne
pas en profiter et donc, qu'il serait idiot de ne pas suivre.

Et Unicode ne correspond pas à cette description?

--
Sylvain

Arnold McDonald \(AMcD\)

06/01/2006 à 15:20

Sylvain Collange wrote:

Mais "si les standards ne lui conviennent pas", c'est donc que le
standard était mauvais, donc soit la norme s'adapte pour suivre
l'éditeur, soit elle disparait par darwinisme et est remplacée par le
standard plus ou moins propriétaire de l'éditeur.

Oui, c'est effectivement comme cela que ça se passe. Cela étant, quand ça
convient pa sà un éditeur, c'est souvent parce qu'il ne faisait pas partie
du groupe de travail ou qu'il n'a pas pu imposer SON standard à lui qui lui
a coûté cher à développer. Les éditeurs travaillent d'abord pour eux avant
le bien être général.

Attends, déjà quand tu vois tous les problèmes politiques que ça pose
de savoir si tel caractère utilisé dans deux langues différentes est
bien le même, tu imagines si Unicode se mettait à imposer des règles
sur l'esthétique des glyphes?...

Bof, pour moi, ils auraient du créer un UNICODE 64 bits, ce qui aurait suffi
à tout le monde. Ensuite, définir des classes. ALphabétique, numérique,
symbole (divisés en sous-catégories), etc. À une époque, je me suis un peu
intéressé à UNICODE, j'en ai retenu principalement que c'est le bin's total.
Déjà, tu trouves très peu de fontes UNICODE, je veux dire qui contiennent
tous les glyphes retenus.

Les polices avec le flag SYMBOL_CHARSET c'est différent, elles datent
d'avant Unicode (ou sont faites par des gens qui n'en ont jamais
entendu parler). Très bon exemple des conséquences d'une absence
totale de norme correcte.

Hmmm. Si j'ai bon souvenir, il y a deux ans, j'avais besoin de caractères
runiques. J'ai utilisé une bonne quinzaine de polices UNICODE (enfin
soit-disant), pas deux avait le même jeu. Pas deux ! Alors, UNICODE, heu...

Et Unicode ne correspond pas à cette description?

Ben, ya pas que pour les runes. Je ne sais plus trop quel autre jeu de
symboles j'avais besoin. Là aussi, Adobe, Microsoft ou Agfa, aucun n'avait
le même glyphe sur certains codes UNICODE. Pour moi, c'est quand même une
norme assez nébuleuse hein :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Sylvain Collange wrote:

Mais "si les standards ne lui conviennent pas", c'est donc que le
standard était mauvais, donc soit la norme s'adapte pour suivre
l'éditeur, soit elle disparait par darwinisme et est remplacée par le
standard plus ou moins propriétaire de l'éditeur.

Oui, c'est effectivement comme cela que ça se passe. Cela étant, quand ça
convient pa sà un éditeur, c'est souvent parce qu'il ne faisait pas partie
du groupe de travail ou qu'il n'a pas pu imposer SON standard à lui qui lui
a coûté cher à développer. Les éditeurs travaillent d'abord pour eux avant
le bien être général.

Attends, déjà quand tu vois tous les problèmes politiques que ça pose
de savoir si tel caractère utilisé dans deux langues différentes est
bien le même, tu imagines si Unicode se mettait à imposer des règles
sur l'esthétique des glyphes?...

Bof, pour moi, ils auraient du créer un UNICODE 64 bits, ce qui aurait suffi
à tout le monde. Ensuite, définir des classes. ALphabétique, numérique,
symbole (divisés en sous-catégories), etc. À une époque, je me suis un peu
intéressé à UNICODE, j'en ai retenu principalement que c'est le bin's total.
Déjà, tu trouves très peu de fontes UNICODE, je veux dire qui contiennent
tous les glyphes retenus.

Les polices avec le flag SYMBOL_CHARSET c'est différent, elles datent
d'avant Unicode (ou sont faites par des gens qui n'en ont jamais
entendu parler). Très bon exemple des conséquences d'une absence
totale de norme correcte.

Hmmm. Si j'ai bon souvenir, il y a deux ans, j'avais besoin de caractères
runiques. J'ai utilisé une bonne quinzaine de polices UNICODE (enfin
soit-disant), pas deux avait le même jeu. Pas deux ! Alors, UNICODE, heu...

Et Unicode ne correspond pas à cette description?

Ben, ya pas que pour les runes. Je ne sais plus trop quel autre jeu de
symboles j'avais besoin. Là aussi, Adobe, Microsoft ou Agfa, aucun n'avait
le même glyphe sur certains codes UNICODE. Pour moi, c'est quand même une
norme assez nébuleuse hein :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain Collange wrote:

Mais "si les standards ne lui conviennent pas", c'est donc que le
standard était mauvais, donc soit la norme s'adapte pour suivre
l'éditeur, soit elle disparait par darwinisme et est remplacée par le
standard plus ou moins propriétaire de l'éditeur.

Oui, c'est effectivement comme cela que ça se passe. Cela étant, quand ça
convient pa sà un éditeur, c'est souvent parce qu'il ne faisait pas partie
du groupe de travail ou qu'il n'a pas pu imposer SON standard à lui qui lui
a coûté cher à développer. Les éditeurs travaillent d'abord pour eux avant
le bien être général.

Attends, déjà quand tu vois tous les problèmes politiques que ça pose
de savoir si tel caractère utilisé dans deux langues différentes est
bien le même, tu imagines si Unicode se mettait à imposer des règles
sur l'esthétique des glyphes?...

Bof, pour moi, ils auraient du créer un UNICODE 64 bits, ce qui aurait suffi
à tout le monde. Ensuite, définir des classes. ALphabétique, numérique,
symbole (divisés en sous-catégories), etc. À une époque, je me suis un peu
intéressé à UNICODE, j'en ai retenu principalement que c'est le bin's total.
Déjà, tu trouves très peu de fontes UNICODE, je veux dire qui contiennent
tous les glyphes retenus.

Les polices avec le flag SYMBOL_CHARSET c'est différent, elles datent
d'avant Unicode (ou sont faites par des gens qui n'en ont jamais
entendu parler). Très bon exemple des conséquences d'une absence
totale de norme correcte.

Hmmm. Si j'ai bon souvenir, il y a deux ans, j'avais besoin de caractères
runiques. J'ai utilisé une bonne quinzaine de polices UNICODE (enfin
soit-disant), pas deux avait le même jeu. Pas deux ! Alors, UNICODE, heu...

Et Unicode ne correspond pas à cette description?

Ben, ya pas que pour les runes. Je ne sais plus trop quel autre jeu de
symboles j'avais besoin. Là aussi, Adobe, Microsoft ou Agfa, aucun n'avait
le même glyphe sur certains codes UNICODE. Pour moi, c'est quand même une
norme assez nébuleuse hein :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Bertrand Lenoir-Welter

06/01/2006 à 17:27

Sylvain Collange :

Je verrais plutôt une blacklist déjà remplie par défaut avec les polices
foireuses connues et éventuellement modifiable par l'utilisateur.

Ouais, c'est merdique mais je crois qu'il n'y a pas d'autre solution. Je
vais l'envisager.

Je me suis amusé à lister mes polices installées en examinant leurs
divers flags. Tout ce que je peux dire, c'est que quasiment aucune ne
les respecte à part celles fournies en standard avec Windows. Par
exemple, aucune de mes nombreuses polices script n'a le flag
lfPitchAndFamily / FF_SCRIPT sauf BrushScript. Même les flags FF_ROMAN
(avec sérifs) et FF_SWISS (sans sérifs) sont rarement respectés. Et je
parle pas non plus du flag FF_MODERN (c'est à dire à empattement fixe),
actif pour beaucoup de polices à taille variable, y compris des
renommées genre Garamond, AvantGarde, Lucida ou Futura.

Bref, c'est le souk, mais il est vrai que je vois pas trop comment on
pourrait imposer de respecter les flags. Si quelqu'un s'amuse à créer
une police romane et l'enregistrer comme étant sans sérifs, qui va
vérifier ? En fait, vu le nombre délirant de polices existantes, c'est
quand même dommage qu'il n'y ait pas une sorte de classification
arborescente à au moins deux niveaux (famille + nom). Je veux dire dans
Windows, un répertoire Fonts avec sous-répertoires, ce qui permettrait à
l'utilisateur de les déplacer ou aller les chercher dans l'un ou l'autre.

Question stupide, tant qu'on y est : y'a moyen de modifier les flags
CharSet et PitchAndFamily d'une police installée ? Ca me permettrait
d'éviter de me palucher la gestion d'une liste noire...

Sylvain Collange

06/01/2006 à 17:57

AMcD wrote:

Bof, pour moi, ils auraient du créer un UNICODE 64 bits, ce qui aurait suffi
à tout le monde.

Je crois pas que personne se soit plaint du manque de place dans les 20
et quelques bits alloués actuellement...

Ensuite, définir des classes. ALphabétique, numérique,
symbole (divisés en sous-catégories), etc.

Ce n'est pas exactement ce qui est défini dans la section 4.5?
http://www.unicode.org/versions/Unicode4.0.0/ch04.pdf#G124142

À une époque, je me suis un peu
intéressé à UNICODE, j'en ai retenu principalement que c'est le bin's total.
Déjà, tu trouves très peu de fontes UNICODE, je veux dire qui contiennent
tous les glyphes retenus.

Parce que ça existe ça? Avec plus de 100000 caractères, ça ferait du
boulot...
En plus, un des gros avantages d'Unicode, c'est que le répertoire est
ouvert, il s'y ajoute des caractères tous les jours (ou presque). Donc
il faudrait constament maintenir la police à jour...

Hmmm. Si j'ai bon souvenir, il y a deux ans, j'avais besoin de caractères
runiques. J'ai utilisé une bonne quinzaine de polices UNICODE (enfin
soit-disant), pas deux avait le même jeu. Pas deux ! Alors, UNICODE, heu...

Tu veux dire que les mêmes caractères étaient à des endroits différents?
Ou bien que le sous-ensemble d'Unicode décrit par chaque police était
différent des autres? Si c'est ça c'est tout à fait normal et je ne vois
pas le problème.

Il y a quelques polices là :
http://www.alanwood.net/unicode/fonts_windows.html#runic

Ben, ya pas que pour les runes. Je ne sais plus trop quel autre jeu de
symboles j'avais besoin. Là aussi, Adobe, Microsoft ou Agfa, aucun n'avait
le même glyphe sur certains codes UNICODE. Pour moi, c'est quand même une
norme assez nébuleuse hein :-).

Bah c'est quand-même pas trop dûr de vérifier dans la norme en question.

la norme :
http://www.unicode.org/versions/Unicode4.1.0/
les tables de caractères :
http://www.unicode.org/charts/

En plus c'est la seule norme informatique que je connaisse qui contienne
des passages culturels sur l'alphabet étrusque ou sur la différence
entre un abjad et un abugida. ;-)

--
Sylvain

AMcD wrote:

Bof, pour moi, ils auraient du créer un UNICODE 64 bits, ce qui aurait suffi
à tout le monde.

Je crois pas que personne se soit plaint du manque de place dans les 20
et quelques bits alloués actuellement...

Ensuite, définir des classes. ALphabétique, numérique,
symbole (divisés en sous-catégories), etc.

Ce n'est pas exactement ce qui est défini dans la section 4.5?
http://www.unicode.org/versions/Unicode4.0.0/ch04.pdf#G124142

À une époque, je me suis un peu
intéressé à UNICODE, j'en ai retenu principalement que c'est le bin's total.
Déjà, tu trouves très peu de fontes UNICODE, je veux dire qui contiennent
tous les glyphes retenus.

Parce que ça existe ça? Avec plus de 100000 caractères, ça ferait du
boulot...
En plus, un des gros avantages d'Unicode, c'est que le répertoire est
ouvert, il s'y ajoute des caractères tous les jours (ou presque). Donc
il faudrait constament maintenir la police à jour...

Hmmm. Si j'ai bon souvenir, il y a deux ans, j'avais besoin de caractères
runiques. J'ai utilisé une bonne quinzaine de polices UNICODE (enfin
soit-disant), pas deux avait le même jeu. Pas deux ! Alors, UNICODE, heu...

Tu veux dire que les mêmes caractères étaient à des endroits différents?
Ou bien que le sous-ensemble d'Unicode décrit par chaque police était
différent des autres? Si c'est ça c'est tout à fait normal et je ne vois
pas le problème.

Il y a quelques polices là :
http://www.alanwood.net/unicode/fonts_windows.html#runic

Ben, ya pas que pour les runes. Je ne sais plus trop quel autre jeu de
symboles j'avais besoin. Là aussi, Adobe, Microsoft ou Agfa, aucun n'avait
le même glyphe sur certains codes UNICODE. Pour moi, c'est quand même une
norme assez nébuleuse hein :-).

Bah c'est quand-même pas trop dûr de vérifier dans la norme en question.

la norme :
http://www.unicode.org/versions/Unicode4.1.0/
les tables de caractères :
http://www.unicode.org/charts/

En plus c'est la seule norme informatique que je connaisse qui contienne
des passages culturels sur l'alphabet étrusque ou sur la différence
entre un abjad et un abugida. ;-)

--
Sylvain

Vous avez filtré cet utilisateur ! Consultez son message

AMcD wrote:

Bof, pour moi, ils auraient du créer un UNICODE 64 bits, ce qui aurait suffi
à tout le monde.

Je crois pas que personne se soit plaint du manque de place dans les 20
et quelques bits alloués actuellement...

Ensuite, définir des classes. ALphabétique, numérique,
symbole (divisés en sous-catégories), etc.

Ce n'est pas exactement ce qui est défini dans la section 4.5?
http://www.unicode.org/versions/Unicode4.0.0/ch04.pdf#G124142

À une époque, je me suis un peu
intéressé à UNICODE, j'en ai retenu principalement que c'est le bin's total.
Déjà, tu trouves très peu de fontes UNICODE, je veux dire qui contiennent
tous les glyphes retenus.

Parce que ça existe ça? Avec plus de 100000 caractères, ça ferait du
boulot...
En plus, un des gros avantages d'Unicode, c'est que le répertoire est
ouvert, il s'y ajoute des caractères tous les jours (ou presque). Donc
il faudrait constament maintenir la police à jour...

Hmmm. Si j'ai bon souvenir, il y a deux ans, j'avais besoin de caractères
runiques. J'ai utilisé une bonne quinzaine de polices UNICODE (enfin
soit-disant), pas deux avait le même jeu. Pas deux ! Alors, UNICODE, heu...

Tu veux dire que les mêmes caractères étaient à des endroits différents?
Ou bien que le sous-ensemble d'Unicode décrit par chaque police était
différent des autres? Si c'est ça c'est tout à fait normal et je ne vois
pas le problème.

Il y a quelques polices là :
http://www.alanwood.net/unicode/fonts_windows.html#runic

Ben, ya pas que pour les runes. Je ne sais plus trop quel autre jeu de
symboles j'avais besoin. Là aussi, Adobe, Microsoft ou Agfa, aucun n'avait
le même glyphe sur certains codes UNICODE. Pour moi, c'est quand même une
norme assez nébuleuse hein :-).

Bah c'est quand-même pas trop dûr de vérifier dans la norme en question.

la norme :
http://www.unicode.org/versions/Unicode4.1.0/
les tables de caractères :
http://www.unicode.org/charts/

En plus c'est la seule norme informatique que je connaisse qui contienne
des passages culturels sur l'alphabet étrusque ou sur la différence
entre un abjad et un abugida. ;-)

--
Sylvain

Arnold McDonald \(AMcD\)

06/01/2006 à 18:24

Sylvain Collange wrote:

AMcD wrote:
Bof, pour moi, ils auraient du créer un UNICODE 64 bits, ce qui
aurait suffi à tout le monde.

Je crois pas que personne se soit plaint du manque de place dans les
20 et quelques bits alloués actuellement...

Chez moi, le UNICODE est géré sur 16 bits (plates-formes Windows). Si je ne
m'abuse, ces 65.536 possibilités n'autorisent pas l'intégralité des kanjis
japonais, coréens et chinois...

Déjà, tu trouves très peu de fontes UNICODE, je veux
dire qui contiennent tous les glyphes retenus.

Parce que ça existe ça? Avec plus de 100000 caractères, ça ferait du
boulot...

Puet-être, mais ce serait utile !

Tu veux dire que les mêmes caractères étaient à des endroits
différents? Ou bien que le sous-ensemble d'Unicode décrit par chaque
police était différent des autres?

Je veux dire que les mêmes caractères étaient à des endroits différents
suivant les polices. Et, mieux, parfois des caractères différents entre
polices. Eh oui, les normes, tout le monde ne les suit pas...

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Arnold McDonald \(AMcD\)

06/01/2006 à 18:29

Bertrand Lenoir-Welter wrote:

Si quelqu'un s'amuse à créer
une police romane et l'enregistrer comme étant sans sérifs, qui va
vérifier ?

Qui peut l'en empêcher surtout !?

Question stupide, tant qu'on y est : y'a moyen de modifier les flags
CharSet et PitchAndFamily d'une police installée ?

Heu, à part via un éditeur de fonte...

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Sylvain Collange

06/01/2006 à 19:17

Bertrand Lenoir-Welter wrote:

Sylvain Collange :

Je verrais plutôt une blacklist déjà remplie par défaut avec les
polices foireuses connues et éventuellement modifiable par l'utilisateur.

Ouais, c'est merdique mais je crois qu'il n'y a pas d'autre solution. Je
vais l'envisager.

Sinon il y a peut-être moyen de récupérer des infos directement dans le
fichier .ttf. Apparement le flag "symbol character set" apparait à
plusieurs endroits différents dans le fichier.
(ch. 2 des specs TrueType
http://www.microsoft.com/typography/specs/default.htm)

Je me suis amusé à lister mes polices installées en examinant leurs
divers flags. Tout ce que je peux dire, c'est que quasiment aucune ne
les respecte à part celles fournies en standard avec Windows.

Intéressant... Et en les examinant avec
http://www.microsoft.com/typography/TrueTypeProperty21.mspx ?

Bref, c'est le souk, mais il est vrai que je vois pas trop comment on
pourrait imposer de respecter les flags. Si quelqu'un s'amuse à créer
une police romane et l'enregistrer comme étant sans sérifs, qui va
vérifier ? En fait, vu le nombre délirant de polices existantes, c'est
quand même dommage qu'il n'y ait pas une sorte de classification
arborescente à au moins deux niveaux (famille + nom). Je veux dire dans
Windows, un répertoire Fonts avec sous-répertoires, ce qui permettrait à
l'utilisateur de les déplacer ou aller les chercher dans l'un ou l'autre.

Je crois que toutes ces infos sont censées suivre la norme PANOSE
(encore une...)
En fait il y a déjà une fonctionnalité de ce genre dans le répertoire
fonts : on peut demander à l'explorateur de les trier par similarité par
rapport à une police donnée. Ce qui est marrant c'est que certaines
polices ne sont même pas similaires à elles-mêmes...

Question stupide, tant qu'on y est : y'a moyen de modifier les flags
CharSet et PitchAndFamily d'une police installée ? Ca me permettrait
d'éviter de me palucher la gestion d'une liste noire...

J'imagine que ça implique de modifier les fichiers .ttf... Pas vraiment
une bonne idée AMA...

--
Sylvain

Bertrand Lenoir-Welter wrote:

Sylvain Collange :

Je verrais plutôt une blacklist déjà remplie par défaut avec les
polices foireuses connues et éventuellement modifiable par l'utilisateur.

Ouais, c'est merdique mais je crois qu'il n'y a pas d'autre solution. Je
vais l'envisager.

Sinon il y a peut-être moyen de récupérer des infos directement dans le
fichier .ttf. Apparement le flag "symbol character set" apparait à
plusieurs endroits différents dans le fichier.
(ch. 2 des specs TrueType
http://www.microsoft.com/typography/specs/default.htm)

Je me suis amusé à lister mes polices installées en examinant leurs
divers flags. Tout ce que je peux dire, c'est que quasiment aucune ne
les respecte à part celles fournies en standard avec Windows.

Intéressant... Et en les examinant avec
http://www.microsoft.com/typography/TrueTypeProperty21.mspx ?

Bref, c'est le souk, mais il est vrai que je vois pas trop comment on
pourrait imposer de respecter les flags. Si quelqu'un s'amuse à créer
une police romane et l'enregistrer comme étant sans sérifs, qui va
vérifier ? En fait, vu le nombre délirant de polices existantes, c'est
quand même dommage qu'il n'y ait pas une sorte de classification
arborescente à au moins deux niveaux (famille + nom). Je veux dire dans
Windows, un répertoire Fonts avec sous-répertoires, ce qui permettrait à
l'utilisateur de les déplacer ou aller les chercher dans l'un ou l'autre.

Je crois que toutes ces infos sont censées suivre la norme PANOSE
(encore une...)
En fait il y a déjà une fonctionnalité de ce genre dans le répertoire
fonts : on peut demander à l'explorateur de les trier par similarité par
rapport à une police donnée. Ce qui est marrant c'est que certaines
polices ne sont même pas similaires à elles-mêmes...

Question stupide, tant qu'on y est : y'a moyen de modifier les flags
CharSet et PitchAndFamily d'une police installée ? Ca me permettrait
d'éviter de me palucher la gestion d'une liste noire...

J'imagine que ça implique de modifier les fichiers .ttf... Pas vraiment
une bonne idée AMA...

--
Sylvain

Vous avez filtré cet utilisateur ! Consultez son message

Bertrand Lenoir-Welter wrote:

Sylvain Collange :

Je verrais plutôt une blacklist déjà remplie par défaut avec les
polices foireuses connues et éventuellement modifiable par l'utilisateur.

Ouais, c'est merdique mais je crois qu'il n'y a pas d'autre solution. Je
vais l'envisager.

Sinon il y a peut-être moyen de récupérer des infos directement dans le
fichier .ttf. Apparement le flag "symbol character set" apparait à
plusieurs endroits différents dans le fichier.
(ch. 2 des specs TrueType
http://www.microsoft.com/typography/specs/default.htm)

Je me suis amusé à lister mes polices installées en examinant leurs
divers flags. Tout ce que je peux dire, c'est que quasiment aucune ne
les respecte à part celles fournies en standard avec Windows.

Intéressant... Et en les examinant avec
http://www.microsoft.com/typography/TrueTypeProperty21.mspx ?

Bref, c'est le souk, mais il est vrai que je vois pas trop comment on
pourrait imposer de respecter les flags. Si quelqu'un s'amuse à créer
une police romane et l'enregistrer comme étant sans sérifs, qui va
vérifier ? En fait, vu le nombre délirant de polices existantes, c'est
quand même dommage qu'il n'y ait pas une sorte de classification
arborescente à au moins deux niveaux (famille + nom). Je veux dire dans
Windows, un répertoire Fonts avec sous-répertoires, ce qui permettrait à
l'utilisateur de les déplacer ou aller les chercher dans l'un ou l'autre.

Je crois que toutes ces infos sont censées suivre la norme PANOSE
(encore une...)
En fait il y a déjà une fonctionnalité de ce genre dans le répertoire
fonts : on peut demander à l'explorateur de les trier par similarité par
rapport à une police donnée. Ce qui est marrant c'est que certaines
polices ne sont même pas similaires à elles-mêmes...

Question stupide, tant qu'on y est : y'a moyen de modifier les flags
CharSet et PitchAndFamily d'une police installée ? Ca me permettrait
d'éviter de me palucher la gestion d'une liste noire...

J'imagine que ça implique de modifier les fichiers .ttf... Pas vraiment
une bonne idée AMA...

--
Sylvain

Sylvain Collange

06/01/2006 à 19:36

AMcD wrote:

Chez moi, le UNICODE est géré sur 16 bits (plates-formes Windows). Si je ne
m'abuse, ces 65.536 possibilités n'autorisent pas l'intégralité des kanjis
japonais, coréens et chinois...

Non, avec les paires de substitutions (surrogates pairs) ça fait
1.114.112 possibilités. Suffisant pour le moment jusqu'à ce qu'on trouve
une autre bidouille (si le format sur 16 bits est encore dans la norme,
c'est bien uniquement à cause du poids de Microsoft, sinon on n'aurait
plus que l'UTF-8 et l'UTF-32).

Puet-être, mais ce serait utile !

Je ne suis pas convaincu. Déjà, ça voudrait dire se contenter d'une
seule police correcte, et puis le mécanisme de substitution de police
marche suffisement bien pour qu'un pack de polices différentes
recouvrant chacun un morceau fasse la même chose qu'une seule police
monolithique.

Je veux dire que les mêmes caractères étaient à des endroits différents
suivant les polices. Et, mieux, parfois des caractères différents entre
polices. Eh oui, les normes, tout le monde ne les suit pas...

Des polices d'avant Unicode 3.0, qui placent le runique dans des zones
privées en attendant la normalisation?
J'imagine mal un auteur de police taper délibérément dans une autre zone
que la sienne juste pour le plaisir de violer la norme...

--
Sylvain

Arnold McDonald \(AMcD\)

06/01/2006 à 20:07

Sylvain Collange wrote:

AMcD wrote:

Non, avec les paires de substitutions (surrogates pairs) ça fait
1.114.112 possibilités.

C'est géré par Windows ça ?

Des polices d'avant Unicode 3.0, qui placent le runique dans des zones
privées en attendant la normalisation?

Heu, c'était il y a deux ans. Quand à savoir ci c'était de l'UNICODE 3.0...

J'imagine mal un auteur de police taper délibérément dans une autre
zone que la sienne juste pour le plaisir de violer la norme...

Ben justement... Le truc c'était que quelques caractères seulement
différaient. C'était bien pénible. Je doute avoir gardé ça dans mes
archives, mais je vais fouiller voir si je te retrouve ces polices.
D'ailleurs, pour la petite histoire, je devais pas être le seul confronté à
ce problème. Si tu prends par exemple le texte de "voyage au centre de la
terre" de J. Vernes, tu remarqueras que suivant les éditeurs c'est pas tout
à fait les mêmes utilisés. 2-3 symboles seulement diffèrent, certes, mais
tout de même. Problème de codage chez les éditeurs :-) ? Je ne sais plus
trop sur quel autre cas j'étais tombé aussi.

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Sylvain Collange

06/01/2006 à 21:41

Arnold McDonald (AMcD) wrote:

Sylvain Collange wrote:
Non, avec les paires de substitutions (surrogates pairs) ça fait
1.114.112 possibilités.

C'est géré par Windows ça ?

Depuis Windows 2000 et IE 5 il me semble.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_192r.asp

--
Sylvain

Filtrer les polices de symboles

10 réponses

Veuillez sélectionner un problème