The Indent property of Table is not respected by PdfFormatProvider.

Add support for importing HTML with syntax <img style="width: 300px; height: 300px;" /> At the moment only HTML attributes are supported.

There are multiple tags and attributes in the Open XML model which define the formatting of the complex script characters and are not implemented in the WordsProcessing model. 

Such tags are:
szCs: Complex script font size;
bCs: Complex script bold;
iCs: Complex script italic;

Attributes:
cstheme: Complex Script Theme Font;

The cs (Complex Script Font) attribute is implemented in the export, but it is not preserved in the model on import.

When exporting a nested table, which is inside a table with cells whose sum of widths is more than 100%, the last cells are missing from the exported with PdfFormatProvider document.

The issue is not observable in the other format providers.

The issue is reproducible only in a specific setup with a specific document. It is related to the calculations of the line spacing when the table row should be split between two pages.

Workaround: Change the line spacing:
foreach (var paragraph in this.document.EnumerateChildrenOfType<Paragraph>())
{
    paragraph.Properties.LineSpacingType.LocalValue = HeightType.Auto;
    paragraph.Properties.LineSpacing.LocalValue = 1;
}

Applying border="1" to a table element, should set table cells borders to the same value. Currently, only the table borders are set.

When the RowSpan value is bigger than the available rows, a ArgumentOutOfRangeException is thrown while exporting the document.

Workaround: Change the value of RowSpan after importing:

foreach (var cell in document.EnumerateChildrenOfType<TableCell>())
{
    while (cell.RowSpan > cell.Row.Table.Rows.Count)
    {
        cell.RowSpan--;
    }
}

Add support for the <w:sym /> element, e.g.:

<w:r>
   <w:sym w:font="Wingdings" w:char="F0FC"/>
</w:r> 


From the specification:
"This element specifies the presence of a symbol character at the current location in the runs content. A symbol character is a special character within a runs content which does not use any of the run fonts specified in the rFonts element (17.3.2.26) (or by the style hierarchy).

Instead, this character shall be determined by pulling the character with the hexadecimal value specified in the char attribute from the font specified in the font attribute."

Currently such symbols are skipped during DOCX import.

Possible workaround: These tags are inserted from MS Word when the Symbol dialog in used. If the document is created with MS Word, the user could insert the symbol using the keyboard, in this case the character is inserted as a normal run.

When a document with ordered list is exported to RTF and opened with WordPad or WinForms' system RichTextBox the numbers of the list are replaced by "{0}".

When a table cell has a smaller width set and inside there is a paragraph with larger indent set or bullets, the table does not expand in order to show the text and the text becomes invisible.

Run's default constructor creates it with Text = null. When document with such run is exported to PDF, NullReferenceException is thrown.

Workaround: Create the Run and immediately set its Text property to string.Emtpy.

Available in LIB Version 2018.1.423.

Applying LockAspectRatio to an image is not respected after opening the document in MS Word - the LockAspectRatio checkbox in the is not checked. An additional XML element (cNvGraphicFramePr) should be added so the UI can respect it.

Add support for exporting hyperlinks which are not valid URIs to PDF. Currently such hyperlink URIs are not exported to the PDF document.

Example of such hyperlink is "mailto:abc%20abc-abc-abc%20%3cabc@abc.com%3e" (mailto:abc abc-abc-abc <abc@abc.com>), but there could be more types. Currently the internal API relies on creating instance of the system Uri class, which is not possible in this case.

Currently there is no easy way to modify the properties of bookmarks and fields in the document. Think of providing API for easier manipulation.

For example, following is one of the easiest approached to change the target of hyperlinks:

                    var hyperlinkStarts = document
                        .EnumerateChildrenOfType<FieldCharacter>()
                        .Where(fc => fc.FieldCharacterType == FieldCharacterType.Start && fc.FieldInfo.Field is Hyperlink);

                    foreach (var fieldCharacter in hyperlinkStarts)
                    {
                        int indexOfCodeRun = fieldCharacter.Paragraph.Inlines.IndexOf(fieldCharacter) + 1;
                        Run hyperlinkCode = (Run)fieldCharacter.Paragraph.Inlines[indexOfCodeRun];

                        string oldUri = ((Hyperlink)fieldCharacter.FieldInfo.Field).Uri;
                        string newUri = "mailto:mail@mail.com";

                        hyperlinkCode.Text = hyperlinkCode.Text.Replace($"\"{oldUri}\"", $"\"{newUri}\"");
                        fieldCharacter.FieldInfo.UpdateField();
                    }

If the background color is applied to <tr> element then it is not imported.

Workaround: The background color may be applied to the cells (<td> elements) in the desired row and this should have the same effect.

When importing paragraphs with negative text-indent from HTML, e.g. 
<p style="text-indent:-12px;">
test
</p>

they should be imported with HangingIndent + the same value with negative sign for LeftIndent, e.g. HandingIndent: 12 AND LeftIndent: -12.

Also, margin-left should be combined with the text-indent, e.g.
<p style="margin-left: 16px;text-indent: -16px;">
test
</p>
should be imported as HandingIndent: 16 AND LeftIndent: 0.

This element specifies that the nearest ancestor structured document tag shall be of a document part type.

<w:sdt>
<w:sdtPr>
…
<w:docPartObj>
…
</w:docPartObj>
</w:sdtPr>
…
</w:sdt>
The docPartObj element in this structured document tag's properties specify that the type of structured document tag is a document part. The child elements must specify the gallery and category semantics for this part, if any.
Currently, such elements are skipped on import.

When paragraph contains only merge fields (and eventually whitespaces), and all of these fields are evaluated to empty string for particular data record, the paragraph could be removed from the merged document.

Example: The document contains two paragraphs:
<<FirstName>>
<<LastName>> <<Address>>

For particular data record, LastName and Address are empty, so the merged document for this data record will contain only one paragraph (the first one). This behavior is expected from customers, as it's implemented by MS Word.

At the moment when a Floating Image is exported to HTML, it is exported as inline and its position is lost.

Exporting to PDF of a table with a first cell having preferred width of 100% and a second cell having preferred width of auto will result in missing the second cell.