Что такое двухбайтный шрифт
«Вы выбрали шрифт с одним byte, чтобы заменить шрифт с двойным byte» при замене японского шрифта
Office 365 ProPlus переименован в Майкрософт 365 корпоративные приложения. Для получения дополнительной информации об этом изменении прочитайте этот блог.
Симптомы
Рассмотрим следующий сценарий. Вы открываете Microsoft® PowerPoint® 2010, русская версия, которая содержит наборы японских шрифтов. На вкладке Главная в группе редактирования в статье Replace щелкните Заменить шрифты. В списке Replace drop-down выберите японский шрифт, который необходимо заменить. Вы выбираете другой японский шрифт в списке With drop-down. Затем нажмите кнопку Заменить.
В этом сценарии шрифт не заменяется. Кроме того, появляется приведенное ниже сообщение об ошибке:
Для замены шрифта с двойным счетом выбран шрифт с одним byte. Выберите шрифт с двойным счетом.
Причина
Эта проблема возникает, если верны следующие условия:
Если эти условия верны, вы не можете заменить шрифт, и вы получите сообщение об ошибке.
Обходной путь
Метод 1. Вручную замените шрифт
Чтобы решить эту проблему, можно найти каждый текстовый объект, использующий шрифт, который необходимо заменить, а затем выбрать текст. Затем на вкладке Home в группе Шрифт в списке капля шрифта выберите шрифт, на который необходимо заменить старый шрифт.
Метод 2. Замените шрифт на компьютере с установленным шрифтом
Чтобы решить эту проблему, можно либо установить шрифт, который необходимо заменить, либо заменить шрифт в презентации на компьютере с уже установленным шрифтом.
Статус
Корпорация Майкрософт подтвердила, что это проблема в продуктах Майкрософт, перечисленных в разделе «Применяется к».
Исчерпывающий пост о внедрении шрифтов в PowerPoint
Шрифты и PowerPoint – один из самых запутанных и противоречивых аспектов этой гениальной программы, поэтому я решил копнуть максимально глубоко, чтобы выяснить все раз и навсегда. Текст содержит небольшое количество технической занудистики по шрифтам, без этого никуда.
В двух словах, PP может внедрять шрифты в презентацию. Но не все и не всегда. Эта возможность зависит от версии программы и от формата шрифта. И это таит в себе ряд засад.
На маке внедрение шрифтов поддерживается c версии PowerPoint 16.17 (Сентябрь 2018). Более ранние версии просто не отобразят внедренные шрифты. Засада, но ладно. Кстати, на Windows шрифты можно внедрять с версии 3.0 (Май 1992).
Допустим, у вас свежайший офис и вы даже знаете какую галочку в настройках надо поставить, но не тут-то было.
Существует три основных формата: TrueType, PostScript и OpenType. Остановимся на каждом на пару слов.
TrueType. Один из двух самых распространенных форматов. Большая часть шрифтов на вашем компьютере – TrueType. Файлы имеют расширение *.ttf.
PostScript. Древнючий формат, заточенный под профессиональную печать. Файлы имеют расширение *.pfb, *.pfm, *.afm. Сегодня встречается чрезвычайно редко.
OpenType. Своеобразный синтез TrueType и PostScript. Это самый современный и прокачанный формат. Может иметь расширение *.otf или *.ttf. В первом случае шрифт основан на PostScript, во втором – на TrueType. И это вторая засада: разные форматы шрифтов могут иметь одинаковое расширение файла!
Итак, мы разобрались какие бывают шрифты, теперь отбросим те, которые PP встроить не может в принципе:
Итого, вы можете внедрять TrueType шрифты с параметрами Editable и Installable и OpenType шрифты на основе TrueType. Вот почему я использую нестандартные шрифты только если экспортирую результат в PDF. Если презентация будет в дальнейшем правиться, я не рискую. За 5 лет работы внедренные шрифты несколько раз конкретно меня подводили своей непредсказуемостью. Слишком много слабых мест и нюансов. Как я уже писал в своем профессионально дневнике, существует много других способов добиться эффекта в презентации.
Свежие версии iOS, Android и веб-версия PowerPoint Online поддерживают внедренные шрифты.
Компью А рт
Символы, знаки и байты: введение в Юникод
Юникод (англ. Unicode) — стандарт кодирования, позволяющий представить знаки практически всех письменных языков. Он был предложен в 1991 году некоммерческой организацией Unicode Consortium, Unicode, Inc. Применение этого стандарта позволяет закодировать очень большое число символов из разных письменностей: в документах Unicode могут соседствовать китайские иероглифы, математические символы, буквы греческого алфавита, латиницы и кириллицы, при этом становятся ненужными кодовые страницы.
Стандарт состоит из двух основных разделов: универсальный набор символов (universal character set, UCS) и семейство кодировок (Unicode transformation format, UTF). Универсальный набор символов задает однозначное соответствие символов кодам — элементам кодового пространства, представляющим неотрицательные целые числа. Семейство кодировок определяет машинное представление последовательности кодов UCS.
Коды в стандарте Юникод разделены на несколько областей. Область с кодами от U+0000 до U+007F содержит символы набора ASCII с соответствующими кодами. Далее расположены области знаков различных письменностей, знаки пунк-туации и технические символы. Часть кодов зарезервирована для использования в будущем. Под символы кириллицы выделены области знаков с кодами от U+0400 до U+052F (рис. 4 и 5), от U+2DE0 до U+2DFF (рис. 6), от U+A640 до U+A69F (рис. 7).
Рис. 4. Базовый русский, расширенная кириллица: украинский, македонский, сербский, старославянский, башкирский, татарский и др.
Рис. 5. Расширенная кириллица: современный абхазский, чувашский, алеутский, мордовский, коми, чукотский, ханты и др.
Рис. 6. Старославянские модифицирующие знаки
Рис. 7. Старославянский и староабхазский
Первая версия Unicode представляла собой кодировку с фиксированным размером символа в 16 бит, то есть общее число кодов было 216 (65 536). Отсюда происходит практика обозначения символов четырьмя шестнадцатеричными цифрами (например, U+0410). При этом в Юникоде планировалось кодировать не все существующие символы, а только те, которые необходимы в повседневном обиходе. Редко применяемые символы должны были размещаться в «области символов для частного использования» (Private Use Area), которая первоначально занимала коды от U+D800 до U+F8FF. Чтобы применять Юникод и в качестве промежуточного звена при преобразовании разных кодировок друг в друга, в него включили все символы, представленные во всех наиболее известных кодировках.
В дальнейшем, однако, было принято решение кодировать все символы и в связи с этим значительно расширить кодовую область. Одновременно с этим коды символов стали рассматриваться не как 16-битные значения, а как абстрактные числа, которые в компьютере могут представляться множеством разных способов.
Поскольку в ряде компьютерных систем (например, Windows NT) фиксированные 16-битные символы уже использовались в качестве кодировки по умолчанию, было решено все наиболее важные знаки кодировать только в пределах первых 65 536 позиций (так называемая basic multilingual plane, BMP). Остальное пространство применяется для «дополнительных символов» (англ. supplementary characters): систем письма вымерших языков или очень редко используемых китайских иероглифов, математических и музыкальных символов.
Для совместимости со старыми 16-битными системами была изобретена система UTF-16, где первые 65 536 позиций, за исключением позиций из интервала от U+D800 до U+DFFF, отображаются непосредственно как 16-битные числа, а остальные представляются в виде «суррогатных пар» (первый элемент пары из области U+D800…U+DBFF, второй элемент пары из области U+DC00…U+DFFF). Для суррогатных пар была использована часть кодового пространства (2048 позиций), ранее отведенного для Private Use Area.
Поскольку в UTF-16 можно отобразить только 2 20 +2 16 –2048 (1 112 064) символов, то это число и было выбрано в качестве окончательной величины кодового пространства Юникода.
Хотя кодовая область Юникода была расширена за пределы 2 16 уже в версии 2.0, первые символы в «верхней» области были размещены только в версии 3.1.
По мере изменения и пополнения таблицы символов системы Юникода и выхода новых версий этой системы (эта работа ведется постоянно, поскольку изначально система Юникод включала только Plane 0 — двухбайтные коды) выходят и новые документы ISO. Система Юникод существует в общей сложности в следующих версиях:
Хотя формы записи UTF-8 и UTF-32 позволяют кодировать до 231 (2 147 483 648) кодовых позиций, было принято решение использовать лишь 1 112 064 для совместимости с UTF-16. Впрочем, даже и этого более чем достаточно — сегодня (в версии 5.1) применяется немногим более 100 тыс. кодовых позиций.
Кодовое пространство разбито на 17 плоскостей (подмножеств) по 2 16 (65 536) символов. Нулевая плоскость называется базовой, в ней расположены символы наиболее употребительных письменностей. Первая плоскость используется в основном для исторических письменностей, вторая — для редко применяемых иероглифов, третья зарезервирована для архаичных китайских иероглифов ККЯ. Плоскости 15 и 16 выделены для частного употребления (табл. 22).
Таблица 22
Базовая многоязыковая плоскость
Basic Multilingual Plane, BMP
Дополнительная многоязыковая плоскость
Supplementary Multilingual Plane, SMP
Дополнительная иероглифическая плоскость
Supplementary Ideographic Plane, SIP
Третичная иероглифическая плоскость
Tertiary Ideographic Plane, TIP
Дополнительная
плоскость особого
назначения
Supplementary Special-purpose Plane, SSP
Применяется как дополнительная область A для частного использования
Supplementary Private Use Area-A, SPUA-A
Применяется как дополнительная область B для частного использования
Supplementary Private Use Area-B, SPUA-B
Для обозначения символов Unicode используется запись вида «U+xxxx» (для кодов 0…FFFF), или «U+xxxxx» (для кодов 10000…FFFFF), или «U+xxxxxx» (для кодов 100000…10FFFF), где xxx — шестнадцатеричные цифры. Например, символ «я» (U+044F) имеет код 044F16 = 110310.
Универсальная система кодирования (Юникод) представляет собой набор графических символов и способ их кодирования для компьютерной обработки текстовых данных.
Графические символы — это символы, имеющие видимое изображение. Графическим символам противопоставляются управляющие символы и символы форматирования.
Графические символы включают следующие группы:
Юникод — это система для линейного представления текста. Символы, имеющие дополнительные над или подстрочные элементы, могут быть представлены в виде построенной по определенным правилам последовательности кодов (составной вариант, composite character) или в виде единого символа (монолитный вариант, precomposed character).
Графические символы в Юникоде подразделяются на протяженные и непротяженные (бесширинные). Непротяженные символы при отображении не занимают места в строке. К ним относятся, в частности, знаки ударения и прочие диакритические знаки. Как протяженные, так и непротяженные символы имеют собственные коды. Протяженные символы иначе называются базовыми (англ. base characters), а непротяженные — модифицирующими (англ. combining characters), причем последние не могут встречаться самостоятельно. Например, символ «á» может быть представлен как последовательность базового символа «a» (U+0061) и модифицирующего символа «’» (U+0301) или как монолитный символ «á» (U+00C1).
Особый тип модифицирующих символов — селекторы варианта начертания (англ. variation selectors). Они действуют только на те символы, для которых такие варианты определены. В версии 5.0 варианты начертания определены для ряда математических символов, для символов традиционного монгольского алфавита и для символов монгольского квадратного письма.
Поскольку одни и те же символы можно представить различными кодами, что иногда затрудняет обработку, существуют процессы нормализации, предназначенные для приведения текста к определенному стандартному виду.
В стандарте Юникода определены четыре формы нормализации текста:
— символ S является начальным, если он имеет нулевой класс модификации в базе символов Юникода,
— в любой последовательности символов, стартующей с начального символа S, символ C блокируется от S, если и только если между S и C есть какойлибо символ B, который или является начальным, или имеет одинаковый либо больший класс модификации, чем C. Это правило распространяется только на строки, прошедшие каноническую декомпозицию,
— первичным композитом считается символ, у которого есть каноническая декомпозиция в базе символов Юникода (или каноническая декомпозиция для хангыля и он не входит в список исключений);
— если очередной символ C не блокируется последним встреченным начальным базовым символом L и может быть успешно первично совмещен с ним, то L заменяется на композит L-C, а C удаляется;
Под терминами «композиция» и «декомпозиция» понимают соответственно соединение или разложение символов на составные части.
Стандарт Юникод поддерживает письменности языков с направлением написания как слева направо (left-to-right, LTR), так и справа налево (right-to-left, RTL) — например арабское и еврейское письмо. В обоих случаях символы хранятся в «естественном» порядке; их отображение с учетом нужного направления письма обеспечивается приложением.
Кроме того, Юникод поддерживает комбинированные тексты, сочетающие фрагменты с разным направлением письма. Данная возможность называется двунаправленностью (bidirectional text, BiDi). Некоторые упрощенные обработчики текста (например, в сотовых телефонах) могут поддерживать Юникод, но не иметь поддержки двунаправленности. Все символы Юникода поделены на несколько категорий: пишущиеся слева направо, пишущиеся справа налево и пишущиеся в любом направлении. Символы последней категории (в основном это знаки пунк-туации) при отображении принимают направление окружающего их текста.
Юникод включает практически все современные письменности, в том числе арабскую, армянскую, бенгальскую, бирманскую, глаголицу, греческую, грузинскую, деванагари, еврейскую, кириллицу, китайскую (китайские иероглифы активно используются в японском языке, а также, довольно редко, в корейском), коптскую, кхмерскую, латинскую, тамильскую, корейскую (хангыль), чероки, эфиопскую, японскую (которая, кроме китайских иероглифов, включает еще и слоговую азбуку) и др.
С академическими целями добавлены многие исторические письменности, в том числе руны, древнегреческая, египетские иероглифы, клинопись, письменность майя, этрусский алфавит.
В Юникоде представлен широкий набор математических и музыкальных символов, а также пиктограмм.
Однако в Юникод принципиально не включаются логотипы компаний и продуктов, хотя они и встречаются в шрифтах (например, логотип Apple в кодировке MacRoman (0xF0) или логотип Windows в шрифте Wingdings (0xFF)). В юникодовских шрифтах логотипы должны размещаться только в Private Use Area.
Консорциум Юникода работает в тесной связи с рабочей группой ISO/IEC/JTC1/SC2/WG2, которая занимается разработкой международного стандарта 10646 (ISO/IEC 10646). Между стандартом Юникода и ISO/IEC 10646 установлена синхронизация, хотя каждый стандарт использует свою терминологию и систему документации.
Сотрудничество консорциума Юникода с Международной организацией по стандартизации (англ. International Organization for Standardization, ISO) началось в 1991 году. В 1993-м ISO выпустила стандарт DIS 10646.1. Для синхронизации с ним консорциум утвердил стандарт Юникода версии 1.1, в который были внесены дополнительные символы из DIS 10646.1. В результате значения закодированных символов в Unicode 1.1 и DIS 10646.1 полностью совпали.
В дальнейшем сотрудничество двух организаций продолжилось. В 2000 году стандарт Unicode 3.0 был синхронизирован с ISO/IEC 10646-1:2000. Предстоящая третья версия, ISO/IEC 10646, будет синхронизирована с Unicode 4.0. Возможно, эти спецификации даже будут опубликованы как единый стандарт.
Аналогично форматам UTF-16 и UTF-32 в стандарте Юникода, стандарт ISO/IEC 10646 также имеет две основные формы кодирования символов: UCS-2 (2 байта на символ, аналогично UTF-16) и UCS-4 (4 байта на символ, аналогично UTF-32). UCS — значит универсальный многооктетный (многобайтовый) кодированный набор символов (universal multiple-octet coded character set). UCS-2 можно считать подмножеством UTF-16 (UTF-16 без суррогатных пар), а UCS-4 является синонимом для UTF-32.
Юникод имеет несколько форм представления (Unicode transformation format, UTF): UTF-8, UTF-16 (UTF-16BE, UTF-16LE) и UTF-32 (UTF-32BE, UTF-32LE). Была разработана также форма представления UTF-7 для передачи по семибитным каналам, но из-за несовмес-тимости с ASCII она не получила распространения и не включена в стандарт. 1 апреля 2005 года были предложены две шуточные формы представления: UTF-9 и UTF-18 (RFC 4042).
В Microsoft Windows NT и основанных на ней системах Windows 2000 и Windows XP в основном используется форма UTF-16LE. В UNIX-подобных операционных системах GNU/Linux, BSD и Mac OS X принята форма UTF-8 для файлов и UTF-32 или UTF-8 для обработки символов в оперативной памяти.
Формат UTF-8 был изобретен 2 сентября 1992 года Кеном Томпсоном и Робом Пайком и реализован в Plan 9. Сейчас стандарт UTF-8 официально закреплен в документах RFC 3629 и ISO/IEC 10646 Annex D.
UTF-8 (Unicode Transformation Format — формат преобразования Юникода) — в настоящее время распространенная кодировка, реализующая представление Юникода, совместимое с 8-битным кодированием текста. Нашла широкое применение в операционных системах и вебпространстве.
Текст, состоящий только из символов Юникода с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от 2 до 6 байт (реально только до 4 байт, поскольку использование кодов больше 221 не планируется), в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx.
Проще говоря, в формате UTF-8 символы латинского алфавита, знаки препинания и управляющие символы ASCII записываются кодами US-ASCII, а все остальные символы кодируются при помощи нескольких октетов со старшим битом 1. Это приводит к двум эффектам.
Даже если программа не распознает Юникод, то латинские буквы, арабские цифры и знаки препинания будут отображаться правильно.
В случае если латинские буквы и простейшие знаки препинания (включая пробел) занимают существенный объем текста, UTF-8 дает выигрыш по объему по сравнению с UTF-16.
На первый взгляд может показаться, что UTF-16 удобнее, так как в ней большинство символов кодируется ровно двумя байтами. Однако это сводится на нет необходимостью поддержки суррогатных пар, о которых часто забывают при использовании UTF-16, реализуя лишь поддержку символов UCS-2.
Символы UTF-8 получаются из Unicode следующим образом (табл. 23).
Шрифты, общие для всех (актуальных) версий Windows, и их Mac-эквиваленты
Введение
В данном списке перечислены шрифты, общие для всех актуальных на данный момент операционных систем Windows (фактически начиная с Windows 98), и их эквиваленты в Mac OS. Такие шрифты иногда называют «безопасными шрифтами для браузеров» (browser safe fonts). Это небольшой справочник, которым я пользуюсь, когда делаю Web-страницы и думаю, что он будет полезен и Вам.
Если Вы новичок в web-дизайне, то может быть думаете что-нибудь типа: «Почему это я должен ограничиваться таким небольшим набором шрифтов? У меня есть огромная коллекция прекрасных шрифтов!» Дело в том, что браузер посетителя может отобразить только те шрифты, которые установлены в его операционной системе (прим. переводчика: в настоящее время уже есть возможность применять фактически любые шрифты при оформлении страниц используя CSS 3 и его новое свойство @font-face; правда, поддерживают эту функцию пока ещё далеко не все браузеры), а это означает, что каждый посетитель Вашей страницы должен быть обладателем выбранных Вами шрифтов. Поэтому Вы должны использовать только те шрифты, которые есть в каждой операционной системе. К счастью, в CSS есть свойство @font-family, облегчающее эту задачу.
Список
2 Символьные шрифты отображаются только в Internet Explorer, в остальных браузерах они обычно заменяются на стандартный шрифт (хотя, например, шрифт Symbol отображается в Opera, а Webdings — в Safari).
3 Шрифт Book Antiqua практически идентичен Palatino Linotype; Palatino Linotype поставляется с Windows 2000/XP, а Book Antiqua — с Windows 98.
4 Обратите внимание, что эти шрифты не TrueType, а bitmap, поэтому они могут плохо выглядеть с некоторыми размерами (они предназначены для отображения в размерах 8, 10, 12, 14, 18 и 24 pt при 96 DPI).
5 Эти шрифты работают в Safari только в стандартном начертании, но не работают при выделении жирным или курсивом. Comic Sans MS также работает жирным, но не курсивом. Другие Mac-браузеры, кажется, нормально эмулируют отсутствующие у шрифтов свойства самостоятельно (спасибо Christian Fecteau за подсказку).
6 Эти шрифты установливаются в Mac только при Classic-инсталляции
Истинные имена TrueType шрифтов и экспорт в PDF
В книге Урсулы Ле Гуин “Волшебник Земноморья” магия требовала знания “истинного имени” того, с чем маг работает. Думаю, любой программист согласится, что идея здравая. URLи, UUIDы и прочие уникальные идентификаторы объектов — это то, с чем мы имеем дело постоянно. И, так же как в волшебном мире, эти истинные имена бывает не так-то просто узнать. По крайней мере для имен шрифтов это так.
Мне нужно было реализовать в нашем программном продукте экспорт текстовых блоков в PDF. Для экспорта используются проприетарные библиотеки Adobe PDF Library (http://datalogics.com/products/pdfl/) и надстройка над ней DLI (Datalogics Library Interface). Не буду углубляться в эти библиотеки, думаю они мало кому интересны. Но полагаю, что проблема, с которой я столкнулся, общая для любой реализации PDF экспорта.
Каждый шрифт (возьмем, например, Arial) имеет 4 различных начертания — обычный, жирный, наклонный и жирный наклонный. Т.е. Arial, Arial Bold, Arial Italic и Arial Bold Italic. Каждое начертание хранится в отдельном TTF файле или в отдельной секции TTC файла. И если мы хотим вывести в PDF файл наклонный или жирный шрифт, мы должны в вызове соответствующей функции явно указать “Arial Italic” или “Arial Bold”. Но в текстовом блоке, который мы экспортируем, указано, что его шрифт “Arial” и отдельно заданы атрибуты Bold и Italic. И EnumFontsFamiliesEx возвращает нам только имя “Arial” и все! В Как же получить нужную нам строку “Arial Italic”?
Очевидное решение — просто приписать строчку “Italic” к имени шрифта — работает не всегда. Например, оно не работает со шрифтом “Lucida Sans Typewriter”. PDF библиотека выдает ошибку, если мы передаем “Lucida Sans Typewriter Italic”.
Ключ к решению (pun intended) — HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts. Достаточно посмотреть в содержимое этого ключа и становится ясно, что нужно было передать “Lucida Sans Typewriter Oblique”. Тогда все работает.
Формат записей в этом ключе нигде не документирован, но, вроде бы, очевиден:
«Arial (TrueType)»=«arial.ttf»
«Arial Italic (TrueType)»=«ariali.ttf»
«Arial Bold (TrueType)»=«arialbd.ttf»
«Arial Bold Italic (TrueType)»=«arialbi.ttf»
«Batang & BatangChe & Gungsuh & GungsuhChe (TrueType)»=«batang.ttc»
…
«Mangal (TrueType)»=«mangal.ttf»
«Mangal Bold (TrueType)»=«mangalb.ttf»
«Meiryo & Meiryo Italic & Meiryo UI & Meiryo UI Italic (TrueType)»=«meiryo.ttc»
«Meiryo Bold & Meiryo Bold Italic & Meiryo UI Bold & Meiryo UI Bold Italic (TrueType)»=«meiryob.ttc»
«MS Gothic & MS PGothic & MS UI Gothic (TrueType)»=«msgothic.ttc»
…
«Lucida Sans Typewriter Regular (TrueType)»=«LTYPE.TTF»
«Lucida Sans Typewriter Bold (TrueType)»=«LTYPEB.TTF»
«Lucida Sans Typewriter Bold Oblique (TrueType)»=«LTYPEBO.TTF»
«Lucida Sans Typewriter Oblique (TrueType)»=«LTYPEO.TTF»
Видно, что для TTC коллекций шрифты, содержащиеся в них, указаны через “ & “.
Алгоритм для установления соответствия между общим именем шрифта и именами начертаний получается такой: для каждого имени начертания отрезаем по одному слову с конца, пока остаток не совпадет с каким-нибудь именем, полученным из EnumFontsFamiliesEx. Кроме того отрезанные слова проверяем на совпадение со словами “Bold”, “Ilalic”, “Semibold”, “Oblique” и запоминаем соответcтвующий атрибут для этого начертания. Например для семейства“Lucida Sans Typewriter”:
Теперь если нужно вывести шрифт “Lucida Sans Typewriter” жирным и наклонным, то мы знаем, что этому начертанию соответствуюет имя “Lucida Sans Typewriter Bold Oblique” и передаем это имя в PDF библиотеку.
Тут, правда, поджидает еще одна неприятность. Например шрифт “Mangal” имеет только жирное начертание (“Mangal Bold”), а вот наклонного у него нет. Хотя мы можем поставить атрибут “наклонный” этому шрифту и Windows GDI в этом случае самостоятельно исказит имеющееся начертание при выводе на экран. При экспорте в PDF же придется проделать это самостоятельно. PDF библиотека может позволить задать матрицу преобразования при выводе текста. Например, в моем случае, это выглядело так:
ASFixedMatrix fontSkew;
if (bSimulateItalic)
<
double angle = 15;
fontSkew.a = fixedOne; // x scale
fontSkew.b = fixedZero; // rotate & skew
fontSkew.c = FloatToASFixed(tan(_PI * angle / 180)); // rotate & skew
fontSkew.d = fixedOne; // y scale
fontSkew.h = 0; // x translation
fontSkew.v = 0; // y translation
dlpdfcontentfontskew(. &fontSkew);
>
Для имитации жирного шрифта красивого решения я не нашел. Я просто печатаю строку, которую надо вывести жирным, несколько раз с небольшим сдвигом. Визуально все выглядит нормально, но расстраивает, что текст в PDF файле дублируется.
Кстати, если уж мы узнаем, что “ＭＳ Ｐゴシック” это “MS Gothic”, то это решает и вторую проблему, по крайней мере для случая, когда в реестре хранится английское имя. Мы просто передадим в PDF библиотеку имя “MS Gothic” и все заработает. Остается установить это соответствие.
Для большинства начертаний из HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts мы поставили в соответствие имена шрифтов из EnumFontsFamiliesEx. Но для некоторых начертаний пары не нашлось. Еще бы — в реестре у нас “MS Gothic”, а EnumFontsFamiliesEx вернул “ＭＳ Ｐゴシック”.
В этом случае остается только самостоятельно разобрать TTF/TTC файл и найти там соответствующее японское имя.
Разбор TTC/TTF файла — задача несложная. За работающий образец можно взять исходники проекта “ttf2eot” code.google.com/p/ttf2eot. Сам формат TTF/TTC хорошо документирован на сайте Microsoft: www.microsoft.com/typography/otspec. Обратить внимание надо на то, что все данные в TTF хранятся в big endian формате, так что все числа и Unicode-строки надо конвертировать перед использованием.
Свой код я, к сожалению, выложить не имею права, поэтому лишь напишу здесь, что искать.
Одно из найденных имен совпадет с каким-то именем из EnumFontFamiliesEx.
Например для начертания “Meiryo Bold Italic” разобрав meiryob.ttc мы узнаем, что этому начертанию соответствует имя “メイリオ” из EnumFontFamiliesEx.
Остается узнать, является ли это начертание жирным и наклонным. Напрашивается идея тоже взять эту информацию из шрифта, но, как выяснилось экспериментально, эти атрибуты в файле шрифта могут быть неверными. Поэтому возьмем их из имени начертания (“Meiryo Bold Italic”), как уже делали выше. Только отрезать слова будем до тех пор, пока остаток не совпадет с любым именем, извлеченным из TTF файла, а не из выдачи EnumFontFamiliesEx.
Таким образом, если надо экспортировать текстовый блок, набранный наклонным и жирным шрифтом с именем “メイリオ”, мы передаем в PDF библиотеку имя “Meiryo Bold Italic”. Профит!