Внедрение шрифтов в графики Gnuplot

Как всегда, беда пришла, и её совсем не ждали. Организаторы конференции SPIE, в которой я заядлый участник, что-то там поменяли в своей системе приёма PDFников статей. Теперь система Numbus Roman не переваривает, и заменяет его чудовищным Courier. Вопрос о внедрении английских шрифтов в графики, созданные gnuplot, встал в полный рост. Летопись героической победы приложенных титанических усилий прилагается.


Загудели, заиграли провода!
Вы такого не видали никогда!
(С) песня советских времён.


Приводимый ниже рецепт успешно опробован на Gnuplot Version 4.2 patchlevel 2 и Debian GNU/Linux "Lenny" v5.0.

Нужон внедрёж!
Пациент выглядит вот так:
#! /usr/bin/gnuplot -persist
set terminal postscript "NimbusSanL-Regu" eps enhanced color
set output "./plots/plotresults_vonkarman.ps"
set logscale x
set format x "10^{%L}"
set logscale y
set format y "10^{%L}"
set style line 1 lt 1 pt 7
set xrange [10**(0):10**(3.4)]
set key top left
set grid
set bmargin 4
set xlabel "Frequency, [Hz]" font "NimbusSanL-Regu,18"
set ylabel "Power [dB/Hz]" font "NimbusSanL-Regu,18"
plot "./results_vonkarmanpsd.numdata" using 1:2 with points linestyle 1
Чтобы узнать, внедрены в график шрифты или нет, нам нужны утилита pfbtops.

Если её нет, при попытке использовать приводимое ниже решение вы увидите такие матюги:
line 0: Command 'pfbtops /usr/share/texmf-texlive/fonts/type1/urw/helvetic/uhvr8a.pfb' generated error, exitcode is 32512

Ради неё придётся ставить пакеты groff и psutils:
aptitude install groff psutils
Это нам даст:
Чтение списков пакетов... Готово
Построение дерева зависимостей
Чтение информации о состоянии... Готово
Чтение информации о расширенных состояниях
Инициализация состояний пакетов... Готово
Чтение описаний задач... Готово
Следующие НОВЫЕ пакеты будут установлены:
groff psutils{a}
0 пакетов обновлено, 2 установлено новых, 0 пакетов отмечено для удаления, и 244 пакетов не обновлено.
Необходимо получить 1998kB архивов. После распаковки 5894kB будет занято.
Хотите продолжить? [Y/n/?]
Да, мы хотим. Теперь у нас всё есть - посмотрим, внедрены ли шрифты:
$ epstopdf plotresults_vonkarman.ps
и далее:
$ pdffonts plotresults_vonkarman.pdf
Выхлоп этой команды будет в виде:
name type emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
Courier Type 1 no no no 8 0
Подсвеченное красным говорит нам всё: шрифты не внедрены. А жаль. Сейчас поправим. Решение выглядит вот так:

#! /usr/bin/gnuplot -persist
set terminal postscript "NimbusSanL-Regu" eps enhanced color fontfile "/usr/share/texmf-texlive/fonts/type1/urw/helvetic/uhvr8a.pfb"
set output "./plots/plotresults_vonkarman.ps"
set logscale x
set format x "10^{%L}"
set logscale y
set format y "10^{%L}"
set style line 1 lt 1 pt 7
set xrange [10**(0):10**(3.4)]
set key top left
set grid
set bmargin 4
set xlabel "Frequency, [Hz]" font "NimbusSanL-Regu,18"
set ylabel "Power [dB/Hz]" font "NimbusSanL-Regu,18"
plot "./results_vonkarmanpsd.numdata" using 1:2 with points linestyle 1
Собственно, нужно вставить:
set terminal postscript "NimbusSanL-Regu" eps enhanced color fontfile "/usr/share/texmf-texlive/fonts/type1/urw/helvetic/uhvr8a.pfb"
с точным указанием пути к шрифту. Теперь нашему графику должно полегчать:
$ epstopdf plotresults_vonkarman.ps
$ pdffonts plotresults_vonkarman.pdf

name type emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
ZEVCBJ+NimbusSanL-Regu Type 1C yes yes no 8 0

Так и есть! Теперь графики содержат шрифты, и всё в статье будет так, как мы хотим того.

Ссылки
Решение творчески переосмыслено здесь.

20 комментариев: |высказаться!| RSS-лента дискуссии.|
iv_vl комментирует...

virens, будь любезен, обрежь этот пост на главной странице, а то слишком много букафф. Очередной рецепт для дебиана, где даже нет его версии, - тут и сказать-то нечего.

cramur комментирует...

iv_vl, да ну, смысл как раз понятен, а то вот ты, сидя на дебиане не той версии не поймёшь, как надо поменять рецепт что ли? Я вообще не на дебиане сижу.

virens, а почему ты не используешь tikz, с ним разве не проще? И унифицированней получается как-то стиль всего документа и, имхо, проще работать с теховскими подписями к графикам.

iv_vl комментирует...

@cramur комментирует...
вот ты, сидя на дебиане не той версии не поймёшь, как надо поменять рецепт что ли?
Выходит, я поторопился. Глянул по версиям дебиана - эти пакеты есть везде.

virens, а почему ты не используешь tikz
Если речь идёт о презентации, то по-моему связка Beamer + Tikz - лучшее решение. Как понимаю, virens'у нужна автоматизация построения графиков с большим кол-вом данных. Тут нужно что-то посерьезнее Tikz, я бы предложил еще MathGL - там в наличии биндинги к питону. В общем, каждой задаче - своё решение. Для придания графикам наилучшего типографского вида предпочёл бы Metapost, а еще лучше - Asymptote.

virens комментирует...

@iv_vl пишет...
virens, будь любезен, обрежь этот пост на главной странице, а то слишком много букафф.
Сделано. И это много букв? Ха! Вот следующий пост будет да - гобелен. Сикстинская капелла нервно курит за углом.

Очередной рецепт для дебиана, где даже нет его версии
А что плохого в рецептах для дебиана? Блог как раз про это. Версию добавил.

@cramur пишет...
надо поменять рецепт что ли?
Если читать пост внимательно, то видно, что от дебиана\убанты это не зависит. Там про гнуплот с латехом, они всюду одинаковые.

virens, а почему ты не используешь tikz, с ним разве не проще?
Так это ж для схем, а у меня графики, которые строятся по экспериментальным\симуляционным данным. Гнуплотом проще, и, как правильно ниже сказал iv_vl, мне надо сразу много графиков.

@iv_vl пишет...
Глянул по версиям дебиана - эти пакеты есть везде.
Конечно.

Если речь идёт о презентации, то по-моему связка Beamer + Tikz
Кстати, это интересный коммент. Надо будет попробовать. Я давно как-то экспериментировал с Tikz, и мне он не понравился. Попробую снова при оказии.

Как понимаю, virens'у нужна автоматизация построения графиков с большим кол-вом данных.
Именно так. Есть куча текстовых файлов с данными. Скрипт на пистоне, в зависимости от параметров, припаривает имя графику, генерит скрипт на гнуплоте, дёргает гнуплот и скармливает ему выхлоп. Гнуплот пыхтит и строит график. Потом пистон дёргает его снова, etc. Механизация!

я бы предложил еще MathGL - там в наличии биндинги к питону.
Попробуем.

Для придания графикам наилучшего типографского вида предпочёл бы Metapost, а еще лучше - Asymptote.
Мне не хочется менять коней на переправе: скрипты есть, гнуплот освоен, всё механизировано. Тык-клац-шлёп - и в статью\конференцию.

Потом, выхлоп гнуплота мне нравится. Я шрифты просто не внедрял (думал, Нимбус Санс есть везде, а он не везде). Вот заметка и нарисовалася.

Rakshas комментирует...

Хм... Интересно.
А если использовать терминал pdfcairo? Там можно прямо указать какой шрифт использовать. Да и на выходе сразу PDF --- не надо туда-сюда PS'ки гонять.

virens комментирует...

@Rakshas пишет...
А если использовать терминал pdfcairo?
Не пробовал. Я пользуюсь всегда dvi2ps для того, чтобы быстро отрисовывался апдейт статьи. Мне так удобнее, поэтому pdflatex я не пользую.

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

iv_vl комментирует...

@virens пишет...
Я давно как-то экспериментировал с Tikz, и мне он не понравился. Попробую снова при оказии.
Попробуй-попробуй, и опиши потом в блоге. Есть приблуда ktikz для, так сказать, визуального осмысления того, что делаешь.

Мне так удобнее, поэтому pdflatex я не пользую.
Вот TeX Live последних версий можно скармливать рисунки в EPS при использовании pdflatex - он сам конвертирует.

По разным причинам, мне удобнее именно PS
Я создавал EPS при помощи Metapost, который должен корректно генерировать EPS, поскольку транслируется в него напрямую. У меня на компьютере все шрифты отображались правильно, а вот на ArXiv.org они отображались странно: на одних графиках шрифты были правильные, на других - полная фигня. И это при том, что все графики создавались по одному шаблону и использовали только обычный латеховский шрифт. Когда мне этот бардак надоел, я просто переделал все рисунки в PDF и больше не испытывал проблем ни с ArXiv, ни с PRA (хотя раньше, ЕМНИП, они требовали именно EPS).

Анонимный комментирует...

на упомянутой автором версии gnuplot 4.2.2 терминалов cairo (pdfcairo и pngcairo) нет, т.к. они были добавлены в 4.4.0; аноним горячо рекомендует.

в gnuplot 4.6.rc1 дополнительно анонсирован терминал epscairo; аноним пока не пробовал.

Анонимный комментирует...

аноним отдельно рекомендует терминал pngcairo, особенно для графиков с числом отрезков, соединяющих линии, и особенно точек, свыше нескольких тысяч.

eps и pdf они конечно все из себя векторные, православные и сакрально-литургические, но вот когда данных реально много, картинка рендерится относительно долго не только самим гнуплотом, но и при каждом последующем просмотре. анонима это порядком раздражает.

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

все это годится, конечно, только для pdflatex, если без дополнительных телодвижений.

virens комментирует...

@iv_vl комментирует...
Попробуй-попробуй, и опиши потом в блоге. Есть приблуда ktikz для, так сказать, визуального осмысления того, что делаешь.
О, а ktikz это интересно и молодёжно. Занёс в список "напосмотреть". Благодарствую.

Вот TeX Live последних версий можно скармливать рисунки в EPS при использовании pdflatex - он сам конвертирует.
До чего техника-то дошла! Ну надо же! То есть ув.тов iv_vl таки советует обновляться? :-)

@Анонимный комментирует...
они были добавлены в 4.4.0; аноним горячо рекомендует.
Автор безусловно ценит горячие рекомендации Анонимуса. Только у автора были проблемы со сборкою оного 4.4.0 на Ленни, а обновляться сейчас автору... скажем так, не до этого. Но автор попробует при оказии.

@Анонимный комментирует...
аноним отдельно рекомендует терминал pngcairo, особенно для графиков с числом отрезков, соединяющих линии, и особенно точек, свыше нескольких тысяч.

Есть такая проблема. У автора был случай, когда на графике было отображено около десятка тысяч точек. Автор отлично понимает Анонимуса: отрисовка шла медленно, пафосно и печально.

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

Автор реквестирует попользоваться оными эпитетами в статье. [лирика: переводил тут намедни большой пост с аглицкого, который скоро выйдет, и нарвался на копирайты издательства. Эти буржуазные копирасты хотели содрать с меня 300 баксов за мой же перевод!]

но вот когда данных реально много, картинка рендерится относительно долго не только самим гнуплотом, но и при каждом последующем просмотре. анонима это порядком раздражает.
Автора это тоже сильно бесит. Есть такая проблема. Автор беспокоится вот о чём: отрендеренные в 300dpi графики иногда на печати выглядят плохо. Рендерить с большим разрешением - выходит крупный файл, а меньшее ставить нельзя. EPS здесь решает, конечно, но отрисовка...

посконный же растр png один раз сгенерирован гнуплотом
Рендеринга разрешение есть вопрос неоднозначный. Магистру Йоде помедитировать над этом нужно. Анонимусу благодарность за медитации направления выражаю.

Rakshas комментирует...

Только у автора были проблемы со сборкою оного 4.4.0 на Ленни, а обновляться сейчас автору... скажем так, не до этого. Но автор попробует при оказии.
В свою очередь искренне рекомендую обновиться сразу на sid и не иметь более проблем с обновлениями. Роллинг-релизы таки рулят.

По разрешению для png, таки рекомендую 600dpi и ни dpi'шкой меньше ;-) Причём делать их из PDF'ок через GIMP или Imagemagick. Со сжатием на 9 получается крайне компактно.

А если графики монохромные, то идеально использовать 1 битный TIFF со сжатием по Fax Group 4 и разрешение 600dpi или 1200dpi. При прекрасном качестве получается до смешного маленький объём.

Анонимный комментирует...

Дорогой аффтар!

Автор реквестирует попользоваться ...

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

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

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

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

среди прочего дорогой аффтар писал:
у меня графики, которые строятся по экспериментальным\симуляционным данным. Гнуплотом проще, и, как правильно ниже сказал iv_vl, мне надо сразу много графиков.

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

cramur комментирует...

Гм. Вообще-то я как раз гнуплотом строю tikz-based экспериментальные данные в автоматическом режиме, в большом количестве, всё то же, что и с любым другим терминалом, в общем-то. Ну да, пару скриптов написать.

Ну то есть есть какая-то принципиальная разница в твоём методе и tikz? Ну то есть кроме привычки?

А по поводу генерации и телодвижений, нашёл отличную штуку - модуль для cmake UseLatex, который тоже рекомендую (хотя, правда, рекомендуется склонность к повышенному использованию коммандной строки)

iv_vl комментирует...

@cramur пишет...
Ну то есть есть какая-то принципиальная разница в твоём методе и tikz? Ну то есть кроме привычки?
Может быть для ваших нужд вполне достаточно Tikz, но зачем выбирать самый медленный движок из всех доступных? Т.е. Tikz - надстройка над PGF, который в свою очередь - надстройка над TeX. Далеко ходить не надо, описание на sourceforge:
PGF is a TeX macro package for generating graphics. It is platform- and format-independent and works together with the most important TeX backend drivers, including pdftex and dvips. It comes with a user-friedly syntax layer called TikZ.

cramur комментирует...

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

iv_vl комментирует...

@cramur комментирует...
на котором Tikz вёл себя медленно

А есть причины, по которым Tikz должен быть медленным? Или на сегодняшнем железе такая задача, как отрисовка двумерного графика, может занимать много времени? Но если вам нужно попасть из точки А в Б, и у вас есть выбор лошади, вы выберете лошадь: а) одну из самых быстрых, или б) красивую, но одну из самых медленных?
К тому же вы очень виртуозно суживаете область Tikz только к двумерным графикам. Но чем тогда выбор Tikz у вас обоснован? У того же Gnuplot возможностей должно быть гораздо больше.

cramur комментирует...

3-е предложение в данной статье как бы намекает на то, что красота - страшная сила.
Если у вас попасть из точки А в Б состоит в наборе текста для статьи, почемы бы не использовать сразу ms word? Быстро ведь, и тратить драгоценное время на компиляцию не надо.

Последний пассаж прекрасен. Я говорю про терминал gnuplot выводящий в tikz. Это позволяет мне использовать все его "гораздо больше" возможностей при выводе двумерной картинки (Hint: двумерная картинка может быть проекцией трёхмерного объекта)
Выбор обоснован на отсутствии принудительного использования psgraf и переключении контекстов для замены символов и радующем глаз результату на выходе и возможности использовать уже освоенный интерфейс gnuplot без изменений.

iv_vl комментирует...

@cramur комментирует...
Я говорю про терминал gnuplot выводящий в tikz

Теперь всё стало на свои места: речь идёт о Gnuplot TikZ terminal. Просто ваша фраза про "tikz-based экспериментальные данные" меня ввела в заблуждение. А так получается красиво, стильно и молодежно. Спасибо за подробный ответ! Остается вопрос: выхлоп терминала вы вставляете в документ или предварительно переводите в EPS или PDF? Второй метод для статей предпочтительнее, да и времени на компиляцию документа тратится меньше.

virens комментирует...

Так, товарищи iv_vl и cramur, я предлагаю вам не переходить на личности и вернуться-таки к конструктиву.

@cramur комментирует...
Вообще-то я как раз гнуплотом строю tikz-based экспериментальные данные в автоматическом режиме, в большом количестве, всё то же, что и с любым другим терминалом, в общем-то. Ну да, пару скриптов написать.
Автор реквестирует скрипты к tikz от тов.cramur. Более того, автор прелагает ув.тов.cramur про это написать небольшой пост с примерами. Автор будет более, чем счастлив, опубликовать пост ув.тов.cramur у себя на блоге, дабы все (в том числе и автор эти строк) узрели сокрушительную силу tikz.

Ну то есть есть какая-то принципиальная разница в твоём методе и tikz? Ну то есть кроме привычки?
Если вопрос адресовался мне, то привычка в моём случае побеждает. Но если tikz будет круче - готов сломать стереотипы и таки перейти на новое (или во всяком случае чаще использовать).

Насчёт поста: если тов. cramur желает, то автор предлагает ему стукнуть мне на почту mydebianblog джымайлком.

cramur комментирует...

Хм. Ну, видать, я просто очень коряво выражал свои мысли, т.к. мне показалось я сразу об этом и говорил :) Не приходилось сталкивался вообще с другими местами использования tikz

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

Отправить комментарий

Подписаться на RSS-ленту комментариев к этому посту.