Missing encoding data for: "MacExpertEncoding"

[trapero]

Hello,

I´m trying to parse the metadata from different files, the library works great but in some documents give me this error:

Missing encoding data for: "MacExpertEncoding"

You can access one of the document in:

http://www.statistik.rlp.de/fileadmin/dokumente/berichte/C1013_201500_1j_L.pdf

I get this error in the demo too.

Do you know a solution?

Thank you

[garraeth]

I'm getting this same message.

A couple resources I found, but I'm no PDF dev so it's foreign to me:

https://github.com/rohitpaulk/pdfparser/blob/master/gems/pdf-reader-master/lib/pdf/reader/encodings/mac_expert.txt

https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf
page: 665

This would be a great addition.

Thanks! Love the project!

[garraeth]

Just on a whim, I created a MacExpertEncoding class (using the MacRomanEncoding.php file as a template) and copied the $encoding data from MacRomanEncoding into my new MacExpertEncoding class...and it worked!

Granted, I might have just gotten lucky.

[smalot]

Could you create a merge request to contribute ?

[adrianbj]

Sorry if I should open a new issue, but I am actually getting this error:

Missing encoding data for: ""

I have worked around it for now by hardcoding StandardEncoding like this:

$className = '\\Smalot\\PdfParser\\Encoding\\StandardEncoding';

The problem is that $this->get('BaseEncoding') returns false

Any thoughts on how to fix this properly?

Thanks.

[k00ni]

Can you provide us the PDF which is causing this problem? It must be free of charge and without any obligations.

[adrianbj]

Hi @k00ni - thanks for responding so quickly. The issue can be seen with this file.
healthy-chesapeake-waterways.pdf

[k00ni]

Is healthy-chesapeake-waterways.pdf free of charge and without any obligations?

[adrianbj]

Yes - it's from here: https://ian.umces.edu/press/newsletters/publication/1/healthy_chesapeake_waterways_2002-05-01/

Filename is different, but that's just because I am rebuilding this site and the new version is automatically renaming PDFs to match the publication title.

[igor-krein]

Currently, in the Encoding.php, there is a "magic" function __toString() implementation, which calls a getEncodingClass() function, which, in its turn, may throw an exception (line 150).

From php.net:

Warning It was not possible to throw an exception from within a __toString() method prior to PHP 7.4.0. Doing so will result in a fatal error.

I think, if there is a need to keep a PHP 7.4 support, better change the line 150 somehow (for example, simply return an empty string). Note that __toString() method must return a string.

[suuuunto]

I am getting the same error, is there a dirty fix for it?

[k00ni]

@igor-krein and @suuuunto does #407 fix it?

[igor-krein]

@igor-krein and @suuuunto does #407 fix it?

The code looks like it should fix the problem, thanks. I'll try to check it in action asap.

UPD: Let's say, it is highly likely that the problem was fixed. Actually, I don't have a sample PDF, I just see there was a problem in the logs (obviously, some clients' PDF files invoked the fatal error; but no client has complained yet, so there are no samples). This log data had appeared since the latest upgrade of the system (looks like composer downloaded the latest PdfParser version, too). So, there were new logs, and now they don't seem to appear anymore.

Thanks for the changes! Can't wait for them to be merged.