I think a better solution is to develop a standard HTML5, CSS and JavaScript combo that researchers can use to publish articles online. The requirements are that using it should be no more difficult than writing papers in Latex, and the layout results should be equally as good.
I've thought about this for a while now. It seems terribly silly for us to spend so much time formatting our papers as pdfs when people mostly read them on a computer anyway. I've been to conferences that - smartly - don't even print the proceedings. They just hand you a USB key with all of the papers and a table of contents in HTML that has authors and titles that links to the correct file.
What we really need is a latex compiling tool like pdflatex except the output is a series of HTML files. And while I know that there exists some versions out there, we really need one that doesn't suck, along with internet appropriate style files, that just spits out html+javascript+css.
But as an end-user, I don't want a series of files. Source code is a major pain in the ass if you're not actively working on it. the whole win of PDF for most people, including me most of the time, is that I don't want to edit the document, but everything is neatly contained within a single file that is ready for printing or viewing with no additional libraries, dependencies, or anything else but a PDF viewer.
I have a few thousand pdf files on my hard disk and already find it hard to manage the collection. If every single on of them had a source tree it would make me cry.
If you're willing to go through a build step, it's fairly easy to get everything into a single document. Sproutcore does it today with no special configuration. There are tricks to getting large amounts of content to load in a performant manner and you'd have to do history API to get transparent support for an entire site but neither hurdle is particularly high. You don't even have to invent a new format for specifying what makes up the site since the web archive standard already exists.
Multiple files is an implementation detail. When navigating through Finder in OSX, "applications" appear to be monolithic, and double-clicking on them will launch the application. But, they are actually just directories with the .app extension. You can navigate through them and inspect the files and subdirectories they contain. But you don't have to.
I know. I rather miss the option to just save a web page as a self-contained file in Chrome, because I used to use that all the time. It's not that you can't do the same things with web technologies, but that it's so much less convenient to do so. I think this is why Instapaper and Readability have become such big hits, because they offer simplicity and one-step document management. PDF does the same thing for more complex documents that need to be presented in a consistent fashion. This CDF format looks like it could be ideal for textbooks, instruction manuals and the like.
There's another comment downthread where I talk about why I don't actually want all the possible editing capabilities to be available most of the time. Sometimes you want to maximize convenience rather than control.
Maybe that's what you really need. CDF goes way beyond latex -- the idea is not to try to replicate ordinary paper-papers in a digital format. But to have programs that explain things through interactivity.
I've thought about this for a while now. It seems terribly silly for us to spend so much time formatting our papers as pdfs when people mostly read them on a computer anyway. I've been to conferences that - smartly - don't even print the proceedings. They just hand you a USB key with all of the papers and a table of contents in HTML that has authors and titles that links to the correct file.