Написание программ на C с выводом графики на postscript

Вопрос навеян этой темой Нужна литература по работе с графикой.

Пробовал ли кто-нибудь из вас писать на языке postscript? Если да, то каковы впечатления от этого языка? Пригоден ли он для графического ввода-вывода и создания графических интерфейсов? Можно ли, допустим, программу писать на C, а графику создавать в ней, посылая команды на postscript'е в поток stdout? Понятно, что стандартный поток вывода должен быть в этом случае связан с каким-то postscript-терминалом или графической (иксовой, виндовой) программой, исполняющей код на postscript'е и рисующей текст и графику в окошке.

Добавлено через 23 часа 23 минуты
И всё же, у кого какие мысли есть?

0

а почему такие "экзотичные" варианты рисования?

0

Если интересуют Cшные либы для такого рисования - стоит посмотреть в сторону TeX/LaTeX - эти пакеты умеют делать выхлоп в DVI, PDF и PS. Есть в них tex2ps, предполагаю, что это только оболочка к к-нить либе.

Наверняка есть и другие библиотеки, не связанные с TeX.

Добавлено через 10 минут
О, нашёл прикольную весЧь GL2PS : http://www.geuz.org/gl2ps/ - библиотека, позволяющая рендерить картинку, реализованную на OpenGL в PS,EPS,PDF и SVG

1

Сообщение от MansMI а почему такие "экзотичные" варианты рисования?

1. Я подумал, такой способ рисования может оказаться ничуть не сложнее, чем тот же GTK+, и нисколько не уступать GTK+ и QT по качеству, если уметь им пользоваться (т. е. знать хорошо postscript).

2. Меня в последнее время заинтересовали способы, как уйти от оконной графики и того способа программирования, который она навязывает, а именно, непременно существующий цикл обработки сообщений, обязательная обработка таких специфических событий, как изменение размера окна и т. п. Как уйти от громоздких рисовальных функций оконного API с кучей параметров, вплоть до указания графического контекста (в Windows он, кажется, называется пером), будь то Xlib, Win32 API, GTK+, QT и т. п.

Возникает мысль, а нельзя ли вернуться к традиционному потоковому вводу/выводу на терминал в том виде, в каком он существует в Unix-подобных операционных системах. Только там он позволяет выполнять лишь символьный вывод. Я же подумал, а нельзя ли эту идею потокового вывода расширить и распространить на случай графики, хотя бы двумерной. Язык postscript, может, и не лучший, но всё же возможный вариант реализовать эту идею.

0

Сообщение от JohnyWalker Возникает мысль, а нельзя ли вернуться к традиционному потоковому вводу/выводу на терминал в том виде, в каком он существует в Unix-подобных операционных системах. Только там он позволяет выполнять лишь символьный вывод. Я же подумал, а нельзя ли эту идею потокового вывода расширить и распространить на случай графики,

А framebuffer или svgalib...

Оконный интерфейс требует цикл обработки не для рисования, а для общения с юзером (отслеживать мышу/клаву). Возможно от цикла в привычном виде можно уйти при однооконной работе. Активное окошко и обрабатывает клаву/мышу, если ловит "клик за пределами"/комбинацию)клавиш - самостоятельно перекидывает управление на стек других окошек/виджетов.
Нечто вроде "консолидированной многозадачности Вынь 3.*" - правда там цикл тоже существовал......

Когда-то рисовал "окошки" под ДОС-ом, пришлось делать базовый класс с обработчиком событий и цикл в майн. Как ни старался уйти от пути TurboVision - не смог, сдался и основа была похожа на TV, но зато остальное сделал проще и понятнее(а сколько багов было - с год вылавливал. Прога уже в цеху стоит и работает без сбоев, а баги в либе в другом проекте лезут и лезут...

1

Сообщение от drfaust Оконный интерфейс требует цикл обработки не для рисования, а для общения с юзером (отслеживать мышу/клаву). Возможно от цикла в привычном виде можно уйти при однооконной работе. Активное окошко и обрабатывает клаву/мышу, если ловит "клик за пределами"/комбинацию)клавиш - самостоятельно перекидывает управление на стек других окошек/виджетов. Нечто вроде "консолидированной многозадачности Вынь 3.*" - правда там цикл тоже существовал...... Когда-то рисовал "окошки" под ДОС-ом, пришлось делать базовый класс с обработчиком событий и цикл в майн. Как ни старался уйти от пути TurboVision - не смог, сдался и основа была похожа на TV, но зато остальное сделал проще и понятнее(а сколько багов было - с год вылавливал. Прога уже в цеху стоит и работает без сбоев, а баги в либе в другом проекте лезут и лезут...

Это всё верно, я и не спорю. Цикл обработки сообщений нужен для того, чтобы непрерывно принимать ввод от пользователя в реальном времени, и тут от него никуда не уйдёшь. Можно разве что разделить программу на два потока — один тот самый цикл обработки сообщений, а во втором логическая вычислительная часть программы безо всякого ввода/вывода и графики. А общаться друг с другом те два потока — вычислительный и графический — могут, например, через глобальные переменные, защищённые мьютексами. И цикл обработки сообщений видимо есть в любой интерактивной программе, даже с чисто текстовым командным интерфейсом вроде shell'а Unix, того же bash в Linux. Если б существовала возможность организовать асинхроннный вызов подпрограммы обработки ввода пользователя по принципу прерывания (к примеру, по тому же принципу, по которому в Unix/Linux вызывается обработчик сигнала, только здесь обработчик ввода запускался бы не при поступлении сигнала, а при поступлении ввода от пользователя - нажатие клавиш на клавиатуре, щелчки мыши и т. п.), то от цикла обработки сообщений и можно было бы уйти. Но так как такого механизма организации взаимодействия с пользователем я ни в одной операционной системе не встречал, то единственным решением остаётся цикл обработки сообщений.

Но мне сейчас интересно другое. Можно ли идею потокового терминального ввода-вывода, который существовал в Unix, но только для текстовой алфавитно-цифровой информации, распространить на графический случай, на графический вывод. Т. е. уйти от вызова кучи рисовальных функций, которые существуют в любой GUI-библиотеке (которые рисуют отрезки, окружности, дуги, прямоугольники, точки, кривые Безье, позволяют вывести растровую картинку в нужное место окна и т. п.), а вместо этого в файл устройства (в тот же stdout) засылать поток символов, который будет правильно пониматься и интерпретироваться устройством (или драйвером) и заставлять устройство выводить графику на экран. Причём использовать для этой цели можно было бы самые обычные функции стандартной библиотеки языка C для вывода текста в файл вроде puts(), printf() и т. п. Главное, чтобы выводимый этими puts(), printf() и прочими функциями поток символов на устройство представлял собой сам по себе какой-то текст на языке, понятном устройству, а не символьную абракадабру. Мысль моя понятна?

Т. е. я думаю сейчас о том, как идеологию графического ввода-вывода на компьютере, в рамках ОС, можно было бы упростить, причём сделать это красиво. И я думаю, какой бы язык подошёл в качестве языка графического устройства, в качестве языка, понимаемого и интерпретируемого этим устройством. И я задумался, является ли postscript хорошим кандидатом на эту роль, или же это постфиксный язык, он сложен и неудобен для обычного программиста, и если уж эту идею как-то и реализовывать, то на роль такого языка надо выбирать что-то другое, что-то более простое и понятное для человека, чем postscript, но при этом примерно с такой же функциональностью. Я и хотел спросить у форумчан мнение об этом языке. Приходилось ли кому-то с ним работать и вручную на нём писать графические файлы и программки? И если да, то какое мнение у вас об этом языке, какое он оставил о себе впечатление?

0

Сообщение от JohnyWalker Пробовал ли кто-нибудь из вас писать на языке postscript?

Да, исключительно в научно-познавательных целях.

Сообщение от JohnyWalker Пригоден ли он для графического ввода-вывода и создания графических интерфейсов?

Смотря что понимать под графическим интерфейсом?
Вы может не до конца предназначение этого языка понимаете? Это по сути набор инструкций для принтера. Для печати каких-нибудь доков пойдёт. А для графики приложений лучше использовать что-то другое (апишное рисование окон, OpenGL, ...) Хотя всё зависит от задачи. Вы вот не до конца свою описали.

1

Сообщение от MrGluck Вы может не до конца предназначение этого языка понимаете? Это по сути набор инструкций для принтера.

MrGluck, я этого языка совсем не знаю, так что моё мнение тут никак экспертным не назовёшь, но мне всё-таки не показалось, что этот язык представляет собой набор инструкций для принтера. Мне показалось, что его предназначение гораздо шире. На мой взгляд, это язык для описания страниц, содержащих типографский текст вперемежку с графикой произвольной степени сложности. Т. е. это язык издательских систем, позволяющий описывать на плоской поверхности изображение, содержащее тексты, выполненные любыми типографскими шрифтами, линии (как прямые, так и искривлённые, для последних в нём предусмотрены кривые Безье), рисунки и картинки. В доказательство того, что это именно язык издательских систем я бы привёл тот факт, что формат pdf целиком основан на postscript'е, является его наследником и дальнейшим развитием. При этом на самом postscript'е, как я понимаю, можно создавать документы, ничуть не уступающие документам в pdf по степени сложности, красоте и качеству (по своим возможностям pdf и postscript примерно равны). Т. е. это не язык управления принтером, это язык создания изображений на любой плоской поверхности, будь то бумага или экран монитора, а ps-принтер (я знаю, что в принтерах этот язык в своё время получил наибольшее распространение) лишь частный случай устройства, создающего такие изображения.

При этом, насколько я понял, язык postscript ни в коем случае не является языком разметки вроде языка системы groff, html, TeX и т. п. Он для этой цели слишком низкоуровневый, он по сравнению с языками разметки слишком детализирует процесс вывода текста и графики. Использовать его в качестве замены языка разметки в общем-то можно было бы, но это слишком неудобно. С другой стороны, возможности postscript'а по части описания вида страницы или образа экрана неизмеримо выше, чем возможности любого языка разметки. На нём можно создать самые невероятные графические и текстовые образы, для чего у языка разметки, скорее всего, просто не хватит средств.

Смотря что понимать под графическим интерфейсом? Для печати каких-нибудь доков пойдёт. А для графики приложений лучше использовать что-то другое (апишное рисование окон, OpenGL, ...) Хотя всё зависит от задачи. Вы вот не до конца свою описали.

У меня чётко сформулированной задачи нет. Идея моя такая. Нельзя ли в некоторых случаях (это всё, конечно, вопрос стиля, вкуса и личных предпочтений программиста) уйти от оконной графики, которая содержит набор некоторых вполне определённых абстракций, таких как окно, событие, щелчок мыши, цикл обработки сообщений, графический контекст (при этом все основные понятия и подходы примерно одинаковы и в Windows, и в Unix/Linux с их системой X Window), и вернуться к терминальному вводу-выводу, каким он был и остаётся в Unix-подобных системах, но при этом сделать этот терминальный, потоковый, консольный ввод-вывод графическим? Тот консольный ввод-вывод, который существует в Unix-подобных системах, позволяет работать исключительно с текстовой информацией (он напоминает работу печатной машинки). Хотелось бы сохранить идею этой потоковой консоли, потокового терминала, но сделать этот терминал графическим, чтобы он отображал не только текст, но и картинки, но при этом и текст он позволял выводить самыми разными шрифтами. То есть задумка у меня общего плана. Хотелось бы обсудить, какими путями подобную идею можно воплотить.

Добавлено через 18 минут
Выводом сырого текста, как это сделано в текстовом терминале Unix, тут уже не обойдёшься. Поэтому для того, чтобы соорудить подобную штуку, необходим специальный язык, который такая графическая консоль или такой графический терминал бы понимал, правильно интерпретировал и выводил согласно его инструкциям и указаниям на экран картинку. Я и хотел спросить, разбирался ли кто из вас с postscript'ом? Можно ли по вашему мнению этот язык считать хорошим кандидатом на роль языка такого графического терминала? Или с ним работать, на ваш взгляд, напрямую сложно и неудобно, и это был бы плохой выбор?

Добавлено через 7 минут
MrGluck, я эту идею изложил ещё в своих предыдущих постах в этой ветке (см. пост №1, №4 и №6). Посмотри все эти посты, чтобы лучше понять, что я имел в виду.

0

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

Сообщение от JohnyWalker Выводом сырого текста, как это сделано в текстовом терминале Unix, тут уже не обойдёшься. Поэтому для того, чтобы соорудить подобную штуку, необходим специальный язык, который такая графическая консоль или такой графический терминал бы понимал, правильно интерпретировал и выводил согласно его инструкциям и указаниям на экран картинку. Я и хотел спросить, разбирался ли кто из вас с postscript'ом? Можно ли по вашему мнению этот язык считать хорошим кандидатом на роль языка такого графического терминала? Или с ним работать, на ваш взгляд, напрямую сложно и неудобно, и это был бы плохой выбор?

Не знаю, насколько вам будет удобно. Но вы вроде бы понимаете, что напрямую PS никто не использует. Его тексты генерируют с помощью других ЯП. С помощью чего вы планируете генерить вывод PS?
Касаемо вашей идеи - а сколько человек захочет нынче использовать графику в консоли в замен иксам? Возможно это влияние майкрософт, а возможно требования используемого софта, но люди привыкли к графике, которую предоставляют DE вроде KDE или Gnome, которые, в свою очередь, вертятся на иксах.
На самом деле, я лишь немного баловался с графикой в консоли. Но разве libsdl не делает то, что ваш нужно? Возможно, логичнее будет написать обёртку вокруг него?

1

Сообщение от MrGluck графику в консоли в замен иксам?

Кто-то запрещает запустить иксы в консольном фреймбуфере?
Вот только с ускорением там будет зело тоскливо.

0

Сообщение от MrGluck Более того, мне кажется, что ваши познания данного языка могут быть даже выше моих т.к. я в него не углублялся.

Нут, они не выше.

Сообщение от MrGluck Не знаю, насколько вам будет удобно. Но вы вроде бы понимаете, что напрямую PS никто не использует. Его тексты генерируют с помощью других ЯП. С помощью чего вы планируете генерить вывод PS?

Вывод на PS при таком подходе я бы порождал из программы напрямую. Т. е. просто посылал бы из программы в поток вывода текст на этом языке.

В этом и заключается суть моей идеи. Вместо использования специальных графических библиотек и рисования объектов на экране путём вызова функций этих библиотек посылать в консоль или терминал поток символов на специальном языке, позволяющем описывать графику. Язык должен быть прост, лаконичен, выразителен, понятен человеку (а не только терминалу) и удобен. Если PS удовлетворяет всем этим требованиям, его можно использовать для осуществления этого подхода. Если же нет, и у этого языка слишком сложный, неудобный и специфический синтаксис, то для этой цели стоит найти другой, более удобный, простой и понятный человеку язык, не уступающий PS по качеству и своим возможностям (или придумать такой язык). Главное, чтобы графика была реализована в виде потокового файлового вывода.

Сообщение от MrGluck Касаемо вашей идеи - а сколько человек захочет нынче использовать графику в консоли в замен иксам? Возможно это влияние майкрософт, а возможно требования используемого софта, но люди привыкли к графике, которую предоставляют DE вроде KDE или Gnome, которые, в свою очередь, вертятся на иксах.

Мне кажется, если бы кому-то удалось действительно качественно и удобно реализовать эту идею и её внедрили бы в консоль (виртуальный терминал) какой-нибудь популярной операционной системы, желающих её использовать нашлось бы немало.

Во-первых, есть куча инженеров и учёных, которые, не являясь профессиональными программистами, знают один или несколько популярных языков программирования (С, C++, Паскаль и т. д.), с удовольствием бы использовали компьютер в своей работе и писали бы на нём программки для решения своих задач. Но изучать современные графические интерфейсы вроде GTK+, QT, wxWidgets, Xlib или Win32 API не все из них хотели бы — все эти библиотеки достаточно сложны, и изучение любой из них потребовало бы уйму времени, которого у них, как правило, нет, да и голова занята совсем другими вещами — знаниями и навыками, касающимися их непосредственной профессии.

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

Если бы удалось реализовать графику в консоли таким путём, о котором я говорю, это бы, возможно, очень упростило работу как непрофессиональным, так и профессиональным программистам. Создание графических программ было бы ненамного сложнее написания программ консольных.

А что касается пользователей, думаю, нашлось бы немало и среди них людей, кому идея бы понравилась и они бы с удовольствием работали с такими программами и в такой среде. Ведь в Unix-подобных ОС (Linux, FreeBSD) текстовая консоль и консольные программы до сих пор очень популярны среди пользователей. А то что я предлагаю, это развитие идеи текстовой консоли и её обобщение на графический случай. А потом, идеи всех пересаживать с оконной графики и "рабочих столов" на консольную графику у меня нет. Хорошо было бы, если бы развивались оба подхода. Какой из них лучше (или оба плохи), может показать лишь время.

Сам подход имеет некоторые преимущества и на системном уровне.

Поскольку PS — язык многих принтеров (прежде всего, конечно, достаточно дорогих моделей в наше время), он бы позволил унифицировать экранный вывод и печать на принтере.

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

Т. к. графика имела бы потоковый вид (т. е. она реализовывалась бы путём записи текста в поток), вывод программы можно было бы перенаправить в файл и сохранить в нём. По сути дела, мы бы получили весь вывод программы в виде документа на postscript'е. Т. е. мы бы сделали то же самое, что делают программисты и пользователи Unix/Linux, когда перенаправляют вывод консольных программ в файл, а потом смотрят его в виде текста в каком-нибудь текстовом редакторе (или при помощи программы cat или more/less). В некоторых случаях такая возможность очень удобна, просто бесценна.

И дело тут даже не в языке postscript как таковом. Язык для этого можно выбрать любой, главное, чтобы он обладал всеми необходимыми свойствами. Важнее сама идея.

И да, ещё одна вещь, о которой нельзя умолчать. Такой подход более абстрактный и математичный, что для вычислительных систем является преимуществом. Графические библиотеки и окна — это более гуманитарный, что ли, подход.

Итого, мы имеем следующие преимущества данного пути: простота + унификация + гибкость.

0

Сообщение от JohnyWalker Вывод на PS при таком подходе я бы порождал из программы напрямую. Т. е. просто посылал бы из программы в поток вывода текст на этом языке.

Слайд-шоу на i9-7960X обеспечено. Рендерить PS то же самое, что и рендерить PDF. Да, качество картинки будет зависеть исключительно от выводящего девайса, и не важно что это, принтер, плоттер, или чертёжник возле кульмана.

PS можно использовать, если нам надо отрисовать одну сцену(чертёж, картинку и т.п), но для интерактивного общения всё будет упираться в связку PS->DVI(отдельная прога) + DVI->device(прога+видеодрайвер). Для примера, возьмите тот же принтак HP с каким нить АРМ-процем в 1ГГц частотой. Замерьте, сколько времени проходит от момента выполнения cat simple_test_page.ps > /dev/ulpt0 и моментом, когда лазерный принтак начнёт раскручивать полигон лазера или крутить картридж. А ведь в прошиве АРМа принтера весьма оптимизированный закрытый софт, а не универсальная прога, задача которой работать под всеми ОС, под всеми CPU, с поддержкой формата, собранного по крупицам, и наверняка неполной информации....

То же самое можно сказать про DVI и PCL, про PDF тихо промолчу...

0

Сообщение от drfaust Слайд-шоу на i9-7960X обеспечено. Рендерить PS то же самое, что и рендерить PDF. Да, качество картинки будет зависеть исключительно от выводящего девайса, и не важно что это, принтер, плоттер, или чертёжник возле кульмана. PS можно использовать, если нам надо отрисовать одну сцену(чертёж, картинку и т.п), но для интерактивного общения всё будет упираться в связку PS->DVI(отдельная прога) + DVI->device(прога+видеодрайвер). Для примера, возьмите тот же принтак HP с каким нить АРМ-процем в 1ГГц частотой. Замерьте, сколько времени проходит от момента выполнения cat simple_test_page.ps > /dev/ulpt0 и моментом, когда лазерный принтак начнёт раскручивать полигон лазера или крутить картридж. А ведь в прошиве АРМа принтера весьма оптимизированный закрытый софт, а не универсальная прога, задача которой работать под всеми ОС, под всеми CPU, с поддержкой формата, собранного по крупицам, и наверняка неполной информации.... То же самое можно сказать про DVI и PCL, про PDF тихо промолчу...

Не соглашусь. Мерить время между посылкой потока в лазерный ps-принтер и тем моментом, когда он начинает крутить свои валики, не вижу смысла. Принтер большой и сложный аппарат, мало ли что в нём происходит за это время. Чтобы такое сравнение было объективным, надо чётко знать, что он за этот промежуток времени делает, сколько времени уходит на приём потока через входной порт и запись его в память, и на саму растеризацию (рендеринг). А потом, не забывайте, у принтера и у любого ЖК-дисплея совершенно разное разрешение. Размер матрицы пикселей у принтера раз в 5 будет больше, чем у экрана, т. е. по-любому принтер требует более объёмных вычислений.

Но главное не в этом. Я не понимаю, почему рендеринг изображения, записанного на постскрипте, должен занимать существенно больше времени, чем рендеринг такого же изображения, полученного путём последовательного вызова функций какого-то графического API, будь то Win32 API или Xlib (или реализованных поверх них GTK+ и QT). Postscript и все эти графические библиотеки реализуют примерно одни и те же графические примитивы — отрезки, прямоугольники, дуги, кривые Безье, заполнение области, ограниченной кривой, шрифты (растровые и векторные) и печать этими шрифтами, всё примерно то же самое. Да, PostScript — интерпретатор. Но, во-первых, он представляет собой стековый язык, а значит, интерпретировать его просто, интерпретатор не сложен, и времени на интерпретацию каждой команды уйдёт очень немного. А во-вторых, в графических библиотеках для получения каждого примитива нужно каждый раз вызывать функцию. Вызов функции с точки зрения процессорного времени дорогая операция. А учитывая, что Win32 API реализован через системные вызовы ядра, а Xlib реализована через протокол обмена между X-клиентом и X-сервером (X-протокол), надо понимать, что времени будет уходить ещё больше, поскольку системный вызов (а он и в том, и в другом случае, и в случае Windows, и в случае Unix, будет происходить) ОЧЕНЬ дорогая операция с точки зрения процессорного времени. Т. е. мне кажется, что рендеринг изображения, заданного похожим образом на Postscript и через какую-то графическую библиотеку, займёт и в том и в другом случае примерно одно и то же время. Если изображение нормально успевает обработаться средствами графической библиотеки, то никакого слайд-шоу не будет и на Postscript'е.

Добавлено через 30 минут

Сообщение от drfaust А ведь в прошиве АРМа принтера весьма оптимизированный закрытый софт, а не универсальная прога, задача которой работать под всеми ОС, под всеми CPU, с поддержкой формата, собранного по крупицам, и наверняка неполной информации....

А тут вообще ничего не понял. Что значит "формат, собранный по крупицам и наверняка неполной информации"?

PostScript — язык с полностью открытой общедоступной спецификацией. Скачать эти спецификации может каждый с сайта Adobe и с других ресурсов, по которым эти файлы расползлись. Никакой тайны и know how он не составляет, чтобы понять, как он работает, не надо колупать программы и хакерским путём выяснять, что же его команды делают. Всего было выпущено три версии стандарта Postscript'а — Level 1, Level 2, Level 3, все их при желании можно найти. Плюс того, по этому формату написано несколько вроде неплохих учебников, но все они на английском языке, на русский ничего не переводилось. Да, формат собственнический, за использование этого языка в печатающих аппаратах вроде принтеров или плоттеров, как я понял, нужно платить лицензионные отчисления фирме Adobe. Но он отнюдь не закрытый.

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

0

Сообщение от JohnyWalker Я не понимаю, почему рендеринг изображения, записанного на постскрипте, должен занимать существенно больше времени, чем рендеринг такого же изображения, полученного путём последовательного вызова функций какого-то графического API, будь то Win32 API или Xlib (или реализованных поверх них GTK+ и QT).

Наверное, потому, что надо будет парсить PS, после чего преобразовывать распарсенное в вызовы системного видеодрайвера. Пример подобных тормозов - реализация вызовох DirectX через вызовы OpenGL в WinE, но там нет к-либо лексического разбора - просто своя(и не очень) реализация вызовов DirectX.

0

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

И кстати, живой пример. В начале 1980-ых годов существовало по меньшей мере 2 графические системы, в которых PS был взят за основу. Это система NextStep, и система SunOS от Sun Microsystems. Правда, Sun Microsystems вскоре отказалась от этой системы в пользу иксов. А система Aqua от Apple не уверен, но не исключаю, что что-то подобное имеет на нижнем уровне своей графической подсистемы. Те две системы, у NextStep и у SunOS правда, были не консольные, а оконные, но они были обе основаны на PS. Думаю, если б это было так сложно, требовало таких громадных вычислений, с этим бы никто не стал связываться, тем более тогда, когда мощность персоналок и рабочих станций была смехотворна по нынешним временам. Так что мне кажется, что проблемы быстродействия здесь просто не существует.

0

Сообщение от JohnyWalker Пробовал ли кто-нибудь из вас писать на языке postscript?

Когда-то создавал программу для спуска полос. И не только.

Сообщение от JohnyWalker Можно ли, допустим, программу писать на C, а графику создавать в ней, посылая команды на postscript'е в поток stdout?

Не все так просто. Будучи программой один участок кода PS может обращаться к другому.

Сообщение от JohnyWalker Т. е. это язык издательских систем, позволяющий описывать на плоской поверхности изображение, содержащее тексты, выполненные любыми типографскими шрифтами, линии (как прямые, так и искривлённые, для последних в нём предусмотрены кривые Безье), рисунки и картинки.

Издательские системы генерируют PS код, а не интерпретируют.
Даже часто создается впечатление, что графическая программа, открывает свой EPS (Encapsulated PostScript), в реальности, просто в комментарии в EPS добавляет свой формат и открывает его.
Представьте что проще написать, программу которая генерирует HTML-код, или программу которая его визуализирует. А PS будет на порядок сложнее.

1