CODEWITHSUNDEEP
phppdflabelfpdf
user3653863
user3653863

Reputation: 257

PHP FPDF Label outputting gibberish/garbage data if not enough labels are printed, but with enough it works just fine

I have a label generator that works fine if you have enough labels to print, in my case it's roughly 3 pages worth of 5160's, or ~70 individual entries. If you have less than that number you end up looking at this instead of downloading your PDF: enter image description here

If you have enough entries it will however work properly and look like this: enter image description here

Noteworthy is that when I changed from real data to dummy data so I could take a screen cap of it the number of pages needed to be ~6, so it seems to fail when there is not enough raw text, rather than individual entries.

I haven't got a clue how to debug this. This is my code that I am working with:

$pdf = new PDF_Label('5160');

        $pdf->AddPage();

        foreach ($entries as $entry) {
            $name = 'Demo thing';

            $date = Carbon::create($order->{'Delivery Date'})->format('M d, Y');

            $text = sprintf("%s\n%s, %s, %s\n%s\n%s", 'Business', 'Employee', '4A', 'Floor 7' ?? '---', $date, $name);
            $pdf->Add_Label($text);
        }

        $pdf->Output();

Has anyone encountered this while working with FPDF_Label before? Any help would be appreciated, thanks!

EDIT: More info about the error checking that FPDF does:

protected function _checkoutput()
{
    if(PHP_SAPI!='cli')
    {
        if(headers_sent($file,$line))
            $this->Error("Some data has already been output, can't send PDF file (output started at $file:$line)");
    }
    if(ob_get_length())
    {
        var_dump('test');
        // The output buffer is not empty
        if(preg_match('/^(\xEF\xBB\xBF)?\s*$/',ob_get_contents()))
        {
            // It contains only a UTF-8 BOM and/or whitespace, let's clean it
            ob_clean();
        }
        else
            $this->Error("Some data has already been output, can't send PDF file");
    }
}

//below is within the main output function
            $this->_checkoutput();
            
            if(PHP_SAPI!='cli')
            {
                // We send to a browser
                header('Content-Type: application/pdf');
                header('Content-Disposition: inline; '.$this->_httpencode('filename',$name,$isUTF8));
                header('Cache-Control: private, max-age=0, must-revalidate');
                header('Pragma: public');
            }
            echo $this->buffer;
            break;

When I see my error it goes through this bit of code and does not output any of those errors you see, so we can say that there is no headers already sent or output in the buffer.

Upvotes: 1

Views: 777

Answers (2)

Mohd Faisal Ali Khan
Mohd Faisal Ali Khan

Reputation: 11

Try writing the following

ob_clean(); before $pdf = new PDF_Label('5160');

and

ob_flush();
exit;

after

$pdf->Output();

Upvotes: 1

user3653863
user3653863

Reputation: 257

I found a solution for this, though it doesn't address the underlying problem. I was comparing headers in the network tab for the working and not working scenarios and noticed that 'Content-Type: application/pdf' was dropped for the shorter entry set (plus some other changes). Since this did not happen outside my Laravel site I tried adding 'exit;' the line after '$pdf->Output();' and it now works regardless of how many entries.

With the longer entry sheet I noticed it adds 'Transfer-Encoding: chunked' as well as keeping the 'Content-Type: application/pdf'. Perhaps there is a bug in the Laravel header handling related to that? I'm really not sure.

Upvotes: 0

Related Questions