I have been hit by a rather curious bug. When I export a text file from Scrivener as RTF, then try to view that file in Windows 7 (in Wordpad, say) I get a corrupted view of the file. I notice that if I open it in TextEdit and remove the top of the file down to the centered title (basically, what you are seeing in the picture) the rest of the file becomes visable.
Notes: This text file is an export from a standard novel template. The word count is correct. Only two lines below the second pipe-like character are actually selectable. The file size is normal, and redownloading from MobileMe to OSX and opening it produces the full text. I also noted that editing the files in TextEdit removes (edit: hides, rather, under OSX) the .RTF extension, although otherwise does not seem to change anything. The file appears to contain the remainder of the data, it is just not being rendered properly. Whether this is an issue with Apple or MS not sticking to the standard for RTF, or whatnot, I do not know.
Also, if this is a known bug and there is a workaround, I humbly apologize and ask you to point me to it. I did a somewhat thorough search and did not spot it. Also, sorry for the resolution of the pic, my monitor runs 2560x1600, I wanted to screenshot the exact view I see when I open the document.
My machine is an Intel MacBook Pro 13", Scrivener v. 1.54, OSX v. 10.6 - Windows machine is Win7, x64.
In this case, it is Microsoft’s WordPad not sticking to the standard for RTF, or rather, not all of it. The RTF file is perfectly fine, and if you open it in Word or most other full-featured word processors, it would display as it should. What’s wrong is that WordPad doesn’t support RTF tables (you can insert Excel spreadsheets, but that is a totally different thing), and that is what Scrivener is using to align the text in the cover page of the document. So as long as the table is intact in the top of the file, WordPad will choke on it. Remove the cover page in an RTF editor that supports them, like TextEdit, and the file will open fine.
If you absolutely need to work with WordPad, I’d try to recreate this cover page using a right-align tab stop instead of a table to get that text over on the right-hand side. If you put the right-tab at 6.5”, that should work good for a standard US Letter printout with 1” margins. Tables are generally better because they can expand to any page width and tab stops are fixed to a certain position (and thus are paper and print setting dependent). The template needs to be as accommodating as possible to a wide range of formats, and most word processors can handle RTF tables, so it’s usually not an issue. But since you are in control of the process from start to finish and know exactly what you need, a tab stop should be safe to use.
You probably just have extensions hidden in the Finder’s preferences. There is an override flag on a per-file basis, and Scrivener might be setting that, but once you save it with TextEdit that flag is removed and it goes back to system default.
Thank you Amber, I was assuming something along these lines.
The gist of the issue is, that I generate these files on the fly for distribution, and editing every time prior to syncing the file to MobileMe is an admittably annoying extra step. It’s unfortunate, but I do not actually own a copy of Word, or any other “full-featured” word processor (my last being StarOffice). Additionally, most of the people I have for test-readers also do not. Question being: is there any way to sidestep the table issue entirely? While the iPhone does not scramble the text entirely, the formatting as viewed is still incorrect (the wordcount is smashed up against the opposite table), and I am sure there are other instances where this could cause an issue. Submissions, perhaps?
I found the Text>>Table menu entry. It is not immediately obvious there is, in fact, a table present. I was unaware of this until you mentioned it. I still have not figured out how to edit what is there in a visible manner, and do not wish to destroy it.
Is there perhaps a ‘compatible’ RTF selection or export option to get around this issue? Also, it may be a concern with the forthcoming Windows version of Scrivener… it would be hilarious to be unable to open your own RTF using the default text editor on the platform.
None of this is commentary on Scrivener, as I have been a long time user, and adore the thought that has gone into the program. Just trying to raise some considerations. I’ve a few other bugs, legetimate ones (duplicating a text item somehow recalling contents that had been deleted from the item, among other things) and also a few more little fidgets that may or may not count (a duplicated section, when removed from the draft and the contents deleted, somehow redacts those contents from my word count) but I’ll produce full reports on those if they remain in 2.0
Will the tab-stop solution I posted above not work? It probably won’t work on the iPhone, but there is very little that can be done to display a full name and word count on the same line, with such a small display, anyway. Since that is just a display problem, even if the tab stop looks off I wouldn’t worry too much about it. Fixing the title page in Scrivener should solve the distribution and post-edit problem, since they’ll all be corrected from the start.
Submissions are probably okay, as most editors and agents use so much Word that many aren’t aware that it even opens RTF files.
Most of the templates do not use a table, it’s just in this case, where most submission guidelines ask for a layout like that, a table is the best solution for most cases, and turning off table borders hides that this is what is being done.
Working with tables is a bit of a pain is OS X’s default provided text editor, and it will probably be easiest to just reconstruct the title page from scratch using regular alignment and tab stop tools, rather than trying to edit it. I’d put the original in one split and the new version in the second split and just reproduce what you see.
Once you get that done, you can stash the old title page somewhere in the Binder, and then save the new title page as your starter template for future projects.
True, but that’s going to be a problem with much more than just tables, and it is a problem on the Mac as well. TextEdit and WordPad are similar in that they are stripped down RTF editors. Neither is really meant to replace a word processor. They don’t support a lot of stuff, and both will mangle the parts they don’t understand. I’m not sure what Scrivener could do to avoid this. Should it really drop all features, like footnotes and headers/footers, inline images, tables, et cetera for the lowest common denominator? And if it has a “Full RTF” and “Simple RTF” mode, what happens to all of that stuff that should be compiled otherwise? Flattening footnotes into raw text is one thing (though not terribly useful for most cases), but what of tables? How should that information even be displayed without the table? What happens to figures?
If it was just you, I’d recommend AbiWord, which is a free cross-platform word processor that is significantly better than OpenOffice in many regards. It handles RTF tables just fine—however it’s not a good solution in your case since, as you say, you are distributing to people all using WordPad. I think reformatting your title page to not use more advanced RTF features is the best bet here.
That’s been fixed in 2.0. What you are probably seeing is a rare case where if you duplicate a document before auto-save kicks in, the old version of the document gets duplicated. Either you are working at lightening speed, or you have auto-save set to a higher interval than standard.
The counting issue might well be fixed too, as that whole bit has been re-hauled. Would you mind posting the steps for that? I could verify whether or not it is a bug and if it still appears in 2.0. If you don’t have time don’t worry about it until the upgrade, though, of course.
1)Duplicate a loaded file
2)Delete the contents of the duplicated file
3)MASSIVE WORDCOUNT DESTRUCTION!! … err… ahem
I should note that this occurs even if you drag the duplicate out of the draft and drop it under research, which has caused me great frustration in a few isolated incidences (I hang my writing sessions not on time, but on progress).
As for the RTF issue, you already have export options that warn of lack for support for certain items (I believe HTML is one). You can convert your table to those tab-stops you mentioned, or have an option to exclude them entirely using the Document Elements. It is all just food for thought, at any rate.
I know you mention methods to change the table using the ruler and via showing the table boundaries, but I have been unable to locate these options. I am sure they are sitting right under my nose, so to speak.
Thanks for all your time, once again. If there is anything else, don’t hesitate to ask!
Ha, all right, I see what you are getting at. Perhaps this example is contrived in order to demonstrate the issue, but at that point I must ask—why don’t you just make a new blank file, since that is what you seem to want here? The reason this happens as it does is: the session counter only tracks the words you add or delete in an editor. If you drag in twenty novels, the meter isn’t going to suddenly fly up to 3,000,000 words, which in most cases is the desired behaviour. Duplication is no different. You didn’t actually write the stuff you just duplicated, so why should it count them in the words written counter? The counter does track edit deletions though, which selecting a bunch of text and removing it will certainly count as. So this isn’t so much a bug as using a file management tool to create a bunch of text and then an editing tool to subtract a bunch of text, when the counter only tracks editing actions, not file level event actions.
I do realise in this particular scenario, it doesn’t make perfect “street sense”, but when you consider that Scrivener can’t really guess at what you are trying to do, and that it has to draw the line somewhere at what is “real writing and editing” as oppose to duplicating files and dragging research in from the Finder, it makes “practical sense” and you just have to work around it. It would take a lot of smarts for Scrivener to realise the “street sense” of what you are doing and distinguish that from other scenarios which, from the program’s point of view, are identical actions.
And yes, it counts all editing in the project, it doesn’t matter where the editing is done. This is something you’ll be able to tweak in 2.0.
Converting them automatically would actually be pretty difficult. It’s kind of transparent, but a lot of the stuff you see is just kind of “passed through” the text engine and handled by Apple. It isn’t easy to work with tables from the programming side of things, so even getting an accurate picture of what is in the table in the first place is a bit tricky, let alone its finer details in formatting, and what the intention of that formatting is—all things the program would need to know to correctly do this—and there wouldn’t be analogues for everything anyway. This case is very simple, so I can suggest a human designed alternative.
Here is an example tab stop setup that will produce the title page look you want:
Note the right-align tab at the 6.5" mark, and circled in the middle is a single tab separating “Your name” from the word count code. Text/Show Invisibles has been turned on to reveal the tab and spaces in this sample. The rest of the title page should be straight forward. Just use centre-alignment for the book title below the contact information block.
Ahh, you misunderstood me. Or I was unclear. I knew how to format the page to recreate the title, just couldn’t find the actual ruler to do it on. I kept looking under the view menu, when it was hiding over in the text menu, which I suppose is a convention I am not familiar with.
At any rate, my concern over the counter was less that it behaves the way it does and more so that it behaves that way outside of the the draft “folder” if you wish to call it that. I assume 2.0 will allow you to inform the counter to only track text within the draft folder, and count all progress toward your goal, regardless of the source. This being especially true considering the possibility to sync offsite work, clean it up, then move it into your draft.
The reason I did not make a new document was to avoid having to set all new attributes, I instead duplicate a “template” with a template title and template synopsis to remind myself to fill in all these areas, and reveal when I have not. Perhaps there is an option to create new texts with these as an actual preset? I wish I had more opportunity to dig into Scriv. Alas, only so many hours in the day, unless you have a hidden resource of time you wish to share. Thank you for the step by step!
Ah, okay, sorry about that. Yes the ruler toggle command being in the Text menu is a bit of a Mac standard thing for Cocoa applications like this.
Yes, and I believe Draft-only will be the default behaviour, but this can be changed to universal 1.x behaviour on a per-project basis as an option.
“Regardless of the source” is a bit more tricky. The same rules will apply, for all of the above reasons, regarding imports and duplications. Text you haven’t actually added to any files using editing commands will not be counted. So if you import an RTF file into the Draft that is not counted. If you paste text into a file in the Draft though, that will be counted.
Okay I follow you now. There will be a document template feature in 2.0. You’ll be able to set up checklists or boilerplates like this and use them to create new documents anywhere in the Binder, as easily as creating a new file. These will still act like duplication though. The sudden generation of text via duplication (whether by template or what have you) is not considered “writing” by the session counter. So deleting boilerplate text will still subtract from the counter.
You might want to consider putting checklists like this into the Documents Notes field. This area is not counted at all by the target counters.
Purely out of curiosity, what happens in 2.0 if you duplicate a file in the Draft section, move it to the Research section, and then delete the text (assuming default behavior of not counting edits outside the Drafts folder)?
It works as you would expect, if the session counter is set to only count editing actions within the Draft, it’s not going to increment or decrement the counter at all for editing actions taken outside of the Draft.