When reading an XLSX file charts are downgraded to 1 column width

[anvarzey]

I want to use PHPSpreadsheet to convert excel files (xlsx) to pdf. Those files include charts that have a width of 4 columns, but when it writes the pdf, the charts are shown as 1 column width so they look much smaller than original ones.

I am using Tcpdf, with other pdf libraries (like mPDF and Dompdf) I have got worse results.

I have also tried to modify the charts using this options with no success.:

• setBottomRightPosition
• setTopLeftPosition
• setRenderedWidth
• mergeCells
• setBottomRightXOffset

This is the original code I am using, without chart modifications:

private function generatePDF($filePath, $pdfFileName)
    {
        Settings::setChartRenderer(MtJpGraphRenderer::class);

        $reader = IOFactory::createReader("Xlsx");
        $reader->setIncludeCharts(true);
        $reader->setLoadAllSheets();
        $spreadsheet = $reader->load($filePath);

        $writer = IOFactory::createWriter($spreadsheet, 'Tcpdf');
        $writer->setIncludeCharts(true);

        $writer->writeAllSheets();
        $writer->save($pdfFileName, IWriter::SAVE_WITH_CHARTS);

        return $pdfFileName;
    }

Orginal Excel file:

Result:

[oleibman]

Hmmm. Yes, I see the same sort of behavior in our samples - 36writeLineChart1.pdf and 36writeMultiple1.pdf. The corresponding html files are fine. I think what is happening is something like the following:

• The chart image is assigned to a cell, which becomes table data in a table row in an html table.
• To the Pdf generators, the table cell assigned to the image has a width which conflicts with the image width, even though the image position is absolute..
• The generators do their best to reconcile the conflicting widths without forcing everything to be split over multiple pages. This will result in shrinking the chart.

I'm not sure what, if anything, we can do. One thing that works, up to a point, is adding a colspan to the first cell over which the cell is overlaid. This won't always be appropriate, but it should be okay in a Pdf. You can get the colspan by merging the cells in its first row over which you've overlaid it. We also provide a means of editing the html before submitting it to Pdf. Another solution is to just generate Html, and then use the "print to Pdf" option to manually generate your file.

I recognize that there are severe limitations in all of those suggestions. Perhaps we can detect this situation at run-time and generate the colspan on our own even when the cells aren't merged. It would need a lot of study.

[oleibman]

If you can test against PR #4327, adding calls to the new methods introduced there, please do so.

[oleibman]

PR #4327 is now merged, permitting a solution to this problem.