First of all, please see my comment to the question. It's long enough to continue in a separate post, but first of all because if has to be some kind of the answer.
From my explanations of this situation, you probably should have understood by now, that it's very likely that you are the one who should do all this work. Can you tell me why not?
There is nothing special in your requirements, nothing very new. The most difficult requirement will be quick load of 10 M of text. Actually, there is one peculiarity of WPF, due to which my incomplete WPF editor (not the one I use on regular basis), actually loads this very quickly, but… when you scroll it, say, to the middle, it becomes slow. This is because WPF has separate UI and rendering threads.
You missed some important features, such as indication of the position of the caret (simple in WPF) and such thing as macro, at least keyboard macro (I implemented them, but, unfortunately, not completely without P/Invoke; something important is still missing from WPF).
Why PDF? Not XPS (which I think is better then damn PDF in a number of aspects)?
Also, your centering, alignment, etc. does not look adequate. It should either be missing, or you would go to the other end, implementation of features close to Microsoft Word or rather LibreOffice (
http://en.wikipedia.org/wiki/LibreOffice[
^]).
If you want to go take this route, why not considering
System.Windows.Documents.FlowDocument
? Please see:
http://msdn.microsoft.com/en-us/library/aa970909.aspx[
^],
http://msdn.microsoft.com/en-us/library/system.windows.documents.flowdocument.aspx[
^].
The contradiction, again, is that you want to show different paragraph alignment but, as I can understand from your list, not different fonts (I refer to the first item of your list). This is not in line with any of the components you might use as a base class. Or you would need to start from very low level, from
Control
class with custom rendering. But imagine what happens if you use Rich Text of
FlowDocument
as the base. You can enforce one uniform font throughout the document. So far so good. But here is the catch: you will have also suppress the clipboard Paste and replace it with your own. Do you see why? Otherwise an attempt to Paste will insert a text fragment with source formatting, something your document is not suppose to render. Not that this is too difficult; it is rather unpleasant.
What else? XML. There is no "just XML". It could be this:
http://en.wikipedia.org/wiki/OpenDocument[
^].
PDF export? Usually, people use iText, or its .NET port, iTextSharp:
http://en.wikipedia.org/wiki/IText[
^],
http://itextpdf.com/[
^],
http://sourceforge.net/projects/itextsharp/[
^],
http://www.javatips.net/blog/2011/09/create-pdf-with-itext-java-tutorial[
^].
Again, consider XPS:
http://en.wikipedia.org/wiki/Open_XML_Paper_Specification[
^].
This is a standard thing:
http://www.ecma-international.org/publications/standards/Ecma-388.htm[
^].
By the way,
FlowDocument
can be exported as XPS.
I've mentioned only a small part of your list. I guess, the main problem will be the choice. You will deal with the temptation to start everything from scratch (in the sense I described above) and the lacks of helping features in existing text-editor-like components and related brick wall. Well, several brick walls… :-)
—SA