Проблема некорректного отображения кириллицы при сохранении табличных документов в формат PDF — одна из самых коварных в экосистеме 1С:Предприятие. Особенно часто она проявляется в связке старых версий платформы (8.2) и современных операционных систем, таких как Windows Server 2012 или Windows 10. Пользователи сталкиваются с ситуацией, когда на сервере документ выглядит идеально, но после отправки клиенту превращается в набор нечитаемых символов.
В данной статье мы подробно разберем, почему возникает эта ошибка, проанализируем техническую подоплеку и рассмотрим несколько эффективных способов решения проблемы — от кардинального обновления системы до временных «костылей».
Прежде чем переходить к лечению, давайте разберем «физику» процесса. Основная причина кроется в механизме формирования PDF-контейнера встроенным движком 1С. При сохранении файла платформа создает так называемые Identity-H или CID-шрифты. Проблема заключается в том, что в структуре такого PDF-файла часто отсутствует или некорректно формируется таблица соответствия кодов символов их графическому начертанию — ToUnicode map.
Разберем ситуацию по шагам. Когда программа-просмотрщик (например, Adobe Acrobat Reader) открывает такой файл, она пытается использовать свои внутренние алгоритмы «угадывания» кодировки. Если ей это удается, мы видим нормальный текст. Однако более строгие программы, такие как Foxit Reader, мобильные просмотрщики на iOS/Android или браузеры (Chrome, Safari), четко следуют спецификации PDF. Если таблицы ToUnicode нет, они отображают символы по умолчанию — те самые «кракозябры» или иероглифы.
Ситуация усугубляется на Windows Server 2012, где была существенно изменена работа подсистемы GDI. Платформа 1С версии 8.2 при обращении к системным шрифтам (особенно к Arial версии 6.0 и выше) получает данные, которые не может корректно упаковать в PDF-контейнер. Примечательно, что жирное начертание Arial Bold часто отображается корректно, в то время как обычный Arial «рассыпается».
Как показывает практика и опыт многих администраторов, наиболее надежным способом решения проблемы является переход на современную версию платформы. Проанализируем результаты тестов: в версии 8.3.5.1248 и выше разработчики 1С переработали механизм экспорта в PDF, адаптировав его под новые стандарты Windows.
Рассмотрим алгоритм действий:
Если по каким-то причинам обновление платформы невозможно (например, из-за жестких требований отраслевого решения или кастомных доработок), рассмотрим более гибкий вариант — изменение шрифтов в печатных формах. Исследования показывают, что шрифт Times New Roman гораздо реже подвержен «эффекту кракозябр», чем стандартный Arial.
Для реализации этого метода проделаем следующие шаги:
Ctrl+A).Arial на Times New Roman.Важный нюанс: Этот метод помогает в 80% случаев, но не является панацеей, так как корень проблемы все равно остается в движке генерации PDF.
Рассмотрим ситуацию, когда стандартная функция 1С «Сохранить как PDF» работает некорректно. Мы можем обойти этот механизм, используя внешнее программное обеспечение. Суть метода заключается в том, что вместо сохранения мы отправляем документ на печать, но вместо физического принтера выбираем виртуальный.
Проанализируем преимущества этого подхода:
Иногда проблема кроется в том, как сама операционная система сопоставляет кодировки для шрифтов. Мы можем принудительно указать Windows использовать кириллическую кодировку для шрифта Arial. Разберем, как это сделать через реестр:
regedit).HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes.Arial,0 и значением Arial,204.Arial,1251 настроены правильно, а параметры типа Arial,1252 (западноевропейская кодировка) не перекрывают кириллицу.Проанализируем еще одну возможную причину — повреждение системного кэша шрифтов. 1С кэширует параметры отображения, и если в кэш попала ошибка, она будет тиражироваться во все новые PDF-файлы. Выполним очистку:
StaticCache.dat в профилях пользователей 1С на сервере..dat из папки C:\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache.Если вы хотите решить проблему программно внутри кода 1С, рассмотрим вариант принудительной установки шрифта для области табличного документа перед выводом на печать. Посмотрим на пример кода:
// Пример программной замены шрифта в табличном документе
ТабДок = Новый ТабличныйДокумент;
// ... (здесь идет формирование документа) ...
// Пройдемся по всем областям и заменим шрифт, если платформа 8.2
Для НомерСтроки = 1 По ТабДок.ВысотаТаблицы Цикл
Для НомерКолонки = 1 По ТабДок.ШиринаТаблицы Цикл
Область = ТабДок.Область(НомерСтроки, НомерКолонки);
Если Область.Шрифт.Имя = "Arial" Тогда
Область.Шрифт = Новый Шрифт("Times New Roman", Область.Шрифт.Размер);
КонецЕсли;
КонецЦикла;
КонецЦикла;
ТабДок.Записать(ПутьКФайлу, ТипФайлаТабличногоДокумента.PDF);
Этот метод позволяет автоматизировать «Решение №2» для всех документов системы без ручной правки сотен макетов в конфигураторе.
Мы проанализировали проблему возникновения «кракозябр» при экспорте в PDF и выяснили, что основной виновник — устаревший механизм формирования CID-шрифтов в платформе 8.2. Наиболее эффективным решением остается обновление платформы до версии 8.3. Если же это невозможно, комбинация смены шрифтов в макетах и использования виртуальных PDF-принтеров позволит вам обеспечить клиентов читаемыми документами вне зависимости от их операционной системы и программного обеспечения.