XeLaTeX/графические спецпредложения

Question

Во-первых, если взять общий вопрос, то pdf:специальные описаны в руководствах dvipdfmи dvipdfmx. Для последнего вам нужен dvipdfmx-special.pdf, к которому я обращаюсь, используя texdoc -l dvipdfmxего запись № 2 в списке файлов.

Версии x:(насколько мне известно) не документированы - читайтеисточник, они происходят из xdvipdfmx, но поскольку dvipdfmxи xdvipdfmxтеперь объединены, это неважно. Главное, что они работают так же, как pdf:...версии, задокументированные для dvipdfm, и что еще важнее, мы знаем, что они использовались таким образом в течение многих лет. Поэтому, хотя они изначально были специфичны для XeTeX, сегодня мы можем смешивать pdf:и x:специальные с , dvipdfmxкак вы видели. (Стоит отметить, что они реализованы независимо, поэтому взаимодействия в целом должны быть протестированы.) В списке XeTeX есть некоторая информация о некоторых специальных, наиболее очевидноhttps://tug.org/pipermail/xetex/2004-May/000220.html.

Пара btrans/ etransобразует область действия матрицы преобразования. (В l3backendверсии того же кода мы используем x:gsave/ x:grestore, что сохраняет/восстанавливает все графическое состояние — что позволяет использовать код совместно с другими операциями.) Пара btrans/ etransполезна, когда требуется явноев паренабор специальных предложений; контраст с x:rotateили подобным, который является «однократной» операцией, поэтому лучше всего подходит для «наращивания»в пределахвнешняя пара x:gsave/ x:grestore. (В l3backendкоде мы используем оба по этой причине, так как они соответствуют API других бэкэндов.)

Использование x:scaleи т. д., как мне кажется, должно быть эквивалентно использованию pdf:brans scale, поскольку оба позволяют бэкэнду «отслеживать» преобразования. Это проявляется, например, когда у вас есть гиперссылки, вложенные в такое пространство: необработанный вызов операции PDF cmприведет к тому, что они будут испорчены. Как отмечено выше, основное различие между ними заключается в том, что версия x:может быть «автономной» внутри серии преобразований, тогда как pdf:btransтребует сопоставления pdf:etransопераций.

На вопрос «зачем масштабировать дважды», это потому, что у вас есть изображение внутри масштабируемого блока. В XeTeX мы не масштабируем изображения «напрямую» (на уровне специального включения изображения), а вместо этого вставляем изображение в блок, который затем масштабируется (это общее с pdfTeX, см. ниже). Таким образом, когда вы включаете изображение, оно устанавливается в полный масштаб (без масштабирования в качестве необязательного аргумента для \includegraphics), и это отображается как масштабирование без операции. Затем вы масштабируетеокружающийполе, которое выполнено в «крупных точках», отсюда и немного странные значения.

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

Наконец, мы переходим к ограничивающему окну. В dvipdfmxмаршруте мы должны использовать вспомогательную программу, extractbbчтобы получить ограничивающий окно. Однако в XeTeX у нас есть примитив изображения \XeTeXpdffile, который может читать PDF напрямую. Требуется аргумент ключевого слова, чтобы сказатькоторыйполе для чтения: это рассматривается в texdoc xetex. Вы увидите там, что этот примитив может масштабировать изображение, в отличие от использования \special{pdf:image ...}, но, как отмечено выше, эта функция не используется. Если бы кто-то выбрал масштабирование/поворот изображения на уровне \XeTeXpdffile, это бы отобразилось в matrix: Я не уверен, насколько хорошо это взаимодействует с гиперссылками в этом случае.

Вставка изображения PDF обрезает его вокруг желаемого ограничивающего поля, что означает, что вам не нужно беспокоиться о единицах. Если вы хотите узнать размер полученного изображения, вы измеряете поле TeX, в котором оно оказывается, например

\setbox0=\hbox{\XeTeXpdffile "foo.pdf" media }%
\edef\pictureheight{\the\ht0 }%
\edef\picturewidth{\the\wd0 }%

поскольку изображение всегда вставляется в опорную точку ящика без глубины. Вы увидите в xetex.defмы используем это, чтобы предположить, что нижние левые координаты всегда (0,0)(ср. dvips, где жизнь более 'интересна').

Для растровой графики примитив \XeTeXpicfileдоступен и может вставлять изображение без необходимости ограничивающего прямоугольника заранее. Как мы только что видели с \XeTeXpdffile, поскольку эти примитивы знают об ограничивающем прямоугольнике изображений, они вставляют их в TeX с «реальным» размером, поэтому мы можем измерить результаты, используя прямоугольник TeX во всех случаях.

Answer 1