The TextProperties.FontSize property specifies the font size for text fragments. The property is of type double. The measurement unit used for font size in RadPdfProcessing is Device Independent Pixels (DIPs). You can convert it to points or other units using the Unit class.

However, when using the TextProperties with widgets the font conversion is not correct. Let's consider the case that we build a PDF document with a TextBoxField occupying a specific rectangle. According to the set text value, we should calculate the appropriate font size so the whole content can fit in the widget's rectangle.

        /// <summary>
        /// Creates a TextBoxField with calculated font size for the given rectangle
        /// </summary>
        private static TextBoxField CreateTextBoxWithCalculatedFont(string name, string text, Rect rect, double fontSize, FontBase font)
        {
            TextBoxField field = new TextBoxField(name);
       
            field.TextProperties.FontSize = Unit.DipToPoint(fontSize);
            field.TextProperties.Font = font;
            field.Value = text;

            var widget = field.Widgets.AddWidget();
            widget.Rect = rect;
            widget.Border.Width = 0;
            widget.TextProperties.FontSize = Unit.DipToPoint(fontSize); 
            widget.TextProperties.Font = font;

            return field;
        }

        /// <summary>
        /// Calculates the optimal font size for text to fit within a specific rectangle
        /// </summary>
        public static double CalculateFontSizeForRectangle(string text, Rect rect, FontBase font)
        {
            double fontSize = 0;
            Size measuredSize = new Size(0, 0);
            Size availableSize = rect.Size;
            while (measuredSize.Width<availableSize.Width && measuredSize.Height< availableSize.Height)
            {
                fontSize++;
                Block block = new Block();
                block.TextProperties.FontSize = fontSize;
                block.TextProperties.Font = font;
                block.InsertText(text);
                measuredSize = block.Measure();
            }

            return fontSize-1;
        }

            // Example: Wide textbox with calculated font size
            string wideText = "This is a wide textbox that demonstrates horizontal fitting of text content.";
            Rect wideRect = new Rect(200, 500, 400, 30);
            double wideFontSize = CalculateFontSizeForRectangle(wideText, wideRect, font);

            TextBoxField wideTextBoxField = CreateTextBoxWithCalculatedFont("WideTextBox", wideText, wideRect, wideFontSize, font);
            document.AcroForm.FormFields.Add(wideTextBoxField);
            var wideWidget = wideTextBoxField.Widgets.First();
            page.Annotations.Add(wideWidget);
            wideWidget.RecalculateContent();

Registering the font used to be enough for resolving the font's characters in .NET Standard

			byte[] fontData = File.ReadAllBytes(".\\files\\cour.ttf");
			FontFamily courierNewFont = new FontFamily("Courier New");
			FontsRepository.RegisterFont(courierNewFont, FontStyles.Normal, FontWeights.Normal, fontData);

However, as of  version 2024.2.426 registering the font doesn't produce the correct result anymore and the text got missing in the PDF fields. When the document is opened in Adobe, the following message appears: 

The FontsProvider works in both versions (before and after 2024.2.426). It is also required to iterate all widgets and apply the font explicitly to the widget.TextProperties.Font property.

InvalidCastException is thrown when importing a document with a structure element with an indirect reference to an integer value.

InvalidCastException: 'Unable to cast object of type 'Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Types.PdfInt' to type 'Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.MarkedContents.StructElementObject'.'

Setting the ComplianceLevel to PdfA3B and the TaggingStrategy to UseExisting when exporting a PDF document leads to the following Error reported by VeraPdf:

Specification: ISO 19005-3:2012, Clause: 6.2.11.5, Test number: 1
For every font embedded in a conforming file and used for rendering, the glyph width information in the font dictionary and in the embedded font program shall be consistent.
Glyph width 274.4140625 in the embedded font program is not consistent with the Widths entry of the font dictionary (value 272)

From R1 2017 all annotations (including sound and video) are supported for import-export scenarios by using PdfStreamWriter class. 

These feedback item will be opened as we may add API for generating and inserting new sound annotations from scratch in the file.

When a source RadFixedDocument is merged to a target RadFixedDocument, the content of the source document is cleared.

WinAnsiEncoding it is imported as StandardEncoding since WinAnsiEncoding is still not implemented in RadPdfProcessing. 

 This is content stream operator that is used to close, fill and then stroke a PDF path geometry.

Available in R3 2018 SP1 release.

When images are added to the document with non-default quality (PdfExportSettings.ImageQuality different that ImageQuality.High) , they are re-encoded, which uses a lot of memory and may cause OutOfMemoryException for large images.
Workaround (works when inserting big JPEG images): In this case ImageQuality.High may be used and RadPdfProcessing will decode only the image headers to insert the image into the PDF file. As image pixels are not decoded with ImageQuality.High, there will be no OutOfMemoryException.

This would allow creating documents with preferences such us HideToolbar, HideMenubar, FitWindow, PrintScaling and all other viewer preferences specified in PDF format specification.

OutOfMemoryException is thrown when generating PDF with many pages each of which contains images, as all of the document model data is in-memory.

The issue is fixed with the new PdfStreamWriter API. As an example, you may see the attached demo to the following feedback item:
https://feedback.telerik.com/Project/184/Feedback/Details/213503-pdfprocessing-optimize-pdfstreamwriter-cache-in-order-to-reduce-memory-when-writ

Available in LIB version: 2017.1.320

This is happening when the pages in the document has content arrays similar to the following:

[34 0 R 243 0 R] [34 0 R 245 0 R] [34 0 R 247 0 R] ....

As you may notice the content stream 34 0 R is reused and the issue is caused by incorrect caching of content stream indirect objects by their reference.

The current implementation of IDisposable implements a simple Dispose method which releases the inner stream resource. However, if the PdfStreamWriter instance is not disposed explicitly by calling Dispose() or by surrounding it in "using" clause, then the inner Stream resource is not Disposed as well. The same applies for PdfFileSource class.

We should implement the IDisposable pattern in a way that the GC disposes the inner stream if needed when collecting the PdfStreamWriter/PdfFileSource class instances.