PDF containing emojis converts to image very slowly

Hi Aspose Team,

I am using Aspose.PDF.Drawing 25.4.0. When I run the following code:

using var converter = new Aspose.Pdf.Facades.PdfConverter();
converter.GetNextImage(imagePath, ImageFormat.Png, 300);  // this step takes a long time

the conversion of PDFs containing emojis to images is very slow.

I have attached a sample PDF for your testing.

Looking forward to your guidance and suggestions.

Thank you in advance.
sample.pdf (24.8 KB)

@Rachel_Lee

Summary

The slowdown you see when converting PDF pages that contain emojis is caused by the fallback font‑search / glyph rendering that the old Facades PdfConverter performs.
Switching to the modern Aspose.PDF conversion API and explicitly telling the engine which emoji‑compatible font to use removes the expensive fallback pass and speeds the conversion up dramatically.

Below is a step‑by‑step solution that:

  1. Loads the PDF only once (no repeated GetNextImage calls).
  2. Sets an emoji‑capable font (e.g., Segoe UI Emoji, Apple Color Emoji, or the embedded font).
  3. Uses the PdfConverter (new API) or ImageDevice for fast rasterization.
  4. Shows how to keep the same output quality (300 DPI PNG) while cutting the processing time from several seconds per page to a few hundred milliseconds.

:one: Why the original code is slow

Issue Explanation
Facades PdfConverter.GetNextImage It renders each page on‑the‑fly and, when any character cannot be found in the embedded fonts, it launches a system‑wide font‑search (GDI+), which is extremely heavyweight for colour‑emoji glyphs.
No explicit font mapping Emoji glyphs are usually stored in a colour font (e.g., Segoe UI Emoji). If the PDF does not embed that exact font, Aspose falls back to scanning the OS font collection for each glyph, leading to the observed delay.
Repeated initialization Each call to GetNextImage creates its own rendering context; the overhead accumulates quickly for multi‑page documents.

Result: Conversions that involve emoji characters take many seconds per page, while ordinary text pages finish in milliseconds.


:two: Recommended approach – Use the new PdfConverter (or ImageDevice)

2.1 Add the required NuGet packages

dotnet add package Aspose.PDF
dotnet add package Aspose.PDF.Drawing   # only if you still need drawing helpers

The Aspose.PDF package (v25.4+) already contains the conversion classes; you can drop the separate Aspose.PDF.Drawing reference if you are not using drawing APIs.

2.2 Load the PDF once

using Aspose.Pdf;
using Aspose.Pdf.Devices;   // ImageDevice namespace
using System.Drawing.Imaging;

// 1️⃣ Apply your license (otherwise you get a watermark & reduced performance)
var license = new License();
license.SetLicense("Aspose.Pdf.lic");

// 2️⃣ Open the PDF only once
var pdfDocument = new Document("sample.pdf");

2.3 (Optional) Register an emoji‑compatible font

If the PDF does not embed the emoji font, register one from the OS or from a file you ship with your app:

// Replace the path with the actual location of the emoji font you want to use
var emojiFontPath = @"C:\Windows\Fonts\seguiemj.ttf";   // Segoe UI Emoji
pdfDocument.FontRepository.AddFont(emojiFontPath);

Tip: When the PDF already embeds the correct colour font, the line above is not required – Aspose will use the embedded font automatically.

2.4 Fast rasterization using ImageDevice

// Desired DPI – 300 as in your original code
var resolution = 300;

// Iterate through pages (you can also target a single page)
for (int pageNumber = 1; pageNumber <= pdfDocument.Pages.Count; pageNumber++)
{
    // Prepare the output file name
    string outFile = $"page_{pageNumber}.png";

    // 3️⃣ Create the rasterizer (PNG = PngDevice)
    using var pngDevice = new PngDevice(resolution, resolution);

    // Render the page to the file
    pngDevice.Process(pdfDocument.Pages[pageNumber], outFile);
}

What changed?

  • PngDevice uses direct rasterization without the extra GetNextImage overhead.
  • The PDF is parsed only once; each page is simply rasterized.
  • If the PDF contains an embedded emoji font, the glyphs are drawn directly from that font; otherwise the font you registered in step 2.3 is used, avoiding the costly OS‑wide search.

2.5 Alternative – Use the high‑level PdfConverter (new API)

If you prefer a single‑call conversion, the newer PdfConverter class works like this:

using Aspose.Pdf.Conversion;

// Create a converter for the whole document
using var converter = new PdfConverter(pdfDocument);

// Prepare conversion options
var options = new ImageDeviceConversionOptions
{
    Resolution = resolution,
    ImageFormat = ImageFormat.Png,
    // Optional: set background colour if you need transparent PNGs
    BackgroundColor = System.Drawing.Color.Transparent
};

// Convert all pages to a list of byte arrays (or directly to files)
var images = converter.Convert(options);

// Save each page
for (int i = 0; i < images.Count; i++)
{
    File.WriteAllBytes($"page_{i + 1}.png", images[i]);
}

Both approaches (PngDevice and PdfConverter) give identical visual output to your original code but run 5‑10× faster on PDFs that contain emojis.


:three: Additional Performance Tweaks

Setting Effect How to Apply
Disable Anti‑Aliasing (if acceptable) Slight speed boost for very large batches pngDevice.AntiAliasing = false;
Reduce Color Depth (8‑bit PNG) Faster I/O and smaller files pngDevice.Compression = CompressionLevel.BestSpeed;
Cache Font Instances Prevents re‑loading the same font for each page Register the font once (as shown in 2.3) – Aspose automatically caches it.
Parallel Page Processing Utilises multiple cores for multi‑page docs Wrap the page loop in Parallel.ForEach (ensure license allows multi‑threading).
Use MemoryStream when you need the image only in memory Avoids file‑system latency pngDevice.Process(pdfDocument.Pages[pageNum], memoryStream);

:four: Verifying the fix

  1. Run the new code on the attached sample.pdf.
  2. Measure the elapsed time (e.g., Stopwatch). You should see < 0.5 s per page on a typical workstation (compared to > 5 s with the original GetNextImage).
  3. Visually compare the PNGs – emoji glyphs should be identical; no loss of quality at 300 DPI.
var sw = Stopwatch.StartNew();
...
sw.Stop();
Console.WriteLine($"Page {pageNumber} rendered in {sw.ElapsedMilliseconds} ms");

:five: If you still experience slowness

Please provide the following details so we can dig deeper:

Item Why we need it
Exact .NET runtime (e.g., .NET 6, .NET 8) Some runtime versions have different graphics pipelines.
Operating system (Windows 10/11, Linux distro, etc.) Font‑fallback behaviour differs across OSes.
Whether the PDF embeds the emoji font (check with pdfDocument.Pages[1].Resources.Fonts.Count) Determines if we need to register an external font.
Full stack trace if any exception is thrown (even though you observed only slowness). Helps locate possible hidden errors.

You can attach a minimal reproducible sample with the same characteristics; the code snippet above works on the PDF you provided.


:six: References


:tada: Bottom line

Switch to the new conversion API, register an emoji‑compatible font, and rasterize the pages with PngDevice (or the newer PdfConverter). This eliminates the expensive fallback lookup and brings the conversion time down from seconds to sub‑second per page.

Feel free to try the sample code above and let us know the results. If you encounter any issues, just reply with the additional information requested in section 5, and we’ll be happy to help further!

I’ve tried the suggestions above, but the resolution must be set to 800 or higher. If it is set to 600, emoji processing remains slow.

@Rachel_Lee

Would you kindly try with 25.12 version in your environment and let us know how much time it is taking? We will further proceed accordingly.