The TableStylesGallery keeps a reference to the document, which doesn't allow the GC to collect it. The issue is reproducible when the document is loaded in RadRichTextBox in the constructor of the window or in its Loaded event.

When the specified length of the stream is larger than the actual one, Adobe throws errors and removes the image.

Workaround:

Set the format provider settings:

PdfFormatProvider provider = new PdfFormatProvider();
PdfExportSettings exportSettings = new PdfExportSettings();
exportSettings.ContentsDeflaterCompressionLevel = 9;
exportSettings.ImagesDeflaterCompressionLevel = 9;
provider.ExportSettings = exportSettings;

As a result, table is visualized in RadRichTextBox with extremely large column widths.

The label for Decimal alignment is truncated.

The theme color is with higher priority. Thus, when the document is exported to DOCX and opened again, the default color is applied to the style.

The invalid document can't be measured and IndexOutOfRangeException/NullReferenceException will be thrown.

I have tried to use the RichTextBox, but found that it does not work very well when it comes to measure the text. This results in clipped text and that the caret can be displayed in a different place then expected.
This can easily be seen with a font like Gabriola, which uses complex kerning metrics. Type a text with a lot of "ff" and "fi" and you will soon see that your caret gets out of sync and that text is sometimes clipped.
When I look at the code of RichTextBox it seems to me that it uses its own calculation of text widths and that the this is based on a very simple method using just the kerning information. There is also a hard coded list containing information which fonts that has kerning info and which fonts that are mono spaced. It seems strange to me to have this in a config file since there is a large number of fonts used by the users.
It also seem to look at the Unicode character family in order to determine if ligatures are used or not, which is also quite strange since ligatures can be used for western characters too. The font Gabriola is an example of this. Look at "fi" in a word like "fine".
It can potentially consume a lot of memory since I think that it builds a dictionary of the kerning of all pairs of characters for all fonts that it encounters.
I guess this way of doing things were made for performance, but unfortunately, good performance doesn't help much if it doesn't work.
I am not sure if I should report this as a bug, since it is more of a fatal design issue of the whole control.

please add shapes support for radrichtextbox. else support another textbox

Please look for the same topic in the forum for context. 
@Todor:
Am attaching the wmf file and png file that don't get rendered.

Possible workaround is to change the document of RadRichTextBox.

The fix will be available in our next LIB release (v. 2016.1.208).

Tab leader (dots) are calculated based on the available space between the end of the text in the entry and the page number. 

Workaround: to change rendering mode to TextBlockWithPropertyCaching:

this.radRichTextBox.TextRenderingMode = TextBlockRenderingMode.TextBlockWithPropertyCaching;

Workaround: Caret could be changed with custom implementation. More information could be found in this help article: http://docs.telerik.com/devtools/wpf/controls/radrichtextbox/ime-support#how-to-implement-your-own-ime-support

When a color property has default (auto) value, do not export a tag which points to omitted defintion in the color table. For example, if a span has transparent highlight (the default one), do not export the \highlight tag since this might lead to some incorrect rendering of the document from other readers - WordPad for example.

The issue is sporadic. Updating the UI resolves it.

Workaround: manually call
this.radRichTextBox.ActiveEditorPresenter.RecreateUI();
just after the acception.