Inconsistency with column and row limit in spreadhseet to PDF

GroupDocs.Viewer Product Family
,
1

Using the following settings for the below document we still get rendered empty columns

viewOptions.SpreadsheetOptions = GroupDocs.Viewer.Options.SpreadsheetOptions.ForSplitSheetIntoPages(maxRowsCount, maxColumnsCount);
viewOptions.SpreadsheetOptions.RenderGridLines = false;
viewOptions.SpreadsheetOptions.DetectSeparator = true;
viewOptions.SpreadsheetOptions.SkipEmptyRows = true;
viewOptions.SpreadsheetOptions.SkipEmptyColumns = true;
viewOptions.SpreadsheetOptions.RenderHeadings = true;
viewOptions.SpreadsheetOptions.BottomMargin = 0;
viewOptions.SpreadsheetOptions.LeftMargin = 0;
viewOptions.SpreadsheetOptions.RightMargin = 0;
viewOptions.SpreadsheetOptions.TopMargin = 0;

This document renders all empty columns.
Problem Excel.zip (14.8 KB)

Cant see anything in the spreadsheet that would cause this.

2

Hi @Anf93 ,

Actually, this is not a bug, but expected behavior. The SkipEmptyColumns flag is intentionally ignored here because you have enabled the RenderHeadings option. If you don’t want the empty columns to be rendered, just remove the RenderHeadings = true from your code or make it to be false, and no empty columns will be rendered in the output PDF.

With best regards,
Denis

3

There still seems to be inconsistencies

Using the spreadsheet below with the same settings as above, it does not render the empty columns.

single_row.zip (18.4 KB)

4

Also removing RenderHeadings like you said just produces this instead.

bad_cols.xlsx.pdf (130.6 KB)

So the columns are still rendered.

5

Hi @Anf93

Sorry for the late reply. We have investigated your files and here is what we can say.

" …it does not render the empty columns" - actually, it should not. Every worksheet “virtually” has 16,384 columns, but if they are not filled with any data, there is no need to render them all. Comparing the initial “Problem Excel.xlsx” document with the latest “single-row.xlsx” is not correct, because the “Problem Excel.xlsx” has the very long textual content in a “C164” cell, and this text is like “pushing” the right border of the viewport away.

“removing RenderHeadings like you said just produces this instead” - actually, the provided code from your side is not full enough. Take a look on the two variables maxRowsCount and maxColumnsCount, which you pass to the ForSplitSheetIntoPages method at the very beginning. I don’t know their actual values, but I assume that they are too big. I can reproduce your resultant PDF when I specify, lets say, ForSplitSheetIntoPages(100, 100). But if it is a ForSplitSheetIntoPages(100, 10), the resultant PDF will be much better looking.

You see, the spreadsheet and fixed-layout document formats are too different. Worksheet , especially if it has a lot of rows and columns, is not equal to the single page, and when saving a worksheet to the PDF, it is always a looking for the best compromise. That’s why the GroupDocs.Viewer contains such complex and various SpreadsheetOptions. In this specific case, the ForSplitSheetIntoPages method defines how will you split/divide the area of the single worksheet onto the many rectangular chuncks, each of one contains only a portion of cells from the worksheet.

Hope this will help. You you have any new questions, please feel free to ask them. And once again, sorry for the late delay.

With best regards,
Denis