Сбой рендеринга шрифта, когда код работает под IIS 7.0

Question

У меня есть устаревший веб-сайт ASP с COM-объектом, работающим под IIS 7.0 на Windows Server 2008. Обычно это прекрасно работает, но в последнее время я столкнулся с довольно странной проблемой, для которой не могу найти решения.

Есть одна страница, которая вызывает пользовательский COM-объект (код VB6, да, я знаю), который вызывает сторонний графический объект COM-рендеринга графики. После тестирования мы обнаружили, что этот код отлично работает под Windows 2003 и IIS 6.0, но не под Windows Server 2008 и IIS 7.0. Проблема в том, что сторонний движок рендеринга не использует правильный (установленный пользователем) шрифт истинного типа и, похоже, использует шрифт по умолчанию.

Когда код со страницы ASP запускается как файл VBScript под учетной записью администратора, рендеринг использует правильный шрифт. Так что вы можете подумать, что это проблема с разрешением. Однако, когда я запускаю VBScript под той же учетной записью, под которой работает веб-сайт и пул приложений IIS, также используется правильный шрифт. Таким образом, только когда код работает под IIS 7.0, он не отображается с правильным шрифтом. Если он запускается из окна CMD под той же учетной записью, что и IIS, он отображается корректно.

Учетная запись, используемая IIS, является пользовательской учетной записью (не NETWORK SERVICE) с очень небольшими привилегиями, однако достаточной для ее функционирования. Веб-сайт работает уже много лет и использует сторонние COM-объекты. Это первый раз, когда возникает такая проблема.

Я думал, что разрешения на шрифт могут быть проблемой, хотя это не объясняет, почему он будет работать за пределами IIS. Чтобы убедиться, что это не является частью проблемы, я дал группе «Все» права на чтение для определенного шрифта. Это не решило проблему.

Принимая во внимание все вышесказанное, я думаю, что мой вопрос сводится к тому, что IIS делает по-другому, что может привести к тому, что код не сможет использовать правильный шрифт. Я знаю, что IIS 7.x автоматически помещает учетную запись пула приложений в группу IIS_IUSRS, прежде чем запускает пул приложений. Но я уже вручную добавил учетную запись в эту группу, поэтому, когда я запускаю VBScript из поля CMD под этой учетной записью, эта учетная запись также является частью группы IIS_IUSRS. Так что должно быть то же самое.

У меня заканчиваются идеи, как это решить. Любые идеи, советы или предложения приветствуются.

Answer 1

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

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

Answer 2

Мне удалось решить эту проблему пару недель назад, и я отвечу на свой вопрос для дальнейшего использования, только что получил электронное письмо от такого же пользователя Superuser, у которого были похожие проблемы.

Проблема, кажется, очень специфична только для Windows Server 2008, возможно, из-за ошибки в этой версии Windows. Этот шрифт был неизвестным нестандартным шрифтом, купленным у небольшой фирмы по созданию шрифтов. Мы уже запросили новую версию шрифта и уже пытались загрузить его в нескольких редакторах шрифтов и повторно сохранить, но безрезультатно.

В конце концов, небольшому бесплатному редактору шрифтов Type Light от CR8 Software Solutions удалось решить эту проблему. Загрузка шрифта в этом редакторе и его повторное сохранение исправили проблему в Windows Server 2008. С тех пор мы можем использовать шрифт как любой другой шрифт.