History of PDFsharp &
MigraDoc project
Here are the general news and improvements of the PDFsharp & MigraDoc project.
For changes in PDFsharp see History PDFsharp
For changes in MigraDoc see History MigraDoc
What’s new in version 6.2.0
Breaking changes
CoreBuildFontResolver removed
See General features below.
General features
CoreBuildFontResolver removed
The code was removed from PDFsharp but still exists in the samples repository.
To reactivate the old behavior under Windows, set UseWindowsFontsUnderWindows to true.
To reactivate the old behavior under WSL2, set UseWindowsFontsUnderWsl2 to true.
Note that these settings only have an effect for the Core build.
Also note that these settings only have an effect under Windows or WSL2, respectively.
No fonts will be found under Linux or MacOS, so do not use these properties if you want to develop portable Core applications.
GlobalFontSettings.UseWindowsFontsUnderWindows = true;
GlobalFontSettings.UseWindowsFontsUnderWsl2 = true;
The name is now SubstitutingFontResolver and it can be found in the PDFsharp.Samples repository.
Information about font resolving
UTF-16LE
We had recently removed the code that reads UTF-16LE strings because that format was not mentioned in the PDF specs. We found a PDF file created with Adobe PDF Library 18.0.3 that contains UTF-16 strings with a LE BOM. PDFsharp can now again read UTF-16 strings with LE BOM.
Digital signatures
PDF documents can now be signed with a digital signature.
Multi-colored glyphs
Multi-colored glyphs like emojis are now supported.
.NET Framework 4.6.2
All assemblies have downgraded .NET Framework references in <TargetFrameworks>
from 4.7.2 to 4.6.2.
net472
becomes net462
.
.NET 8
We added .NET 8 (net8.0
) to <TargetFrameworks>
.
PDF/A
PDF documents can now be PDF/A-conforming. We are still working on this feature, so currently there are some limitations.
PDFsharp.Shared
Code that grants friendly access to all PDFsharp Project assemblies lives in this new assembly.
General issues
Updated NuGet package references to avoid vulnerability warnings
The warnings came from transitive packages, i.e. packages used by packages that were referenced by PDFsharp.
The vulnerable code was not invoked by PDFsharp.
MD5 replaced
We use the class MD5Managed instead of MD5 from .NET.
One reason is that .NET MD5 cannot be used in a FIPS-compliant environment.
Another reason is that some platforms like Blazor do not support the retired class MD5 anymore.
Some PDF encryption versions require MD5, therefore it is not possible to remove MD5 completely.
For FIPS-compliance, do not use encryption standards that are based on MD5.
Cleanup NuGet packages
MigraDoc packages now depend on PDFsharp NuGet packages instead of including assemblies directly.
All packages now depend on e.g. Microsoft.Extensions.Logging
instead of including the Microsoft assembly.
.restext files removed
Some assemblies had a subfolder de
containing German messages.
We removed all .restext
resources. All messages are now available in US English only.
What’s new in version 6.1.1
PDFsharp 6.1.1 contains bug fixes.
- Fix in class ImageSelector in GDI build that prevents reading pictures correctly from memory streams.
- Fix for PDF User Access Permissions that prevents PDFsharp from reading correct PDF files with all bits set in this flags value.
- Each PDFsharp assembly now has a build number in the assembly file version that is increased with every new release.
It is
6.1.1.7121
for this version (days from 2005-01-01 to 2024-07-01). While using semantic versioning works fine when your project relies on NuGet packages, it may lead to issues when you add PDFsharp assemblies to your customized setup program. Windows setup updates assemblies if, and only if, the assembly file version is larger than the already installed one. All PDFsharp 6.1.0 assemblies from preview 1 to RTM had the same assembly file version6.1.0.0
. - We accidentally used
net472-windows
instead ofnet472
as aTargetFrameworks
entry. Pointlessly,net472-windows
worked fine without any issues. So doesnet472-abc123
. We have no idea why.
What’s new in version 6.1
Notes on version 6.1.0
This version brings new features like the Interpolate property of the Image class in MigraDoc.
We improved the image handling and the font handling, so in some cases you will get smaller PDF files as a result.
Notes on version 6.1.0 Preview 3
The Core build now uses a built-in font resolver that will support basic fonts like Arial and Times New Roman when run under Windows or WSL2. Surrogate fonts will be used when run under Ubuntu Linux, but font support may vary depending on the Linux distribution. No fonts will be found when running under MacOS.
When distributing applications that use the Core build, make sure to include a font resolver that handles all font requests your application depends on, so it can run on any computer that supports the Core build, including MacOS and others.
Notes on version 6.1.0 Preview 1
Version 6.1.0 adds multi-targeting, supporting .NET 6 and .NET Standard 2.0 for the Core build and .NET 6 and .NET 4.7.2 for the GDI+ and WPF builds.
We are still working on the default FontResolver for the Core build. With version 6.1.0 it is highly recommended to supply a FontResolver for the Core build.
You can try SegoeUiFontResolver
or SegoeWpFontResolver
that are included with this release while evaluating PDFsharp. Note that these FontResolvers are meant to get you started. For applications that use the Core build you should include an own implementation of IFontResolver that fulfills your requirements.
Feel free to use the code of those supplied FontResolvers to create your own FontResolver according to your requirements.
The assemblies are now strong-named (*.snk
) again because version 6.1 supports .NET Standard 2.0 and .NET Framework 4.7.2. See Strong Name Signing for further information why.
What’s new in version 6.0
Notes on version 6.0.0
We are still working on the default FontResolver for the Core build. With version 6.0.0 it is highly recommended to supply a FontResolver for the Core build.
You can try NewFontResolver
, SegoeUiFontResolver
, or SegoeWpFontResolver
that are included with this release. Note that NewFontResolver
was renamed to SnippetsFontResolver
with version 6.1.0 Preview 1. Note that SnippetsFontResolver
is no longer available as of version 6.1.0 Preview 3.
Feel free to use the code of those supplied FontResolver to create your own FontResolver according to your requirements.
Ported to .NET 6
- PDFsharp now based on .NET 6. So it runs where .NET 6 runs including Windows, Linux, and Mac.
- PDFsharp 1.5 based on .NET Framework will keep available on GitHub but will not be maintained anymore.
- PDFsharp packages come in three flavors:
- The Core version that runs everywhere where .NET runs.
- The GDI+ build that uses GDI+ (System.Drawing) and runs under Windows only.
- The WPF build that uses Windows Presentation Foundation and runs under Windows only.
- Versioning switched to semantic versioning for the NuGet packages. The package version is now aligned with the .NET version.
- Outdated concepts removed:
- The assemblies are not strong-named (
*.snk
) anymore. See Strong Name Signing for further information why.
- The assemblies are not strong-named (
Differences between Core build and the other builds
The Core build does not depend on Windows-specific assemblies. This allows the Core build to be used under other platforms like Linux and macOS, but leads to some differences.
- Font handling: Both the GDI+ build and the WPF build allow you to use all TrueType fonts installed under Windows without writing any code. The portability of the Core build requires a FontResolver that supplies the font data. You can try
SnippetsFontResolver
,SegoeUiFontResolver
, orSegoeWpFontResolver
that are included with this release. - Image formats: The Core build supports Windows BMP files, Portable Network Graphic PNG files, and JPEG files. We recommend to convert other images to the Windows BMP format. Images will be compressed when they are added to PDF. While conversion from e.g. GIF to BMP leads to larger image files, the resulting PDF files should have about the same size.
- Font outlines: The GDI+ and WPF build can convert font glyphs to graphical paths, allowing them to be used with graphical operations. One use are large texts with special effects, e.g. for watermarks. This is not yet possible with the Core build. Color can still be applied to text, but some advanced styles cannot yet be achieved.
Code review and update
The source code was revised. Here are the most important changes.
- Old code for Silverlight, WRT, Windows Phone was mostly removed.
- Code uses new C# features until C# 11
- Code was reworked for nullable value types. All projects are now 'nullable' enabled.
- The attribute InternalsVisibleTo is not required anymore, exceptions may be unit tests.
Benchmark results
We achieved speed improvements in many areas. See MigraDoc history for details: MigraDoc benchmark results
Update from older versions
For information about the transition from PDFsharp 1.5 or PdfSharpCore 1.3 to PDFsharp 6 see Upgrade to PDFsharp 6.