By opening an existing xlsx file and using function wb.Save(…, SaveFormat.Pdf); we create an PDF file and was expected, that it looks very close to if we use “Print as PDF” from MS Excel. But there are differences in mutual positions of all elements/cells as like as was any kind of zoom or fittering applied so that sometimes some elements are moved to another page.
We accept that Fonts can be different, but we cant reach equality in mutual positions of elements/cells, what is important for us…
To get much better matching we have used LoadOptions and PdfSaveOptions, by reading of manual and a bit experimenting we have found as set of parameters that provide better result, but it isn’t the 100% equality.
So, please, could you say, is it possible at all? If yes then, how can we reach it? If not, is there any plans to improve such behavier, may be add some new options or improve ready existend options to reach better equality of PDF from Aspose and Excel?
In Attachment:
TestProject.zip project to demonstrate saving as PDF with options by default, and with our set of options
TemplateAndResults.zip our template.xlsx and 3 PDF for visual comparison.
PS: To compare templates we open files with the same scale in any PdfReader
With each new release, we enhance the Excel to PDF rendering continuously to acquire maximum fidelity and precision (I guess 100% fidelity might be impossible in any case). Please note, Aspose.Cells tries to render PDF file (from Excel spreadsheet) similar to what MS Excel generates when you Save As “PDF” in MS Excel manually. I tested by opening your Excel XLSX file into MS Excel manually and then save it as “PDF”. The output PDF is almost same with output PDF generated by Aspose.Cells. Could you test it as I did and then check if you find any significant difference when comparing output PDF (by MS Excel) Vs output PDF by Aspose.Cells, kindly elaborate with screenshots to highlight the differences/issues. We will look into it soon.
Hallo, @amjad.sahi,
sorry yes, may be my first template and pdf files are not very clear. I have made an new one and some screenshots to explain what I mean.
The wors effect for as, that when we save workbook as pdf without any options we get one page insteed two pages, so one line that shuld be on top of second page moved to bottom first page.
And in common, what we dont realy like, all elements are a bit bigger and mutual positions of elements ist different and not proportional.
We have found that by using AutoFitterOptions by open a workbook we get the best result, at least pages breakers match. But actually in them case apper a question, why this options have no affect when we save workbook as xlsx and have only affect on pdf rendering, and why it isn’t mentioned in API description…
And may be you could analyse options that we set in our example and recomend us, how we can get the best match of aspose generated pdf and excel generated pdf, may be we havn’t considered some other options, that can be helpful?
Thanks for the new template file, screenshots and other resource files.
After an initial test, I reproduced the issue(s) as you mentioned via screenshots by using your template file. I found there are differences regarding shapes rendering and page breaks in the rendered PDF by Aspose.Cells for .NET APIs.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): CELLSNET-53425
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
When you open source file in Excel, Excel will automatically autofit rows that are not custom height. So, it is right to load Workbook with AutoFitterOptions.OnlyAuto set to true.
Autofit also affects the saved xlsx by updating the cached row height for rows that are not custom height. You can output the first row height Console.WriteLine(wb.Worksheets[0].Cells.GetRowHeight(0)); to check the different with/without autofit.
However, when you open the saved xlsx file in Excel, Excel will automatically autofit rows that are not custom height too. The row height may be different in Excel with different System display settings(e.g. 100%, 150%, 200%).
Because Excel saved pdf files may be different with different Windows display settings, so Aspose.Cells aims to generate pdf which is almost same as the pdf generated by Excel(Save as) with Windows display setting 100%. Here I attached Excel saved pdf in Windows display setting 100% and Aspose.Cells saved pdf with option in your code. For comapring, I enabled the gridline in page setup.pdfs_Gridline.zip (194.6 KB)
Hi, @peyton.xu,
thank you for clarification.
We have one another example, that we would like to clear.
Why aspose print time format in pdf not equally to “save as pdf” from MS Excel?
Please note, by default, when you do convert Excel file to PDF via Aspose.Cells APIs, the numbers and Date/Time values are rendered according to the locale/regional settings for the os. You can change/set regional settings/locale using LoadOptions.Region property while loading the Excel file. By the way, when I opened your Excel file into MS Excel, the DateTime value is shown in the format “m/d/yyyy h:mm”. So, the DateTime value is shown as: “6/5/2023 8:00”, see the attached screenshot for your reference.
(please note I am using Windows 10 (us-english locale). sc_shot1.png (85.2 KB)
What is your environment with regional/locale settings details?
I have de-AT locale on my mashine, and have set custom format “TT.MM.JJJJ hh:mm” CellFormat.png (20.2 KB)
and MS excel prints the in the same format, so in MS Excel and in pdf saved from excel I see “05.06.2023 08:00”. And actually expect the same in pdf from aspose. I have even set workbook local to the same “de-AT”
We are pleased to inform you that your issue (logged earlier as “CELLSNET-53482”) has been resolved. The fix will be included in an upcoming release (Aspose.Cells v23.6) that we plan to release in this week. You will be notified when the next version is released.
The issues you have found earlier (filed as CELLSNET-53482) have been fixed in this update. This message was posted using Bugs notification tool by johnson.shi