In OOXML, table row can define table properties named 'table level property exception' using 'tblPrEx' element. These properties shall be respected by the row instead of the table properties defined on table level.

Add similar property in the TableRow model and respect it in the corresponding exports.

The 'border' attribute of Html <table /> is imported wrong. When set to 0, a 1px border is rendered. 

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.

Import of Tables with border style needs improvements. Currently, it takes multiple seconds to import table with 100x6 cells no matter if the border style is defined globally or locally. This may be seen when importing the attached files "table with borders.html" and "table single border style.html". Importing the same table without borders is achieved in less than a second which may be seen with the attached "table without borders.html".

This property allows the user to set the transparency of the image watermark. In the XML, the property is written using the 'blacklevel' attribute of the image.

If HTML document is imported, and it contains image with invalid URL, then the image is imported with this URL in the document model. On subsequent export to Docx, the library tries to download the image data, which throws WebException. Instead, the image should be replaced with generic 'error' image.

Workaround: Manually test the image URL for correctness on HTML import, and replace the data:

        static void Main(string[] args)
        {
            HtmlFormatProvider htmlFormatProvider = new HtmlFormatProvider();
            htmlFormatProvider.ImportSettings.LoadFromUri += (sender, e) =>
            {
                if (!IsValid(e.Uri))
                {
                    e.SetData(File.ReadAllBytes("no-image.png"));
                }
            };
        }

        private static bool IsValid(string uri)
        {
            try
            {
                using (WebClient client = new WebClient())
                {
                    client.DownloadData(uri);
                }
            }
            catch (WebException)
            {
                return false;
            }

            return true;
        }

When MergeField is present in the document, and this merge field is evaluated to an empty string - this, for example, happens when the property in the data source is set to null, empty string, or is missing at all - the result fragment remains in the result document. Instead, it should be removed.

Steps to reproduce: 
- Create document with merge field, the field should contain result fragment, and set data source which contains null or string.Empty value for the field:

            RadFlowDocument document = new RadFlowDocument();
            RadFlowDocumentEditor editor = new RadFlowDocumentEditor(document);

            editor.InsertField("MERGEFIELD FirstName ", "«FirstName»");

            List<Person> source = new List<Person>()
            {
                new Person() { FirstName = string.Empty }
            };

            RadFlowDocument mergedDocument = document.MailMerge(source);
Expected: The result document is empty.
Actual: The result document contains "«FirstName»" string.

Available in LIB Version 2017.3.1120.

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.

Implement import of bullets and numbering which use the old Word 6.0/Word 95 format from RTF. This includes, but is not limited to, the following RTF tags: \pnlvlN, \pnlvlblt, \pnlvlbody, \pnlvlcont. See RTF specification, "Word 6.0 and Word 95 RTF" heading for full description.
WordPad and some legacy systems export lists with this formatting, so the construction is relatively widespread.
According to the specification, if RTF reader doesn't support specific bullets/numbering tags, it can use the \pntext tag to read the bullets/numbering as plain text; but currently WordsProcessing always ignores the \pntext tag. Because of this, the bullets or numbers of lists in the old format are missing after import.

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

When the current position is in the middle of a paragraph and the InsertSection() method is invoked, it should automatically split the content at the current position and transfer the content that is on the right side of the position to the new section along with all the following blocks. 

At this point, the method transfers only the content of the current paragraph and, if the section has following paragraphs, they are left in the "old" one.

The exception is thrown because we try to export a tblGrid element, but currently we do not support this: https://feedback.telerik.com/Project/184/Feedback/Details/190082-wordsprocessing-export-tblgrid-table-grid-property-for-table-elements

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.

Enable the customers to add digital signatures to the documents and read signed documents.

The calculations are wrong, leading to single lines on a page. As a result, the content of the PDF document is laid out on a bigger number of pages.

Workaround: Change the line spacing and its type before exporting to PDF:

foreach (var paragraph in this.document.EnumerateChildrenOfType<Paragraph>())
{
	HeightType? heightType = paragraph.Properties.LineSpacingType.GetActualValue();
	if (heightType == HeightType.Exact || heightType == HeightType.AtLeast) 
	{
		paragraph.Properties.LineSpacingType.LocalValue = Telerik.Windows.Documents.Flow.Model.Styles.HeightType.Auto;
		paragraph.Properties.LineSpacing.LocalValue = 2;
	}
}