Re: Representative glyphs for combining kannada signs

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Mar 21 2006 - 21:43:10 CST

  • Next message: Peter Constable: "RE: Representative glyphs for combining kannada signs"

    From: "Antoine" <Antoine@Leca-Marti.org>
    > Philippe Verdy wrote:
    >> And IE cannot then select another font listed in the "font-family:"
    >> CSS style.
    >
    > Quelque chose me dit que mettre Arial Unicode dans une feuille de style est
    > une /mauvaise/ idée : la police n'est pas librement accessible (légalement),
    > elle requiert une licence (Office) qui la lie de plus en plus à une
    > plateforme donnée, elle a des problèmes de rendu, elle pèse son poids, enfin
    > bref elle accumule les inconvénients.

    Je n'ai pas dit qu'une feuilledestyle sur le Webdevrait spécifier UNIQUEMENT cette police. Mais il est très courant quecette police soit listée car elle permet un support meilleur de l'écriture Latine et IPA, et de quelques autres écritures, par rapport à l'Arial de base, ou même par rapport aux pseudo-polices "serif" et "sans-serif" par défaut des navigateurs.

    Dès le moment où un site doit lister au moins une police pour certains systèmes, cette spécification va faire que les polices par défauts définies par l'utilisateur ne seront PLUS utilisées. La solution serait alors que les sites ne spécifient AUCUNE police, mais supposent que ces polices sont configurées toutes correctement par l'utilisateur dans son navigateur.

    Malheureusement la complexité de ce réglage, et le fait que nombre d'utilisateurs n'aiment pas du tout les choix par défaut des navigateurs qui sont d'utiliser une police sérif par défaut (Times New Roman dans IE sous Windows pourl'écriture latine), difficile à lire à l'écran, fait que la police choisie par l'utilisateur, qui peut être pratique parfois pour bien lire la plupart des textes latins à l'écran, ne fonctionnera pas pour lire tous les textes latins des sites web.

    Aussi les visiteurs se plaignent de ne pas pouvoir lire le contenu àcause de leur réglages personnels. Ils demandent donc auxauteurs de site de préciser les polices utilisables pour lire correctement le contenu. Sur un site vraiment international comme Wikipédia par exemple (ce pourrait être lesite de Mathématica, ou un site consacré aux langues...), où un support étendu du Latin est nécessaire, il faut bien préciser une autre police que celle par défaut des navigateurs (polices sérif, Times New Roman sous Windows) ou des réglagescourants des utilisateurs (Arial, voire Arial Unicode MS pour ceux qui l'ont, et veulent visiter les sites qui utilisent des caractères latins étendus sans l'indiquer par un forçage de police).

    > Par contre, l'avoir en défaut local a plus de sens. La seule chose, c'est
    > qu'il ne faut pas la sélectionner pour les écritures qu'elle ne supporte pas
    > (ce qui tombe sous le sens écrit comme cela).

    Tant que c'est pour afficher du Latin, OK. Mais l'inclusion trop imcomplète des écritures commel'Oriya danscette police est plus un bogue de cette police, qui est normalement conçue pour Windows, sur un système qui va l'utiliser avec Uniscribe, sachant très bien qu'Uniscribe demande des tables OT supplémentaires.

    Peut-être qu'à l'origine, Uniscribe ne demandait pas ces tables et affichait les polices telles quelles(sans réordonnancement, ...). Mais le fait d'avoir modifié Uniscribe a cassé cette supposition (que les auteurs de la police AUMS savaient fausse). Hors Uniscribe a d'abord été modifié dans *Office* (là même où l'on trouve la police *AUMS*, donc c'est le même produit). Il en ressort que c'est un bogue de compatibilité d'Office, puisque non seulement cette mise à jour d'Uniscribe n'a pas amélioré les choses, mais a en fait cassé des écritures entières, faute d'avoir corrigé en même temps la police AUMS qui fait partie du même produit mis à jour.

    Il en résulte un système où AUMS est voulu, demandé, et recommandé par les utilisateurs pour le support de l'écriture latine, mais pose des tas de problèmes avec les écritures incomplètes mal supportées.

    En mettant à jour Uniscribe dans Office, Microsoft aurait mieux fait de mettre à jour la police AUMS pour en SUPPRIMER TOTALEMENT les écritures incomplètes, afin que d'autres polices puissent supporter ces écritures. Hors le fait qu'AUMS paraisse dans une feuille de style web, ou soit sélectionnée par l'utilisateur pour l'écriture latine (et soit même prise comme police possible de repli/fallback dans Uniscribe pour certains blocs!) empêche la prise en compte des autres polices.

    J'ai réellement le cas insoluble où il est impossible de régler le navigateur ou de concevoir une feuille de style capable d'afficher en même temps toutes les écritures, qui peuvent cependant être corectement affichées individuellement, quitte à casser l'affichage correct d'une autre écriture.

    Ce cas insoluble survient justement entre les écritures comme Oriya (celles incomplètes, et même erronées, dans AUMS) et l'écriture latine complète: impossible d'avoir les deuxensembles simultanément, sauf en utilisant pour les deux ensembles des "polices géantes Unicode" comme Code2000 (mais à qui il manque trop de ligatures, et dont le design est loin d'être soigné et lisible à l'écran).

    > Après, se plaindre qu'elle ne devrait pas être sélectionnable, c'est un
    > autre souci, cf. supra.

    Dans l'immédiat, laseule chose que j'aitrouvé àfaire est de DESINSTALLER/EFFACER complètement AUMS du système. Pour le support du Latin, je passe par une autre police sans-sérif, restreinte aux seuls caractères latins.

    Il faut aussi noter que la quasi-totalité des polices ont des caractères latins de base. Donc on ne peut pas les mettre en premier dans une feuille de style, faute de quoion perdrait les caractères Latins étendus. Ces polices sont donc placées normalement après la police Latine étendue dans une feuille de style.

    Si j'avais quelquechose d'autre à demander à Microsoft ou aux auteurs de polices, ce serait d'arrêter d'inclure le jeu Latin de base trop incomplet dans les polices d'autres écritures. Lavie serait nettement plus facile avec des polices conçues séparément:
    * Polices Latine+Grec+Cyrillique+Ponctuation générale
    * Polices de symboles géométriques et mathématiques (y compris letterlike).
    * Polices Arabes
    * Polices Hébreues
    * Polices Devanagari
    * Polices Gurmukhi...
    * Polices Tibétaines
    * Polices Coréennes (sans Latin!)
    * Polices Han (plusieurs styles chinois traditionnel, simplifié, japonais)
    * Polices Japonaises (Hira-Kata), normalement combinées à une police Han et ne contenant aucun "demi-"caractère Latin (maiscontenant les formes pleines carrées)

    On pourrait ensuite créer des polices composites, mais seulement en prenant des ensembles cohérents et complets. L'import partiel des glyphes sans les tables OT requises doit être BANNI dans toute police composite.



    This archive was generated by hypermail 2.1.5 : Tue Mar 21 2006 - 21:47:40 CST