PDF σε Markdown και DOCX στο Delphi με PDFlibPas

Το PDFlibPas μετατρέπει περιεχόμενο PDF σε δύο επεξεργάσιμες μορφές χωρίς αυτοματισμό Office. Οι ExportPageMarkdown και ExportDocumentMarkdown επιστρέφουν σημασιολογικό Markdown με συναγόμενες επικεφαλίδες, ταξινομημένες και μη λίστες και πίνακες με pipes, ενώ οι SaveDOCXToFile και SaveDOCXToStream γράφουν ένα πακέτο WordprocessingML που περιέχει παραγράφους, επικεφαλίδες, εγγενή αρίθμηση λίστας, εντοπισμένους πίνακες, στυλ γραμματοσειράς, αλλαγές σελίδας και τοποθετημένες εικόνες PNG

Και οι δύο τρέχουν εξ ολοκλήρου σε Pascal, σε server, χωρίς εγκατεστημένο Word και χωρίς COM. Αυτός ο περιορισμός είναι ο λόγος που το χαρακτηριστικό υπάρχει σε μια βιβλιοθήκη PDF και όχι σε ένα εργαλείο desktop

Γιατί είναι πραγματικά δύσκολο το "PDF σε Word";

Επειδή μια σελίδα PDF δεν περιέχει παραγράφους. Περιέχει τελεστές εμφάνισης κειμένου που τοποθετούν runs γλυφών σε συντεταγμένες, με όποια σειρά τα εξέπεμψε ο παραγωγός, χωρίς καμία υποχρέωση να υποδείξει ότι δύο runs ανήκουν στην ίδια πρόταση, πόσο μάλλον στο ίδιο στοιχείο λίστας. Η μορφή σχεδιάστηκε για να περιγράφει ακριβώς μια τυπωμένη σελίδα και το επιτυγχάνει απορρίπτοντας τη δομή που παρήγαγε τη σελίδα

Έτσι κάθε converter πρέπει να ανακατασκευάσει ό,τι πέταξε η γεννήτρια. Η ομαδοποίηση γραμμών προέρχεται από κατακόρυφη απόσταση και ευθυγράμμιση baseline. Τα όρια παραγράφου προέρχονται από αλλαγές απόστασης και εσοχή. Μια επικεφαλίδα είναι μια γραμμή της οποίας η γραμματοσειρά είναι μεγαλύτερη ή βαρύτερη από το κύριο κείμενο και ξεχωρίζει από ό,τι ακολουθεί. Μια λίστα είναι μια σειρά παραγράφων που ξεκινούν με χαρακτήρα bullet ή μοτίβο αρίθμησης. Ένας πίνακας είναι ένα πλέγμα μπλοκ κειμένου των οποίων οι άκρες ευθυγραμμίζονται σε γραμμές και στήλες. Καθένα από αυτά είναι μια συναγωγή, και συναγωγή σημαίνει καλό αποτέλεσμα σε έγγραφα που ακολουθούν συνηθισμένες τυπογραφικές συμβάσεις και μέτριο σε έγγραφα που δεν το κάνουν

Τα tagged PDF είναι η εξαίρεση, και μια μεγάλη. Όταν το έγγραφο φέρει ένα δέντρο δομής, οι ρόλοι παραγράφου, επικεφαλίδας, λίστας και πίνακα καταγράφονται αντί να εικάζονται, γι' αυτό η δουλειά προσβασιμότητας που περιγράφεται στο δομή προσβασιμότητας tagged PDF αποδίδει και στην ποιότητα μετατροπής. Αν ελέγχετε τον παραγωγό, η επισήμανση tagging της εξόδου σας είναι το πράγμα με τη μεγαλύτερη μόχλευση που μπορείτε να κάνετε για όποιον αργότερα θα τη μετατρέψει

Εξαγωγή Markdown, μία σελίδα τη φορά

Η διαδρομή Markdown είναι αυτή που επιλέγετε όταν ο προορισμός είναι ένα pipeline κειμένου: ένας ιστότοπος τεκμηρίωσης, ένα ευρετήριο αναζήτησης, ένα corpus ανάκτησης για έναν βοηθό. Οι επιλογές είναι μια μάσκα bit: PDF_MARKDOWN_INCLUDE_PAGE_MARKERS, PDF_MARKDOWN_DETECT_HEADINGS, PDF_MARKDOWN_PRESERVE_STYLES, με το PDF_MARKDOWN_DEFAULT να συνδυάζει και τα τρία

var
  Pdf: TPDFlib;
  Md: WideString;
begin
  Pdf := TPDFlib.Create;
  try
    Pdf.LoadFromFile('handbook.pdf', '');

    // Μία σελίδα, ως string
    Md := Pdf.ExportPageMarkdown(1, PDF_MARKDOWN_DEFAULT);

    // Ένα εύρος σελίδων, streamed στον δίσκο ως UTF-8 χωρίς BOM
    Pdf.SaveMarkdownToFile('1-40',
      PDF_MARKDOWN_DETECT_HEADINGS or PDF_MARKDOWN_PRESERVE_STYLES,
      'handbook.md');
  finally
    Pdf.Free;
  end;
end;

Οι page markers αποδίδουν στη δουλειά ανάκτησης. Ένα κομμάτι κειμένου που φέρει τη σελίδα από την οποία προήλθε μπορεί να παρατεθεί με ακρίβεια, και ένας αναγνώστης που ακολουθεί την παραπομπή προσγειώνεται εκεί όπου βρίσκεται πράγματι ο ισχυρισμός. Απενεργοποιήστε τους όταν το Markdown προορίζεται για ανθρώπινη ανάγνωση, όπου τα όρια σελίδας από την αρχική διάταξη είναι θόρυβος

Τα σημεία εισόδου streaming μετράνε για μεγάλα έγγραφα. Οι SaveMarkdownToStream και SaveMarkdownToFile γράφουν UTF-8 μία σελίδα τη φορά και δεν κάνουν buffer ολόκληρη την έξοδο, οπότε ένα εγχειρίδιο 900 σελίδων δεν γίνεται πρώτα ένα string 900 σελίδων στη μνήμη. Η απουσία byte-order mark είναι επίσης σκόπιμη: ένα BOM σε αρχείο Markdown μπερδεύει έναν εκπληκτικό αριθμό static site generators και εργαλείων diff

DOCX χωρίς εγκατεστημένο Office

Ο DOCX writer παράγει το ίδιο το πακέτο: εγγραφές ZIP γραμμένες ως ακατέργαστο Deflate με ελέγχους CRC, τα μέρη WordprocessingML, και τις σχέσεις που τα δεσμεύουν. Τίποτα δεν καλεί το Word, κάτι που σημαίνει ότι η μετατροπή τρέχει σε headless server, μέσα σε λογαριασμό υπηρεσίας, σε container, σε όλα τα σημεία όπου ο αυτοματισμός Office είναι είτε χωρίς άδεια, ασταθής ή απαγορευμένος

var
  Pdf: TPDFlib;
  Target: TFileStream;
begin
  Pdf := TPDFlib.Create;
  Target := TFileStream.Create('handbook.docx', fmCreate);
  try
    Pdf.LoadFromFile('handbook.pdf', '');
    Pdf.SaveDOCXToStream('1-40',
      PDF_DOCX_INCLUDE_IMAGES or PDF_DOCX_DETECT_HEADINGS or
      PDF_DOCX_PRESERVE_STYLES or PDF_DOCX_PRESERVE_PAGE_BREAKS,
      Target);
  finally
    Target.Free;
    Pdf.Free;
  end;
end;

Τα δεδομένα εικόνας γράφονται καθώς επεξεργάζεται κάθε σελίδα αντί να συλλέγονται και να προσαρτώνται στο τέλος, οπότε η κορυφή χρήσης μνήμης ακολουθεί μία σελίδα και όχι ολόκληρο το έγγραφο. Η ρητή σειρά σελίδων διατηρείται, και η επιλεγμένη σελίδα PDF επαναφέρεται στη συνέχεια, κάτι που έχει σημασία όταν η εξαγωγή είναι ένα βήμα μέσα σε μια μεγαλύτερη εργασία που είχε επιλεγμένη σελίδα για άλλους λόγους

Τι σας προσφέρει η ντετερμινιστική συσκευασία;

Αναπαραγωγιμότητα byte προς byte. Δύο μετατροπές της ίδιας εισόδου με τις ίδιες επιλογές παράγουν το ίδιο πακέτο, κάτι που σημαίνει ότι μπορείτε να κάνετε hash στην έξοδο για να εντοπίσετε αλλαγή, να συγκρίνετε δύο εκδόσεις ενός παραγόμενου εγγράφου, και να κάνετε cache επιθετικά χωρίς να ανησυχείτε ότι μια πανομοιότυπη είσοδος παρήγαγε διαφορετικό artefact

Ο αυτοματισμός Office δεν μπορεί να το υποσχεθεί αυτό. Ενσωματώνει χρονοσφραγίδες, αναγνωριστικά αναθεώρησης και μεταδεδομένα εξαρτώμενα από τη μηχανή, οπότε το ίδιο έγγραφο μετατρεπόμενο δύο φορές διαφέρει με τρόπους που ματαιώνουν το hashing. Η ίδια λογική οδηγεί τα ντετερμινιστικά αναγνωριστικά αρχείου που συζητούνται στο ντετερμινιστικά PDF ID για αναπαραγώγιμες εκδόσεις: όταν η έξοδος είναι αναπαραγώγιμη, η επαλήθευση γίνεται σύγκριση αντί για επιθεώρηση

Πού είναι καλή η έξοδος, και πού όχι

Να είστε ειλικρινείς με τους χρήστες σας για αυτό, επειδή η ποιότητα μετατροπής ποικίλλει περισσότερο με την είσοδο παρά με τον converter. Tagged PDF και επιχειρηματικά έγγραφα δημιουργημένα καθαρά, τιμολόγια, αναφορές, συμβόλαια, μετατρέπονται καλά: οι επικεφαλίδες προσγειώνονται ως επικεφαλίδες, οι πίνακες επιβιώνουν, οι λίστες αριθμούνται σωστά ξανά στο Word. Ακαδημαϊκές διατάξεις δύο στηλών μετατρέπονται αποδεκτά αν η γεωμετρία στηλών είναι κανονική. Πίνακες που εκτείνονται πέρα από αλλαγές σελίδας ανασυντίθενται μέσω συναγωγής και μερικές φορές διασπώνται. Έντονα σχεδιασμένο διαφημιστικό υλικό, όπου το κείμενο τοποθετείται για οπτικό εφέ και όχι σε σειρά ανάγνωσης, μετατρέπεται άσχημα, και καμία ποσότητα συναγωγής δεν το διορθώνει

Τα σαρωμένα έγγραφα είναι μια εντελώς ξεχωριστή περίπτωση. Μια σελίδα που είναι μία μεγάλη εικόνα δεν περιέχει αντικείμενα κειμένου, οπότε δεν υπάρχει τίποτα προς εξαγωγή μέχρι να υπάρξει ένα text layer· η διαδρομή OCR που το παράγει είναι προαπαιτούμενο, όχι επιλογή. Πριν τρέξετε μια μεγάλη παρτίδα, δειγματίστε μια δωδεκάδα αντιπροσωπευτικών αρχείων και δείτε την έξοδο, και εξετάστε την απαρίθμηση στοιχείων σελίδας πρώτα, όπως περιγράφεται στο αναζήτηση κειμένου και απαρίθμηση στοιχείων σελίδας, για να δείτε τι πράγματι περιέχουν οι σελίδες

Για pipelines βοηθού και ανάκτησης η διαδρομή Markdown είναι συνήθως ο καλύτερος στόχος: οι επικεφαλίδες γίνονται όρια κομματιού, οι πίνακες παραμένουν ευανάγνωστοι ως πίνακες pipe, και οι page markers δίνουν σε κάθε κομμάτι μια παραθέσιμη θέση. Για ανθρώπινη επεξεργασία, το DOCX είναι η απάντηση, επειδή αυτό που θέλει ο χρήστης δεν είναι το κείμενο αλλά η δυνατότητα να το αλλάξει

Το PDFlibPas είναι μια βιβλιοθήκη PDF για Delphi, C++Builder και Lazarus με αντίστοιχα interfaces DLL και ActiveX, οπότε οι ίδιες κλήσεις εξαγωγής είναι διαθέσιμες από C#, C++ ή scripting hosts. Πλήρης τεκμηρίωση και δοκιμαστική έκδοση βρίσκονται στη σελίδα του PDFlibPas Delphi PDF library