History of PDFsharp &
MigraDoc project

Here are the general news and improvements of the PDFsharp & MigraDoc project.

What’s new in version 6.2

PDFsharp 6.2.0 Preview 3

PDFsharp features

Improved access to CropBox, ArtBox, BleedBox, TrimBox
PdfPage now has new properties that make access to those boxes easier. These are HasBleedBox, BleedBoxReadOnly, and EffectiveBleedBoxReadOnly.
Same applies to ArtBox, CropBox and TrimBox.

Loading images: Improved access to buffer of MemoryStream
LoadImage from MemoryStream now works with a buffer that is not publicly visible.
For better performance, set 'publiclyVisible' to true when creating the MemoryStream.

PDFsharp issues

Lexer.ScanNumber and CLexer.ScanNumber
Based on a bug that crashed PDFsharp if a number in a PDFfile has to much leading zeros, we revised the code of Lexer.ScanNumber and CLexer.ScanNumber.

No more commas allowed in XUnit
An old hack allowed XUnit to be assigned from a string that uses a comma as decimal separator. This was introduced for languages like German, that use a comma instead of a point as decimal separator. Now you get an exception. Applies also to XUnitPt.

MigraDoc features

MigraDoc Preview user control restored for GDI build
The MigraDoc Preview user control is again available in the GDI+ build. MigraDoc Preview samples for GDI and WPF have been added to the samples repository.

Color.Parse no longer causes exceptions when invoked with a number value
If Color.Parse is invoked with a number value, as in var color = Color.Parse("#f00");, it no longer throws a handled exception internally.

PDFsharp 6.2.0 Preview 2

PDFsharp 6.2.0 Preview 2

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 have recently removed the code that read 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 now can again read UTF-16 strings with LE BOM.

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.

PDFsharp features

MD5 replaced where possible
The ImageSelector class needs hash codes for internal use. We now use SHA1 instead of MD5 because MD5 is not FIPS-compliant and not supported everywhere. Early PDF encryption uses MD5. So PDFsharp must use MD5 when opening files created with such early encryptions. And PDFsharp must use MD5 when creating files with such early encryptions.

Inefficient reading of object streams
Reading files with many objects in many object streams now works much faster.

Ignore incorrect "/Length" entry on streams close to EOF
PDFsharp 6.2.0 Preview 1 failed if a PDF contained a stream close to the end of file with an incorrect /Length attribute. PDFsharp 6.2.0 Preview 2 can correct the /Length attribute even for streams close to the end of the file.

ImageSelector improved
We fixed incorrect handling of identical images with only different masks.

Issue with Google Slides
PDFsharp can now open PDF files created from Google Slides.

Size of digital signature may vary without timestamp
PDFsharp 6.2.0 Preview 1 took into account that the size of digital signatures with timestamp could vary from call to call. PDFsharp 6.2.0 Preview 2 now takes into account that the size of digital signatures without timestamp can also vary from call to call.

Option to read images from non-seekable streams
PDFsharp is now able to read images from streams that are not seekable.

PDFsharp issues

Bug fixes in PNG reader
Fixed issues with reading PNG files in Core build.

Correct datetime format in XMP meta data
Time zone was missing.

Handle Reverse Solidus without effect correctly
The reverse solidus was handled incorrectly for invalid combinations of reverse solidus and other characters.

Fixes with encrypted PDFs
Fixes for issues with encrypted PDFs.

Improved behavior or better error messages for streams with limited capabilities
PDFsharp now shows better error messages when trying to read a PDF from streams that cannot seek, cannot report their length, or are otherwise limited.

Corrected bug with page orientation
When opening and modifying existing PDF pages, there sometimes were issues due to page rotation and page orientation. Behavior has changed for page format Ledger and apps supporting Ledger format must be tested and may have to be updated. This is a breaking change.

BeginContainer issue fixed
BeginContainer and EndContainer can now be used even in GDI build when drawing on PDF pages.

MigraDoc features

MigraDoc: No more hard-coded fonts names
It is now possible to control font names used by MigraDoc for error messages and characters for bullet lists. PDFsharp 6.2.0 Preview 1 and earlier always used Courier New for error messages like Image not found and used hard-coded fonts for bullets.

MigraDoc issues

MigraDoc: Infinite loop in renderer
We fixed a bug that led to an infinite loop in PDF Renderer.

Corrected bug with page orientation
When opening and modifying existing PDF pages, there sometimes were issues due to page rotation and page orientation. Behavior has changed for page format Ledger and apps supporting Ledger format must be tested and may have to be updated. Behavior has also changed when you set a new page format or orientation after setting page height and/or page width, including modifying a Clone() of the DefaultPageSetup. The new method ResetPageSize should be called before setting PageFormat and Orientation for a "cloned" PageSetup. These are breaking changes.

PDFsharp 6.2.0 Preview 1

Features

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.

Bug fixes

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.

PDFsharp.Shared
Code that grants friendly access to all PDFsharp assemblies lives in this new assembly.

Bug in parsing object referenced
Lexer now supports white-space within object references.

Page orientation now works as expected
The connection between page Width, Height, PageOrientation, and PageRotation was weird. It was replaced by a consistent concept. This is a breaking change.

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 version 6.1.0.0.
  • We accidentally used net472-windows instead of net472 as a TargetFrameworks entry. Pointlessly, net472-windows worked fine without any issues. So does net472-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 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.

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.

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.

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, or SegoeWpFontResolver 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

References

For changes in PDFsharp see History PDFsharp

For changes in MigraDoc see History MigraDoc