When there is an abstractNum defined with the same abstractNumId in word\glossary\numbering.xml and in the word\numbering.xml, a "System.ArgumentException: An item with the same key has already been added." exception is thrown.

In other cases, the import overwrites the styles from the main document part with the ones defined in the glossary or fails to import different parts of the content. 

Workaround: Delete the glossary files:

string path = "File.docx";
using (Stream str = new FileStream(path, FileMode.OpenOrCreate, FileAccess.ReadWrite))
{
	using (ZipArchive archive = ZipArchive.Update(str, null))
	{
		foreach (ZipArchiveEntry entry in archive.Entries.ToList())
		{
			if (entry.FullName.Contains("glossary/"))
			{
				entry.Delete();
			}
		}
	}

	DocxFormatProvider provider = new DocxFormatProvider();
	RadFlowDocument flowDocument = provider.Import(str, null);
}

MS Excel offers the following text styling options:

I'm working on a project that has a service component that will be generating Excel xlsx documents for distribution.  While there is a UI for administrative tasks, the service itself will run without an interface.  I'm using the Documents.Core, and several other associated libraries to accomplish this.  Two issues I've encountered, one is setting up the project with the appropriate libraries and keeping the version in sync with the Admin application, second is protecting those libraries once they are packaged for release.  I had a support ticket open to determine how to accomplish the latter, but the first is still a manual issue.  

So the feature request is to include the ability in the project templates and/or Convert to Telerik WPF Application to support a headless document solution.  It would ideally include (only) the required libraries and maintain their linkage to the appropriate library version with the rest of the solution which occurs with a full Telerik WPF UI app.  It would also include the necessary boilerplate code and references to properly protect the libraries.  I was referred to another feedback request on improving the overall library protection build process, but while related, what I'm asking for here is not exactly the same.