dompdf / php-font-lib

A library to read, parse, export and make subsets of different types of font files.
GNU Lesser General Public License v2.1
1.73k stars 256 forks source link

unpack(): Type n: not enough input, need 2, have 0 in php-font-lib\src\FontLib\Binary_Stream.php on line 183 #47

Closed fitoe closed 7 months ago

fitoe commented 8 years ago

With the font "4YEOstamp.ttf","2 Prong Tree.TTF", In the "Unicode map", there is an error:

unpack(): Type n: not enough input, need 2, have 0 in php-font-lib\src\FontLib\Binary_Stream.php on line 183

~!Y2KBUG.zip~ ~2 Prong Tree.zip~


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

bsweeney commented 8 years ago

Relevant discussion on the dompdf support group: https://groups.google.com/d/topic/dompdf/MgyHUAVhwr0/discussion

samhibberd commented 8 years ago

Is there a fix for this?

lucianoo6 commented 3 years ago

infelizmente esse erro e devido a um falta de caractere porem eu uso o @ pra suprimir o erro pois ainda não encontrei outra solução exemplo:

`$answerHeader    = @unpack('ntype/nclass/Nttl/nlength', $answerHeaderBin);`
bsweeney commented 2 years ago

It looks like there are multiple possible causes for this error state per discussion in the forums and information available from dompdf/dompdf#2674. Since the linked resources from the OP are no longer available it's difficult to determine the exact cause here.

jeliasson commented 2 years ago

For anyone else ending up here with the same error, I found @lucianoo6's comment helpful as a workaround. It translates to "unfortunately this error is due to a lack of character but I use @ to suppress the error because I still haven't found another solution example:"

I donkey-patched this using below. It's not pretty, but it does the job for now.

# Donkey patch row 218
cat vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php | sed "s/\$a \= unpack/\$a \= \@unpack/g" > ./donkey-patch.php && mv ./donkey-patch.php vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php

# Donkey patch row 219
cat vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php | sed "s/\$v \= \$a\[/\$v \= \@\$a\[/g" > ./donkey-patch.php && mv ./donkey-patch.php vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php

# Verify output of donkey patches
cat vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php | grep '$a = @unpack'
cat vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php | grep '$v = @$a'
UpperLimits commented 1 year ago

Got this error on our Magento2 store and we followed @jeliasson Fix, which worked. Thank you.

FIX BY Adding @ at lines 218 and 219

    $a = @unpack("nn", $this->read(2));
    $v = @$a["n"];

ERROR

main.ERROR: Warning: unpack(): Type n: not enough input, need 2, have 0 in /var/www/vhosts/upperlimitsinc.com/httpdocs/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 218 [] []
bsweeney commented 1 year ago

If anyone is able to share a font causing the issue we'll take another look.

omerkoseoglu commented 1 year ago

Example file causing the problem.

10 Cent Soviet Bold.ttf.zip

bsweeney commented 1 year ago

Can confirm that I get this with the 10 Cent Soviet Bold font. Thanks for the sample.

omerkoseoglu commented 1 year ago

Its true. "10 Cent Soviet Bold"

mleahy-rns commented 1 year ago

Is there any update on this issue? I'm running into the same issue but in a slightly different way. The proposed fix of silencing the warning errors does not fix anything. I was originally using dompdf version 1.0.2 and upgraded to version 2.0.3. Neither version addresses this issue.

I'm using a Google font using the following link: <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Questrial" />

The error is thrown when using the linked stylesheet. However, copying the contents of the stylesheet into a local version seems to work just fine. The linked stylesheet contains 3 URLs to external WOFF2 font files.

alex-petrea commented 1 year ago

I have the same issue with the font Varela Round - (https://fonts.google.com/specimen/Varela+Round?query=varela) which was working fine until today for the past 3 years.

I tried using it from the local storage and the error persist. I switched to a different font and it works just fine.

Webess commented 1 year ago

I have the same issue with the font Arimo https://fonts.google.com/specimen/Arimo Regular (400) font weight is working fine, but other font weights do not work.

onepoordeveloper commented 11 months ago

Another font causing the issue - Exmouth exmouth_.ttf.zip

Resolved by prepending @ on line 196 & 198

image
erlangparasu commented 10 months ago

still got this issue on 0.5.4

atrandafir commented 10 months ago

Also started to experience this issue today. I don't know if Google Fonts have changed the way they work but until now all was working fine. I solve it using @jeliasson and @UpperLimits fix, so thanks guys!

bmellink commented 10 months ago

I had the same issue in readInt16() in lines 218/219 and made the same change:

public function readInt16() {
    $a = @unpack("nn", $this->read(2));
    $v = @$a["n"];

    if ($v >= 0x8000) {
      $v -= 0x10000;
    }

    return $v;
  }

This change should be considered a temporary solution as this is a bad coding habit that only suppresses an exception. For those wanting to use it, I created a fork at https://github.com/bmellink/php-font-lib with instructions how to change your composer.json to use the replacement code.

wpmvangroesen commented 10 months ago

You can also try to use the code in the pull request #121 . Doesn't use @ suppression and seems to work.

bsweeney commented 9 months ago

Ultimately, this particular message is a symptom not a cause and so not something I would necessarily recommend "fixing" by hiding the error. Looking at the cited fonts I did find a few issues that were caused by fonts that were not fully valid (based on strict reading of the spec) or a deficiency in the php-font-lib is parsing.

First, a few fonts had an invalid segment in the cmap table. The particular nature of the invalid data causes the font parser to read past the end of the file. This is, apparently, common enough a problem that other libraries have built in logic to handle the case. php-font-lib should as well, I'm thinking we should ignore 0xFFFF mapping and set other invalid maps to gid 0 (missing glyph).

Initially I'm only handling the attempt to read past the EOF, which I've only encountered so far the 0xFFFF mapping. Ultimately I think we'll want to ensure that the glyph index pointer is within the bounds of the subtable to fully account for potential errors in the cmap data (#127).

References:

Found in:

Second, php-font-lib was handling zero-byte glyphs incorrectly. The glyph parsing logic always attempted to read the number of contours for a glyph. If the glyph has no representation (e.g. a space), then attempting to read the number of contours would actually:

  1. Read the number of contours for the next glyph in the glyf table.
  2. Read the first few bytes of the next font table.
  3. Read past the end of the font file, if the glyf table is positioned last in the font file and the last glyph had zero data.

The last scenario would be the one to generate the error indicated here. To address this php-font-lib should only attempt to read contours if the glyph has data.

Found in:

Lastly, I didn't encounter any parsing error for some of the cited fonts. If I can't reproduce the error then I can't identify the issue. If anyone experiencing issues with these fonts can provide more details I'll look further.

One more thing, I did find an error in the generated font file for some of the fonts. These fonts use the short version loca table (glyph length / 2). The glyph sizes generated by php-font-lib were not padded and, as a result, the lengths recorded in the table for a subsetted font could be invalid. To address this php-font-lib will pad glyphs written to the generated font.

Found in:


As for whether or not to mask file read exceptions, I'm leaning towards not. There are multiple methods that utilize the BinaryStream read methods. It's difficult to say what the impact would be to return empty data universally on failure. Also, php-font-lib is not reading arbitrary chunks from the font file, it is attempting to read file locations based on the direction of the font table data. An error in the read indicates either a parsing error in php-font-lib that we should address or a structural issue in the font file that we should consider handling.

maitrecanard commented 8 months ago

Hello, I also have this problem but I don't use font, I can't resolve the situation

lslqtz commented 5 months ago

2024/02/15 04:43:48 [error] 1852#0: *1848 FastCGI sent in stderr: "PHP message: PHP Warning: unpack(): Type n: not enough input, need 2, have 0 in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 218; PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 219; PHP message: PHP Warning: unpack(): Type n: not enough input, need 2, have 0 in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 218; PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 219; PHP message: PHP Warning: unpack(): Type n: not enough input, need 2, have 0 in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 218; PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 219; PHP message: PHP Warning: unpack(): Type n: not enough input, need 2, have 0 in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 218; PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 219; PHP message: PHP Warning: unpack(): Type n: not enough input, need 2, have 0 in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 218; PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 219; PHP message: PHP Warning: unpack(): Type n: not enough input, need 2, have 0 in /var/www/html/vendor/phenx/php-font-lib/src/FontLib/BinaryStream.php on line 196; PHP message: PHP Warning: Trying to access array offset on value of type bool in /

Same issue, I'm subsetting 40 fonts, so I can't pinpoint which font is causing the problem. Okay, I think I know the problem, it should be the problem caused by my setData.