bithost-gmbh / pdfviewhelpers

TYPO3 CMS extension that provides various Fluid ViewHelpers to generate PDF documents.
GNU General Public License v3.0
44 stars 20 forks source link

Font in Tablecell not visible after Pagebreak #155

Closed Gernott closed 4 years ago

Gernott commented 4 years ago

If you use with a

inside with background-colour in cells, then the text on page 2 in cell one is not visible, when the content of this cell is parted on 2 pages. See attached PDF (press strg+a on page 2 to see the hidden text).

example.pdf WebsitePdf.zip

maechler commented 4 years ago

@Gernott Thanks for reporting! I will have a look at it this week, but probably this is a TCPDF issue.

Gernott commented 4 years ago

It seems to work with direct PHP / TCPDF 6.3.5 (Github Master). See attached PHP and PDF file with same HTML code. phptry.zip

maechler commented 4 years ago

@Gernott Perfect thanks, so we will update TCPDF soon and test it!

Gernott commented 4 years ago

Hmmmm, I replaced the TCPDF version in the EXT:pdfviewhelpers 2.3.1 in the folder Resources/Private/PHP/tcpdf/ from 6.2.26 to 6.3.2 (from Github). But the problem still appears with my PDF Viewhelper. So it is more tricky. I have no idea where to look now. Do you have any hints what I can try now?

maechler commented 4 years ago

I guess I would have to start using a debugger now as well. But maybe you can find out something by starting to comment out TCPDF methods that we have overwritten in BasePDF, e.g. Header or Footer: https://github.com/bithost-gmbh/pdfviewhelpers/blob/84fdcb4336fb39bd4d4173bcbf39e46acc479db1/Classes/Model/BasePDF.php#L168-L180

If commenting out one of these functions helps, we know where to have a closer look at. You should be able to recognise the methods we have overwritten by looking for the comment @inheritdoc.

maechler commented 4 years ago

@Gernott The problem seems to be within our function renderHeader in BasePDF. You could provide your own PDF class (see https://docs.typo3.org/p/bithost-gmbh/pdfviewhelpers/master/en-us/ConfigurationReference/AdvancedCustomization/Index.html#extend-basepdf-class), overwrite the function and comment out $this->setPageMark();

public function renderHeader()
{
    $graphicVars = $this->getGraphicVars();

    parent::setHeader();
    $this->setGraphicVars($graphicVars);
    //$this->setPageMark();
}

I am not entirely sure anymore why we use $this->setPageMark() at this point, it seems to have fixed a PDF compliance issue. Although it also might be that it serves no purpose whatsoever, I will have to further investigate this.

maechler commented 4 years ago

This should be fixed in v2.3.2 which I just released.

The problem seemed to be that setting a page mark at this point lead to a wrong ordering of the background and the text within the PDF document. The text was being rendered, but it was hidden behind the coloured background.

Gernott commented 4 years ago

Tested and works fine. Thank you - good work!