| Accueil | Archives francophones de TidBITS | Sommaire des quatre derniers TidBITS traduits | L'Equipe francophone de TidBITS | Consignes pour traduire TidBITS | LexBITS |
TidBITS Logo

TidBITS#467/15-Feb-99

Pourquoi les pages web des utilisateurs de Windows affichent-elles les textes en tous petits caractères ? Geoff Duncan promène sa loupe sur cette question et nous éclaire sur les points picas, pixels ainsi que sur la question "pourquoi Mac OS et Windows n'affichent pas les caractères de la même façon". Adam de son coté nous entretient de la pérennité des URL sur la Toile (et nous donne des conseils pour lutter contre les liens brisés). Au chapitre nouveautés, nous commentons la sortie de "Macintosh Runtime" pour Java 2.1, des "Action Files 1.2", de "ShareWay IP 2.0", ainsi que MasterJuggler 2.0.2.

Sommaire:

Copyright 1998 TidBITS Electronic Publishing. Tous droits réservés.
Renseignements: info@tidbits.com Commentaires: editors@tidbits.com

Cette édition de TidBITS est rendue possible en partie grâce au soutien financier de:

Ce numéro est traduit de l'américain par:

MailBITS/15-Feb-99

Action Files 1.2 se substitue aux services de navigation de Mac OS -- La dernière mise à jour du célèbre Action Files, de Power On Software désactive l'interface de navigation du Mac OS d'Apple ("Navigation Services") pour lui substituer ses propres boîtes de dialogue offrant des services améliorés. Cette MAJ est d'autant plus bienvenue qu'elle apporte une foule de corrections de bogues. (Voir "Get a Piece of the Action Files" dans TidBITS-434). Actuellement, peu d'applications font appel aux "Navigation Services", qui remplacent les boîtes de dialogues traditionnelles d'ouverture et d'enregistrement de Mac OS ; une fois installé, l'interface d'Action Files 1.2 apparaît donc à la place des boîtes de dialogue d'ouverture et d'enregistrement de fichiers et ce quelque soit l'application utilisée. La version 1.2 a par ailleurs accru sa compatibilité avec Kaléidoscope, gère mieux les alias et les volumes de plus de 4 Go et permet une meilleure configuration des réglages par défaut du programme. Les possesseurs d'Action Files peuvent télécharger la nouvelle version (1,1 Mo) chez Power On Software et l'utiliser avec leur numéro de série actuel. [JLC]

http://www.actionutilities.com/site/html/products/ACTIONFiles.html
http://db.tidbits.com/getbits.acgi?tbart=04931

MasterJuggler compatible avec Mac OS 8.5 -- Alsoft vient de sortir une mise à jour gratuite de MasterJuggler, son logiciel de gestion de polices de caractères, mise à jour qui résout les quelques incompatibilités que l'utilitaire démontrait avec Mac OS 8.5. Outre la résolution de bogues mineurs constatés dans les menus déroulants, la mise à jour 2.0.2 de MasterJuggler Pro règle un problème avec Font Guardian, l'utilitaire qui vérifie l'intégrité d'une police, lorsque ce dernier scrute les ressources du Mac au démarrage. Pour plus d'infos cf. "Font Outfitters" dans TidBITS-334 pour un comparatif de MasterJuggler et de Suitcase 3.0. La mise à jour 2.0.2 est un fichier de 350K à télécharger. [JLC]

http://www.alsoft.com/MJPtech.html
http://db.tidbits.com/ getbits.acgi?tbart=00956

Open Door Networks lance ShareWay IP 2.0 -- Avec la mise à jour de ShareWay IP 2.0, Open Door Networks rend encore plus accessibles, via TCP/IP, les Mac partageant des fichiers et les serveurs AppleShare moins récents (voir "Share and Share IP Alike" dans TidBITS-436). La caractéristique majeure de ShareWay IP 2.0 est l'intégration d'un protocole de localisation de type SLP (Server Location Protocol) qui permet de trouver et d'accéder à un serveur en mode dynamique, un peu comme on sélectionne un serveur AppleTalk dans le Sélecteur. Les serveurs de type ShareWay IP 2.0 s'auto-enregistrent d'abord par SLP pour laisser ensuite aux utilisateurs le soin de choisir un serveur parmi la liste proposée dans la fonction "AFP Engage 2.0" qui fait partie des outils de connectivité proposés par Open Door. En outre, cette version 2.0 permet de travailler en tâche de fond, de se brancher en temps réel et offre une sécurité rehaussée. Etant donné que le module SLP de Apple est limité, seules les versions "Personal" et "Standard" de ShareWay IP ont été mises à jour vers la version 2.0 ; une éventuelle nouvelle version du module SLP d'Apple devrait permettre à Open Door de lancer une version multi-serveurs professionnelle de ShareWay IP. Les mises à jour sont gratuites pour les acheteurs ayant acquis le produit après le 3 janvier 1999 ; sinon elles coûtent entre $34 et $89 pour les utilisateurs individuels, en fonction de la version de ShareWay IP. Une remise s'applique aux détenteurs de licences multipostes. On peut télécharger des versions d'évaluation. [ACE]

http://www2.opendoor.com/gateway/sharewayip20.html
http://db.tidbits.com/getbits.acgi?tbart=04961

MRJ 2.1 : encore plus rapide et compatible avec Explorer -- Apple vient de sortir "Macintosh Runtime for Java 2.1", une nouvelle version qui offre des performances nettement améliorées par rapport aux anciennes versions de MRJ et qui est compatible avec le navigateur Microsoft Internet Explorer. (Microsoft avait abandonné son propre émulateur Java le lendemain de la décision du Tribunal donnant raison à Sun qui avait porté plainte pour contrer les modifications que Microsoft avait apportées à Java ; cf. TidBITS-456.) MRJ 2.1 respecte le cahier des charges du Java JDK 1.1.6 élaboré par Sun, et est par ailleurs compatible avec "Foundation Classes" du Sun Java ainsi qu'avec les outils de développement d'interfaces graphiques "Swing" (versions 1.0.3 et 1.1), et sait gérer des scripts AppleScript (bien que dans l'immédiat nous ne voyons pas l'utilité d'une telle compatibilité). Bien que MRJ 2.1 ne soit pas capable d'interpréter correctement toute la gamme des applets Java qui pullulent sur le Web (d'ailleurs la notice technique déconseille aux utilisateurs de trop s'approcher pour l'instant des jeux proposés par le serveur "Yahoo Games" Apple travaillant encore à la résolution de certains problèmes), MRJ 2.1 est néanmoins compatible avec Internet Explorer -assurez-vous simplement que dans les réglages Explorer vous avez indiqué que MRJ doit être utilisé comme émulateur Java. Il est par ailleurs entièrement compatible avec les environnements de programmation "Java development" sur Macintosh. Les navigateurs Netscape quant à eux utilisent leur propre version de Java et ne peuvent donc pas faire appel à MRJ pour l'instant.

MRJ 2.1 nécessite une configuration PowerPC tournant sous Mac OS 7.6.1 ou au-delà (Mac OS 8.1 ou plus est conseillé) doté d'au moins 24 Mo de RAM, 20 Mo d'espace libre sur votre disque dur ainsi qu'Open Transport 1.1 ou plus. MRJ 2.1 installe la version 1.4.2 de l'extension "Text Encoding Converter 1.4.2" sur tous les systèmes et si vous êtes sous MacOS 7.6.1, il installe la version 1.0.3 du Tableau de Bord "Apparence". A noter que MRJ 2.1 n'est pas livré avec "Apple Applet Runner" ; vous pouvez utiliser Apple Applet Runner 2.0 (livré avec MRJ 2.0 et donc avec Mac OS 8.1 et au delà) ou le télécharger avec le MRJ SDK du site Web qu'Apple met à la disposition des développeurs. MRJ 2.1 n'est pas pour les modems timides étant donné qu'il représente un fichier de 7.8 Mo (NdT: 10.5 Mo chez moi) à télécharger. [GD]

http://db.tidbits.com/getbits.acgi?tbart=05182
http://developer.apple.com/java/

L'insupportable légèreté des URLs

par Adam C. Engst ace@tidbits.com

La semaine dernière, TidBITS présentait la deuxième édition de sa rubrique "Les Outils de la Rédaction". Lors de la première parution, nous vous présentions GURU, un utilitaire fort pratique de chez Newer Tech qui permet de calculer la mémoire vive installable dans votre machine. Plusieurs lecteurs ont suivi le lien fourni avec cet article et qui pointait vers la fiche technique de GURU parue en novembre 1998. Horreur et stupéfaction : cette URL n'était plus valable et ne permettait pas de télécharger la dernière version de GURU.

http://db.tidbits.com/ getbits.acgi?tbart=05191
http://www.newerram.com/ New_Folder/guru.html

Étant donné que beaucoup d'entreprises ne planifient pas le réaménagement de leur site Web il n'est pas rare que nous recevions des remarques de ce genre. La restructuration des sites casse les liens existants produisant ainsi ce que nous appelons des liens "pourris" ("linkrot"). La majorité de nos lecteurs tolèrent bien, même si c'est avec un brin d'irritation, le fait que les anciennes éditions de TidBITS contiennent des liens cassés: mais pourquoi diable ne corrigeons-nous pas ces liens pourris ?

Histoire exacte ou révisionnisme historique ? -- Un de nos plus grands principes, fréquemment contesté par d'autres personnes, est que le contenu de TidBITS, une fois publié, doit être quasiment immuable. La seule raison de modifier une édition de TidBITS après publication est une erreur de typographie. La raison de cette ferveur est notre désir de respecter le concept d'exactitude historique. Nous croyons que si nous avons écrit quelque chose dans l'édition du 30 novembre 1998, les mots choisis doivent rester à jamais les mêmes. Sans cela, comment un lecteur qui lit aujourd'hui cette parution pourrait être sûr de lire le même article que celui publié originalement. En outre, même si une telle idée peut sembler émaner d'un ego sur-dimensionné, nous voulons permettre aux historiens du futur de se faire une image réelle de la communauté Macintosh à un moment donné et de ce qui la différenciait des autres groupes d'utilisateurs informatiques. Nous voulons présenter au futur une image réelle du passé.

Cette rectitude de pensée est souvent contestée même à l'intérieur de notre équipe, car il est toujours tentant, de corriger après coup une grossière erreur. Comme tout le monde, nous n'aimons pas paraître sous un mauvais jour et si je pouvais juste corriger cette petite erreur... Pas question. Si nous avons fait une erreur après le gravage dans le marbre, et bien cette erreur restera gravée dans le marbre, la correction étant faite dans un numéro suivant.

Ces attitudes proviennent du monde de la publication sur papier. Même si je ne suis pas un amateur des publications écrites, le papier par lui-même se prête bien à la permanence et l'archivage de l'information. Une fois publié un mot écrit sur papier ne peut être modifié. Il est aussi facile d'empiler les numéros d'une publication et d'y rechercher ensuite une information. Même si TidBITS est publié sous format électronique, nous désirons arriver au même résultat de permanence et d'archivage.

Bref, vous pouvez être sur que ce que vous lisez aujourd'hui dans une édition de TidBITS ne changera jamais. Nous ne retournerons jamais dans une ancienne édition pour y changer autre chose qu'une coquille. Nous espérons d'ailleurs pouvoir bientôt mettre en place un système d'enfilades chronologiques dans notre base de données, ainsi lors de la consultation de la version originale nous pourrons proposer des liens vers les corrections apportées ultérieurement.

En outre nous apportons grand soin à nous assurer que les URL dans notre base de données aient une validité permanente. Les conventions que nous avons adoptées pour nommer nos éditions sont simples et cohérentes, et notre script CGI "GetBITS" développé spécialement pour nos besoins, nous permet d'utiliser des URL courts et stables pointant vers des articles individuels dans notre base de données ainsi que vers des enfilades de contributions à TidBITS Talk.

Le problème des liens brisés -- Fort heureusement, renouer les bouts d'un lien brisé n'est pas très difficile, à condition bien sûr que la page que vous cherchez existe toujours. Le moyen le plus simple est de "remonter l'URL", c'est à dire d'effacer un à un les différents éléments constitutifs de cet URL en partant de la fin jusqu'à ce que vous arriviez enfin sur une page à partir de laquelle vous pouvez recommencer votre quête. Prenez cet URL par exemple.

http://www.tidbits.com/about/about-tidbits.html

Si vous avez reçu un message d'erreur alors que vous suiviez ce lien, la première chose à faire est d'effacer l'élément "about-tidbits.html" et de tenter à nouveau d'accéder à cet URL. Si vous recevez à nouveau un message d'erreur, alors supprimez l'élément "about/" et essayez à nouveau. Vous vous retrouvez au niveau d'entrée du site et pouvez alors, partant de là, rechercher la page disparue.

Les URL binaires -- Un autre problème s'est présenté quand j'ai voulu publier l'URL permettant de télécharger la mise a jour du gratuiciel GURU sur la liste "TidBITS Talk". Quand on sort des versions successives d'un logiciel, comment inclure le numéro de la version en cours dans son nom sans se retrouver avec des liens brisés après la mise à jour ? Si vous êtes éditeur en ligne de logiciels, je vous conseille d'aller jeter un coup d'oeil à l'enfilade de messages que cette question à généré afin d'y apprendre divers moyens d'éviter que les liens binaires ne se corrompent.

http://db.tidbits.com/getbits.acgi?tlkthrd=588

Lectures supplémentaires -- Je vous recommande enfin, la lecture de l'excellente rubrique "Alertbox" de Jakob Nielsen qui a traité de ce sujet plusieurs fois. Une première fois concernant les URL pourries, (apparemment plus de 6 pour cent des liens sur l'Internet sont brisés), et une deuxième fois concernant l'entretien de votre "jardin cybernétique", c'est à dire le fait de retourner sur votre site pour rafraîchir les pages. Jakob abonde dans mon sens quand il explique l'importance de la précision historique et la nécessité d'éviter de faire du révisionnisme historique - si ces sujets vous intéressent, je ne saurais trop vous encourager à lire ces articles.

http://www.useit.com/alertbox/980614.html
http://www.useit.com/alertbox/981129.html

Sur le Web, Windows s'affiche en tout petit

par Geoff Duncan geoff@tidbits.com

En tant que journaliste spécialisé, je me sens dans l'obligation d'évoquer un aspect un honteux de notre métier : nous cachons parfois certaines informations. En fait, c'est inévitable. De même que le savoir peut être infini, transmettre ce savoir nécessite parfois un nombre infini de mots. Mais rassurez-vous, nous taisons parfois des informations pour votre propre bien ! Notre société contient des vérités qui peuvent vous traumatiser, et c'est notre boulot de vous protéger, vous qui êtes nos innocents lecteurs, de ces abîmes malveillants.

C'était d'ailleurs le cas avec l'article d'Adam "Les navigateurs Web 4.5 à l'usage" dans TidBITS-465, où il notait : "Comme Windows pense que les moniteurs utilisent une définition de 96 ppp par défaut, au lieu des 72 ppp du Mac, les concepteurs de pages HTML sous Windows rétrécissent souvent la taille des polices pour que le texte n'apparaisse pas trop large aux utilisateurs de Windows. Les utilisateurs du Mac sont alors confrontés à un texte minuscule, difficile à lire. "

http://db.tidbits.com/getbits.acgi?tbart=05255

Le commentaire d'Adam est correct, mais les lecteurs de TidBITS ne savent pas ce qui est bon pour eux. Il y a eu plus de lecteurs qui ont réagi à ces deux phrases qu'il n'y en a parfois pour un numéro tout entier. Ils nous ont posé toutes sortes de questions sur l'affichage des polices de caractères, la résolution physique des moniteurs, ils voulaient savoir quel système, de Windows ou du Mac, était le système qui affichait le texte "correctement" et plein d'autres choses encore.

Si cela ne vous suffit pas, bon, d'accord. Le présent article lève quelques-uns des "boucliers" journalistiques que nous mettons habituellement en place normalement pour votre bien. Ne venez pas vous plaindre ensuite, nous aurons au moins tenté de vous protéger.

On ne louche pas! -- La plupart des utilisateurs du Macintosh sont tombés, à un moment ou à un autre, sur des pages web qui contiennent du texte en caractères incroyablement petits. Si cela ne vous est jamais arrivé, allez passer quelques minutes sur le site web de Microsoft, en particulier dans les sections consacrées à Windows. Il n'est pas rare d'y voir du texte en caractères de 4 pixels de haut.

http://www.microsoft.com/windows/

Ce phénomène n'est pas limité au web. Combien de fois vous est-il arrivé d'avoir à modifier un document envoyé par un utilisateur de Windows qui pense que Times en taille 10 est parfait pour la visualisation à l'écran ? Ou bien il vous est peut-être arrivé d'avoir à examiner une feuille de calcul formatée en Arial taille 9... Est-ce que tous les utilisateurs de Windows disposent d'une sorte de mode de vision télescopique qui fait que les caractères leur paraissent plus grands qu'ils ne sont en réalité ?

Eh bien, oui, croyez-le ou non, c'est le cas.

Faisons le point. -- La confusion commence avec une unité que quasiment tout le monde utilise: le point. On utilise les points tous les jours, en choisissant une police de 12 points pour une lettre, ou une police de 36 points pour un titre. Mais savez-vous ce qu'est un point ?

Nombre de personnes vous diront qu'un point est 1/72ème de pouce. C'est correct, mais seulement pour les systèmes imageurs utilisés dans la plupart des ordinateurs (tels QuickDraw d'Apple et PostScript d'Adobe). Sortie des ordinateurs, la définition d'un point varie entre différents systèmes de mesure, dont aucun ne considère le point comme 1/72ème d'un pouce.

Techniquement, un point est un douzième de pica. Un pica ? Qu'est-ce ? Le premier système de point moderne fut publié en 1737 par Pierre Fournier, qui utilisa une unité de douze points qu'il appela le cicero soit 0,1648 pouce. De ce fait, un point représenterait une unité de longueur égale à 0,0137 pouce. En 1770, François Ambroise Didot convertit le système de Fournier pour l'harmoniser avec le pied français légal en cours, créant un pica agrandi à 0,1776 pouce, avec 12 points mesurant chacun 0,0148 pouce. Mais le destin veillait et les Français passèrent au système métrique à la fin du XVIème siècle, par contre le système de Didot s'était tellement répandu qu'il fût maintenu et est à ce jour toujours utilisé en Europe. Dans le système de Didot, un pica est plus grand qu'un sixième de pouce, et ainsi son point -toujours appelé point Didot- est plus grand que 1/72ème de pouce.

Les États-Unis, bien sûr, ont fait leur propre soupe. En 1879 ils commencèrent à adopter un système développé par Nelson Hawks, qui croyait que l'idée d'un système de point était de son fait et seulement du sien. Revendication d'originalité mise à part, le système d'Hawk mit seulement une décennie à envahir l'édition Américaine, et aujourd'hui un pica Américain mesure 0,1660 pouce, un peu moins d'un sixième de pouce, et un point (souvent appelé un point pica) est de 0,0138 pouce, très proche de la valeur originelle de Fournier, mais encore un poil plus petit que le fameux 1/72ème de pouce.

Également en 1879, Hermann Berthold convertit le système de points Didot en métrique et le système Didot-Berthold est toujours utilisé en Allemagne, en Russie et en Europe orientale. Juste pour compliquer les choses encore plus, beaucoup d'européens mesurent les caractères directement en millimètres, court-circuitant complètement le point.

Le terme pica peut troubler les lecteurs assez âgés pour se souvenir des machines à écrire et des imprimantes à marguerites. Ces technologies décrivaient les polices en termes d'espacement, c'est à dire combien de caractères peut-on aligner horizontalement sur un espace d'un pouce. Les polices pica correspondaient à 10 caractères par pouce, les élite à 12 caractères par pouce et les micro-élite à 15 caractères par pouce. De nos jours, on simulerait ces échappements avec des polices à espacement fixe (comme Courier) à respectivement 12, 10 et 8 points.

Pour comprendre pourquoi les textes sur les pages Web Windows apparaissent souvent trop petites sur Macintosh, on peut faire comme l'ordinateur : présumer qu'il y a 72 points par pouce.

Pas votre caractère -- Lorsque vous vous référez à un texte d'une taille spécifique, vous décrivez la hauteur de ce texte plutôt que sa largeur ou la dimension d'un caractère particulier (ou glyphe) dans une typo. Donc, s'il y a 72 points par pouce, vous pourriez penser qu'un caractère en 72 points ferait un pouce de hauteur -mais vous auriez tort à tous les coups. La taille maximum d'un texte est mesurée à partir du haut de l'ascendant le plus élevé (généralement un "d" ou un "l" minuscule, ou une majuscule) jusqu'à l'extrémité basse maximum (jambe) d'un caractère (généralement un "j" ou un "y" minuscule). La plupart des caractères d'une typo utilise seulement une portion de cette taille totale et donc mesurent moins d'un pouce pour une taille de 72 points.

Si ceci ne vous dit rien, pensez à un "point" (ponctuation). A n'importe quelle taille, un point ne mesure qu'une petite fraction de la hauteur occupée par la plupart des autres caractères de la police. Lorsque vous écrivez en 72 points vous ne vous attendez pas à ce que le point fasse un pouce de hauteur. Les minuscules (bas de casse) utilisent en général moins d'espace vertical que les majuscules (capitales), et les capitales utilisent en général les deux tiers de la hauteur totale de la police. (si vous êtes curieux la lettre la plus haute dans une typo est souvent le "J" majuscule: il a quelquefois une jambe descendante même quand il est en capitale).

Pour rendre les choses encore un peu plus compliquées, certaines polices cassent ces règles. Les symboles spéciaux, les diacritiques et les ponctuations peuvent dépasser les limites spécifiées par une taille de typo, bien qu'il soit rare pour un caractère isolé de dépasser aussi bien la limite haute que la limite basse. D'autres typos peuvent ne pas utiliser toute la hauteur disponible : c'est pourquoi la police Times peut paraître plus petite que d'autres polices à la même taille.

Si la taille du point est une indication de la hauteur du texte, qu'en est-il de la largeur ? A l'inverse du point qui est une sorte de mesure absolue, la largeur du texte est mesurée en utilisant l'"em". ` Un "em" est la largeur égale à la taille du point de la police utilisée. Ainsi, dans une police de taille 36, un em est égal à 36 points; dans une police à 12 points, un em vaut 12 points. L'unité de l'em était à l'origine basée sur le M majuscule qui était souvent le caractère le plus large du temps des machines à écrire mécaniques. Aujourd'hui, cependant, le M majuscule n'a plus habituellement une largeur exacte d'un em, autorisant un peu d'espace devant et derrière le caractère. L'em est important parce qu'il est une mesure relative, mais les implications de l'em vont bien au delà de l'objet de cet article

Poussière de pixel -- Maintenant que vous en savez plus sur les façons un peu floues de mesurer la taille des caractères, comment fait un ordinateur pour afficher un texte sur un moniteur ?

Supposons que vous écrivez un roman, et vous fixez la taille des titres de chapitres en texte de 18 points. D'abord, l'ordinateur a besoin de connaître la hauteur d'un texte de 18 points. Puisque les ordinateurs savent qu'il y a 72 points dans un pouce, c'est facile : 18 points correspondent à 18/72ème de pouce, soit exactement un quart de pouce. L'ordinateur peut donc tracer sur l'écran un texte dont la hauteur est d'un quart de pouce.

C'est là que l'univers devient étrange. Votre ordinateur conçoit votre moniteur comme une grille cartésienne faite de pixels ou de "points". Pour votre ordinateur, votre affichage est : tant de pixels de large sur tant de pixels de haut, et tout ce qui est sur votre écran est dessiné en utilisant des pixels. Ainsi, la résolution physique de votre affichage peut être exprimée en pixels par pouce (ppi), ou, plus communément, en points par pouce (dpi [en français: ppp]).

Pour écrire un texte en 18 points, qui équivaut à un quart de pouce en hauteur, votre ordinateur doit savoir combien de pixels contient un quart de pouce. Pour le trouver, vous pourriez penser que votre ordinateur interroge votre affichage sur sa résolution physique - mais vous auriez tort. Au lieu de cela, votre ordinateur fait une hypothèse patente, quasi pathologique, sur le nombre de pixels contenus dans un pouce, sans un se soucier ni de la taille de votre moniteur ni de la résolution ni de quoi que ce soit d'autre.

Si vous utilisez un Mac, votre ordinateur partira toujours du principe que votre moniteur affiche 72 pixels par pouce, ou 72 ppp (points par pouce). Si vous utilisez Windows, votre ordinateur part généralement du principe que votre moniteur affiche 96 pixels par pouce, mais si vous utilisez des "grandes polices", Windows suppose qu'il peut afficher 120 pixels par pouce. Les systèmes Unix varient, mais supposent généralement un affichage entre 75 et 100 ppp. De nombreux environnements graphiques pour Unix ont des solutions de configurations, et j'ai entendu dire qu'il existe une manière de configurer les paramètres d'affichage utilisés par Windows NT et peut-être Windows 98. Cependant, le problème fondamental persiste : l'ordinateur n'a aucune idée de la résolution physique "véritable" de votre affichage.

Partant de cela, un Macintosh utilisera 18 pixels pour afficher un texte en 18 points alors que Windows en utilisera 24, Unix en utilisera entre 19 et 25 et un ordinateur Windows configuré en "grandes polices" en utilisera 30.

Et voilà pourquoi, d'un point de vue de taille d'affichage, les utilisateurs Windows voient s'afficher sur leurs écrans des textes qui sont d'environ 33% plus gros que les mêmes textes sur l'écran d'un Macintosh -si l'on se place du point de vue du Macintosh, les usagers de Windows disposent d'une vision télescopique. Quand vous visualisez le résultat final sur un écran dont tous les pixels ont la même taille, les différences peuvent aller de la simple gène à l'illisibilité. Soit le texte Windows est énorme, soit le texte Mac est minuscule -au choix. Voyez mon exemple ci-dessous.

http://www.tidbits.com/geoff/texttest.html

Parfois, une grosse vaut mieux qu'une petite... -- Nous arrivons donc à la question à 1000 FF : pourquoi du texte Windows s'affiche-t'il en tout petit sur les écrans Mac. Mettons que votre écran d'ordinateur - ou bien la fenêtre de votre navigateur Web - mesure 640 par 480 pixels. Si on laisse de côté la barre de menus, la barre de titre et autres encombrements de l'écran, le Mac peut donc afficher 40 lignes d'un texte en 12 points dans cet espace (un texte à interlignage fixe c'est à dire qu'il n'y a pas de double interlignage ou d'espace supplémentaire entre les lignes). Mais dans les mêmes conditions, Windows ne peut afficher que 32 lignes du même texte ; étant donné que Windows utilise plus de pixels pour afficher le même nombre de caractères. En conséquence, les concepteurs Web utilisant Windows spécifient souvent une taille de caractère plus petite afin de faire entrer plus de texte dans cet espace réduit. Le résultat est que les usagers du Mac se prennent une double claque : non seulement le Mac a besoin de moins de pixels pour afficher les caractères mais en plus le texte est composé dans un corps tellement petit qu'il en devient presque illisible.

Un jour, il faudra bien en venir aux points -- La base du problème vient du fait que l'ordinateur cherche à adapter une unité de mesure physique -le point- à un périphérique de sortie dont il ignore les caractéristiques. Un écran d'ordinateur n'est rien d'autre qu'un système de projection analogique : bien qu'on puisse régler jusqu'à un certain point sa précision d'affichage, l'écran en soi n'a pas de moyen de déterminer la quantité de pixels qu'il affiche sur une surface donnée. Les nouvelles générations de périphériques à programmation numérique -les moniteurs comme des écrans à cristaux liquides- devraient permettre de communiquer cette résolution à l'ordinateur et d'adapter l'affichage en conséquence. Toutefois, à ce jour, je ne connais aucun périphérique qui en soit capable. De telles fonctions feraient sans aucun doute appel aux cartes de contrôle vidéo et nécessiteraient des modifications du système d'opération. En revanche, certains moniteurs sont capables de transmettre des données à l'ordinateur, dont la résolution en pixels disponible.

Pourquoi Windows et Macintosh font-ils des hypothèses aussi différentes sur les résolutions d'affichage ? Sur le Macintosh, c'est en relation avec le WYSYWIG : Ce Que Vous Voyez Est Ce Que Vous Imprimez. Le Mac a popularisé l'interface graphique, et Apple a compris que le rendu à l'écran d'un Mac doit correspondre d'aussi près que possible à ce que le Mac imprimera sur une feuille de papier. En conséquence, les pixels correspondent aux points : comme le Mac croit qu'il y a 72 points par pouce, il affiche 72 pixels par pouce. à l'époque glorieuse d'avant les imprimantes laser à 300 dpi, le Mac était un exemple stupéfiant de WYSYWIG. Les affichages sur les Mac compacts originaux et les périphériques couleur variaient de 71 à 74 dpi - c'est suffisamment proche de 72 dpi pour cacher le fait que le Mac n'avait aucune idée de la résolution des périphériques.

En fait, pendant des années, Apple a résisté aux résolutions supérieures et aux écrans multisync. Après tout, plus le pixel s'éloigne du 72ème de pouce, moins le Mac est WYSYWIG. La popularité croissante de Windows, les pressions financières des fabricants de PC et la forte demande de portables ont finalement amené Apple à céder et les Macintoshs d'aujourd'hui affichent généralement plus de 72 dpi. Un moniteur de 17 pouces tournant en 1024 par 768 pixels affiche généralement de 85 à 90 dpi. L'écran intégré de l'iMac a une surface visible de 13,8 pouces (mesuré diagonalement). Une rapide vérification avec le théorème de Pythagore montre que l'écran de l'iMac donne un bon 58 dpi à 640 par 180, mais presque 93 dpi à 1024 par 768. Un PowerBook G3 avec un écran de 13,3 pouces (toujours en mesure diagonale) affiche plus de 96 dpi à 1024 par 768. Le prochain écran plat 1600SW de SGI arborera une résolution de 110 dpi.

http://www.sgi.com/peripherals/flatpanel/

Les raisons historiques de l'hypothèse que fait Windows sur les écrans de 96 dpi (points par pouce) sont moins claires. Le standard semble avoir été posé par le Video Electronics Standards Association (VESA) avec la spécification VGA (Video Graphics Adapter), qui annonce la domination du marché par Windows. Pour moi, il aurait pu y avoir des soucis de compatibilité avec les anciens standards d'affichage CGA et EGA, et il semble que personne ne puisse lire un texte de taille inférieure à 10 ou 12 points sur un écran VESA ayant une résolution inférieure à 96 dpi. Le Macintosh a prouvé que c'était faux, en grande partie grâce à la conception soignée de ses polices écran en mode point, comme Geneva, Monaco, Chicago et New York. Plus ironiquement, bien que la résolution des Macintosh les plus courants s'approche effectivement très près de 96 dpi, Windows affiche habituellement des résolutions bien inférieures aux 96 dpi attendus. Si vous connaissez un utilisateur Windows ayant un écran de 17 pouces utilisant une résolution de 1024 par 768, son écran affiche probablement entre 85 et 90 dpi - tout comme un Macintosh l'aurait fait.

La confusion a atteint un point... -- J'espère que cet article vous aura montré comment les ordinateurs s'appuient sur une unité de mesure en soi déjà imprécise (le point), en font un étalon pour définir l'affichage de caractères typographiques qui eux-mêmes utilisent leur taille de corps de façon arbitraire et enfin envoient le tout vers un périphérique de sortie qui, en toute probabilité, n'affiche pas ce que le contrôleur vidéo de l'ordinateur croit qu'il affiche. Comme vous pouvez le constater, c'est un beau bordel sans même que nous ayons à aborder le terrain miné de systèmes d'opération.

Les défenseurs de Windows claironnent parfois que la plus grande résolution d'affichage est un des avantages de leur système, ou alors ils disent que la résolution moindre sur les Mac est un des enfants du placard d'Apple. D'un point de vue historique, aucune de ces affirmations n'est vraie. Bien que certaines tailles de textes soient rendues avec plus de fidélité sur Windows, ce dernier sacrifie l'idée du WYSIWYG afin d'obtenir une résolution supérieure. Malheureusement, la conclusion de cette situation est qu'aucun des systèmes couramment en usage n'est capable d'afficher de façon fiable du texte, donc tout le monde est perdant.

Voilà, il faut que je m'arrête car votre écran doit être plein... à moins que vous ne soyez sur un autre système.

Les publications et les sites non-commerciaux à but non lucratif peuvent reproduire ou établir des liens sur ces articles dans la mesure où référence est faite à leur origine. Tout autre doit nous contacter. L'exactitude de nos articles n'est pas assurée. Caveat lector. Les noms de publications, de produits et de sociétés peuvent être des marques déposées. TidBITS ISSN 1090-7017..

Accueil | Archives francophones de TidBITS | Sommaire des quatre derniers TidBITS traduits | L'Equipe francophone de TidBITS <