XeLaTeX / đồ họa đặc biệt

Question

Khi tôi sử dụng mã sau trong XeLaTeX

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

tệp XDV chứa các mã opcodes sau:

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

Tôi có thể tìm mô tả về các điểm đặc biệt với không gian tên xvà ở pdfđâu?

Tôi đoán rằng điều đó pdf:btransgiữ trạng thái đồ họa hiện tại trong bộ nhớ và bắt đầu một cái mới, có phải là x:scaleđặc biệt dành riêng cho XeLaTeX không?

Tại sao đầu tiên có thang điểm 0,99667 (thu được từ \resizebox) và sau đó là thang điểm khác có thang điểm 1,0?

Trong phần pdf:imageđặc biệt, tôi thấy một matrixtừ khóa làm tôi nhớ đến ma trận trạng thái đồ họa PostScript, tại sao ma trận này không được sử dụng cho việc chia tỷ lệ? Tôi đã xem trong tài liệu của mình và tất cả các hình đều có cùng một ma trận "đơn nhất", trong trường hợp nào thì ma trận này sẽ khác?

Và câu hỏi cuối cùng: Tôi thấy điều đó, trái ngược với những điểm đặc biệt của PostScript như

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

trong đó hộp giới hạn rõ ràng, trong pdf:imagehộp không có giới hạn và hộp cắt phải được trích xuất từ ​​tệp PDF. Bạn có biết một số công cụ giải nén hộp cắt một cách an toàn không? Tôi đã thử nghiệm pdfinfovà nó tạo ra mã sau:

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

"Kích thước trang" có thực sự là hộp cắt không? Và là điểm PostScript "pts" (= bp) hay điểm TeX (= pt)?

Answer 1

Đầu tiên, lấy câu hỏi chung, các điểm pdf:đặc biệt được mô tả trong dvipdfmvà dvipdfmxhướng dẫn sử dụng. Đối với thứ sau, bạn muốn dvipdfmx-special.pdf, tôi truy cập bằng cách sử dụng texdoc -l dvipdfmxvì nó là mục nhập số 2 trong danh sách tệp.

Các x:phiên bản không được ghi lại (theo hiểu biết của tôi) - đọc nguồn , những phiên bản này bắt nguồn từ xdvipdfmx, nhưng kể từ khi dvipdfmxvà xdvipdfmxbây giờ được hợp nhất, điều này không quan trọng. Điều quan trọng là chúng hoạt động giống như pdf:...các phiên bản được ghi lại dvipdfmvà quan trọng hơn nữa là chúng tôi biết rằng chúng đã được sử dụng theo cách đó trong nhiều năm. Vì vậy, mặc dù những bắt đầu như XeTeX cụ thể, hôm nay chúng ta có thể intermix pdf:và x:đặc biệt với dvipdfmxnhư bạn đã thấy. (Cần lưu ý rằng chúng được thực hiện độc lập, vì vậy các tương tác nói chung cần được kiểm tra.) Có một số thông tin trên danh sách XeTeX về một số điểm đặc biệt, rõ ràng nhấthttps://tug.org/pipermail/xetex/2004-May/000220.html.

Các btrans/ etranscặp tạo thành một phạm vi cho ma trận chuyển đổi. (Trong l3backendphiên bản của cùng một mã, chúng tôi sử dụng x:gsave/ x:grestore, lưu / khôi phục toàn bộ trạng thái đồ họa - cho phép một số chia sẻ mã với các hoạt động khác.) Cặp btrans/ etransrất hữu ích khi người ta muốn một tập hợp đặc biệt được ghép nối rõ ràng ; tương phản với x:rotatehoặc tương tự, là thao tác 'một phát' nên phù hợp nhất để 'xây dựng' bên trong một cặp x:gsave/ bên ngoài x:grestore. (Trong l3backendmã, chúng tôi sử dụng cả hai vì lý do này, vì chúng khớp với các API từ các chương trình phụ trợ khác.)

Sử dụng x:scale, v.v., tôi nên nghĩ là tương đương với sử dụng pdf:brans scale, vì cả hai đều cho phép các biến đổi phụ trợ 'theo dõi'. Điều này hiển thị ví dụ khi bạn có các siêu liên kết được lồng trong một không gian như vậy: một lệnh gọi thô tới một cmthao tác PDF sẽ có nghĩa là những siêu liên kết này bị rối tung lên. Như đã lưu ý ở trên, sự khác biệt chính giữa hai x:phiên bản là phiên bản có thể 'độc lập' bên trong một loạt các phép biến đổi, trong khi pdf:btransyêu cầu các pdf:etranshoạt động phù hợp .

Đối với câu hỏi 'tại sao chia tỷ lệ hai lần', đó là vì bạn có một hình ảnh bên trong một hộp được chia tỷ lệ. Trong XeTeX, chúng tôi không chia tỷ lệ hình ảnh 'trực tiếp' (ở cấp độ đặc biệt để bao gồm hình ảnh), mà chúng tôi chèn hình ảnh vào bên trong hộp sau đó được chia tỷ lệ (điều này được chia sẻ với pdfTeX, xem bên dưới). Do đó, khi bạn bao gồm hình ảnh, hình ảnh được đặt ở tỷ lệ đầy đủ (không chia tỷ lệ làm đối số tùy chọn \includegraphics) và hiển thị dưới dạng tỷ lệ không chọn. Sau đó, bạn chia tỷ lệ một hộp xung quanh , được thực hiện theo 'điểm lớn', do đó các giá trị hơi lạ.

(Với XeTeX, chúng tôi có thể chọn chia tỷ lệ hình ảnh tại điểm bao gồm, nhưng điều đó không hiệu quả với dvipdfmxviệc chia sẻ mã mà chúng tôi tránh. bao gồm không cung cấp tỷ lệ cho tất cả các loại hình ảnh, vì vậy tuyến mã được chia sẻ tốt nhất là mở rộng một hộp chứa.)

Cuối cùng, chúng ta chuyển sang hộp giới hạn. Trong dvipdfmxlộ trình, chúng ta phải sử dụng chương trình bổ trợ extractbbđể lấy hộp giới hạn. Tuy nhiên, trong XeTeX, chúng tôi có một hình ảnh nguyên thủy \XeTeXpdffile, có thể đọc PDF trực tiếp. Phải mất một đối số từ khóa để nói mà hộp để đọc: đây được bao phủ trong texdoc xetex. Bạn sẽ thấy ở đó tính năng nguyên thủy này có thể thực hiện điều chỉnh tỷ lệ hình ảnh, ngược lại với việc sử dụng \special{pdf:image ...}, nhưng như đã lưu ý ở trên, tính năng đó không được sử dụng. Nếu một người chọn chia tỷ lệ / xoay hình ảnh ở \XeTeXpdffilemức độ, điều này sẽ hiển thị trong matrix: Tôi không chắc trong trường hợp này điều đó tương tác tốt như thế nào với các siêu liên kết.

Chèn hình ảnh PDF sẽ cắt xung quanh hộp giới hạn mong muốn, có nghĩa là bạn không cần phải lo lắng về các đơn vị. Nếu bạn muốn biết kích thước của hình ảnh kết quả, bạn đo hộp TeX mà nó kết thúc, chẳng hạn

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

vì hình ảnh luôn được chèn vào điểm tham chiếu của hộp không có chiều sâu. Bạn sẽ thấy trong xetex.defchúng tôi sử dụng điều đó để giả định rằng tọa độ phía dưới bên trái luôn luôn như vậy (0,0)(xem dvips, nơi cuộc sống 'thú vị hơn').

Đối với đồ họa bitmap, bản gốc \XeTeXpicfilecó sẵn và có thể chèn hình ảnh mà không cần hộp giới hạn trước. Như chúng ta vừa thấy \XeTeXpdffile, vì những người nguyên thủy này nhận thức được hộp giới hạn của hình ảnh, họ chèn chúng vào TeX với kích thước 'thực', vì vậy chúng ta có thể đo lường kết quả bằng cách sử dụng hộp TeX trong mọi trường hợp.