Waarom W niet in linker bovenhoek?
Ik ben druk bezig met de ontwikkeling van een open source alternatief voor Microsoft Office. Ik ben een heel eind gevorderd maar zit met enkele vraagstukken inzake typografie. In de layout engine worden paragrafen tekst conform gekozen letterfamilie en puntgrootte en marges in een layout geplaatst en getoond op scherm. Deze berekende layout is ook de basis voor PDF export.
Nu zie ik dat in andere populaire tekstverwerkers (zoals MS Word en Apple Pages) er altijd wat ruimte wordt gereserveerd aan de bovenkant. De bovenkant van een letter op de eerste regel raakt niet de bovenmarge. Zie ook twee schermafbeeldingen uit MS Word en Apple Pages. Ik vraag me af waarom dat is. Is het niet logischer om de bovenkant uit te lijnen aan de bovenmarge, en op basis van de instelde regelhoogte witruimte te plaatsen aan de onderkant van de regel?
Zie ook laatste afbeelding (van mijn tekstverwerker in ontwikkeling), waar de tekst dus wel is uitgelijnd aan de bovenmarge.
Heeft iemand een idee waarom Word en Pages hier ruimte vrij laten? Is er een historische reden?
Nog een aanvulling op mijn bericht van gisteren. Als je in de ingewanden van een font kijkt, kom je in de OS/2- en hhea-tabellen verschillende metrische waarden tegen. Een eenvoudig rekenvoorbeeld maakt misschien duidelijker hoe deze waarden zich tot elkaar kunnen verhouden.
Vaak worden de verticale waarden zo gekozen dat zij uiteindelijk dezelfde totale verticale omvang opleveren. Dit zorgt ervoor dat lettertypen zich in verschillende omgevingen zo veel mogelijk hetzelfde gedragen. Deze afstemming is echter een praktische conventie en geen vereiste die in de specificaties is vastgelegd.
Stel dat de Typo-metrics als volgt zijn:
sTypoAscender: 750
sTypoDescender: 250
sTypoLineGap: 220
De totale verticale omvang bedraagt dan 1220 units. Een mogelijke invulling van de Windows-metrics is:
usWinAscent: 950
usWinDescent: 270
De hhea-waarden kunnen dan bijvoorbeeld zijn:
ascender: 950
descender: -270
lineGap: 0
Hoewel de afzonderlijke waarden verschillen, blijft de totale verticale omvang gelijk. Daardoor kunnen verschillende metrische systemen toch tot een vergelijkbare regelhoogte leiden.
Een ander veelvoorkomend scenario, vooral in combinatie met de USE_TYPO_METRICS-bit, is dat de Typo- en hhea-metrics gelijk worden gemaakt, bijvoorbeeld:
ascender: 750
descender: -250
lineGap: 220
Een derde benadering, die vooral bij sommige webfonts wordt toegepast, is om usWinAscent en usWinDescent leidend te maken voor de overige verticale metrics. Dit kan verschillen tussen browsers en applicaties die verschillende metrische systemen gebruiken verkleinen.
Er zijn dus meerdere manieren om consistente verticale metrics op te bouwen. De uiteindelijke regelhoogte en de positionering van de eerste basislijn zijn afhankelijk van zowel de interpretatie van de metrische waarden door de applicatie als de keuzes die bij het ontwerp van het lettertype zijn gemaakt.
De vraag over de positionering van de eerste regel is interessant. Allereerst is het perspectief duidelijk westers: wat precies de bovenkant van een letter is, zal bijvoorbeeld een Vietnamees wellicht anders ervaren. Ergens moet de eerste regel beginnen en er moet ruimte zijn voor accenten en andere diakritische tekens. Bovendien worden in programma’s als Microsoft Word en Adobe InDesign natuurlijk veel meer schriften gebruikt dan alleen het Latijnse.
Een OpenType-lettertype bevat verschillende sets verticale metrics. De ontwerpwaarden zijn:
– sTypoAscender
– sTypoDescender
– sTypoLineGap
Daarnaast zijn er de Windows-metrics usWinAscent en usWinDescent. Die zijn bedoeld als ‘clippingmetrics’: zij moeten ervoor zorgen dat ook de hoogste accenten en de diepste staarten niet worden afgesneden. Voor Apple-systemen bestaan daarnaast de hhea-waarden (Ascender, Descender en LineGap), die historisch werden gebruikt voor de regelopbouw en teruggaan op de oorspronkelijke TrueType-architectuur van de Mac, die nog nauw aansloot bij de bitmapperiode.
Historisch gebruikten Windows-programma’s vaak de usWin-waarden voor de regelafstand, terwijl macOS zich baseerde op de hhea-metrics. Tegenwoordig bevatten veel OpenType-fonts de USE_TYPO_METRICS-bit, waarmee applicaties worden gevraagd de Typo-metrics te gebruiken. Mijn ervaring (die ik nog eens wil controleren) is dat de afstand van de bovenkant van een tekstkader tot de eerste basislijn dan in de praktijk vaak wordt afgeleid van de sTypoAscender in combinatie met de sTypoLineGap, en dus niet uitsluitend van de ascender.
Dat extra wit is overigens niet per se onlogisch: het verkleint de kans dat accenten of andere diakritische tekens buiten het tekstkader vallen. Bovendien kennen programma’s als Microsoft Word en Adobe InDesign een lange ontwikkelingsgeschiedenis. De manier waarop zij verticale fontmetrics interpreteren, is niet alleen het gevolg van de OpenType-specificatie, maar ook van tientallen jaren aan achterwaartse compatibiliteit.
Het is natuurlijk denkbaar dat je dit gedrag optioneel maakt, zodat gebruikers desgewenst de eerste basislijn direct op de sTypoAscender kunnen laten baseren.
Beste Bart,
Wat deze ruimte aan de bovenzijde is of zou moeten zijn verschilt per lettertype dat ik weet. Volgens mij, maar ik ben geen letterontwerper, is alleen de corpsgrootte een vast gegeven. Maar waar de basislijn staat van een letter, hoe groot het letterbeeld is of dat er een overhang gebruikt om een diakriet te plaatsten verschilt per lettertype, eigenlijk net zoals dit met loden letters ook het geval is.
Beste Bart
is dit niet een ruimte voor een diakriet boven een kapitaal? Zie: ,https://ruudhuysmans.nl/diakriet.jpg
Hallo Ruud, dat zou kunnen inderdaad. Al vraag ik me dan af waarom die diakrieten/accenten dan ook niet precies uitlijnen met bovenmarge.. Zie https://webdesq.net/transport/diakrieten.png
Enig idee hoe ik uit een TrueType (of een gedecomprimeerde WOFF2) file kan uitlezen wat die extra ruimte aan boven dan zou moeten zijn?
Of heeft er iemand een begrijpelijke uitleg hoe de verschillende hoogtes/breedtes in zo’n TTF gedefinieerd zijn?
Beste Bart, een interessante vraag. Maar ik ben bang dat er onder de lezers van deze site niet veel mensen zijn die er iets zinnigs over kunnen zeggen. Je kunt je vraag misschien beter stellen op een forum als TypeDrawers: typedrawers.com. Daar zitten specialisten.