Keeping RTFs as files

Would there be a way to keep RTFs imported into DT as files (such as .pdfs can be)?

The reason I ask is because I’ve started keeping correspondence and other documents in DT. After fiddling around and getting frustrated with DT’s word processing features (DT isn’t a word processor), I’ve begun writing these things generally in Nisus Writer Express, then archiving them in DT.

The problem is that in order to work further on a document archived in DT, I have to do it in DT or save the file, open the file in NWX, do the work, save it, trash the original entry in DT, then re-import the updated NWX file. Whew!

But the real worry is that the RTF features in NWX won’t translate to DT, in which case DT could be distorting the files imported into it.

You’ve put your finger on a problem. Panther Cocoa text doesn’t properly render, for example, tables in Word RTF documents (or tables in rich text captures of Web pages).

Apple needs to do something about this. I’m hoping that Cocoa RTF will solve those problems under Tiger. I’ve seen hints that this may happen.

And it would be neat if we could place tables in DT RTF text – as we could in a ClarisWorks page more than 10 years ago.

This is one of my most urgent problems with DT. I observe myself not using the app recently, because at the moment I am in another "stage of writing" rather than collecting and searching information.

Although using TextEdit’s styles was helpful, this does not work properly (TE keeps the formatting, but not the information that a part is formatted by a style which might have to be updated) and many other basic word processor features miss.

So I am working on different projects testing NisusExpress and Mellel. Since Nisus saves files in RTF, the RTF should be imported into DT and no File will be saved. One loses not only tables, but footnotes, footers, headers, styles etc. in TextEdit.

It seems that Mellel offers a less complex workflow since the format is not readable for DT. One can store the Mellel file in DT AND produce a PDF that can be searched, linking from the PDF to the Mellel file. Thus, the original file can be opened from the PDF. After working on the text, another PDF can be stored with the print dialogue, and the text file is automatically updated. Problem> The old PDF has to be deleted.

So far,

I wholeheartedly agree, and while I hope that Apple makes changes to the Cocoa RTF rendering code, I still think that it would be a good option for DT to index RTF content without incorporating the file wholesale into the database (as it does with pdfs).

This has great potential for other non-binary filetypes as well. I regularly get powerpoint presentations (shrug) which I’d love to archive in DT. How great would it be to open the PPT presentation from DT after having it pop up as relevant to a search for a word included in the presentation?

This is the thing: even with better RTF support from the OS, DT will never be a word processor. I’m fine with that, as I very much like NWX and would question DEVON’s rational if they bloated DT by trying to incorporate WP features. DT, however, needs to be able to index and manage content from other apps (particularly ones that generate universal file formats such as RTF) without hijacking said content. Spotlight will do this, and I think to maintain relevance as a product distinct from simple OS functionality, DT needs to be able to gracefully handle more filetypes.

The only way what I propose above differs from the way DT currently handles .pdfs is that DT can display .pdfs and it cannot display sophisticated .RTFs. I’m fine if in such cases DT just presents the text of a linked RTF file without any formatting, but with a link to the actual file.

As an interface aside, it would be great if there were key modifiers which determined how a file dragged into DT would be incorporated into the database. So, for example, option drag into the DT dock icon or a DT window would incorporate an RTF file as a copied file whereas a straight drag would incorporate an RTF file into the database.

I’ve been hoping for more flexibly with that, too.  Having to fuss with preferences to modify “Copy files (into database|to database folder)” behavior (or even just to remember it) is awkward when frequently switching methods depending on the content.  So far it’s been easier sticking with one method for consistency and memory’s sake.