Overview of MigraDoc
MigraDoc is a document generator. It supports almost anything you find in any good word processor. You just add paragraphs, tables, charts, arrange all this in sections, use bookmarks to create links, tables of contents, indexes, etc. MigraDoc will do the layout creating page breaks as needed. MigraDoc will create PDF or RTF documents.
- Your project must be .NET 6 or higher, .NET Framework 4.7.2 or higher, or .NET Standard 2.0.
- Rename XFontStyle to XFontStyleEx
XFontStyle changed its meaning.
- The Core builds (NuGet packages PdfSharp and PDFsharp-MigraDoc) no longer use Windows components and can be used under Linux and other platforms.
- The Core builds support common raster image formats. See specifications for details. Supported image formats
- The PdfDocumentRenderer now encodes text always in Unicode. The parameter is obsolete.
- MigraDoc now ignores SpaceBefore for the first paragraph on a page. With the new behavior, you can add an empty paragraph before the first paragraph, then SpaceBefore at the second paragraph can be used to add space.
- Breaking change on decimal TabStop alignment
- We adapted Microsoft Words' alignment behavior for decimal TabStops and fixed some issues. As a result there's a breaking change in MigraDocs decimal TabStop alignment.
- '.' and ',' are no longer both recognized as decimal separator. Instead, the decimal separator defined in the current culture is used for alignment. This way we fixed alignment of numbers containing group separator but not decimal separator.
- Introduced a Culture property in Document to use a decimal separator and group separator differing from current culture.
- Fixed alignment of numbers like ".5" and "-.5"
- The DefaultPageSetup should never be modified. Attempts to modify it may now lead to exceptions. Create a Clone() of the DefaultPageSetup and change that as needed.
- Change on rendering RTF files:
PDFsharp now provides a consistent behavior for all tabstop usages in PDF and RTF generation. In RTF itself, there is no tab needed to reach a single decimal tabstop that is located inside a table. This is a special case which differs from all other tabstop usages where a tab is always needed to reach a tabstop.
To achieve a consistent behavior where a tab is always needed, PDFsharp renders an additional tabstop at position 0 in this special case on RTF generation.
The old behavior can be restored using the backward compatibility setting MigraDoc.Capabilities.BackwardCompatibility.DoNotUnifyTabStopHandling.