We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Aspose-cells-python Workbook save method overloads

Documentation outlines multiple overloads for save method. All overloads are named same, just accepting different types. It is not clear how to select the correct overload
image.png (18.2 KB)

Can you create an example of saving a Workbook as PDF to bytes?

Please try the following codes to set SaveFormat:
import aspose.cells
from io import RawIOBase
from aspose.cells import Workbook
from aspose.cells import SaveFormat
from aspose.pyio import BufferStream

workbook = Workbook("input.xlsx")
withio.BytesIO() as write_f:
    data = write_f.read()

Ran the sample code on Windows and Linux. On windows works as expected. Running on Linux, Python v3.9, I get the following exception:
Exception: RuntimeError: Proxy error(CellsException): The type initializer for threw an exception.
Stack: …
File ‘/home/site/wwwroot/ConvertExcelToPdfNet/init.py’, line 29, in main
workbook.save(write_f, SaveFormat.PDF)

Unfortunately, the type initializer name is obfuscated with the square chars and is not clear what it is.

Example triggering the excepiton:

import logging
import os
import pathlib
import tempfile
from aspose.cells import Workbook, SaveFormat, FontConfigs

full_path = pathlib.Path(__file__).parent.resolve()
target_temp_path = tempfile.TemporaryDirectory()
documents_relative_path = "assets/documents"
fonts_relative_path = "assets/fonts"
template_file_path = os.path.join(full_path, documents_relative_path, "template.xlsx")
target_file_path = os.path.join(target_temp_path.name, "output.pdf")
fonts_folder_path = os.path.join(full_path, fonts_relative_path)

workbook = Workbook(template_file_path)
FontConfigs.set_font_folder(fonts_folder_path, True)

with open(target_file_path, "wb+") as write_f:
    workbook.save(write_f, SaveFormat.PDF) <<<< Exception thrown
    file_bytes = write_f.read()

Please try the following code(aspose-cells-python 23.1.0) which works fine in our side(Windows 10 x64 Python 3.10,and Linux(Ubuntu 18.04,Python 3.6.9)) if there is still exception we suspect it may be an environmental issue.Thanks!

import aspose.cells
from aspose.cells import Workbook, SaveFormat
workbook = Workbook("input.xlsx")
with open("output.pdf", "wb+") as write_f:
  workbook.save(write_f, SaveFormat.PDF)
  file_bytes = write_f.read()

Looks like aspose-cells-python throws exceptions in Azure Functions Python runtime. Full stack/exception below

Result: Failure Exception: RuntimeError: Proxy error(CellsException): The type initializer for ‘’ threw an exception. Stack: File “/azure-functions-host/workers/python/3.9/LINUX/X64/azure_functions_worker/dispatcher.py”, line 452, in _handle__invocation_request call_result = await self._loop.run_in_executor( File “/usr/local/lib/python3.9/concurrent/futures/thread.py”, line 58, in run result = self.fn(*self.args, **self.kwargs) File “/azure-functions-host/workers/python/3.9/LINUX/X64/azure_functions_worker/dispatcher.py”, line 718, in _run_sync_func return ExtensionManager.get_sync_invocation_wrapper(context, File “/azure-functions-host/workers/python/3.9/LINUX/X64/azure_functions_worker/extension.py”, line 215, in _raw_invocation_wrapper result = function(**args) File “/home/site/wwwroot/function_app.py”, line 28, in test_function workbook.save(write_f, SaveFormat.PDF)


Thanks for providing further details.

We will look into it and get back to you soon.

1 Like

What is your OS environment and python version,3.9.? then we will try to setup the same environment to reproduce your problem. In addition, is there a problem running the following code in your environment?

import aspose.cells
from aspose.cells import Workbook, SaveFormat
workbook = Workbook("input.xlsx")
workbook.save("output.pdf", SaveFormat.PDF)

This is the image used in Azure to run Aspose.Cell
Azure Functions Python by Microsoft | Docker Hub
OS Version: Debian 11
Platform: CPython
Python version: 3.9

I can successfully export xls => pdf on Windows 10 by both passing in an output file and exporting to a stream.

To make sure Aspose working in the target environment, I tested another method.
Test steps: load xlsx file into a Workbook, get fonts from loaded workbook. That is successful. Once I try to export to PDF, I get exception. Detailed log below:

2023-01-27T14:55:01Z [Information] Platform: CPython
2023-01-27T14:55:03Z [Information] [Aspose.Cells.Font [ Calibri; 11; Regular; Color [A=255, R=0, G=0, B=0] ], Aspose.Cells.Font [ Arial; 10; Regular; Color [A=255, R=0, G=0, B=0] ], Aspose.Cells.Font [ Georgia; 14; Bold; Color [A=255, R=72, G=135, B=178] ],…]
2023-01-27T14:55:03Z [Information] /home/site/wwwroot/assets/documents/template.xlsx
2023-01-27T14:55:03Z [Information] Proxy error(CellsException): The type initializer for ‘’ threw an exception.
2023-01-27T14:55:03Z [Information] Traceback (most recent call last):
File “/home/site/wwwroot/function_app.py”, line 38, in test_function

We have encapsulated System.Drawing.Common in our product, and we initially estimate that it is not supported on your platform because converting to a PDF file requires System.Drawing.Common.

Article describing the issue is https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only

If that is the case, no Linux platform would be able to run Aspose. Is that the case?

There is a recommended action, but I am unsure how to apply and try it given Python wrapper. Please advise. Thank you!

Please try to install libgdiplus on your Debian 11

sudo apt-get install libgdiplus


Question before we dig into creating custom Azure Funciton image to include the additional library - will this new library solve the issue or is it just for debugging?

Installing libgdiplus library requires custom docker image. That diminishes the cross platform usability and increases complexity to setup and deploy.

Any way the additional library be imported and installed as dependency internally in aspose?

We use System.drawing.common for drawing. In Linux, System.drawing.common depends upon libgdiplus. We encountered similar issue on another newly installed Linux machine. However it was resolved after installing libgdiplus on it. So please try it.

Please note, libgdiplus is compulsory on Linux, which depends on many other libraries. Moreover, it is not appropriate to include so many dependent libraries (dependencies) in our released package as this may increase the file size.

Hope this helps a bit!