When DT imports a Word .doc file, it always converts it to RTF. When the imported document is “Opened With… Word”, the RTF conversion drops lots of important formating. So, is there a way to make it so that when the imported document is Open…With Word, all the formating and graphics are maintained, without having to depend on the link to the External original file?
Thanks!
No. To see the Word document as originally created, with full formatting, layout and images, you must open the externally linked file, using Launch Path.
Bill,
until a year and a half ago, or so, DT saved (if you so wished) Word .docs in a file named files with the backup in application support. That way you could always launch the original .doc file. Not any more. Why? Was this part of the degrading of the personal edition (together with removing the possibility to use folder scripts etc.) to make the pro version look like a better deal?
Hi Guys,
I know that I don’t understand ALL of the amazing power that DT brings to the table (but I know it is there), nor do I understand all of the workarounds on how to get things done. Yet, having to jump through a hoop to keep a .doc file’s orginal integrity (by not moving the original .doc file’s location… which would break the link to it) appears to me to be a big problem, if not a deal-breaker. Or is it just that I’m missing something? I want this to work so bad!
Why is it converted to .rtf in the first place… just so that DT can display it in its own window? If that is the case, why not keep the original file and translate it to .rtf dynamically on an as needed basis. I applogize, but I don’t get it (at least yet)?
Thanks!
Oh… one other thing… with regard to what “Mats” noted above… I’m using a newly downloaded demo copy of DT Pro Office. The behavior as noted in the earlier version would have been fine with me. I wish it still did this.
Thanks Again,
PS - I’m still hoping that I’m not not seeing the forest (my solution) for the trees!
Perhaps because a native Word document is bigger than a RTF one (revisions, bmp images, garbage as only Word can produce 
, …), so that the DT database will be very huge? No ?
Microsoft’s .doc file format is proprietary. To render Word files completely would require licensing code from Microsoft, or reverse engineering of Word – neither of which would be practical for DEVONtechnologies.
DT instead captures the text content of Word documents for search and analysis in the database. As that’s the principal information content of the Word documents, that makes the rich text useful in the database.
Word files have always been a special case with DT databases. If access to the full content and layout of Word files is important, I would recommend Index-captures of them. There will be one-way synchronization of changes made, from the external file to the database.
Bill,
I think you miss the point. Word files are indeed proprietary. That doesn’t stop anyone from saving them as Word files. What I could do before was to treat them in as rtf:s in DT and save them in the back-up file as Word files, so that whenever I wanted the original file i could launch it through DT. Of course you could do it the way you describe, but that would require that you first file the document in finder, then import it to DT, and file it in DT.
So then why would you need DT to launch the file? It’s counterintuitive, roundaboutbothersome and no fun.
The thing is, that the intuitive and simple way once was available. So why not restore it?
Hi Bill… and all… thanks so much for your time and insights. I have so much to learn!
With what I have learned so far, I have to agree with “Mats”. I can fully appreciate what you are sayiing and the challenge of perfectly rendering .doc files within DT (both here and in previous discussions along this line). The RTF conversion and it’s shortcommings would be OK, if I didn’t have to actively pay so attention (and be so carefull) to maintain the ability to retrive a guaranteed accurate copy of the original .doc file. If I so much as alter a file’s location, the link to it is lost.
If DT could be told (optionally?) to keep the origninal .doc file inside of itself, then I would always have it, the integrity to external links would no longer matter and if DT didn’t do a good enough job of rendering it, then Word could be called upon to perfectly open the file directly, with the ability to edit it (if needed). That would be perfect.
As it is, I have to keep originals in a place that will never change, worry about duplicate file names and use extra disk space. It all takes a lot of extra time and discipine. I hope you don’t think I’m being argumentative or a problem child. DT is amazing… nothing else is even close. Perhaps that’s the reason I care so much… it really is so close to being perfect! I want this to work SO bad! javascript:emoticon(’:)’)
As another kludge, you can always zip the word docs and save them in DTP.
I blame M$ for most of this kind of nonsense.
Perhaps creating a smart folder in the Finder for .doc files and then indexing that folder’s contents in DTP?
Updating the contents periodically would give you access to your .doc files, no matter where the actual file was, yes?
Mats, in the earliest versions of DT (and continuing today) it was never possible to edit an Imported Word file under Word and directly save the edit changes to the database. Import-captured Word files have always required saving of edit changes to the Finder and a re-import of the document into the database, each time the original Word file is modified.
If, however, Word files are Index-captured, modification and saving of an external Word file is synchronized one-way to the RTF content of the database. That’s why I recommend Indexing Word files to heavy users of MS Word, so that full access to the Word file and synchronized changes of the text content in the database when files are modified happens in a straightforward way.
The purpose of capturing Word files into the database remains – incorporating the text content for searching and analysis in concert with other sources of information such as text, HTML and PDF reference materials.
That long-standing pesky behavior of Word files as physically remaining outside the database folder or package will continue until the major restructuring of the database structure in version 2.0.
Personally, because I prefer my databases to contain Imported files (i.e., to be self-contained) I avoid MS Word. My current word processor is Papyrus 12, using that application’s hybrid PDF file format. My Papyrus hybrid PDFs let me use only one file, located in the database internal Files folder. Not only does it render inside my database exactly as it looks under Papyrus, I can open it under Papyrus, edit and save it back to the internal Files folder and the changes are visible in my database. One more advantage: I can attach my word processor document to an email without worrying whether the recipient has an application capable of reading it; it’s read as PDF on any computer platform. If I’ve got hyperlinks (URLs or links to endnotes, for example) they work when read as a PDF. As Papyrus 12 does a reasonably good job of opening .doc files and can save as .doc (readable as Word 2003 files), I didn’t bother to install MS Office on my MacBook Pro.
Bill,
true. But I did have an option to save the original Word file, be it my old invoices, attachments to mails I’ve recieved etc. in the file where also my pdf files land up when I imort them. I couldn’t edit them and see the changes in my data base if I didn’t re-import them, but theey were always there to launch for reference when I wanted them. So I didn’t have to bother with two file/folder structures, one in DT and one in Finder.
I could also use a handy little “Save in DT” script on which I dropped all files I wanted to save in DT. Once I had done that the original file was moved to the Files folder in the Library, it was searchable in DT and it vanished from the desktop. Perhaps this wouldn’t be conveniant for everyone, but it was for me. I could also use Folder actions to save documents in a file in Finder and have them searchable in DT.
For me, losing these functionalities meant a degrading, not an upgrading of the application.
Mats
I have to agree with Mats 100% on this one. This is a bigger problem for me as most of the time I only deal with PDFs and only occasionally have to store Word docs. This means that I have usually forgotten about DT’s Jeckyll & Hyde character with regard to Word documents.
My database is set to import everything into the Files folder. I did a quick test. I imported an Omnis datafile, which is a completely propietary database format and DTP imported the file correctly into the Files folder without fuss or complaint even though it doesn’t understand the format and can’t display it. On the other hand I tried to import a simple Word document and DT won’t automatically put it into the Files folder. It’s listed in the database all right but instead of importing it links to the copy on my desktop. As far as I am concerned this inconcistent bahaviour is inexplicable and problematic for users. DT doesn’t even give any obvious feedback that this is the case and I have already deleted a couple of word files because I had forgotten that importing them into the database didn’t place them in the Files folder.
The fact that this used to work that way makes this all the harder to understand and telling us it will be fixed in the mythical version 2 really doesn’t help. As a programmer I have difficulty believeing that this is some kind of programming limitation since we’re just talking about creating a copy of a file in a different location. I could perhaps understand if it was some kind of licencing issue with MS.