Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS#467/15-Feb-99

Waarom hebben Web pages bedoeld voor Windows gebruikers zo'n kleine tekst? Geoff Duncan legt het allemaal uit in deze aflevering, kijkend naar punten, pica's, pixels en hoe het Mac OS en Windows de letters verschillend weergeven. Adam komt er bij met wat overpeinzingen over bestendigheid van URL's op het Web (en wat te doen met gebroken URL's), en in het nieuws zien we Macintosh Runtime voor Java 2.1, Action Files 1.2, ShareWay IP 2.0, en MasterJuggler 2.0.2.

Onderwerpen:

Copyright 1999 TidBITS Electronic Publishing. All rights reserved.
Information: <[email protected]> Comments: <[email protected]>

Je kunt je gratis abonneren op de Nederlandse afleveringen van TidBITS door een (blanco) mailtje te sturen naar: [email protected]. Je krijgt deze dan per e-mail toegestuurd.
Om je abonnement op te zeggen, kun je een mailtje sturen naar: [email protected].

De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de USA.

Deze editie van TidBITS werd gedeeltelijk gesponsord door:

Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:

MailBITS/15-Feb-99

Vertaling: [MSH] & [HB].

Action Files 1.2 pikt Nav Services in -- De meest recente opwaardering van Power On Software's populaire Action Files zet Apple's Navigation Services onder Mac OS 8.5 opzij ten gunste van het verbeterde Open en Bewaar dialoogvakje, dat Action Files verschaft, en het stopt er een handjevol verbeteringen bij. (Zie "Pak een stuk van de Action Bestanden" in TidBITS-434). Thans ondersteunen weinig applicaties Navigation Services, dat de traditionele Open en Bewaar boxen in het Mac OS vervangt; Action Files 1.2 verschijnt nu in plaats van Open en Bewaar dialoogboxen van alle applicaties. Tevens geeft de update meer verenigbaarheid met Kaleidoscope, werkt beter met aliassen en volumes groter dan 4 GB en geeft meer controle over de basisinstellingen van her programma. Bezitters van Action Files kunnen de nieuwe versie van Power On Software downloaden (1.1 MB) en gebruiken met de bestaande registratienummers. [JLC]

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

MasterJuggler bereikt verenigbaarheid met Mac OS 8.5 -- Alsoft publiceerde een gratis update voor zijn letterkeuze-beheersing MasterJuggler, en herstelde daarbij enkele onverenigbare zaken t.a.v. het Mac OS 8.5. De MasterJuggler Pro 2.0.2 Update herstelt een probleem als Font Guardian (een onderdeel dat de betrouwbaarheid van font bronnen onderzoekt) werd gebruikt om te scannen bij het opstarten van de Mac. Ook corrigeert deze update kleine foutjes in verband met het selecteren van zaken in MasterJuggler's pop-up menu's. Zie "Font leveranciers" in TidBITS-334 voor een vergelijking van MasterJuggler en Suitcase 3.0. De 2.0.2 updater is een 350K download. [JLC]

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

Open Door Networks Geeft ShareWay IP 2.0 Uit -- Open Door Networks heeft ShareWay IP 2.0 uitgegeven, een upgrade van hun nuttige netwerk-gereedschap, dat Macs met Personal File Sharing of oudere AppleShare servers toegankelijk maakt via TCP/IP (zie "Share en Share IP Alike" in TidBITS-436). Het voornaamste nieuws in ShareWay IP 2.0 is ondersteuning voor SLP (Server Location Protocol), een manier om dynamisch servers te lokaliseren en toegankelijk te maken, veel lijkend op de AppleTalk Chooser. In wezen maken ShareWay IP 2.0-gebaseerde servers zich bekend door SLP, daarna kunnen gebruikers AFP Engage 2.0 - in Open Door - toepassen om een lijst van beschikbare servers te bekijken. Andere nieuwe dingen in 2.0 zijn een werkwijze voor een uitsluitend achtergrond modus , real -time verslaggeving en verbetering in veiligheidszaken. Tengevolge van beperkingen in de SLP plug-in van Apple zijn alleen de Persoonlijke en Standaard edities van ShareWay IP opgewaardeerd naar 2.0; een toekomstige versie van de SLP plug-in zou Open Door in staat moeten stellen een versie van de multi-server ShareWay IP Professional vrij te geven. Opwaarderingen zijn gratis voor kopers na 3 jan 99 en kost anders tussen $34 en $89 voor de individuele gebruikerslicentie, afhankelijk van de versie van ShareWay IP. Afprijzingen zijn verkrijgbaar voor upgrades voor sites en proefkopieën zijn voor downloaden beschikbaar. [ACE]

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

MRJ 2.1 werkt sneller, werkt met Explorer -- Van Apple verschijnt Macintosh Runtime for Java 2.1, dat belangrijke prestatieverbeteringen heeft ondergaan in vergelijking met vorige versies van MRJ en dat nu kan gebruikt worden met Microsoft's Internet Explorer Web browser. (Microsoft heeft de ondersteuning van hun eigen Java virtual machine stopgezet onmiddellijk nadat Sun de rechtszaak tegen Microsoft's Java implementaties won; zie TidBITS-456.) MRJ 2.1 voldoet aan Sun's Java JDK 1.1.6 specificaties, ondersteund optioneel Sun's Java Foundation Classes en Swing interface toolkit (versies 1.0.3 and 1.1), en voegt ondersteuning toe voor Applescript (hoewel we niet weten hoe nuttig dit zal zijn op korte termijn). Alhoewel MRJ 2.1 nog altijd niet eender welke Java applet draait (de release notes waarschuwen de gebruikers om weg te blijven van Yahoo Games terwijl Apple het probleem onderzoekt), werkt MRJ 2.1 met Internet Explorer - verzeker je er echter wel van dat MRJ is geselecteerd als Explorer's Java virtual machine - en Java ontwikkelingsomgevingen voor Macintosh. Netscape browsers gebruiken hun eigen Java implementatie en kunnen momenteel MRJ niet gebruiken.

MRJ 2.1 heeft een PowerPC-Mac nodig met Mac OS 7.6.1 of later (Mac OS 8.1 of later is aangeraden) met minstens 24 MB RAM, 20 MB vrije schijfruimte, en Open Transport 1.1 of beter. MRJ 2.1 installeert Text Encoding Converter 1.4.2 op alle systemen, en indien je Mac OS 7.6.1 gebruikt, installeert het versie 1.0.3 van het Appearance regelpaneel. Merk op dat MRJ 2.1 niet geleverd wordt met de Apple Applet Runner; je kan Apple's Applet Runner 2.0 gebruiken (geleverd bij MRJ 2.0, en dus ook bij Mac OS 8.1 of hoger) of deze downloaden met de MRJ SDK van Apple's developer Web site. MRJ 2.1 is een 7,8 MB download. [GD]

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

De Ondraaglijke Lichtheid van URL's

door Adam C. Engst <[email protected]>. Vertaling: [DPF] & [Tess].

De vorige editie van TidBITS kende het tweede deel uit onze serie Gereedschappen Die We Echt Gebruiken; de eerste aflevering ging over GURU, de utility van NewerRAM. Een aantal lezers klikten op de link in het artikel van vorige week naar het GURU artikel om tot de ontdekking te komen dat de URL die we voor GURU gaven in November 1998 niet langer meer werkt.

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

We ontvangen hier vaak berichten over, omdat veel bedrijven niet vooruit denken wanneer ze hun Web sites veranderen waardoor URL's ophouden te werken, een proces dat wel "linkrot" genoemd wordt. De meeste mensen maken er geen punt van dat oude edities van TidBITS naar foutieve URL's verwijzen, maar vaak is er wel een kleine suggestie van irritatie: waarom hebben we deze linkrot niet eerder aangepakt?

Historische Accuraatheid -- Eén van onze sterkste maar ook meest aangevallen overtuigingen is dat onze inhoud niet wijzigbaar is - het enige wat we ooit veranderen nadat we een editie verspreid hebben zijn tikfouten. Onze reden hiervoor is dat we aanhangers zijn van het concept van historische accuraatheid. We vinden dat, als we iets in de 30-Nov-98 editie van TidBITS hebben geschreven, deze woorden tot in eeuwigheid vast moeten blijven staan. Hoe kunnen mensen die die editie bekijken anders weten dat ze dezelfde tekst lezen als deze die we gepubliceerd hebben op die datum? En, alhoewel we onszelf vleien met deze gedachte, wat moeten historici anders aan met onze schrijfsels, wanneer ze proberen te achterhalen wat er toch was met de Macintosh-gemeenschap dat ze zich zo onderscheidden van andere groepen computergebruikers? We willen de toekomst een accurate blik op het verleden gunnen.

Deze politiek wordt vaak aan het wankelen gebracht omdat het zelfs voor ons verleidelijk is op fouten te herstellen. We willen er niet slecht uitzien, en wanneer we slechts die ene kleine verandering in een artikel zouden doen... Nee. Wanneer we een fout maken, is die fout als het ware in steen uitgebeiteld, en moeten we er in de editie van de volgende week maar melding van maken.

In feite komen deze overtuigingen nog vanuit een wereld die helemaal 'bestuurd' wordt door drukwerk op papier, en alhoewel ik er geen fan van ben om dat door te zetten puur en alleen vanwege de fysiek, leent papier zich tot zowel een permanente staat als tot archiveren. Je kunt de woorden die op een pagina in een tijdschrift zijn afgedrukt niet meer veranderen, en het is eenvoudig om alle edities van zo'n tijdschrift op volgorde op een stapel te leggen en er doorheen te bladeren op zoek naar bepaalde informatie. Alhoewel TidBITS electronisch is, streven we naar een vergelijkbaar niveau van informatie en archiveren.

In het kort kun je er dus op vertrouwen dat wat je in een editie van TidBITS leest tot in de eeuwigheid hetzelfde zal blijven. We zullen nooit een archief wijzigen om een andere fout dan een tikfout aan te passen. We hopen echter snel zgn. 'forward linking' in onze database toe te passen zodat correcties toegankelijk zullen zijn vanuit het originele artikel.

Daarbovenop zullen we onze uiterste best doen om ervoor te zorgen dat al onze URL's permanent zullen zijn. De manier waarop we onze edities nummeren en noemen is eenvoudig en consistent, en onze eigen GetBITS CGI zorgt ervoor dat we korte, permanente URLs in onze database hebben die naar individuele artikelen verwijzen, om van discussielijnen in TidBITS Talk nog maar te zwijgen.

Omgaan met defecte URL's -- Gelukkig is het terugvinden van een Web pagina niet moeilijk als een URL het niet meer doet, er van uitgaand dat die pagina nog steeds bestaat. De truc is de pagina's en de directories van het eind van de URL te verwijderen totdat je bij een pagina komt vanaf het welke je weer naar de gewenste pagina kan beginnen te browsen. Neem deze URL.

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

Als je een foutmelding krijgt bij het betreden van deze URL, zou je het eerst "about-tidbits.html" moeten verwijderen en vervolgens de URL weer naar de Web browser sturen. Als die kortere URL ook een error page oplevert, zou je "about/" moeten verwijderen en het nog een keer proberen. Dat brengt je naar het hoogste niveau van de site, wat een bruikbaar startpunt zou moeten leveren om verder te zoeken.

Binair URL's -- Toen ik de geüdate GURU URL naar TidBITS Talk postte, rees een hieraan gerelateerde kwestie. Wanneer je verschillende versies van een programma post, wat doe je dan met het gegeven dat het opnemen van het versienummer in de naam automatisch defecte URL's verzekert na een upgrade? Als je software distribueert, trek dan de verschillende manieren na om binaire linkrot te voorkomen.

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

Verder lezen -- Tenslotte heeft Jakob Nielsen's voortreffelijke Alertbox column dit onderwerp verschillende malen aangesneden, eerst met betrekking tot linkrot (blijkbaar zijn meer dan zes procent van de links op het Web defect), en ten tweede over "content gardening", de kunst om terug te gaan om de pagina's vers te houden. Jakob heeft een link naar mijn commentaar over historische accuraatheid en noodzaak om historisch revisionisme te voorkomen - het is het lezen waard als je geïnteresseerd bent in het onderwerp.

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

Waarom onder Windows gemaakte web-pagina's zulke kleine letters hebben

door Geoff Duncan <[email protected]>. Vertaling: [MK], [JS], [IdM] & [JV].

Als technisch journalist voel ik me geroepen eens een weinig uitgesproken waarheid uit mijn vakgebied te noemen: soms zien we wel eens iets over het hoofd. Dat is gedeeltelijk ook niet te vermijden. Net zoals kennis een oneindig grote waarde kan hebben, kan voor het overbrengen van die kennis een oneindig aantal woorden nodig zijn. Maar verdorie, soms laten we dingen weg met het welzijn van de lezer voor ogen! In deze wereld komen waarheden voor waarvan je hoofdpijn kunt krijgen, en het is ons werk om jou, onschuldige lezer, te behoeden voor deze kwaadwillende poelen des verderfs.

Zo was het ook in het geval van Adams artikel "Het sturen van de 4.5 Web Browsers" in TidBITS-465, waarin hij opmerkte: "Aangezien Windows denkt dat je een scherm gebruikt dat een resolutie heeft van 96 dpi tegenover de 72 dpi bij de Mac, gaan webdesigners die met Windows werken dikwijls kleinere fontgrootten gebruiken, zodat de tekst niet te groot schijnt voor Windows-gebruikers. Mac-gebruikers worden dan geconfronteerd met minuscule tekst die moeilijk leesbaar is."

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

Wat Adam hier zegt is correct, maar de lezers van TidBITS weten niet wat goed voor ze is. Op deze twee zinnen zijn meer reacties binnengekomen dan soms op een heel nummer, waarbij ze vragen stelden over weergave van lettertekens, over het fysieke oplossend vermogen van monitors, over wie het nu "op de goede manier" deed, Windows of Macintosh, en nog veel meer.

Als je goed genoeg niet goed genoeg vindt, prima. In dit artikel stel ik een paar journalistieke schilden buiten werking die we normaliter toepassen in je eigen belang. Zeg niet dat we je niet hebben proberen te beschermen.

Tuur-O-Visie -- Het grootste deel van de Mac-gebruikers is wel eens terecht gekomen op web pagina's met onleesbaar kleine tekst. Als jij daar niet toe behoort, zoek dan maar eens Microsoft's web site op - en dan vooral de pagina's die zijn gewijd aan Windows zelf - waar het niet ongebruikelijk is als Mac-gebruiker te worden geconfronteerd met tekst die tussen de een en de vier pixels groot is.

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

Dit verschijnsel beperkt zich niet tot het web. Hoe vaak ben je niet gedwongen een document te bewerken van een Windows-gebruiker die denkt dat 10-punts Times een prima schermlettertype is? Of misschien heb je wel eens naar een spreadsheet moeten kijken dat men had gemaakt in 9-punts Arial. Hebben alle Windows-gebruikers een soort ingebouwde verrekijkers in hun ogen die de tekst groter laat lijken?

Nou eh, ja, inderdaad. Zo is het precies.

Punten maken -- De verwarring begint bij een eenheid die bijna iedereen gebruikt: de punt. We gebruiken de punt elke dag, we kiezen een 12-punts letter voor een brief, of een 36-punts letter voor een kop. Maar weet je ook wat een punt eigenlijk is?

Veel mensen zullen je vertellen dat een punt 1/72 inch is. Dat klopt, maar dit geldt alleen in de beeldverwerkende subsystemen binnen de meeste computers (waaronder Apple's QuickDraw en Adobe's PostScript). Buiten een computer varieert de definitie van een punt tussen de verschillende maatstelsels, en in geen daarvan is een punt precies 1/72 inch.

Technisch gezien is een punt het twaalfde deel van een pica. Maar wat is een pica? Het eerste moderne puntensysteem werd gepubliceerd in 1737 door Pierre Fournier, die een eenheid met een grootte van 12 punten gebruikte. Deze eenheid noemde hij een cicero, en een cicero was 0,1648 inch. In dit systeem zou een punt dus een lengte-eenheid zijn gelijk aan 0,0137 inch. In 1770 zette François Ambriose Didot het systeem van Fournier om, ten einde het in lijn te brengen met de wettelijke lengtemaat van die tijd, de Franse voet. Hierdoor schiep hij een grotere pica, namelijk 0,1776 inch, waardoor 12 punten ieder 0,0148 inch besloegen. Het lot wilde dat de Fransen overgingen naar het metrieke stelsel aan het eind van de 18e eeuw, maar het systeem van Didot was stevig geworteld en wordt nog steeds op grote schaal gebruikt in Europa. In Didot's systeem is een pica groter dan 1/6 inch, en dus is zijn punt - die nog steeds de Didot-punt wordt genoemd - groter dan 1/72 inch.

De V.S. hadden uiteraard hun eigen oplossing. In 1879 adopteerde de V.S. een systeem dat ontwikkeld was door Nelson Hawks, en hij geloofde dat het idee van een punt-systeem van hem en van hem alleen was. Los van de claims op originaliteit was het systeem van Hawks binnen tien jaar het dominerende systeem voor de Amerikanen, en vandaag de dag is een Amerikaanse pica gelijk aan 0.1660 inch, net iets minder dan een zesde inch, en een punt, (vaak een pica-punt genoemd) is 0.0138 inch, dicht bij Fournier's oorspronkelijke waarde, maar net een klein beetje minder dan 1/72 inch.

In 1879 converteerde Hermann Berthold het systeem van Didot naar metrische waarden, en het Didot-Berthold systeem is nog steeds in gebruik in Duitsland, Rusland een Oost-Europa. Om de zaken nog ingewikkelder te maken gebruiken veel Europeanen getallen in millimeters, en slaan ze de punten geheel over.

De term pica is wellicht verwarrend voor lezers die oud genoeg zijn om zich tikmachines en daisy wheel printers te herinneren. Deze technologieën beschrijven type in termen van pitch, ofwel het aantal karakters dat horizontaal in een inch past. Pica type correspondeert met 10 karakters per inch, elite met 12 karakters per inch, en micro-elite met 15 karakters per inch. Vandaag de dag doe je deze pitches na met een mono gespatieerd lettertype (zoals Courier) op 12, 10 en 8 punts respectievelijk.

Om te begrijpen waarom tekst op een Windows Web pagina vaak te klein lijkt op een Macintosh, kun je hetzelfde doen als wat je computer doet: neem aan dat er 72 punten in een inch zitten.

Niet Jouw Type -- Wanneer je een tekst van een bepaalde puntgrootte beschrijft, heb je het over de hoogte van de tekst in plaats van de breedte of de afmetingen van een bepaald karakter (of glyph) in een lettertype. Dus, als er 72 punten in een inch zitten, zou je kunnen denken dat een 72 punts grootte precies een inch hoog is - maar dan heb je het vrijwel altijd fout. De maximale hoogte van tekst is gemeten vanaf de top van de hoogste stijger van een lettertype (meestal een kleine letter d of l, of een hoofdletter) tot de onderkant van de laagste afdaler (meestal een kleine letter j of y). De meeste vormen in een lettertype gebruiken slechts een gedeelte van deze totale hoogte en zijn dus minder dan een inch hoog op 72 punts grootte.

Als je dit niet begrijpt, denk dan aan een komma. Op elke grootte neemt een komma slechts een klein deel in van de hoogte die vrijwel elk ander karakter in een lettertype inneemt. Als je 72 punts tekst gebruikt verwacht je niet dat een komma een inch hoog is. Kleine letters gebruiken over het algemeen minder verticale ruimte dan hoofdletters, en hoofdletters gebruiken over het algemeen twee derde van de totale verticale hoogte. (Als je nieuwsgierig bent: de grootste letter van het alfabet is vaak de hoofdletter J: ze daalt soms een beetje af, zelfs als hoofdletter.)

Om de zaken wat verwarrender te maken breken sommige lettertypen deze regels. Speciale symbolen, diakritische tekens, en leestekens gaan voorbij aan de limieten die door een grootte gedefinieërd worden, hoewel het zeldzaam is dat een enkel karakter zowel de boven- als onderlimieten breekt. Andere lettertypen gebruiken wellicht niet de volledige vertikale ruimte die beschikbaar is; dat is waarom Times vaak kleiner lijkt dan andere lettertypes op dezelfde grootte.

Als een puntsgrootte een indicatie is van de teksthoogte, hoe zit het dan met de breedte? In tegenstelling tot punten, wat een (soort) absolute maat is, wordt tekstbreedte gemeten met een em. Een em is een breedte gelijk aan de puntsgrootte van het lettertype dat gebruikt wordt. Dus, in 36 punts grootte, is een em gelijk aan 26 punten; in 12 punts, is een em 12 punten. De em is oorspronkelijk gebaseerd op een hoofdletter M, wat vaak het breedste karakter was in een lettertype in de tijd dat er met de hand gezet werd. Vandaag de dag is een hoofdletter M meestal geen volledige em in breedte, met een beetje ruimte voor en achter het karakter. De em is belangrijk omdat het een relatieve eenheid is, maar de implicaties van de em zijn niet belangrijk voor dit artikel.

Pixel Dust -- Nu je een beetje afweet over de ietwat wazige methodes om tekst te meten, hoe gebruikt een computer die informatie nu om tekst af te beelden op een monitor?

Stel dat je een roman schrijft, en je zet de hoofstuktitels in 18 punt. Eerst moet de computer weten hoe hoog 18 punt is. Omdat een computer gelooft dat er 72 punten in een inch (duim) gaan, is dat simpel: 18 punt is 18/72ste van een inch, of precies één vierde van een inch. Daarna beeldt de computer tekst af op je scherm die precies een kwart inch hoog is.

Nu wordt het vreemd. Je computer denkt dat je monitor een Cartesisch rooster is, gemaakt van pixels of "dots". Voor je computer is je scherm zoveel pixels breed en zoveel pixels hoog, en alles op je scherm wordt getekend met behulp van pixels. Dus de fysieke resolutie van je scherm kan worden uitgedrukt in pixels per inch (ppi) of , meer gebruikt, dots per inch (dpi).

Om 18-punts tekst te tekenen met een hoogte van een kwart inch, moet je computer weten hoeveel pixels er gaan in een kwart inch. Je zou veronderstellen dat je computer - om dat te weten te komen- met je monitor praat over diens fysieke resolutie - maar nee hoor. In plaats daarvan maakt je computer een patente, haast pathologische veronderstelling over hoeveel pixels er in een inch gaan, ongeacht de grootte van je scherm, de resolutie, of wat dan ook.

Als je een Mac gebruikt, veronderstelt je computer altijd dat je monitor 72 pixels per inch weergeeft. Als je Windows gebruikt, zal je computer meestal veronderstellen dat je scherm 96 pixels per inch weergeeft (96 dpi), maar als je "grote fonts" gebruikt, veronderstelt Windows dat het 120 pixels per inch kan tonen (120 dpi). Bij Unix systemen varieert het, maar ze gaan meestal uit van 75 to 100 dpi. De meeste grafische omgevingen voor Unix hebben één of andere manier om die instelling te configureren, en ik heb gehoord dat er een manier is om de dpi-instellingen van Windows NT en misschien wel van Windows 98 te configureren. Maar het fundamentele probleem blijft bestaan: de computer heeft geen benul van de fysieke resolutie van je scherm.

Deze veronderstellingen betekenen dat een Macintosh 18 pixels gebruikt om een 18-punts tekst weer te geven, een Windows systeem doorgaans 24 pixels, en dat een Unix systeem meestal tussen 19 en 25 pixels gebruikt, en een Windows systeem met een grote font-instelling 30 pixels.

Dus, in termen van rauwe pixels, zien de meeste Windows gebruikers tekst die 33 procent groter is dan tekst op een Macintosh; vanuit Macintosh-standpunt zien Windows-gebruikers echt met een telescoop. Als je de resultaten op een scherm ziet waar alle pixels dezelfde grootte hebben, gaan de verschillen van merkbaar tot dramatisch. De Windows-tekst is reusachtig, of de Mac-tekst is klein - kies maar uit. Zie onderstaand voorbeeld.

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

Grootte is wel belangrijk -- Dit leidt tot het antwoord op onze 20$-vraag: waarom tekst op web-pagina's gemaakt voor Windows-gebruikers er op een Mac zo klein uitziet. Stel dat het scherm van je computer - of het venster van je browser - 640 op 480 pixels meet. Als we menu-balken, titelbalken en andere troep even vergeten, kan de Mac in dat vlak 40 lijnen van 12-punts tekst weergeven (met vaste interlinie, dus zonder extra wit tussen de lijnen). Onder dezelfde voorwaarden toont Windows slechts 32 lijnen tekst; omdat Windows meer pixels gebruikt om tekst te tekenen, wordt dezelfde ruimte met minder tekst gevuld. Daardoor specifiëren web-designers die Windows gebruiken vaak kleine fontgrootten om meer tekst binnen een gegeven ruimte te proppen, en Macintosh-gebruikers krijgen een dubbele rekening: tekst die al met minder pixels werd getoond op een Mac-scherm wordt nog verkleind, tot op het punt waarop de tekst onleesbaar wordt.

Pijnlijke Puntjes -- Het fundamentele probleem is dat de computer een fysieke maat - het punt - probeert over te zetten naar een weergavetoestel met onbekende fysieke karakteristieken. Een standaard computermonitor is in feite een analoog projectiesysteem: hoewel de geometrische aspecten tot op zekere hoogte kunnen aangepast worden, heeft de monitor zelf geen enkel idee over hoeveel pixels hij toont over een gegeven fysieke afstand. Nieuwe digitaal programmeerbare displays - waaronder zowel CRTs als platte LCDschermen - schijnen hoop te bieden dat ze resolutie-informatie kunnen doorspelen naar de computer. Desondanks ken ik nog geen systemen die dat nu doen, en een volledige ondersteuning zou uiteraard moeten ingebouwd worden in de video-hardware en de operating systems. Merk op dat vele schermen wel enkele eigenschappen doorspelen naar de computer, waaronder de beschikbare logische resoluties in pixels.

Waarom maken Windows en Macintosh zo'n verschillende veronderstellingen over de resoluties van de schermen? Op de Mac moest het WYSIWYG (What You See Is What You Get) kunnen leveren. De Mac populariseerde de grafische interface, en Apple verstond dat wat op het Macintoshscherm stond fysiek zo veel mogelijk moest lijken op de afgedrukte versie. Dus, pixels komen overeen met punten. Evenals de Mac gelooft dat er 72 punten in een inch zitten, toont hij ook 72 pixels per inch. In de periode voor de 300 dpi laserprinters was de Mac een verbluffend staaltje van WYSIWYG, en displays in de oorspronkelijke compacte Macs en ook de originele kleurenschermen van Apple gingen van 71 tot 74 dpi - dicht genoeg bij 72 dpi om te kunnen verbergen dat de Mac geen flauw idee had van de fysieke resolutie van het scherm.

In feite verzette Apple zich jarenlang tegen hogere schermresoluties en tegen multisync displays; tenslotte, hoe meer de pixel zich verwijderde van 1/72 ste van een inch, hoe meer de Mac zich verwijderde van een WYSIWYG-machine. De groeiende populariteit van Windows, prijsdruk van PC-fabrikanten en een grote vraag naar laptops dwongen Apple flexibeler te worden op dit punt, en nu geven Macintosh-schermen doorgaans meer dan 72 dpi weer. Een 17 inch scherm dat draait op 1024 x 768 pixels toont normaal gezien tussen de 85 en 90 dpi. Het ingebouwde scherm van de iMac heeft een bruikbaar gebied van 13,8 inch (in diagonaal gemeten); als je even snel de stelling van Pythagoras toepast, kom je tot de conclusie dat het scherm van de iMac werkt op een nogal magere 58 dpi voor een resolutie van 640 op 480, maar bijna aan 93 dpi voor 1024 op 768. SGI's aangekondigde 1600SW platte scherm heeft een resolutie van 110 dpi.

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

De historische redenen achter het vooropstellen van 96 dpi schermen door Windows is minder duidelijk. De standaard schijnt te zijn bepaald door de Video Electronics Standards Association (VESA) met de specificatie van de VGA (Video Graphics Adapter), wat ietwat vooraf gaat aan het marktoverwicht van Windows. Voor zover ik kan zien waren er waarschijnlijk problemen qua compatibiliteit met de oudere CGA en EGA video systemen, en schijnbaar geloofde niemand binnen de VESA dat tekst onder de 10 of 12 punten leesbaar zou zijn op schermen met een resolutie kleiner dan 96 dpi. De Macintosh bewees het tegendeel, vooral door het zorgvuldig ontwerp van zijn scherm-bitmap fonts, zoals Geneva, Monaco, Chicago en New York. Ironisch genoeg, hoewel de resolutie van gangbare Macintosh-schermen stilletjesaan meer naar de 96 dpi toegaat, hebben de Windows-schermen over het algemeen resoluties die lang niet aan de 96 dpi standaard toekomen. Als je een Windows-gebruiker kent met een 17 inch monitor aan 1024 x 768, dan geeft zijn monitor waarschijnlijk weer tussen de 85 en 90 dpi - wat hetzelfde zou zijn bij een Macintosh.

Verbind de puntjes -- Hopelijk toont dit artikel je hoe een computer een ietwat vage maat neemt (het punt), dat als meetlat aanvaardt om karakters weer te geven die zelf een arbitrair deel van hun puntgrootte gebruiken, en uiteindelijk die informatie doorgeeft naar een scherm dat, naar alle waarschijnlijkheid, niet overeenkomt met het intern weergavesysteem van de computer. Het resultaat is een complete warboel, zelfs als je het platform uit de vergelijking weglaat.

Voorstanders van Windows bazuinen de hogere tekstresolutie van hun systeem soms uit als een voordeel, of beweren dat de Mac's lagere tekstresolutie diens kleine, vuile geheimpje is. Historisch gezien klinkt geen van beide beweringen erg waarheidsgetrouw. Hoewel tekst op een Windowssysteem bij een bepaalde puntgrootte exacter wordt weergegeven, geeft Windows WYSIWYG op ten voordele van die extra pixels. Jammer genoeg moet je concluderen dat geen van de gangbare systemen voor welk platform dan ook veel kans maakt accuraat geformatteerde tekst voort te brengen, zodus: iedereen is verliezer.

En dat is dan al de tekst die past... of niet past, afhankelijk van je systeem.

Niet-winstgevende en niet-commerciële publicaties en Websites mogen artikels overnemen of een HTML link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We garanderen de precisie van de artikels niet. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.

Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering