At this point the PdfFormatProvider does not support floating images and these elements are skipped when exporting to PDF.

The feature is trivial for floating images with "Behind Text"/"In Front of Text" settings, but otherwise floating images are affecting the text layout in complex ways.

Add support for shapes, and especially for shapes with textual content. 
In OOXML, shapes are represented by the wps:wsp element, and shapes with textual content by <wps:txbx>, <w:txbxContent>.
Such shape can be added to a Word document using the Insert -> Text -> Text Box -> Draw Text Box, or through a shape's context menu -> Add Text.

Do not confuse these shapes with Text/Rich Text content controls (see https://feedback.telerik.com/Project/184/Feedback/Details/190057 )

At this point, the justify alignment is not supported. Provide the ability to export text with this setting.
This functionality is dependent on PdfProcessing: Provide API for setting the text alignment to Justify

Implement nested mail merge and master-detail scenario.

Implement support for content controls (a.k.a. Structured document tags), which will allow inserting editing controls in the document:

- Rich Text
- Plain Text
- Check Box
- Combo Box
- Drop-down list
- Date picker

Do not confuse this feature with form fields support (see https://feedback.telerik.com/Project/184/Feedback/Details/219850 ).

This feature includes: table of figure, table of tables etc.

TOC field contains PageRef fields inside it. To update it, we will need pagination (layout) support and PageRef fields implementation. Also TOC update can be influenced by TC fields presence in the document.

Implement export to PDF.

The API should allow you to perform a text-based search and return the parent element(s) of the result(s) or directly the found element(s).

The attached sample project below demonstrates a possible workaround for PAGE and NUMPAGES fields when exporting to PDF. The demo shows how to generate document from scratch containing PAGE and NUMPAGES fields and export it to PDF.

In WordsProcessing you could set 

table.Alignment = Telerik.Windows.Documents.Flow.Model.Styles.Alignment.Center;

But when the document is exported to PDF, this is not respected.

Enable the customers to work with .doc files.

Introduce an option to replace a Run text with line breaks and/or new lines or with other document elements such as Table, Image, Paragraph and etc. 

The following code snippet shows how a Run can be replaced with another inline element:

RadFlowDocument document = new RadFlowDocument();
RadFlowDocumentEditor editor = new RadFlowDocumentEditor(document);
 
editor.InsertText("text");
editor.InsertText("REMOVE");
editor.InsertText("text");
 
foreach (Run run in document.EnumerateChildrenOfType<Run>().ToList())
{
    if (run.Text == "REMOVE")
    {
        Paragraph paragraph = run.Paragraph;
        int childIndex = paragraph.Inlines.IndexOf(run);
 
        ImageInline image = new ImageInline(document);
        using (Stream stream = File.OpenRead("example_image.png"))
        {
            image.Image.ImageSource = new Telerik.Windows.Documents.Media.ImageSource(stream, "png");
        }
 
        paragraph.Inlines.Insert(childIndex, image);
        paragraph.Inlines.Remove(run);
    }
}

Respect the Height property of TableRow when exporting with PdfFormatProvider.

Add support for horizontal lines in documents.

In DOCX, such lines are defined using the legacy VML definitions:
The definitions above and the <hr/> HTML tag are currently not supported and skipped on import, leading to missing horizontal lines in the document.

Hyperlinks with fragment identifiers are not resolved correctly.

Example:

https://docs.telerik.com/devtools/document-processing/libraries/radwordsprocessing/overview#key-features

The vertical alignment of the table cells is not exported to PDF. The values are always exported with top alignment.

When this type of section break is used, the next section should start on the same page instead on the next one.

Text frames are paragraphs of text in a document which are positioned in a separate region or frame in the document and can be positioned with a specific size and position relative to non-frame paragraphs in the current document. More information about it is available in section 22.9.2.18 ST_XAlign (Horizontal Alignment Location) of Open Office XML.

Currently some properties are supported only in their shorthand forms, and others - only in their longhand forms:
- 'background' shorthand is not supported.
- 'margin' shorthand is not supported.
- 'padding' shorthand is not supported.
- 'border' shorthand is supported, but 'border-bottom-color', 'border-bottom-style', 'border-bottom-width', 'border-left-color', 'border-left-style', 'border-left-width', 'border-right-color', 'border-right-style', 'border-right-width', 'border-style', 'border-top-color', 'border-top-style', 'border-top-width', 'border-width' are not supported.
IMPORTANT: This feature is available in .NET Core, .NET 6 and above.

Currently, the text is exported but the strikethrough line is not drawn in the exported PDF.

When exporting a DOCX file to PDF format, the following error message occurs: