In PDF-file in Font internal encryption point to dictionary without Type item, therefore encryption treated not like encryption but just like PDFObject and as result text incorrectly decoded (because both BaseEncoding item and differences array item ignored).

This PR fixes it.

Also has been deleted unnecessary unicode string decode test for file with WinAnsiEncoding text encoding.

Also deleted for $unicode passed by reference parameters in Font class because seems that it have no sense (not sure).

Potentially this PR can fix some of the many other opened issues related to incorrect result text encoding.

Alternative Autoloader built in

Since v0.18.2 you don't need to do the following steps to use PDFParser without Composer. Please check https://github.com/smalot/pdfparser#install for further information on our alternative autoloader.

:exclamation: Outdated

Last checked in 2020

Updated file: vendor-autoload.zip - See https://github.com/smalot/pdfparser/issues/117#issuecomment-673408008

The ../vendor/autoload.php gets generated when we use composer and we include it in our scripts for PdfParser access. If we wish to freeze our install and manage it without using Composer, this said file can be created to have the following:

<?php
/**
 * this file acts as vendor/autoload.php
 */

/*
Using PDFParser without Composer
Folder structure
================
webroot
  pdfdemos
    INV001.pdf # test PDF file to extract text from for demo
    test.php # our operational demo file
  vendor
    autoload.php
    smalot
      pdfparser # unpack from git master https://github.com/smalot/pdfparser/archive/master.zip release is 0.9.25 dated 2015-09-15
        docs # optional
        samples # optional
        src
          Smalot
            PdfParser
*/

$prerequisites = array();

/**
 * TODO: ADAPT THIS PATH TO pdfparser
 */ 
$pdfparser = '/host/path/to/pdfparser';

$prerequisites['pdfparser'] = array (
    $pdfparser.'/Config.php',
    $pdfparser.'/Parser.php',
    $pdfparser.'/Document.php',
    $pdfparser.'/Header.php',
    $pdfparser.'/PDFObject.php',
    $pdfparser.'/Element.php',
    $pdfparser.'/Encoding.php',
    $pdfparser.'/Font.php',
    $pdfparser.'/Page.php',
    $pdfparser.'/Pages.php',
    $pdfparser.'/Element/ElementArray.php',
    $pdfparser.'/Element/ElementBoolean.php',
    $pdfparser.'/Element/ElementString.php',
    $pdfparser.'/Element/ElementDate.php',
    $pdfparser.'/Element/ElementHexa.php',
    $pdfparser.'/Element/ElementMissing.php',
    $pdfparser.'/Element/ElementName.php',
    $pdfparser.'/Element/ElementNull.php',
    $pdfparser.'/Element/ElementNumeric.php',
    $pdfparser.'/Element/ElementStruct.php',
    $pdfparser.'/Element/ElementXRef.php',
    $pdfparser.'/Encoding/StandardEncoding.php',
    $pdfparser.'/Encoding/ISOLatin1Encoding.php',
    $pdfparser.'/Encoding/ISOLatin9Encoding.php',
    $pdfparser.'/Encoding/MacRomanEncoding.php',
    $pdfparser.'/Encoding/WinAnsiEncoding.php',
    $pdfparser.'/Font/FontCIDFontType0.php',
    $pdfparser.'/Font/FontCIDFontType2.php',
    $pdfparser.'/Font/FontTrueType.php',
    $pdfparser.'/Font/FontType0.php',
    $pdfparser.'/Font/FontType1.php',
    $pdfparser.'/RawData/FilterHelper.php',
    $pdfparser.'/RawData/RawDataParser.php',
    $pdfparser.'/XObject/Form.php',
    $pdfparser.'/XObject/Image.php'
);

foreach($prerequisites as $project => $includes) {
    foreach($includes as $mapping => $file) {
      require_once $file;
    }
}

/*
// Information for comparison with composer
use Datamatrix;
use PDF417;
use QRcode;
use TCPDF;
use TCPDF2DBarcode;
use TCPDFBarcode;
use TCPDF_COLORS;
use TCPDF_FILTERS;
use TCPDF_FONTS;
use TCPDF_FONT_DATA;
use TCPDF_IMAGES;
use TCPDF_IMPORT;
use TCPDF_PARSER;
use TCPDF_STATIC;
*/

We can now create a test.php in the deployment folder (pdfdemos here) with:

<?php
include "../vendor/autoload.php";

$directory = getcwd();
$file = 'INV001.pdf';
$fullfile = $directory . '/' . $file;
$content = '';
$out = '';
$parser = new \Smalot\PdfParser\Parser();

$document = $parser->parseFile($fullfile);
$pages    = $document->getPages();
$page     = $pages[0];
$content  = $page->getText();
$out      = $content;
echo '<pre>' . $out . '</pre>';

EDIT 1 by k00ni: added updated PHP code from @ndmax. Also removed tecnickcom/tcpdf (not needed anymore) and added code highlighting.

When trying to encode my pdf i get the following error

Object list not found. Possible secured file.

What does this mean?

If I use pdftotext from the command line, I'm able to output the text of my test-file just fine.

When I try to extract text from this file (http://billybala.brgweb.com.br/tmp/1435983113.pdf) it inserts white space beetween letters:

The code:

   $fulltext = 'Full text: ';
   $parser = new \Smalot\PdfParser\Parser();
   $pdfsource = $parser->parseFile($pdf);
   $pages  = $pdfsource->getPages();
   $pagecount = count($pages);
   $output .= "Total pages: $pagecount<br>";
   // Loop over each page to extract text.
   foreach ($pages as $page) {
    $fulltext .= utf8_decode($page->getText());
   }
   echo $fulltext;

The output is:

Full text: C 3 9 9 0 0 9 N T O U D e a r E d i t o r : W i t h g r o w i n g p o p u l a t i o n a n d e v e r m o r e a d v a n c e d t e c h n o l o g i e s , n a t u r a l r e s o u r c e s p r o v i d e d b y l a n d c a n n o l o n g e r f u l f i l l t h e i n c r e a s i n g d e m a n d s o f t h e h u m a n p o p u l a t i o n . I n a n a t t e m p t t o e n s u r e t h e i r m a r i n e r i g h t s a n d i n t e r e s t s , m a n y c o u n t r i e s h a v e t a k e n t h e s t e p t o e s t a b l i s h c o m p e t e n t m a r i n e a u t h o r i t i e s . T h e s e a u t h o r i t i e s a r e a s s i g n e d t h e m i s s i o n t o i n t e g r a t e o c e a n p o l i c i e s , a n d h a v e t h e r e s p o n s i b i l i t y t o o v e r s e e v a r i o u s m a r i n e a f f a i r s . T h i s p a p e r g i v e s i n s i g h t i n t o t h e s c o p e o f m a r i n e a f f a i r s , a n d s u m m a r i z e s t h e p r e s e n t s t a t e o f m a r i n e a u t h o r i t y e s t a b l i s h m e n t i n a n u m b e r o f o c e a n s t a t e s i n c l u d i n g t h e U n i t e d S t a t e s , C a n a d a , C h i n a , J a p a n a n d K o r e a . I t g o e s o n t o d i s c u s s t h e h i s t o r y a n d p r o c e s s o f e s t a b l i s h i n g c o m p e t e n t m a r i n e a u t h o r i t i e s i n T a i w a n . T h e T a i w a n e s e G o v e r n m e n t h a s c o n f i r m e d t h e e s t a b l i s h m e n t o f T h e T a s k F o r c e f o r M a r i t i m e A f f a i r s ( T h e T a s k F o r c e ) . I t i s r e s p o n s i b l e f o r t h e i n t e g r a t i o n o f v a r i o u s m a r i n e a u t h o r i t i e s i n T a i w a n a n d t h e n e w l y e s t a b l i s h e d c o m p e t e n t a u t h o r i t y i s s c h e d u l e d t o c o m e i n t o o p e r a t i o n i n J a n u a r y 2 0 1 2 . T h e T a s k F o r c e w i l l s e r v e a s a u s e f u l s o u r c e o f r e f e r e n c e f o r m a n y s c h o l a r s w o r k i n g i n t h e m a r i n e a n d o c e a n s c i e n c e d i s c i p l i n e s . F u r t h e r m o r e , t h e i n s i g h t f u l a n a l y s i s p r e s e n t e d i n t h i s p a p e r w i l l e n a b l e y o u r r e a d e r s t o a c q u i r e a b e t t e r u n d e r s t a n d i n g o f t h e s c o p e o f m a r i n e a f f a i r s , t h e s t a t u s o f c o m p e t e n t m a r i n e a u t h o r i t i e s i n c e r t a i n c o u n t r i e s , a n d t h e h i s t o r y a n d p r o c e s s i n t h e e s t a b l i s h m e n t o f s u c h a u t h o r i t i e s i n T a i w a n . F o r t h e r e a s o n s s t a t e d , I f e e l t h i s p a p e r p r o v i d e s h i g h l y v a l u a b l e i n f o r m a t i o n s u i t a b l e f o r p u b l i c a t i o n i n y o u r j o u r n a l . S h o u l d t h e e d i t o r h a v e a n y s u g g e s t i o n o r c o m m e n t p l e a s e d o n o t h e s i t a t e t o c o n t a c t u s , w e s h a l l r e s p o n d i m m e d i a t e l y .

I created a very simple PDF for testing, because I had issues getting correct x and y coordinates when using getDataTm() (unfortunately, I can't provide any other PDFs for privacy reasons...)

=> xy.pdf

    $parser = new \Smalot\PdfParser\Parser();
    $pdf    = $parser->parseFile('xy.pdf');
    
    $pages = $pdf->getPages();

    foreach ($pages as $index => $page) {
        if (null === $page) {
            continue;
        }
        
        var_dump($page->getDataTm());
    }

For this PDF, the Text is not read correctly when using getDataTm() (but interestingly, it works when using getText() instead). Instead, where the text should be, there's what looks like HEX-encoded strings:

array (size=13)
  0 => 
    array (size=2)
      0 => 
        array (size=6)
          0 => string '1' (length=1)
          1 => string '0' (length=1)
          2 => string '0' (length=1)
          3 => string '1' (length=1)
          4 => string '33.173' (length=6)
          5 => string '665.721' (length=7)
      1 => string '00270050005000430042005300010001' (length=32)
  1 => 
    array (size=2)
      0 => 
        array (size=6)
          0 => string '1' (length=1)
          1 => string '0' (length=1)
          2 => string '0' (length=1)
          3 => string '1' (length=1)
          4 => string '213.173' (length=7)
          5 => string '665.721' (length=7)
      1 => string '00230042005B004300420053' (length=24)
  2 => [...]

If i parse a PDF i get the following error: "mb_convert_encoding(): Illegal character encoding specified" in "/vendor/smalot/pdfparser/src/Smalot/PdfParser/Font.php Line: 500". The list of supported character encodings doesnt list any entry of "Mac" or something... http://php.net/manual/de/mbstring.supported-encodings.php.

My company uses wkhtmltopdf to generate PDF files. Our automated testing uses pdfparser to verify that the generated content matches what we expect. I'm in the process of updating from v0.11 to v0.18.2. We got the expected output in the older version, but the newer version is inserting extra spaces into the content.

Expected content: Snippet 1 EN Actual content: S nip pet 1 E N

Note that I have stepped through the code and verified that they are in fact spaces and not other bad unicode characters, and found the code that is inserting the spaces.

I'm not sure of the actual terminology here, since I'm unfamiliar with the PDF format, but I'll do my best to describe what's going on.

The actual "content" of the PDF file is as follows:

/F6 16 Tf 1 0 0 -1 0 0 Tm
8 -15 Td <0001> Tj
10.1562500 0 Td <0002> Tj
10.1406250 0 Td <0003> Tj
4.43750000 0 Td <0004> Tj
10.1562500 0 Td <0004> Tj
10.1562500 0 Td <0005> Tj
9.84375000 0 Td <0006> Tj
6.26562500 0 Td <0007> Tj
5.07812500 0 Td <0008> Tj
10.1718750 0 Td <0007> Tj
5.07812500 0 Td <0009> Tj
10.1093750 0 Td <000A> Tj 

From what I understand, Td is an x, y offset, and Tj is an index into an encoding table, as follows:

0001 = 'S'
0002 = 'n'
0003 = 'i'
0004 = 'p'
0005 = 'e'
0006 = 't'
0007 = ' '
0008 = '1'
0009 = 'E'
000A = 'N'

As you can see, the content is correct and does not contain extra spaces. The issue seems to come from the Td command. Some have wider x offsets, causing the following code in pdfparser to insert extra spaces (starting at PDFObject:289, "// horizontal offset"):

                    // move text current point
                    case 'Td':
                        $args = preg_split('/\s/s', $command[self::COMMAND]);
                        $y = array_pop($args);
                        $x = array_pop($args);
                        if (((float) $x <= 0) ||
                            (false !== $current_position_td['y'] && (float) $y < (float) ($current_position_td['y']))
                        ) {
                            // vertical offset
                            $text .= "\n";
                        } elseif (false !== $current_position_td['x'] && (float) $x > (float) (
                                $current_position_td['x']
                            )
                        ) {
                            // horizontal offset
                            $text .= ' ';
                        }
                        $current_position_td = ['x' => $x, 'y' => $y];
                        break;

I have tested the exact file in other parsers (gimp, okular, chrome, firefox, edge, word) and all render correctly.

I have attached the file for reference.

36360.00.d28.pdf

closes #532

Previously, the coordinates in getDataTm() were calculated without taking into accout the scaling that happens by the set font size and text matrix.

In a PDF that would e.g. look like:

• /R9 11.04 Tf (second operand is font size)
• 0.999402 0 0 1 70.8 698.96 Tm (first and fourth operand set horizontal and vertical scaliing)

When the posiiton is changed using the text positioning operators Td or TD, the new coordinates are now calculated with the set scaling.

One line in the test files was changed to reflect the correct scaling.

This pull request also fixes a sign error in the calculation of the y-coordinate in TD.

fixes at least #201

maybe #72 too, but i cannot download the pdf anymore

closes https://github.com/smalot/pdfparser/pull/245 maybe closes https://github.com/smalot/pdfparser/pull/256

Hi,

I'm using version 2.2.1 and trying to spot location of a string in some pages.

The PDF is generated by my own use of TCPDI.php

Method getText works like a charm but getDataTm always return an empty array ([]).

Here is the page details:

{ "Type": "Page", "Parent": { "Type": "Pages", "Count": "65" }, "LastModified": "2022-08-31T13:57:58+02:00", "Resources": [], "MediaBox": [ 0, 0, 595, 842 ], "CropBox": [ 0, 0, 595, 842 ], "BleedBox": [ 0, 0, 595, 842 ], "TrimBox": [ 0, 0, 595, 842 ], "ArtBox": [ 0, 0, 595, 842 ], "Contents": { "Filter": "FlateDecode", "Length": "97" }, "Rotate": "0", "Group": { "Type": "Group", "S": "Transparency", "CS": "DeviceRGB" }, "PZ": "1" },

There was a discussion in #318 whether to merge in a change that might require adaptions by users of this library. PDFParser follows Semantic Version, which has some implications how to handle that situation. One is to bump major version from 0.x to 1.0. I will outline the arguments I heard so far and wanna invite all of you to vote. Feel free to comment, I will add new arguments to the lists.

Thank you for helping here

:+1: - Yes, jump to 1.0 :-1: - No, keep 0.x for now

Arguments against 1.0

1. A check to some extent is required to determine if all parts of the library (API) are as we want them to be. The focus has to be on the current feature set and behavior behind. Is there something which is fishy and has to be taken care of before 1.0?
   • Based on Github stats there are almost 800 projects directly or indirectly depending on PDFParser. Some may also use this in production environments generating money. PDFParser is an Open Source library with no obligations, but in my opinion we can't just change something and leave developers out in the cold.
   • If we just bump the version we acknowledge that the current state is fine. But if we encounter major problems in the near future we might be forced to bump again..
2. Currently we receive many fixes and some features, for instance from @PaulBehrendtVentoro, @Connum and @izabala.
   • That is great! But because of that it is important to know, if its planned to have API changes be part in future contributions.
   • As long as we have 0.x, changes in API (or behavior) won't be merged, but in case a (basic) check like in (1.) was conducted, we can collect API changes and put them together into a new 1.x release.

Arguments for 1.0

1. Semantic Version allows the bump from 0.x to 1.0 at any point. Developers "know" that this might happen and their code might be affected.
2. People using Composer constraint "^0.x" or stay at 0.x are not affected and shouldn't experience any problems.
3. Make changes in API or behavior optional and allow developers to enable them via parameter.

Implications here

• [ ] prepare a new release
• [ ] add an UPGRADE file to inform developers of required code changes

BTW.: The vote may lead our decision to keep #314 or not.