Compile to "Doc" actually creates an RTF file

When I compile to a .doc format, what I actually get is an rtf file with the .doc extension. Yes, Word can read it, but other applications that can read Word documents cannot read the rtf file, most notably applications on my phone or tablet. It’s fine if Windows can’t (yet) create a true .doc file, but it shouldn’t offer to compile to .doc and then export in rtf format. If I want it in rtf format, I’ll select rtf.

No word on this?

There are application out there that can read .doc files but can’t read .rtf files?

This is the first I’ve heard that it’ not a true .doc file. What gives you that impression? Which software is struggling to open the .doc files?

Tried this. It’s true.

I ran a compile to .rtf and another to .doc changing only the Compile For setting. I got the same file size, 86KB. Dragged them both into Visual Studio. They look the same and are all text.
If you drag a real .doc into studio it won’t open it but instead sends it out to your .doc app, in my case Lotus Symphony.

First few lines of the .doc are the same as the .rtf:

{\rtf1\ansi\ansicpg1252\deff0 {\fonttbl{\f0\fnil\fprq2 Courier New;}{\f1\fnil\fprq2 Calibri;}} {\colortbl;\red0\green0\blue0;}
In Symphony I added a single blank to a single line of the .doc file and saved it as .doc. The size went to 112KB and will not open in Studio.

Yes, for example, Kingsoft Office for Android reads .doc files, but when it opens a .rtf file you get a lot of overhead, as shown in the previous post like: {\rtf1\ansi\ansicpg1252\deff0

This is rtf format, not doc format. This is important because there are very few apps (that I’ve found) that read .rtf on Android. The one I’ve found is kind of annoying.

It’s perfectly fine if the Windows version can’t (yet) support .doc files. I think they kind of get that “for free” for the Mac, so maybe it’s not as easy on Windows (if that makes sense for you). But I don’t want them to pretend it’s a .doc when they’ll really put it in .rtf format. That doesn’t let me know how I’m supposed to handle it.

I was going to comment on this as well. I am testing out some stuff to use on my iphone as stop-gap measures between now and the Scriv for iphone version.

Quickoffice could read a .doc created by Word but the .doc created by Scrivener left it with lots of rtf tagging visible. No clue as to why this is. It would add a step or three between moving stuff to the phone to noodle on (heck, it isn’t a great situation anyways, all told) (Kudos to QuickOffice to at least have a testable free version–I think I’ll go with them over Docs 2 Go just for that reason. Assuming I get anything at all. PlainText is doing fine for now).

Anyways, yeah. Everything else reads the rtf tagging without an issue, including Word, which is the Queen Bee of Persnickety-ness, so I was surprised.

I wonder if this is related to these being mobile apps we’re discussing, though to be honest I’d have not expected it from Android apps the same way. (As in, I know that the iOS specifically has major deficiencies in viewing rich text–it doesn’t do it natively, and thus all the stuff you normally take for granted has to be individually programmed in each app).

This isn’t actually that unusual of a thing. Calling an RTF file with a .doc extension is something that has been done for many years, mostly because RTF is an open-specification format (anyone can download the specs and make an editor) and DOC is not. However on the other hand you have a whole multitude of people who, if they don’t see .doc on the end of the file, think its not a document that Word can load. So calling an RTF a .doc has been a convenient way to just get on with business. It has only somewhat recently become an issue with mobile applications that specifically target .doc (for the same reason you’ve got people that think an RTF can’t load in Word), but can’t actually read RTF. Obviously, the way around it is to compile as RTF and save it as a .doc using something that can do so.

Part of what causes it to seem like we are pretending might be my fault. When I wrote up that section of the user manual, I wasn’t sure if we were using Office extensions to generate a genuine .doc or what, so it might be worded ambiguously. The Mac documentation is very specific about the default .doc export being a masqueraded RTF. We aren’t trying to fake anyone out here. I’ll make sure to double-check the wording in the Windows manual for the next release and make it is more specific in regards to what is happening internally.

I have to ask that, if the .doc file is really only a basic .rtf file, then why is winword.exe called by Scrivener when the application starts? Why is MS Word required at all for the compilation of a .doc file since it’s really an .rtf?

EDIT: I think I have an answer for my own question. I checked under the compile options again and I see that there is also a .docx option, so that would probably be the reason. Right?


Yes Gina,

There is an option to switch this off in the beta if this is causing you problems.

Hmm. I’ll have to research where the user manual is for Scrivener, though I’d argue that to effectively use (at least the simple features of) a UI you shouldn’t have to refer to the documentation. Help text when you choose this option would have helped.

It’s unfortunate that I’ll have to add an extra step to the compile process forever in the future (many publishers specifically do not want .docx yet). Or do you think compiling a true .doc might be able to make it onto the backlog?

At any rate, thanks for the response.

Look under Help in the menu.

Yes, for simple things I would agree. Trying to take that principle too far leads to dumbed down interfaces though, and I’m not a fan of that. I’d rather something be optimised for the middle-high crowd. You might have to actually learn how to use the software, but once you do, it’s markedly more efficient that software that is bogged down by wizards, excessive confirmations, and wastefully demonstrative interfaces. I digress.

In this case, I don’t know, that’s kind of a technical detail that most people don’t even care about. It’s actually kind of rare that anyone even runs into this. The vast majority of people blissfully use RTF files as DOC files. Throwing a warning in their face would confuse and alarm them needlessly, potentially into thinking they are doing something wrong and wasting time trying to figure it out. It’s only a small minority of people using mobile office suites that tend to run into this, and I don’t think it is unreasonable for the documentation to pick up those cases.

Seeing as how compiling is one of those every-eight-month tasks for most people, in the grand scheme this is a smaller issue. Perhaps you compile more often than the average person. We have to decide where to focus time based on the greater good. If compiling was something everyone using Scrivener did a dozen times a day, and they had to use other programs to successfully complete this hypothetical task every time, we’d probably spend more time trying to figure out a solution to avoid it.

Seeing as how .doc is a fading abomination of a format that is universally despised by all developers (probably even Microsoft) but doesn’t yet die already because people keep on using it and preferring it, probably not. :slight_smile: It truly is a huge mess of a format that is completely undocumented to the public. That means any attempt to write a program that can read and write .doc files essentially has to “hack” the format by looking at the end product rather than the mechanisms and specifications that creates the product. Best solution is to utilise libraries written by people that do nothing other than attempt to unravel .doc/x all day long, rather than try and do that and write a useful program for writers. Unfortunately, the job is tough enough that even those who make it their entire job to create .doc/x converters don’t always do a good job; and since there isn’t a big market for it there aren’t a lot of people doing it.

We are experimenting with some new code on the Mac, which is Java based, to replace Apple’s .doc/x conversion engine. It’s does a very good job but is a bit slow, so it might not always work for every situation. Maybe if this technology proves useful it can be something implemented into the Windows version as well. We’ll see; I can’t really comment on that as it isn’t my choice to make.

touche :slight_smile:

Well, thanks.

Is the .docx actually a .docx?

I think it is good that you focus on the areas of greatest need. And to be honest, if/when scrivener for iOS comes along the point will be less required for me–but it will make things slightly more annoying for the foreseeable future.

I think that it would be good to make it clear in the documentation that if there are issues, this is what is happening. It honestly didn’t occur to me until I saw the thread that that’s why I couldn’t get the app to read the files. I haven’t had it show up outside the mobile apps but when it did it was VERY frustrating. (Most Word-capable apps are around $10, and i would have been very angry if I’d bought one and it didn’t work. Luckily for me, I was doing the trial version of QuickOffice.)