XeLaTeX / grafiki specjalne

Question

Kiedy używam następującego kodu w XeLaTeX

\resizebox{\textwidth}{!}{\includegraphics{foo.pdf}}

plik XDV zawiera następujące rozkazy:

PUSH
XXX "pdf:btrans"
XXX "x:scale 0.99667 0.99667"
PUSH
PUSH
PUSH
PUSH
PUSH
PUSH
XXX "pdf:btrans"
XXX "x:scale 1 1"
PUSH
PUSH
XXX "pdf:image matrix 1.0 0.0 0.0 1.0 0.0 0.0 page 0 pagebox cropbox (foo.pdf)"
POP
POP
XXX "pdf:etrans"
POP
POP
POP
POP
POP
POP
XXX "pdf:etrans"
POP

Gdzie mogę znaleźć opis ofert specjalnych z przestrzenią nazw xi pdf?

Domyślam się, że to pdf:btranszachowuje aktualny stan grafiki w pamięci i uruchamia nowy, czy jest to x:scalecoś specjalnego dla XeLaTeX?

Dlaczego najpierw jest skala 0,99667 (uzyskana z \resizebox), a potem kolejna ze skalą 1,0?

W pdf:imagedodatku widzę matrixsłowo kluczowe, które przypomina mi macierz stanu grafiki PostScript, dlaczego ta macierz nie jest używana do skalowania? Zajrzałem do mojego dokumentu i wszystkie figury miały tę samą „jednolitą” matrycę, w jakich okolicznościach ta matryca byłaby inna?

I ostatnie pytanie: widzę to, w przeciwieństwie do specjalnych PostScript, takich jak

PSfile=%0022fig1.eps%0022 llx=0 lly=0 urx=104 ury=131 rwi=1040

gdzie obwiednia jest jawna, w przypadku pdf:imagenie ma ramki ograniczającej, a pole przycinania musi zostać wyodrębnione z pliku PDF. Czy znasz jakieś narzędzie, które bezpiecznie wyodrębnia Cropbox? Przetestowałem pdfinfoi wygenerowałem następujący kod:

Creator:        TeX
Producer:       pdfTeX-1.40.20
CreationDate:   Mon Aug 31 13:24:48 2020 CEST
ModDate:        Mon Aug 31 13:24:48 2020 CEST
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      347 x 426 pts
Page rot:       0
File size:      11745 bytes
Optimized:      no
PDF version:    1.5

Czy „Rozmiar strony” to faktycznie pole przycinania? Czy punkty PostScript „pts” (= bp) czy punkty TeX-a (= pt)?

Answer 1

Po pierwsze, biorąc pod uwagę ogólne pytanie, oferty pdf:specjalne są opisane w instrukcjach dvipdfmi dvipdfmx. W drugim przypadku chcesz dvipdfmx-special.pdf, do którego uzyskuję dostęp, texdoc -l dvipdfmxponieważ jest to wpis nr 2 na liście plików.

Te x:wersje nie są (według mojej wiedzy) udokumentowane - czytanie źródła , pochodzą one z xdvipdfmx, ale ponieważ dvipdfmxi xdvipdfmxsą teraz połączone, to nie ma znaczenia. Kluczem jest to, że działają one tak samo, jak pdf:...wersje udokumentowane dla dvipdfm, a co ważniejsze, wiemy, że były używane w ten sposób przez wiele lat. Więc chociaż te zaczęły się jako specyficzne dla XeTeX-a, dziś możemy mieszać pdf:i mieszać oferty x:specjalne, dvipdfmxjak widzieliście. (Warto zauważyć, że są one implementowane niezależnie, więc interakcje powinny być generalnie testowane.) Na liście XeTeX jest trochę informacji o niektórych ofertach specjalnych, oczywiściehttps://tug.org/pipermail/xetex/2004-May/000220.html.

btrans/ etransPary tworząc zakresu macierzy transformacji. (W l3backendwersji tego samego kodu używamy x:gsave/ x:grestore, który zapisuje / przywraca cały stan grafiki - co pozwala na współdzielenie kodu z innymi operacjami.) Parametr btrans/ etranspair jest przydatny, gdy chce się jawnie sparowanego zestawu specjalnych; kontrast z x:rotatelub podobnym, co jest operacją „jednorazową”, najlepiej nadającą się do „budowania” w zewnętrznej części x:gsave/ x:grestoreparze. (W l3backendkodzie używamy obu z tego powodu, ponieważ pasują one do interfejsów API z innych backendów).

Używanie x:scaleitp. Powinno być równoważne używaniu pdf:brans scale, ponieważ oba pozwalają backendowi „śledzić” transformacje. Pokazuje się to na przykład, gdy masz hiperłącza zagnieżdżone w takiej przestrzeni: surowe wywołanie cmoperacji PDF oznacza, że ​​się pomieszają. Jak wspomniano powyżej, główna różnica między nimi polega na tym, że x:wersja może być „samodzielna” w serii przekształceń, podczas gdy pdf:btranswymaga pdf:etransoperacji dopasowywania .

Jeśli chodzi o pytanie „po co skalować dwa razy”, to dlatego, że masz obraz w skalowanym pudełku. W XeTeX nie skalujemy obrazów „bezpośrednio” (na poziomie specjalnym, aby uwzględnić obraz), ale raczej wstawiamy obraz do pudełka, które jest następnie skalowane (jest to udostępniane pdfTeX, patrz poniżej). W związku z tym, gdy dołączasz obraz, jest on ustawiony na pełną skalę (bez skalowania jako opcjonalny argument do \includegraphics), a to pojawia się jako skalowanie bez operacji. Następnie skalujesz otaczające pudełko, co odbywa się w „dużych punktach”, stąd nieco dziwne wartości.

(Z XeTeXem moglibyśmy wybrać skalowanie obrazu w punkcie włączenia, ale to nie działa, dvipdfmxwięc aby udostępniać kod, unikamy go. Zasadniczo nowszy kod zaplecza ma tendencję do podążania za pdfTeX, a prymityw, którego używa dla obrazu Włączanie nie oferuje skalowania dla wszystkich typów obrazów, więc najlepszą wspólną trasą kodu jest skalowanie pola zawierającego).

Na koniec przechodzimy do obwiedni. Na dvipdfmxtrasie musimy skorzystać z programu pomocniczego, extractbbaby uzyskać obwiednię. Jednak w XeTeX mamy prymityw obrazu \XeTeXpdffile, który może bezpośrednio czytać PDF. Potrzeba argumentu słowa kluczowego, aby powiedzieć, które pole przeczytać: jest to objęte texdoc xetex. Zobaczysz tam, że ten prymityw może wykonać skalowanie obrazu, w przeciwieństwie do używania \special{pdf:image ...}, ale jak wspomniano powyżej, ta funkcja nie jest używana. Jeśli zdecydujesz się skalować / obrócić obraz na \XeTeXpdffilepoziomie, pojawi się to w matrix: Nie jestem pewien w tym przypadku, jak dobrze współdziała z hiperłączami.

Wstawienie obrazu PDF przycina wokół żądanej ramki ograniczającej, co oznacza, że ​​nie musisz martwić się o jednostki. Jeśli chcesz poznać rozmiar wynikowego obrazu, mierzysz na przykład pole TeX-a, w którym się kończy

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

ponieważ obraz jest zawsze wstawiany w punkcie odniesienia pudełka bez głębi. Zobaczysz, xetex.defże używamy tego do założenia, że ​​współrzędne w lewym dolnym rogu są zawsze (0,0)(por. dvipsTam, gdzie życie jest bardziej „interesujące”).

W przypadku grafiki bitmapowej prymityw \XeTeXpicfilejest dostępny i może wstawić obraz bez konieczności wcześniejszego stosowania obwiedni. Jak właśnie widzieliśmy \XeTeXpdffile, ponieważ te prymitywy są świadome obwiedni obrazów, wstawiają je do TeX-a z „rzeczywistym” rozmiarem, więc we wszystkich przypadkach możemy mierzyć wyniki za pomocą ramki TeX-a.