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).
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?
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.
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.
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.
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).
maechler
commented
4 years ago
Gernott
commented
4 years ago
maechler
commented
4 years ago
Gernott
commented
4 years ago
maechler
commented
4 years ago
maechler
commented
4 years ago
maechler
commented
4 years ago
Gernott
commented
4 years ago
- © Githubissues.
- Githubissues is a development platform for aggregating issues.
example.pdf WebsitePdf.zip
@Gernott Thanks for reporting! I will have a look at it this week, but probably this is a TCPDF issue.
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
@Gernott Perfect thanks, so we will update TCPDF soon and test it!
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?
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 inBasePDF
, e.g.Header
orFooter
: https://github.com/bithost-gmbh/pdfviewhelpers/blob/84fdcb4336fb39bd4d4173bcbf39e46acc479db1/Classes/Model/BasePDF.php#L168-L180If 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
.@Gernott The problem seems to be within our function
renderHeader
inBasePDF
. 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();
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.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.
Tested and works fine. Thank you - good work!