Well, there are two parts to a word processor. One is managing the document model (with all auto-updating and complex layouting), and the other is getting it shown on screen.
The text view is only a view, so it only handles the latter. To do this, it needs a rather low-level view of the things to render. It is up to the word processor application to process your document and provide the view with some pre-layouted rendering instructions.
If the text view design starts with “HTML” or “PDF”, I think things have already gone wrong. What we need is a view with an API to drive it. Parsing and rendering specific document formats is not something to be handled on that side, but on the side of applications wanting to use the view.
For HTML, we are mostly covered with WebKit. There is a little work to be done to clean up the APIs for BWebView, but it’s already there in WebKit sources and could be exposed for apps to use it. However, it is not designed to be an editor for HTML documents, more a viewer/browser.