HTML to PDF conversion hangs infinit

Hi Aspose Team,

We have a discovered a problem/hang situation when converting a specific HTML file to PDF.
Please see attached zipped html file
92942.zip (7.8 MB)

We’re using the latest version of Aspose.PDF 26.4.0 with the following code:

AsposePdf::Aspose.Pdf.HtmlLoadOptions options = new();
options.CustomLoaderOfExternalResources = new(NoLocalFilesLoader);
AsposePdf::Aspose.Pdf.Document pdfDocument = new(filename, options);
pdfDocument.Save(convertedFilename);

Thanks for investigating this problem !

Kind Regards,
Anders

1 Like

@andersalvsaker
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): PDFNET-62101

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.

Hi, thank you kindly for reporting the issue and providing files
We registered a task for development team to address this issue, you’ll be notified when it will be updated

I am part of the company reporting this issue.

The file is a 10.88 MB HTML. Only 43 elements and ~1.1 KB of markup — body is dominated by three data:image/jpeg;base64,… iPhone 16 photos, each 4032×3024 px (decoded 2.2–3.1 MB per image). No <img width/height> set.

~146 MB of raw RGBA (3 photos × 4032×3024×4) inflates to ~26 GB, then it stops making progress. Seems like the photos are laid out at native pixel size on A4/Letter (no CSS scaling, no width /height on <img> ), forcing them to tile across many page boxes.

I can see why this is a very problematic HTML-document to convert, but I would rather have it fail with an exception than eating all memory and forcing a restart.

@aklefdal
Thank you for additional info , I’ll attach it to the description of task

From a architectural point of view, I would say that doing so much work in a constructor ( Aspose.Pdf.Document..ctor(string, LoadOptions) that it hangs is a problem. I would strongly prefer that work that can fail is done in a async method with support for CancellationToken.

I found a very sensible work around:

PageLayoutOption = HtmlPageLayoutOption.ScaleToPageWidth

Still a lot of work is done in a constructor without support for CancallationToken, but at least we get a result quite quickly. The PDF document ends looking very scaled down, but so does the HTML page.

@aklefdal
I think there’s a CancellationToken support available , you can check it out

As for workaround it’s great that it is present and resolves the issue but I think the issue should be investigated in any case as such hangs doesn’t seem as correct behavior so I’ll leave the issue open for now

Thank you kindly for thorough investigation, I’ll add the info about workaround to the rest of task’s description