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

Случайно, изучая заголовки, которые отправляет «Виола», я обнаружил, что этот браузер каким-то образом работать с «ПостСкриптом» — это язык описания страниц, который используется, например, принтерами. Для этого, как оказалось, нужно использовать отдельный тег FIGURE.

Непонятно для этого понадобился отдельный тег, ну вот так сделано. Для наглядности вот пример его использования:

<FIGURE TYPE="application/postscript" SRC="test_figure_ps.ps"
WIDTH="100" HEIGHT="100" MAYDELAY="2000" ISMAP></FIGURE>

У него больше атрибутов, чем я использовал в примере, в минимуме ему нужен только TYPE и SRC, а остальные атрибуты у меня тут используются как ненужные подробности в моём рассказе, но так уж мне захотелось.

Когда я сделал тестовую страничку с этим тегом, оказалось, что ISMAP и MAYDELAY с «ПостСкриптом» не работали, как и, собственно, само отображение «ПостСкрипта».

С отображением я справился быстро. Секрет в том, что «Виола» на самом деле этот язык сама по себе не понимала, до моего вмешательства она использовала довольно неряшливый код, который использовал кучу временных файлов и две утилиты, — gs и ppmtogif, при помощи которых она получала GIF, который на самом деле и отображался.

Я весь этот код просто выкинул и заменил на вызов утилиты magick, которая умеет конвертировать «ПостСкрипт» в GIF напрямую безо всяких посредников. Пришлось только учесть, что по-умолчанию она создаёт GIF с прозрачностью, тогда как предыдущий набор использовал белый фон.

Довольно быстро я починил и реализацию атрибута ISMAP — просто скопировал его из обработчика формата XBM, где он работал, а починку MAYDELAY отдал нейросети.

Вроде ничего сложного, опять же — этот атрибут работал у XBM, я предполагал, что сеть быстро разберётся в чём там дело, передрав рабочий код и наложив его на особенность — XBM отображается напрямую внутренней библиотекой браузера, а «ПостСкрипт» конвертируется.

Примерно спустя час я сдался. Ни ChatGPT 5.1 Codex, ни Gemini 3 Pro, ни моя любимая Sonnet 4.5 с задачей не справились — каждая из них писала мне огромную простыню кода, которая задачу не решала.

Кусок кода, который надо было поправить, выглядел следующим образом. Если атрибут MAYDELAY не указывался, то вызывалась конвертация «ПостСкрипта» в GIF и он показывался, в противном случае запускался таймер, который вызывал loadData — другой… э… метод, назовём это так, программы на внутреннем языке «Виолы», в котором конвертации не было.

Модели это видели и просто копировали конвертацию в этот метод, но к моменту срабатывания таймера файл, с которым нужно было работать, уже пропадал. Думаю, его удалял сборщик временных файлов, встроенный в «Виолу». В итоге ничего толком не работало: модели ходили по кругу и, пытаясь исправить ситуацию, писали всё больше кода.

Исправление, которое сделал я, работает очень просто: я сначала делаю конвертацию, потом смотрю, есть ли параметр MAYDELAY, если нет, отдаю сконвертированную в GIF картинку в отрисовку, если есть, откладываю отрисовку, передавая в метод loadData уже сконвертированную картинку.

По сути, я передвинул несколько строк кода чуть ниже, это всё моё исправление. Я как-то очень разочарован, что умнейшие из нейросетей до этого не додумались. Можно посмотреть в моём коммите, но там сразу несколько вещей исправляются.

Пример изображения PostScript взят из чужого репозитория

Пока искал в интернете информацию по тегу FIGURE, набрёл на какую-то недоделанную, но очень интересную презентацию «A Quick Review of HTML 3.0». Судя по версии HTML, это должно быть в районе 1995 года.

Под подзаголовком «Figures with local event processing» скрывается видение того как в будущем будет выглядеть веб в виртуальной реальности. Причём автор считал, что это будет ближайшее будущее:

К концу этого десятилетия дальнейший рост соотношения цена/производительность позволит доступным настольным системам запускать высокореалистичные модели виртуальной реальности. […] сейчас самое подходящее время для разработки механизмов, позволяющих людям делиться VR-моделями в глобальном масштабе.

Я и не знал, что первый коммерческий наголовный дисплей был выпущен в 1994-м году, думал в 90-е такое только в фантастических фильмах встречалось:

Джойстики и устройства типа «SpaceBall» улучшают управление, но не могут конкурировать с полной «погружённостью», которую обеспечивают наголовные дисплеи. Системы премиум-класса используют магнитное отслеживание положения головы и конечностей пользователя, а также устройства вроде трёхмерных мышей и киберперчаток, ещё больше усиливающие иллюзию.

Автор соврешенно справедливо полагал, что звук тоже важен, не только изображение:

Звук может быть не менее важен для иллюзии, чем визуальная симуляция: звук тикающих часов усиливается по мере того, как вы к ним приближаетесь. Самолёт с рёвом пролетает над головой, перемещаясь от одного горизонта к другому.

Можно подумать что тут написано про какие-то приспособления, которые позволяют почувствовать виртуальную гравитацию:

Виртуальная среда может накладывать те же ограничения, что и реальный мир, например силу тяжести или ограничение движения ходьбой, подъёмом/спуском по лестнице, поднятием и опусканием предметов. Либо, наоборот, пользователи могут «обзавестись суперсилами» и с лёгкостью летать по воздуху или даже проходить сквозь стены!

…но на деле речь просто реализацию физики на экране:

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

А тут технически интересная, но сейчас уже неактуальная идея, которая в теории могла бы помочь сэкономить вычислительные ресурсы — идея строить виртуальную среду из готовых предметов, используя для этого специальный язык разметки:

Возможно, мы сможем опереться на опыт конвертации документов и SGML и задавать VR-среды на логическом уровне, предоставив браузерам заполнять детали в соответствии с возможностями каждой платформы.

Базовая идея заключается в том, чтобы составлять VR-среды из ограниченного набора логических элементов, например стул, дверь, пол. Размеры некоторых элементов можно брать по умолчанию. Для других, например размеров комнаты, требуются списки точек — скажем, для описания многоугольника, задающего план пола. Дополнительные параметры задают цвет и текстуру поверхностей. Рамка картины, висящей на стене, может быть описана с помощью растрового изображения.

Я немного сократил статью, она чуть больше, но, к сожалению, не дописана, кончается в неожиданном месте:

Хранение таких подробностей в отдельных файлах даёт несколько преимуществ: