Fixes an "Undefined offset: 1" PHP Notice.

[pocketarc]

When using DejaVu Sans or any @font-face font, this would always throw PHP errors in my app. It makes sense to check if it's set to prevent the notice. Ideally, though, this shouldn't even be throwing errors, but I don't know enough about php-font-lib's code to figure out what is going on.

Here's a minimal test case HTML that causes the error: http://i.28hours.org/files/php-font-lib-undefined-offset.html

[bsweeney]

Just to note this is produced when a document is parsed by dompdf.

The following simplified test case gives "Undefined offset: 2".

<h1 style="font-family: dejavu sans;">a</h1>

I don't know if the problem is php-font-lib or something dompdf is doing incorrectly, but it definitely merits further investigation.

[pocketarc]

Let me know if there's anything at all I can do to help track it down. I've been using dompdf for the longest time and I'd love to help out.

[indreka]

Doesn't omitting the ->w() call skip writing the bytes, thus causing the output font file have partial data and invalid offsets?
Probably there is some issue during the parsing part, that doesn't fill the initial data block fully.
Can you give the font file you are using so it can be tested (different versions can be bit different)?

[bsweeney]

I was testing with DejaVu Sans in dompdf 0.6.2 and dompdf 0.7.0. I don't recall what version is used in 0.6.2, but in 0.7.0 we used the version 2.35 DejaVu fonts.

[pocketarc]

And I didn't see an impact when it comes to omitting the ->w() call, possibly because the data wasn't there to be added in the first place. The PDFs we generate continue to work without any problem whatsoever.

[bsweeney]

note: relevant to #50.

[mnabialek]

Any chance to merge this? I see this is exact same problem as I described in #52