XeLaTeX / กราฟิกพิเศษ
เมื่อฉันใช้รหัสต่อไปนี้ภายใต้ XeLaTeX
\resizebox{\textwidth}{!}{\includegraphics{foo.pdf}}
ไฟล์ XDV มี opcodes ต่อไปนี้:
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
ฉันจะหาคำอธิบายพิเศษของเนมสเปซxและได้pdfที่ไหน?
ฉันเดาว่าpdf:btransจะคงสถานะกราฟิกปัจจุบันไว้ในหน่วยความจำและเริ่มต้นใหม่x:scaleความพิเศษเฉพาะสำหรับ XeLaTeX หรือไม่
เหตุใดจึงมีสเกล 0.99667 อันดับแรก (ได้มาจาก\resizebox) และอีกอันหนึ่งมีสเกล 1.0
ในpdf:imageแบบพิเศษฉันเห็นmatrixคำสำคัญที่ทำให้ฉันนึกถึงเมทริกซ์สถานะกราฟิก PostScript เหตุใดจึงไม่ใช้เมทริกซ์นี้สำหรับการปรับขนาด ฉันดูในเอกสารของฉันและตัวเลขทั้งหมดมีเมทริกซ์ "รวม" เหมือนกันเมทริกซ์นี้จะแตกต่างกันภายใต้สถานการณ์ใด
และคำถามสุดท้าย: ฉันเห็นว่าตรงกันข้ามกับข้อเสนอพิเศษของ PostScript เช่น
PSfile=%0022fig1.eps%0022 llx=0 lly=0 urx=104 ury=131 rwi=1040
ในกรณีที่กล่องขอบเขตมีความชัดเจนในpdf:imageกล่องไม่มีขอบเขตและต้องแยกส่วนครอบตัดออกจากไฟล์ PDF คุณรู้จักเครื่องมือบางอย่างที่แยกครอปบ็อกซ์อย่างปลอดภัยหรือไม่? ฉันทดสอบpdfinfoและสร้างรหัสต่อไปนี้:
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
"ขนาดหน้ากระดาษ" เป็นกล่องครอบตัดจริงหรือไม่ และ "pts" จุด PostScript (= bp) หรือจุด TeX (= pt)?
คำตอบ
ขั้นแรกให้ถามคำถามทั่วไปข้อ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/ etranspair มีประโยชน์เมื่อต้องการชุดพิเศษที่จับคู่อย่างชัดเจน ตัดกันx:rotateหรือคล้ายกันซึ่งเป็นการดำเนินการแบบ "ถ่ายครั้งเดียว" จึงเหมาะที่สุดสำหรับการ "สร้าง" ภายในด้านนอกx:gsave/ x:grestoreคู่ (ในl3backendโค้ดเราใช้ทั้งสองด้วยเหตุผลนี้เนื่องจากตรงกับ API จากแบ็กเอนด์อื่น ๆ )
การใช้x:scaleฯลฯ ฉันควรคิดว่าเทียบเท่ากับการใช้pdf:brans scaleเนื่องจากทั้งคู่ปล่อยให้การแปลง 'ติดตาม' แบ็กเอนด์ สิ่งนี้จะปรากฏขึ้นเช่นเมื่อคุณมีไฮเปอร์ลิงก์ซ้อนอยู่ภายในช่องว่างดังกล่าวการเรียกแบบดิบไปยังการcmดำเนินการPDF จะทำให้สิ่งเหล่านี้ยุ่งเหยิง ดังที่ระบุไว้ข้างต้นข้อแตกต่างที่สำคัญระหว่างทั้งสองคือ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 ได้ในทุกกรณี