Fix invalid return type on unknown glyph

[PrinsFrank]

When an unknown glyph is encountered, the glyph itself is returned, which is a string:

// Encoding/PostScriptGlpyhs.php

/**
 * @return float|int|mixed
 */
public static function getCodePoint($glyph)
{
    $glyphsMap = static::getGlyphs();

    if (isset($glyphsMap[$glyph])) {
        return hexdec($glyphsMap[$glyph]);
    }

    return $glyph; // <======
}

The function 'translateChar' in Encoding.php directly returns the result of the above function, but has a return type of 'int'.

// Encoding.php

public function translateChar($dec): int // <=====
{
    if (isset($this->mapping[$dec])) {
        $dec = $this->mapping[$dec];
    }

    return PostScriptGlyphs::getCodePoint($dec);
}

This PR returns null on an unknown glyph instead, and passes the $dec_av to the encoding function instead to preserve the glyph representation in the final result as in the test for issue #359

The Newly added test throws a TypeError about strings when the return type should be an int for unknown glyphs without these changes.

[PrinsFrank]

Sorry, forgot to run cs fixer before pushing. Fixed!

[PrinsFrank]

@k00ni Is the 'Needs work' tag still relevant or was it added because of the failing cs pipeline? What can I do to get this merged?

[k00ni]

@k00ni Is the 'Needs work' tag still relevant or was it added because of the failing cs pipeline? What can I do to get this merged?

It was because of failing CS pipeline and some code parts I wanted to discuss before using them. I am currently super busy and not sure when I work on this. At a first glance it looks good.

@j0k3r can you take this one?

[k00ni]

Thanks for your pull request @PrinsFrank. If I understand you correctly your fix makes PDFParser more resistant against unknown glyphs as well as prevents TypeError.

[j0k3r]

I've tested it locally and it (indeed) fix the issue with the related PDF.