PDF có thêm một khoảng trống trong tất cả các từ sau khi chạy qua Ghostscript


10

Bản PDF này được sản xuất bởi Abbyy Finereader 10:

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

Bạn có thể sao chép và dán câu đầu tiên và nhận kết quả văn bản (rất tốt) này:

Der »Bund Deutscher Gymnastik-Schulleiter« wurde am 20. Tháng 11 năm 1955 anläßlich einer Zusammenkunft der Leiterinnen und Leiter der privateaten deutschen Gymnastik-Ausbildungsstätten gegründet.

Sau khi xử lý với Ghostscript 9.02 (Windows 64 bit), tôi nhận được tệp này:

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

Bây giờ câu đầu tiên có vẻ lạ - có thêm khoảng trắng trước ký tự cuối cùng của mỗi từ.

Der »Bun d Deutsche r GymnastikSchulleiter« wurd eam 20. Novembe r 195 5 anläßlic h eine r Zusammenkunf t der Leiterinne n un d Leite r de r private n deutsche n GymnastikAusbildungsstätte n gegründet.

Điều này có tác động tiêu cực chính mà bạn không thể tìm kiếm toàn bộ từ trong Acrobat Reader. Tôi có thể tái tạo hiệu ứng với bộ tham số tối thiểu sau đây cho Ghostscript:

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

Có ý kiến ​​gì không?


@Erwin Jurschitza: bạn có muốn theo kịp liên kết của tập tin from_abbyy.pdf của bạn trong một thời gian, vì vậy nó có thể được truy xuất ngay cả sau một vài tháng không?
Kurt Pfeifle

@pipitas: Không vấn đề gì, đó là trên Amazon S3.

Câu trả lời:


8

Tôi thấy đây là một vấn đề thú vị và đã xem xét kỹ hơn ...

Đầu tiên, tôi đã sử dụng qpdfcông cụ dòng lệnh để giải nén các luồng dữ liệu PDF để tôi có thể thấy rõ hơn các mã nguồn của cả hai tệp:

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

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

Nhìn vào một trong những lần xuất hiện đầu tiên có thêm một khoảng trống (đó là chuỗi gốc "Bund Deutscher Gymnastik-Schulleiter" biến thành "Bun d Deutsche r GymnastikSchulleiter" ), tôi tìm thấy các đoạn PDF sau:

Trong 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

Trong 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

Để cho bạn biết một chút về các toán tử đồ họa PDF được sử dụng ở đây có nghĩa là gì, đây là một danh sách ngắn:

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

Như bạn có thể thấy, Ghostscript đã thay thế toán tử Tm( ma trận văn bản ) ban đầu bằng một Td( di chuyển điểm hiện tại văn bản ) và nó cũng đã thêm một 2.16501 0 Td... Tôi không biết tại sao lại như vậy. Tôi sẽ gửi báo cáo lỗi cho bugzilla của Ghostscript [*] và xem họ có quan tâm đến việc giải quyết nó không.

Tuy nhiên, xin lưu ý rằng vấn đề này không xảy ra, nếu tôi sử dụng Linux Acrobat Reader 9.4.2 và sử dụng hành động menu "Tệp -> Lưu dưới dạng văn bản ..." . Trong trường hợp này, không có khoảng trắng bổ sung (nhưng một vài ngắt dòng bổ sung). Trên Linux cũng vậy, văn bản không thể tìm kiếm chính xác và cũng hiển thị các khoảng trắng thừa khi thực hiện copy'n'paste ....


[*] Tôi sẽ cập nhật ở đây với số lỗi khi tôi thực hiện.


Cập nhật:

Sau khi suy nghĩ thêm một chút về Tmtoán tử thay thế , bây giờ tôi nghĩ rằng đây không phải là gốc rễ của vấn đề.

Khi nhận ra điều đó, tôi đã cố gắng thực hiện chuyển đổi với Ghostscript v8.71 thay vì v9.02. Và tôi nên nói gì? Vấn đề sao chép không xảy ra với đầu ra v8.71!

Điều đó có nghĩa là: có một vấn đề trong Ghostscript 9.02 không có ở 8.71. Nhiều khả năng nó phải làm với các số liệu phông chữ được nhúng trong tệp PDF đầu ra. Bởi vì các đoạn PDF được trích dẫn ở trên giống với đầu ra v8.71 như trong đầu ra v9.02 ....

Cập nhật 2:

URL của mục nhập lỗi trong bugzilla của Ghostscript:

Cập nhật 3:

Lỗi này dường như đã được sửa trong khi đó. Tôi không thấy điều đó xảy ra với các phiên bản Ghostscript tôi đã thử nghiệm lại với: Git hiện tại (v9.10GIT) cũng như với Ghostscript v9.06.


@pipitas: Cảm ơn bạn rất nhiều vì đã phân tích điều này!

5

Nếu bạn quét một trang có văn bản thành PDF và chạy ứng dụng OCR trên đó, thì văn bản sẽ được thêm vào trang, nhưng "chế độ hiển thị văn bản" được đặt thành ẩn. Nó ở đó, nhưng nó không được hiển thị trên màn hình (hoặc trên giấy nếu được in). Những gì bạn nhìn thấy hoặc in là hình ảnh quét ban đầu.

Làm thế nào chúng ta có thể làm cho văn bản vô hình có thể nhìn thấy?

Chà, chúng ta có thể chỉnh sửa PDF ... Mã PDF để đặt hiển thị văn bản thành vô hình là đây:

3 Tr

Bạn không thể tìm thấy chuỗi này (chưa) trong bản gốc from_abbyy.pdf cũng như trong from_ghostscript.pdf vì các phần của tệp PDF được nén. Vì vậy, chúng tôi giải nén chúng càng nhiều càng tốt với sự giúp đỡ của qpdf:

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

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

Bây giờ chúng ta có thể tìm thấy chuỗi trên một cách dễ dàng (và chỉ có một lần xuất hiện trong mỗi tệp).

Chúng ta hãy chuyển nó sang một trong các chế độ hiển thị văn bản. Nhìn chung, chúng ta có thể chọn trong số 8 chế độ hiển thị văn bản này:

 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

Nếu tôi sử dụng chế độ "điền", văn bản từ OCR có thể sẽ trông không được tốt cho lắm trên hình ảnh quét bên dưới. Vì vậy, tôi thích các biến thể "đột quỵ". Vì vậy, tôi chỉ cần thay đổi dòng trên để đọc

 1 Tr

Nhìn vào bản PDF đã sửa đổi này, tôi không thích nó, vì băng thông mặc định quá dày so với sở thích của tôi. Ngoài ra, màu của nét phác thảo là màu đen (mặc định); Tôi thích màu đỏ hơn để có độ tương phản với hình dạng được quét ban đầu. Do đó, tôi thêm một số mã vào phía trước của dòng này để đặt băng thông thành một phần tư điểm:

 .25 w

và một số khác để đặt màu Stroke thành màu đỏ:

 1 0 0 RG

Dòng hoàn chỉnh bây giờ là:

 .25 w 1 0 0 RG 1 Tr

Đó là tất cả.

Lưu ý rằng thao tác nhỏ của chúng tôi đã làm hỏng tệp, vì "TOC" (theo thuật ngữ kỹ thuật: xrefbảng của nó ) sẽ không còn hiệu lực. Acrobat Reader hoặc Acrobat Professional vẫn sẽ mở nó (thậm chí không phàn nàn) và âm thầm "sửa chữa" phần xref của tệp. Những người xem PDF khác có thể từ chối tệp, nhưng hiện tại chúng tôi không quan tâm ...

Dưới đây là ảnh chụp màn hình của kết quả: phóng to chiều rộng cửa sổ (Ảnh chụp màn hình đầu tiên được phóng to theo chiều rộng cửa sổ.) phóng to tới 800% (Ảnh chụp màn hình thứ hai được phóng to lên 800%.)

Các đường viền màu đỏ là văn bản được quét hiện rõ, giống như chúng ta muốn.

Tôi đã tiến hành quy trình tương tự như đã nêu ở trên cho cả hai tệp from_abbyy.pdfafter_ghostscript.pdf . Tôi đã mở cả hai kết quả trong 2 trường hợp khác nhau của Acrobat Reader. Nếu chúng ta làm cho cả hai thu phóng đến cùng một giá trị và tối đa hóa cả hai cửa sổ, thì có thể dễ dàng chuyển đổi chế độ xem giữa cả hai tệp qua [alt]+[tab]. Đây là một cách tốt để tiết lộ ngay cả sự khác biệt kết xuất tốt nhất giữa hai tệp PDF.

Kết quả của tôi là: thậm chí không có một pixel nào khác nhau giữa đầu vào của Ghostscript (v9.02) và đầu ra của nó cho tệp này. Nhưng có một sự khác biệt nếu bạn muốn sao chép văn bản ...


1

Tôi không thấy vấn đề được mô tả. Tôi đã mở tệp PDF 'sau' với Acrobat Professional 9.0 và văn bản được sao chép và dán chính xác.

Ghostscript diễn giải đầy đủ tệp PDF và tạo một tệp PDF mới dựa trên những gì nó diễn giải, nó không có mối quan hệ nào với tệp gốc ngoài việc nó ghi lại vị trí của văn bản.

Do bộ tính năng phong phú của PDF, có thể đặt các ký tự ở cùng một vị trí bằng nhiều phương pháp khác nhau. Vì vậy, không có gì sai hoặc bất ngờ theo cách mà GS đang sản xuất tệp PDF.

Cho rằng văn bản có thể được lưu chính xác, đây là vấn đề của các phép thuật Acrobat quyết định xem hai ký tự 'lân cận' có liền kề nhau hay không có khoảng cách giữa, khi được xử lý như ASCII liên tiếp.

Tôi không tin rằng vấn đề có thể là số liệu phông chữ được nhúng vì lý do đơn giản là phông chữ không được nhúng :-) Phông chữ đang được sử dụng là Helvetica, không được nhúng trong tài liệu và vì vậy Acrobat (ít nhất là đối với tôi) sử dụng ArialMT. Lưu ý rằng tệp PDF 'gốc' cũng không chứa phông chữ.

Cuối cùng tôi sẽ xem xét lỗi được báo cáo, nhưng nó sẽ không sớm và tôi nghi ngờ có bất cứ điều gì chúng ta có thể (hoặc sẽ) làm về nó. Dường như với tôi đây là một hậu quả không thể tránh khỏi của heuristic. Nó có thể giúp nhúng các phông chữ, mặc dù vậy, ít nhất chúng sẽ nhất quán.


@ user701996: Thú vị - không có vấn đề gì với Acrobat Pro 9.0? Acrobat Reader X của tôi (10.0.1, Windows) có vấn đề.

@ user701996: Tôi đã mở tệp trong Acrobat Professional 9.4.4. Copy'n'paste của sau khi làm việc -file không. Lưu dưới dạng văn bản ... tuy nhiên không hoạt động ....
Kurt Pfeifle

@ user701996: Ngay cả khi phông chữ không được nhúng, số liệu phông chữ . Hmmm, trừ khi phông chữ là một trong 'Base 14' .... Vì vậy, bạn có thể đúng trong trường hợp này. Tôi sẽ xem xét kỹ hơn.
Kurt Pfeifle

@ user701996: Bạn có vẻ như bạn là một trong những người Ghostscript. Bạn có phải?
Kurt Pfeifle

1

Từ báo cáo lỗi Ghostscript tại:

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


Bây giờ tôi đã có thể tái tạo vấn đề và nó không phải là hồi quy từ 8.71, đây là một sự tiến triển (và thay đổi Adobe).

8.71 xuất hiện với một lỗi khiến nó viết các CMU ToUnicode không hợp lệ. Tài liệu Adobe sai lệch và mâu thuẫn đã dẫn đến CMap được viết dưới dạng CMap, trong khi trên thực tế CMU ToUnicode có các quy tắc riêng, không tương thích.

CMU ToUnicode thường chỉ được sử dụng để tìm kiếm và sao chép / dán. Như tên ngụ ý, chúng được sử dụng để ánh xạ mã ký tự thành các điểm mã Unicode. CMU ToUnicode trong tệp PDF 8.71 không được sử dụng, vì nó không hợp lệ, phiên bản sau này là hợp lệ và Acrobat được biết là sử dụng nó.

Dường như trong Acrobat Reader lên đến và bao gồm 9,2 sự tồn tại của dữ liệu ToUnicode không tạo ra sự khác biệt. Tại một số điểm sau 9.2, cơ chế tìm kiếm đã thay đổi và Acrobat dường như sử dụng hai cơ chế khác nhau tùy thuộc vào việc có Toapnicode CMap hay không. Tôi không có quyền truy cập vào Acrobat Pro sau 9.2 và chỉ mới cài đặt Reader X, tôi không có gì giữa.

Phương pháp 'không Unicode' hoạt động trên tất cả các phiên bản Acrobat, phương pháp 'Unicode' không thành công trên các phiên bản mới hơn.

Tôi đã chỉ ra điều này bằng cách đặt khoảng trắng cho tham chiếu tới CMU ToUnicode từ FontDescriptor. Nếu được yêu cầu tôi có thể làm cho các tệp khác nhau có sẵn, nhưng chúng lớn khi chúng được giải nén.

Vì tìm kiếm là một nỗ lực heuristic trong PDF, nó sẽ không thể đảm bảo kết quả. Sự thay đổi trong hành vi là do Acrobat chứ không phải Ghostscript và thay đổi trong Ghostscript là để sửa một lỗi thực sự, do đó, một sự tiến triển, không phải là hồi quy.


0

Để kiểm tra xem vấn đề này có được kết nối với 'nhúng' của phông chữ hay không, tôi đã thực hiện một chuyển đổi khác, trên Linux. Tôi đã sử dụng dòng lệnh này để Ghostscript nhúng các phông chữ được sử dụng:

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

Ghostscript sẽ hiển thị đầu ra này:

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 đã nhúng các phông chữ từ một họ phông chữ có tên NimbusSanL . Vì vậy, không còn ArialMT , như được Acrobat Reader sử dụng để kết xuất trên màn hình để thay thế cho Helvetica bị thiếu (xem thêm bình luận của user701996 ở trên). Lưu ý, Ghostscript sẽ đổi tên phông chữ đó thành Helvetica ngay khi được nhúng. Nhưng đó không phải là vấn đề, bởi vì NimbusSanL được tạo ra như một bản sao của Helvetica ...

Tuy nhiên, ngay cả đối với bản PDF đầu ra này, copy'n'paste từ Acrobat Reader sẽ không hoạt động tốt. Mặc dù thực tế là Reader không còn cần phải sử dụng ArialMT để thay thế Helvetica. Trình đọc hiện sử dụng bản sao NimbusSanL / Helvetica được nhúng.

Cho đến nay, chúng tôi đã thiết lập những sự thật về văn bản sao chép từ Acrobat Reader hoặc Acrobat Professional:

  • Đầu ra của Ghostscript v9.02 không hoạt động đủ tốt cho tệp này.
  • Đó là trường hợp cho dù phông chữ được nhúng bởi GS hay không.
  • Đó là trường hợp của GS trên Windows XP cũng như GS trên Linux.

  • Đầu ra của Ghostscript v8.71 DOES hoạt động đủ tốt cho tệp này.

  • Đó là trường hợp cho dù phông chữ được nhúng bởi GS hay không.
  • Đó là trường hợp của GS trên Windows XP cũng như GS trên Linux.

  • Ngay cả đối với đầu ra nơi copy'n'paste bị hỏng, Save as văn bản ... không.

Tôi vẫn không hiểu tại sao điều này nên xảy ra. Nhưng rõ ràng nó trông giống như một số hồi quy (có thể là nhỏ) của Ghostscript trên đường từ v8.71 đến 9.02.

Bây giờ, hãy thử phần mềm xem PDF khác với các tệp PDF 'quan trọng':

  • Adobe Reader X bên trong Wine trên Linux: copy'n'paste là b0rken giống như với v9.4.4.
  • Evince v2.32.2 trên Linux: copy'n'paste hoạt động.
  • PDFXChange Viewer 2.5 (bản dựng 191) trên Windows XP Prof: copy'n'paste hoạt động.
  • Trình đọc MuPDF 0.8 trên Linux: không biết cách sao chép - nhưng 'tìm kiếm' hoạt động hoàn hảo.
  • Tìm thấy s.th. được gọi là "Trình xem PDF 0.1.7" trên Linux: copy'n'paste hoạt động.
  • SumatraPDF v1.5 bên trong Wine trên Linux: copy'n'paste hoạt động.
  • SumatraPDF v1.5.1 trên Windows XP: copy'n'paste hoạt động.
  • FoxitReader 4.3.1.0113 trên Windows XP: copy'n'paste hoạt động.
  • Nitro PDF Reader bên trong Wine trên Linux: copy'n'paste hoạt động.

Lưu ý, vẫn còn những khác biệt khác, nhưng rất nhỏ giữa tất cả các trình đọc PDF 'đang hoạt động' trong đó bản án của tôi là bản sao . Chẳng hạn như dấu gạch ngang bị thiếu ở đây hoặc một số khoảng trắng được nhân đôi giữa các từ ở đó và những thứ khác ... Tôi hiện không có lời giải thích tại sao điều này có thể xảy ra, nhưng có lẽ đó là nguyên nhân gốc rễ tại sao có khoảng cách lớn giữa các sản phẩm Adobe (không có bản sao hoạt động cho tập tin này) một trong những người đã từng và "phần còn lại của thế giới" ở bên kia.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.