Очень хорошее введение в Что должен знать каждый разработчик о шрифтах .
Я скопировал пост здесь, но большая часть поста зависит от конкретных шрифтов, на которых написаны части и изображения, поэтому я настоятельно рекомендую ссылку выше.
Я изначально думал, что использовать шрифты будет довольно просто. Тем не менее, правильная обработка шрифтов оказалась значительным усилием в Windward Reports (наша система отчетов XML и SQL). Если вы собираетесь сделать гораздо больше, чем поместить текстовую строку в форму, подробности начинают иметь значение.
Шрифты и глифы
Так что же такое шрифт? По сути, шрифт представляет собой серию символов. То, что вы считаете символом, подобным букве А, является глифом. Шрифт - это набор глифов для всех букв этого шрифта. Если вы получите шрифт Helvetica, все их глифы выглядят в одном направлении. Если вы получите шрифт Times Roman, они выглядят по-другому. Каждый набор глифов этого шрифта.
Теперь нам нужно ввести понятие кодовых страниц. Кодовая страница - это сопоставление номера символа с конкретным глифом. Программы изначально сохраняли каждый символ в виде байта. Тогда для азиатских наборов символов были системы DBCS (некоторые символы были 1 байтом, некоторые 2). Программы сегодня в основном используют Unicode, но веб-страницы, как правило, имеют формат UTF-8, представляющий собой многобайтовую последовательность, которая может иметь длину до 4 байтов.
Зачем поднимать кодировку? Потому что каждый шрифт имеет кодировку, в которой символ 178 может возвращать очень разные символы в зависимости от кодовой страницы, используемой шрифтом. Большинство файлов шрифтов используют Unicode, поэтому у вас есть стандарт, но многие программы по-прежнему используют определенные кодовые страницы, где эта страница сопоставлена со шрифтом. Это то, что происходит при отображении ABC и шрифта Wingdings, поэтому вы получаете you. Итак, во-первых, вам нужно убедиться, что используемая кодировка соответствует или сопоставлена с кодировкой используемых вами шрифтов.
И это становится еще сложнее. Символы со значениями 0xE000 - 0xF8FF не определены. Каждый шрифт может делать те, что они хотят (одно из применений - добавить скрипт Klingon). Таким образом, символ со значением в этом диапазоне по определению привязан к файлу шрифта, который он использует для отображения этого шрифта. Так работает большинство шрифтов с символами.
Хорошо, значит, вы используете Unicode, ваш файл шрифтов использует Unicode, вы передаете ему строку и ... строка отображается пустой. В чем дело? Ну, нет требования, чтобы файл шрифта имел глиф для любого заданного символа. Шрифт Symbol не будет иметь ABC. Большинство шрифтов, используемых в Европе и Америке, не имеют китайских, японских или корейских символов. Не является ошибкой использовать глиф, которого нет у шрифта, но он не будет отображать ничего, не пустой, а ничего (т. Е. 0 точек в ширину).
Вы также можете столкнуться с подобной проблемой, если используете одну из старых кодовых страниц, если хотите отобразить глиф, который не существует в кодовой странице. В этом случае вам необходимо отобразить другую кодовую страницу, по крайней мере, для этого символа (именно так Word использовал для обработки этого случая).
Семейства шрифтов
Шрифты делятся на несколько разных классов. Во-первых, это пропорциональные и моноширинные шрифты. В моноширинном шрифте все символы имеют одинаковую ширину. И высота постоянна в том, что все строчные буквы имеют такую же высоту, как и все прописные. Избегайте моноширинных шрифтов, насколько это возможно, потому что их гораздо сложнее читать. Азиатские шрифты почти все моноширины, потому что все символы китайского ханьского алфавита имеют одинаковую ширину и высоту, поэтому пропорциональность не имеет смысла. С другой стороны, иврит и арабский в значительной степени должны быть пропорциональны.
Далее идет шрифт с засечками, где вы получаете материал в конце их хода, без засечек, где вы не получаете ничего лишнего в конце, декоративный, где он находится далеко от нормы, и символ, который может иметь что-нибудь случайное , включая штрих-коды, которые соответствуют номерам ASCII кодов символов, сопоставленных с глифами. И это только западноевропейские алфавиты.
Fontметрика
Теперь мы приступаем к измерению шрифтов, и по большинству (не всем) шрифтов это измерение глифов. Стандартное измерение, используемое для шрифтов, - это точка, и хотя существует много историй о том, что изначально означала точка, для компьютерного мира она составила 72 точки == 1 дюйм. Вы также можете иногда увидеть твип, обозначающий двадцатую часть точки, поэтому 1440 твипов == 1 дюйм. И теперь у нас есть EMU, где 914400 EMU == 1 дюйм (подробнее здесь). Если вы работаете с точками, вам нужно использовать переменные с плавающей точкой. С твипами обычно все в порядке, а с EMU определенно.
Затем идет размер шрифта. Это совершенно произвольное число. Думайте об этом как о диагональном размере старых мониторов с ЭЛТ, где фактический размер был близок к тому, что вы ожидали, но никогда не был таким числом. Размер точки определяет размер отображаемых глифов, но он не имеет конкретного измерения на странице.
Теперь вот где это начинает становиться интересным, fontmetrics. Во-первых, все должно быть измерено от базовой линии. Работа с любой другой частью шрифта не будет работать - вы столкнетесь с серьезными проблемами. Так что начните там. Самая высокая нарисованная часть над базовой линией - это подъем, а самая низкая нарисованная часть под базовой линией - это спуск, измеренный от базовой линии.
Тогда есть интервал между двумя строками текста. Это настройка шрифта, так как дизайнер шрифтов определяет, какой интервал подходит для этого шрифта. Это может быть возвращено разными способами, Windows считает это интервалом, который вы поместили над следующей строкой, возвращая меру от базовой линии до базовой линии, в то время как Java рассматривает его как интервал ниже строки перед следующей строкой и возвращает только это значение. Этот начальный интервал - это интервал, который вы помещаете между строками одинакового одинарного текста Если интервал больше одного интервала, вы добавляете к этому значению.
Как правило, вы хотите получить эти высоты для шрифтов, а не для строки глифов в отображаемой строке. Зачем? Потому что, если бы строка была «мы были wrox» - без восходов и спусков, линия была бы помещена ближе к другим строкам в абзаце, и это выглядело бы странно. Вам также нужно посмотреть на все шрифты и размеры точек, потому что если какой-то текст больше, вы должны использовать большие значения ascent / descent / Ведущие. Но только для строк, которые имеют больший текст, а не для всего абзаца. И снова, все это измеряется от базовой линии, которая является единственным способом обработки смешанных шрифтов / размеров.
Хорошо, высота занимает немного работы, но это довольно просто, но ширина - это становится действительно интересным. И под интересным я имею в виду, что вы должны все сделать правильно. По сути, за исключением шрифтов с фиксированной шириной, сложение ширины каждого глифа не будет равным ширине всех этих глифов, отображаемых вместе. Почти никогда. Зачем? Пара причин:
• Кернинг - это место, где буквы располагаются на основе буквы, к которой они примыкают. Вот почему AB остается четким, в то время как tt довольно сильно перекрывается.
• Комбинации некоторых символов в латинских алфавитах объединяются, например, ae становится æ и в немецком ss становится ß.
• Глифы иврита и арабского языка различаются для одного и того же символа в зависимости от того, находится ли он в начале, в середине или в конце слова. И в случае арабского языка особенно глифы, используемые на концах, имеют тенденцию быть шире, чем глифы в середине. Таким образом, ширина dependent зависит от того, где она находится в строке.
IБионаправленные шрифты имеют дополнительную проблему, перечисленную ниже.
• Сложные скрипты, такие как Indic (India), изменят глиф в локации, составляя его из нескольких символов. Таким образом, строка из трех символов может быть от 1 до 3 символов.
Очень просто, ты ниd передать полную, полностью отформатированную строку в API-интерфейс fontmetrics, предоставляемый платформой, на которой вы работаете, чтобы получить длину строки. Это дорогостоящий вызов, потому что строка будет отображаться в памяти для определения длины, но нет альтернативы, которая будет точной. И вы должны использовать те же параметры измерения, что и при рендеринге. Каждый раз, когда они не совпадают, мы обнаруживаем достаточно большие различия, чтобы человеческий глаз мог их различить. Лучший способ проверить свой код на это - посмотреть на выровненный по правому краю текст, потому что при рендеринге обычно нужно получить базовую позицию левого конца строки, поэтому, если вы вычислите неправильную длину - он покажет.
Двунаправленный текст
Наконец, у нас есть проблема двунаправленного текста (арабский и иврит). Двунаправленный текст идет справа налево, кроме цифр и латинских слов слева направо. Таким образом, он читается справа налево, затем по номеру или последовательности латинского текста вы перепрыгиваете в крайнюю левую точку, читаете слева направо назад, туда, где вы завершили предыдущий иврит / арабский, а затем переходите к началу латинского / номер части и вернуться справа налево.
Было проведено множество исследований относительно того, когда должны произойти эти переключения. Существуют символы с сильным направлением, символы со слабым направлением и символы, не имеющие направленного предпочтения. Вы не молитесь о правильном применении этих правил. Никто. Но еще не все потеряно. Практически у каждой платформы, включая Java и Windows, есть API, в котором вы предоставляете строку символов в порядке чтения, и она будет правильно отображать их в соответствии с правилами. У них также есть API-интерфейс, который сообщает вам, где находится каждый персонаж и к какому персонажу следует перейти, если вы хотите переместить символ каретки на 1 вперед или назад.
Вы можете использовать этот API для любого рендеринга шрифтов и перемещения каретки, независимо от текста, и он будет хорошо работать - и на сложных сценариях. Это немного сложно начать с этого, если вы не нацелены на би-ди или сложные сценарии, но если вы собираетесь быть там, в конце концов, лучше начать с его использованием, чтобы вам не пришлось перепроектировать свой код. Поверьте мне, вы действительно не хотите пересматривать архитектуру (мне пришлось один раз - ОЙ!).
Внимание!
Не копируйте шрифты Windows в Linux или другие операционные системы. Метрики шрифта, как правило, отключены, и текст будет выглядеть не так. Я не знаю, что, поскольку TrueType должен быть переносимым, но на практике, так же, как Java пишется один раз, везде отлаживается, шрифты, как правило, проектируются, когда везде настраиваются. Получите шрифты от поставщика, который оптимизировал их для вашей платформы.