Different Fonts, Bullets, Numbering, and Text Effects_Updated Version.zip (37.4 KB)
When the attached file is converted from a PowerPoint presentation into an PDF file, some of the moveto and lineto operations on the 7th page contain values of NaN.
Thanks for the report. We tried to reproduce this on our side with the attached presentation, but we don’t see it. Converting it to PDF with GroupDocs.Conversion for .NET 26.6 gives us a clean page 7 — no NaN in any of the moveto/lineto operations. We also checked a range of earlier versions and the different PDF/A and PDF/UA output formats, with the same result.
So it looks like something specific to your setup. Could you share a minimal project that reproduces it, along with the PDF you’re getting? The resulting file would help a lot here, since it pins the problem down without us having to guess at the environment.
It would also be useful to know which version you’re on, and what OS the conversion runs on. If it’s Linux or a container, please let us know which base image and whether any fonts are installed there. Page 7 of this deck is the underline and strikethrough slide, and those are drawn as paths from font metrics, so a missing font is one thing that could plausibly explain the difference between your output and ours.
Yes, this is happening in an Linux Docker container. I’ll work on making the recreation project, including the dockerfile and other items
We are also on 26.1.0. If we upgrade to 26.6.0 we are required to update System.Drawing to 7.0.0, but this causes issues on Linux with another library we use.
Here’s a reproduction. It may be a bit unintuitive but the test passes if Aspose can’t read the instructions because one of the operands is not a number. When I run the test in Reproduction.cs it will fail in Windows, but when I run it through the docker builder in RunInContainer.ps1 it will pass. The PowerPoint file included in this project is just the seventh slide of the previously shared file.
NotANumberReproduction.zip (60.1 KB)
Thanks for the reproduction — that made this quick to pin down. We reproduced it in your container.
It’s narrower than it looks: only the double underline and double strikethrough get NaN coordinates, and your load/convert options aren’t involved — plain defaults reproduce it identically. It’s Linux-only, and it came in with 25.7.0. 25.6.0 converts the same file correctly; every release since, including the latest, emits NaN, so upgrading won’t help. The impact varies by viewer too — Chrome just drops the two lines, but Acrobat shows an error and stops rendering the rest of the page.
Logged as CONVERSIONNET-8388; we’ll update this thread once the development team has looked at it. For now, 25.6.0 is the last version that renders these correctly on Linux.
One aside, since you mentioned it: on Linux, pinning System.Drawing.Common to 6.0.0 isn’t a preference; it’s required — 7.0.0 and later are Windows-only by design and throw PlatformNotSupportedException on anything else.
When we try to upgrade past 26.1.0, it fails due to the required dependency on System.Drawing.Common 7.0.0
Package restore failed. Rolling back package changes for ‘Milyli.Blackout.Conversion.AzureFunctions’.
Detected package downgrade: System.Drawing.Common from 7.0.0 to centrally defined 6.0.0. Update the centrally managed package version to a higher version.
Milyli.Blackout.Conversion.AzureFunctions → GroupDocs.Conversion 26.6.0 → GroupDocs.Conversion.Net100 26.6.0 → System.Drawing.Common (>= 7.0.0)
Milyli.Blackout.Conversion.AzureFunctions → System.Drawing.Common (>= 6.0.0)
As you’ve said, we’ve had to pin version 6.0.0 in order for it to work on Linux. Is this inability to upgrade GroupDocs.Conversion past 26.1.0 intended?
No, that’s not intended — it’s a packaging bug on our side.
26.6.0 splits into per-framework runtime packages, and the net8.0 and net10.0 ones require System.Drawing.Common 7.0.0. That’s wrong for Linux, since 7.0.0 is Windows-only. The net6.0 and net462 packages still ask for 6.0.0 — your log shows Net100 being selected, so it’s the .NET 10 build that hits it.
The restore failure is protecting you, though. We tested 26.6.0 on net10.0 on Ubuntu: with System.Drawing.Common 7.0.0 the conversion throws PlatformNotSupportedException at runtime. Bumping your central pin to 7.0.0 would get you past restore and then fail on the first conversion.
If you want to move off 26.1.0 before we fix the package, you can keep the 6.0.0 pin as-is and just stop NU1605 being fatal:
$(NoWarn);NU1605You already reference System.Drawing.Common directly, so 6.0.0 wins the resolution — the downgrade warning is the only thing failing the build. We reproduced your exact NU1605 error with a central-package-management setup like yours, applied this, and 26.6.0 then converted correctly on Linux.