Как правильно посчитать baseline для строки?

Как найти ноль на линейке?

Typo Descent идёт вниз от baseline, Typo Ascent — вверх. В сумме они дают Em Size. По твоей ссылке — 770 вверх и 230 вниз, итого: 1000.

Давай перефразирую. Допустим я хочу { font-size: 16px; line-height: 24px; }

Где относительно верхушки строки должен пройти baseline?

Всякие крайние случаи, которые раздуют line box не рассматриваем. Это для микроконтроллеров, там надо только пару простейших случаев, чтобы легко дизайн переносился.

Берём из твоего шрифта Win Asc, Win Dsc и Em Size. (Например, LiberationSans — 1854, 434, 2048).
Высота Content Area: 16*(1854+434)/2048 = 17.875px
Предполагаю, что шрифтовый Line Gap (67) добавится поровну сверху и снизу (для размера шрифта 16px это примерно полпикселя, так что можно и вовсе проигнорировать).
Тогда зазор между Line top и верхом Content area (24 - 17.875)/2 = 3.0625
Зазор от верха Content Area до baseline: 16*1854/2048 = 14.484
От line top до baseline: 14.484+3.0625 = 17.547

«По-моему так» (с)

Спасибо!

Собсна, я в статье не смог найти где прямым текстом написано, что «сontent area» (ascent + descent после масштабирования) выравнивается по дефолту в середину строки. И что положение «em box» тоже берется относительно середины «сontent area». Если это так, то дальнейшие вычисления понятны.

Правильно ли я понимаю, что line gap нужен только для многострочного режима, если юзер надумает выставить слишком мелкий line-height, и в «нормальных» условиях можно просто проигнорировать?

Baseline хранится в самом шрифте же, ибо зависит от желаний дизайнера шрифта и письменности.

А я уж думал там гномы с кисточками и акварелью.

Там приведены примеры того чего происходит с разным вертикальным выравниванием и из этого вырисовывается, что если ничего не задать, то будет выравнивание вида «середина контента по середине строки».

Да, чтоб Line gap поучаствовал нужно больше одной строки. Но если он не нулевой, то он должен бы добавляться всегда. Просто если line-height задана безразмерно, то она вычислится от размера шрифта с учётом Asc/Dsc/Em/Gap. А если задать в пикселях (что вроде как не рекомендуют), то судя по всему line-height-у становится пофиг на то что там в шрифте и если шрифт оказался выше размера строки, значит будут строки друг на друга налезать.

Baseline как таковой не хранится. Это ж «всегда 0», чего его хранить?

А как же baseline table?

PS: только погружаюсь во всю эту тему с текстом.

Фигасе в ОpenType понаворотили...

Есть правда подозрение, что всегда будет или так:
«list identical baseline values with the roman baseline positioned at a Y value of zero (0)»
или эдак:
«with the default baseline for each script at the zero (0) coordinate».

Наверное, для случая Vit это ничего не меняет (вряд ли у него шрифты со сдвинутой базовой для латиницы/кириллицы), но в общем случае ты прав — надо добавлять поправку на ветер.
И интересно было бы поглядеть, а браузеры-то эту фигню вообще понимают?.. =)

https://mdn.mozillademos.org/en-US/docs/Web/SVG/Attribute/dominant-baseline$samples/Example?revision=1526844 ?

Вот тут ещё про «hanging baseline» немного: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6bsln.html

Хьюстон, у нас проблемы. Есть открыть в фонтфорже параметры фонта, то там на секциях General и OS/2 ascent-ов с descent-ами овердохрена.

Roboto Regular:

- General asc: 1536
- General desc: 512
- EM: 2048
- OS/2 Typo Ascent: 1536
- OS/2 Typo Descent: -512
- OS/2 Typo Line Gap: 102
- OS/2 Win Ascent: 1946
- OS/2 Win Descent: 512
- OS/2 HHead Ascent: 1900
- OS/2 HHead Descent: -500
- OS/2 HHead Line Gap: 0

Причем, если я правильно понял, то фонтфорж для рисования линий верх/низ использует general, а в статье пишут для браузеры используют либо Win либо HHead.

Тогда не совсем понятно, нахрена вообще general asc/desc нужен.

Поскольку мы юзаем opentype.js для рендеринга, пока считаем что оно внутри как-то само собой правдоподобно переварит.

Текушая актуальная проблема - как правильно заскейлить фонт, если юзер хочет NNpx, и что оставить в заголовке битмапного фонта чтобы правильно позиционировать внутри строки.

Если мы про векторные шрифты, а не про растровые, то: font_size / units_per_em. При условии что у нас стандартный dpi.

Я думаю, что правильнее всего было бы на целевых шрифтах проверить целевые браузеры. Нарисовать какую-нибудь сетку и вывести текст размером 100, а то и 200. В основном, чтобы убедиться, что результаты более-менее совпадают с тем чего понаписано в статье.

С другой стороны...
В твоём примере разница в расположении baseline для шрифта 16px при вычислении с использованием Win vs HHead составит 0.13px.

Чем мельче шрифт, тем меньше разница. Полпикселя набегает для шрифта размером 61px. Чёрт его знает как оно округляет, так что при таком размере шрифта уже можно на пиксель промахнуться.
Но мне почему-то кажется, что для тебя это некритично =)

C разницей Win/HHead вопросов нет. Меня смущает что они сильно зависят от наличия всяких акценов над буквами. Если выпилить глифы с ударениями, домиками и т.п, то метрики резко уменьшатся.

Если рассуждать логически, чтобы визуально шрифт от добавления новых глифов не уезжал, надо использовать типографические метрики (они соответствуют горизонтальным линиям в фонтфорже).

Непонятно почему в браузерах тогда сделано явно иначе.