PDF นี้ผลิตโดย Abbyy Finereader 10:

http://ebooks.zeitr.org/from_abbyy.pdf

คุณสามารถคัดลอกและวางประโยคแรกและรับผลลัพธ์ข้อความ (ดีมาก) นี้:

Der » Bund Deutscher Gymnastik-Schulleiter «เมื่อวันที่ 20 พฤศจิกายน 1955 อ่านเพิ่มเติม

หลังจากประมวลผลบางอย่างด้วย Ghostscript 9.02 (Windows 64 บิต) ฉันได้รับไฟล์นี้:

http://ebooks.zeitr.org/after_ghostscript.pdf

ตอนนี้ประโยคแรกดูเหมือนแปลก - มีช่องว่างเพิ่มเติมก่อนอักขระตัวสุดท้ายของแต่ละคำ

Der » Bun d Deutsche r GymnastikSchulleiter « wurd eam 20. Novembe r 195 5 ปีที่ผ่านมาคุณสามารถเข้าสู่

นี่มีผลกระทบเชิงลบหลักที่คุณไม่สามารถค้นหาคำทั้งหมดใน Acrobat Reader ฉันสามารถสร้างเอฟเฟกต์ใหม่ด้วยชุดพารามิเตอร์ขั้นต่ำต่อไปนี้สำหรับ Ghostscript:

-sDEVICE=pdfwrite ^
-dBATCH ^
-dNOPAUSE ^
-sstdout="myStdOut" ^
-sOutputFile="myDestFile.pdf" ^
 mySourceFile.pdf

ความคิดใด ๆ

ฉันพบว่านี่เป็นปัญหาที่น่าสนใจและมองใกล้ ๆ ...

ก่อนอื่นฉันใช้qpdfเครื่องมือ commandline เพื่อยกเลิกการบีบอัดสตรีมข้อมูล PDF เพื่อให้ฉันสามารถดูซอร์สโค้ดของไฟล์ทั้งสองได้ดีขึ้น:

qpdf.exe ^
   --qdf ^
     from_abbyy.pdf ^
     qdf--from_abbyy.pdf

qpdf.exe ^
   --qdf ^
     after_ghostscript.pdf ^
     qdf--after_ghostscript.pdf

ดูที่หนึ่งในเหตุการณ์แรกที่มีการเพิ่มช่องว่าง (เป็นสตริงดั้งเดิม"Bund Deutscher Gymnastik-Schulleiter"กลายเป็น"Bun d Deutsche r GymnastikSchulleiter" ) ฉันพบไฟล์ PDF ต่อไปนี้:

ใน qdf - from_abbyy.pdf:

( Deutsche) Tj
0 Tc
(r) Tj
1 0 0 1 143.236 265.140 Tm     %% Tm = 'text matrix' operator
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite) Tj

ใน qdf - after_ghostscript.pdf:

( Deutsche)Tj
0 Tc
36.235 0 Td                    %% extra Td = 'move text current point' operator
(r)Tj
2.16501 0 Td                   %% Td = 'move text current point' instead of Tm
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite)Tj

เพื่อให้คุณเข้าใจว่าตัวดำเนินการกราฟิก PDF ใช้ที่นี่หมายถึงอะไรนี่คือรายการย่อ:

Tj - show text
Tc - set character spacing
Tm - set text matrix
Tw - set word spacing
Td - move text current point

อย่างที่คุณเห็น Ghostscript จะแทนที่โอเปอเรเตอร์ดั้งเดิมTm( เมทริกซ์ข้อความ ) ด้วยหนึ่งTd( ย้ายจุดปัจจุบันของข้อความ ) และเพิ่มอีกหนึ่ง2.16501 0 Td... ฉันไม่รู้ว่าทำไมถึงเป็นเช่นนั้น ฉันจะส่งรายงานข้อผิดพลาดไปยัง bugzilla ของ Ghostscript [*]และดูว่าพวกเขาสนใจที่จะแก้ไขหรือไม่

แต่ทราบว่าปัญหานี้จะไม่เกิดขึ้นถ้าผมใช้ลินุกซ์ Acrobat Reader 9.4.2 และใช้การกระทำที่เมนู"File -> บันทึกเป็นข้อความ ..." ในกรณีนี้ไม่มีช่องว่างเพิ่มเติม (แต่มีการแพร่กระจายเพิ่มอีกเล็กน้อย) บน Linux ข้อความนั้นไม่สามารถค้นหาได้อย่างถูกต้องและยังแสดงช่องว่างเพิ่มเติมเมื่อทำcopy'n'paste ....

^{[*]ฉันจะอัปเดตที่นี่พร้อมหมายเลขข้อบกพร่องเมื่อฉันทำเสร็จแล้ว}

ปรับปรุง:

หลังจากไตร่ตรองเพิ่มเติมเกี่ยวกับตัวTmดำเนินการที่ถูกแทนที่ไปแล้วตอนนี้ฉันคิดว่านี่ไม่ควรเป็นสาเหตุของปัญหา

เมื่อทราบว่าฉันพยายามแปลงด้วย Ghostscript v8.71 แทนที่จะเป็น v9.02 และฉันควรจะพูดยังไงดี? ปัญหา copy'n'paste ไม่เกิดขึ้นกับเอาต์พุต v8.71!

นั่นหมายความว่า: มีปัญหาใน Ghostscript 9.02 ที่ไม่ได้อยู่ใน 8.71 เป็นไปได้ว่าส่วนใหญ่เกี่ยวข้องกับเมตริกแบบอักษรที่ฝังอยู่ในผลลัพธ์ PDF เนื่องจากตัวอย่าง PDF ที่ยกมาข้างต้นนั้นเหมือนกันในเอาต์พุต v8.71 เหมือนกับในเอาต์พุต v9.02 ....

อัปเดต 2:

URL ของรายการบั๊กใน bugzilla ของ Ghostscript:

• http://bugs.ghostscript.com/show_bug.cgi?id=692206

อัปเดต 3:

ข้อผิดพลาดนี้ดูเหมือนจะได้รับการแก้ไขในขณะเดียวกัน ฉันไม่เห็นมันเกิดขึ้นกับ Ghostscript เวอร์ชันที่ฉันได้ทำการทดสอบอีกครั้งด้วย: Git ปัจจุบัน (v9.10GIT) หรือกับ Ghostscript v9.06

หากคุณสแกนหน้าเว็บที่มีข้อความเป็น PDF และเรียกใช้แอปพลิเคชัน OCR จากนั้นข้อความจะถูกเพิ่มลงในหน้า แต่ "โหมดการแสดงผลข้อความ" ถูกตั้งค่าเป็นมองไม่เห็น มี แต่ไม่มีการแสดงผลบนหน้าจอ (หรือบนกระดาษหากพิมพ์) สิ่งที่คุณเห็นหรือพิมพ์คือภาพต้นฉบับที่สแกน

เราจะทำให้ข้อความที่มองไม่เห็นปรากฏได้อย่างไร

เราสามารถแก้ไข PDF ... รหัส PDF เพื่อตั้งค่าการแสดงผลข้อความเป็นล่องหนคือ:

3 Tr

คุณไม่พบสตริงนี้ (ยัง) ในต้นฉบับfrom_abbyy.pdfหรือในfrom_ghostscript.pdfเนื่องจากบางส่วนของ PDF ถูกบีบอัด ดังนั้นเราจึงคลายการบีบอัดข้อมูลเท่าที่จะทำได้ด้วยความช่วยเหลือของqpdf:

qpdf \
 --qdf \
   from_abbyy.pdf \
   qdf--from_abbyy.pdf

qpdf \
 --qdf \
   after_ghostscript.pdf \
   qdf--after_ghostscript.pdf

ตอนนี้เราสามารถค้นหาสตริงข้างต้นได้อย่างง่ายดาย (และมีเพียงหนึ่งเกิดขึ้นในแต่ละไฟล์)

ลองเปลี่ยนเป็นโหมดการแสดงผลข้อความอย่างใดอย่างหนึ่ง โดยรวมเราสามารถเลือกระหว่างโหมดการแสดงผลข้อความ 8 โหมด:

 0 -  fill glyph shapes
 1 -  stroke glyph shapes
 2 -  fill, then stroke glyph shapes
 3 -  neither fill nor stroke glyph shapes (invisible)
 4 -  fill and add to path for clipping glyph shapes
 5 -  stroke glyph shapes and add to path for clipping
 6 -  fill, then stroke glyph shapes and add path for clipping
 7 -  add glyph shapes to path for clipping

หากฉันใช้โหมด "เติม" ข้อความจาก OCR อาจดูไม่ดีเท่าบนภาพสแกนต้นแบบ ดังนั้นฉันชอบตัวแปร "จังหวะ" ดังนั้นฉันก็เปลี่ยนข้างบนบรรทัดเพื่ออ่าน

 1 Tr

ดู PDF ที่ดัดแปลงนี้ฉันไม่ชอบเพราะ linewidth เริ่มต้นหนาเกินไปสำหรับรสนิยมของฉัน นอกจากนี้สีของลายเส้นโครงร่างเป็นสีดำ (ค่าเริ่มต้น) ฉันต้องการสีแดงเพื่อที่จะได้ตัดกับรูปร่างที่สแกนไว้ตั้งแต่แรก ดังนั้นฉันเพิ่มรหัสบางส่วนที่ด้านหน้าของบรรทัดนี้ซึ่งตั้ง linewidth ถึงหนึ่งในสี่ของจุด:

 .25 w

และอื่น ๆ เพื่อตั้งค่าจังหวะสีเป็นสีแดง:

 1 0 0 RG

บรรทัดที่สมบูรณ์ตอนนี้อ่านแล้ว:

 .25 w 1 0 0 RG 1 Tr

นั่นคือทั้งหมดที่

โปรดทราบว่าการเปลี่ยนแปลงเล็กน้อยของเราทำให้ไฟล์เสียหายเนื่องจาก "TOC" (ในแง่เทคนิค: xrefตาราง) จะไม่สามารถใช้งานได้อีกต่อไป Acrobat Reader หรือ Acrobat Professional จะยังคงเปิดมัน (โดยไม่บ่นแม้) และ "ซ่อม" ส่วน xref ของไฟล์ในใจ โปรแกรมดู PDF อื่น ๆ อาจปฏิเสธไฟล์ แต่ตอนนี้เราไม่สนใจ ...

นี่คือภาพหน้าจอของผลลัพธ์: (ภาพหน้าจอแรกถูกซูมไปที่ความกว้างของหน้าต่าง) (ภาพหน้าจอที่สองถูกซูมเป็น 800%)

โครงร่างสีแดงคือข้อความที่สแกนที่ทำให้มองเห็นได้ในขณะนี้ตามที่เราต้องการ

ข้าพเจ้าได้ปฏิบัติตามขั้นตอนที่ระบุไว้ข้างต้นสำหรับไฟล์ทั้งfrom_abbyy.pdfและafter_ghostscript.pdf ฉันเปิดทั้งสองผลลัพธ์ในสองอินสแตนซ์ที่แตกต่างกันของ Acrobat Reader [alt]+[tab]ถ้าเราทำให้พวกเขาซูมทั้งค่าเดียวกันและเพิ่มทั้งหน้าต่างแล้วมันเป็นเรื่องง่ายที่จะสลับมุมมองระหว่างทั้งสองไฟล์ผ่านทาง นี่เป็นวิธีที่ดีในการเปิดเผยความแตกต่างของการแสดงผลที่ดีที่สุดระหว่างสองไฟล์ PDF

ผลลัพธ์ของฉันคือ: ไม่มีแม้แต่พิกเซลเดียวที่แตกต่างกันระหว่างอินพุต Ghostscript (v9.02) และเอาต์พุตสำหรับไฟล์นี้ แต่มีความแตกต่างค่อนข้างมากถ้าคุณต้องการ copy'n'paste text ...

ฉันไม่เห็นปัญหาที่อธิบายไว้ ฉันเปิดไฟล์ 'after' ด้วย Acrobat Professional 9.0 และข้อความถูกคัดลอกและวางอย่างถูกต้อง

Ghostscript ตีความไฟล์ PDF ทั้งหมดและสร้างไฟล์ PDF ใหม่ตามสิ่งที่ตีความมันไม่มีความสัมพันธ์กับไฟล์ต้นฉบับอื่นนอกจากที่บันทึกไว้ตำแหน่งของข้อความ

เนื่องจากชุดคุณลักษณะที่หลากหลายของ PDF จึงเป็นไปได้ที่จะวางตำแหน่งอักขระไว้ในที่เดียวกันโดยใช้วิธีการที่หลากหลาย ดังนั้นจึงไม่มีอะไรผิดปกติหรือไม่คาดคิดต่อวิธีที่ GS กำลังสร้างไฟล์ PDF

เนื่องจากสามารถบันทึกข้อความได้อย่างถูกต้องนี่เป็นเรื่องของการวิเคราะห์พฤติกรรมของ Acrobat ที่ตัดสินใจว่าอักขระ 'ใกล้เคียง' สองตัวติดกันหรือมีช่องว่างระหว่างเมื่อจัดการเป็น ASCII ที่ต่อเนื่องกัน

ฉันไม่เชื่อว่าปัญหาอาจเป็นแบบตัวอักษรแบบฝังตัวด้วยเหตุผลง่ายๆที่แบบอักษรไม่ได้ฝังอยู่ :-) แบบอักษรที่ใช้คือ Helvetica ซึ่งไม่ได้ฝังอยู่ในเอกสารดังนั้น Acrobat (สำหรับฉันอย่างน้อย) ใช้ ArialMT โปรดทราบว่าไฟล์ PDF 'ดั้งเดิม' นั้นไม่มีแบบอักษรด้วย

ในที่สุดฉันจะดูข้อผิดพลาดที่รายงาน แต่มันจะไม่เร็วและฉันสงสัยว่ามีอะไรที่เราสามารถ (หรือจะ) ทำเกี่ยวกับเรื่องนี้ สำหรับฉันแล้วนี่เป็นผลสืบเนื่องมาจากการวิเคราะห์พฤติกรรมอย่างหลีกเลี่ยงไม่ได้ มันอาจช่วยในการฝังแบบอักษรแม้ว่าอย่างน้อยก็จะสอดคล้องกัน

จากรายงานข้อผิดพลาด Ghostscript ที่:

http://bugs.ghostscript.com/show_bug.cgi?id=692206

ตอนนี้ฉันสามารถทำซ้ำปัญหาได้แล้วและไม่ใช่การถดถอยจาก 8.71 ซึ่งเป็นความก้าวหน้า (และการเปลี่ยนแปลงของ Adobe)

8.71 มาพร้อมกับข้อบกพร่องซึ่งทำให้การเขียน ToUnicode CMaps ไม่ถูกต้อง เอกสาร Adobe ที่ทำให้เข้าใจผิดและขัดแย้งกันนำไปสู่ ​​CMap ที่เขียนเป็น CMap ซึ่งในความเป็นจริง ToUnicode CMaps มีกฎของตัวเองเข้ากันไม่ได้

ToUnicode CMaps ปกติแล้วจะใช้สำหรับการค้นหาและคัดลอก / วาง ตามชื่อหมายถึงพวกเขาจะใช้ในการแมปรหัสอักขระกับจุดโค้ด Unicode ToUnicode CMap ในไฟล์ 8.71 ไม่ได้ใช้เพราะมันไม่ถูกต้องส่วนหนึ่งในรุ่นที่ใหม่กว่านั้นถูกต้องและ Acrobat นั้นใช้งานได้

ปรากฏว่าใน Acrobat Reader จนถึงและรวมถึง 9.2 การมีอยู่ของข้อมูล ToUnicode นั้นไม่แตกต่างกัน ณ จุดหลัง 9.2 กลไกการค้นหาเปลี่ยนแปลงและ Acrobat ดูเหมือนจะใช้สองกลไกที่แตกต่างกันขึ้นอยู่กับว่ามี ToUnicode CMap ฉันไม่สามารถเข้าถึง Acrobat Pro หลังจาก 9.2 และเพิ่งติดตั้ง Reader X เมื่อเร็ว ๆ นี้ฉันไม่มีอะไรระหว่าง

วิธีการ 'ไม่มี Unicode' ทำงานบน Acrobat ทุกรุ่นวิธี 'Unicode' จะล้มเหลวในรุ่นที่ใหม่กว่า

ฉันแสดงสิ่งนี้โดยการเว้นวรรคสีขาวอ้างอิงถึง ToUnicode CMap จาก FontDescriptor หากต้องการฉันสามารถทำให้ไฟล์ต่าง ๆ พร้อมใช้งานได้ แต่มีขนาดใหญ่ตามที่แตกไฟล์

เนื่องจากการค้นหาเป็นความพยายามแบบฮิวริสติกในรูปแบบ PDF จึงไม่สามารถรับประกันผลลัพธ์ได้ การเปลี่ยนแปลงพฤติกรรมนั้นเกิดจาก Acrobat ไม่ใช่ Ghostscript และการเปลี่ยนแปลงใน Ghostscript คือการแก้ไขข้อผิดพลาดจริงดังนั้นความก้าวหน้าไม่ใช่การถดถอย

เพื่อตรวจสอบสภาพปัญหานี้เชื่อมต่อกับ 'embedded-ness' ของตัวอักษรหรือไม่ฉันได้ทำการแปลงอีกครั้งบน Linux ฉันใช้ commandline นี้เพื่อให้ Ghostscript ฝังแบบอักษรที่ใช้:

gs \
 -o after_ghostscriptonlinux.pdf \
 -sDEVICE=pdfwrite \
 -dPDFSETTINGS=/prepress \
 -sEmbedAllFonts=true \
  from_abbyy.pdf

Ghostscript จะแสดงผลลัพธ์นี้:

GPL Ghostscript SVN PRE-RELEASE 9.02 (2011-02-07)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Loading NimbusSanL-Regu font from %rom%Resource/Font/NimbusSanL-Regu... 2776276 1420923 2081124 778943 3 done.
Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 2853416 1529123 2137980 831640 3 done.
Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 2970748 1643508 2194836 886454 3 done.

Ghostscript ได้ฝังตัวอักษรจากครอบครัวตัวอักษรชื่อNimbusSanL ดังนั้นไม่มีArialMTอีกต่อไปเช่นเดียวกับที่ใช้สำหรับการแสดงผลบนหน้าจอโดย Acrobat Reader เพื่อทดแทน Helvetica ที่หายไป (ดูความคิดเห็นของผู้ใช้ 701996 ด้านบน) โปรดทราบว่า Ghostscript จะเปลี่ยนชื่อแบบอักษรนั้นเป็น Helvetica ทันทีที่ฝังตัว แต่นั่นไม่ใช่ปัญหาเพราะ NimbusSanL ถูกสร้างขึ้นเป็นโคลนของ Helvetica ...

อย่างไรก็ตามถึงแม้จะเป็น PDF เอาท์พุทนี้ copy'n'paste จาก Acrobat Reader ก็ใช้งานไม่ได้ แม้ว่าที่จริงแล้ว Reader จะไม่ต้องการใช้ ArialMT แทน Helvetica ก็ตาม Reader ตอนนี้ใช้ NimbusSanL / Helvetica-clone ที่ฝังอยู่

จนถึงตอนนี้เราได้สร้างข้อเท็จจริงเหล่านี้เกี่ยวกับ copy'n'pasting text จาก Acrobat Reader หรือ Acrobat Professional:

• เอาต์พุตของ Ghostscript v9.02 ทำงานได้ไม่ดีพอสำหรับไฟล์นี้
• ในกรณีนี้ไม่ว่าแบบอักษรจะถูกฝังโดย GS หรือไม่ก็ตาม

• นี่เป็นกรณีสำหรับ GS บน Windows XP และ GS บน Linux

• เอาต์พุตของ Ghostscript v8.71 ทำงานได้ดีพอสำหรับไฟล์นี้

• ในกรณีนี้ไม่ว่าแบบอักษรจะถูกฝังโดย GS หรือไม่ก็ตาม

• นี่เป็นกรณีสำหรับ GS บน Windows XP และ GS บน Linux

• แม้สำหรับการส่งออกที่ copy'n'paste เสียบันทึกเป็นข้อความ ...ไม่

ฉันยังไม่เข้าใจว่าทำไมจึงเป็นเช่นนี้ แต่ดูเหมือนว่าการถดถอยของ Ghostscript (อาจเล็กน้อย) เรียงจาก v8.71 ถึง 9.02

ตอนนี้เรามาลองซอฟต์แวร์ตัวดู PDF อื่น ๆ กับไฟล์ PDF 'วิกฤติ':

• Adobe Reader X ข้างใน Wine บน Linux: copy'n'paste เป็น b0rken ในแบบเดียวกับ v9.4.4
• Evince v2.32.2 บน Linux: copy'n'paste ใช้งานได้
• PDFXChange Viewer 2.5 (สร้าง 191) บน Windows XP Prof: copy'n'paste ทำงานได้
• MuPDF reader 0.8 บน Linux: ไม่ทราบวิธีการ copy'n'paste - แต่ 'search' ทำงานได้อย่างไร้ที่ติ
• พบ s.th เรียกว่า "PDF Viewer 0.1.7" บน Linux: copy'n'paste ใช้งานได้
• SumatraPDF v1.5 ใน Wine บน Linux: copy'n'paste ใช้งานได้
• SumatraPDF v1.5.1 บน Windows XP: งาน copy'n'paste
• FoxitReader 4.3.1.0113 บน Windows XP: งาน copy'n'paste
• Nitro PDF Reader ใน Wine บน Linux: copy'n'paste ทำงานได้

หมายเหตุยังมีอื่น ๆ แต่ความแตกต่างน้อยมากระหว่างทั้ง 'ทำงาน' ผู้อ่านไฟล์ PDF ที่คำตัดสินของฉันคืองาน copy'n'paste เช่นเส้นประหายไปที่นี่หรือมีช่องว่างสองเท่าในระหว่างคำที่มีและสิ่งอื่น ๆ ... ฉันยังไม่มีคำอธิบายว่าทำไมตอนนี้อาจเป็นเช่นนี้ แต่อาจเป็นสาเหตุเดียวกันที่ทำให้เกิดช่องว่างขนาดใหญ่ระหว่างผลิตภัณฑ์ Adobe (ซึ่งไม่มี copy'n'paste ที่ใช้งานได้สำหรับไฟล์นี้) อันที่หนึ่งมีและ "ส่วนที่เหลือของโลก" ที่อีกอันหนึ่ง