Hello! I’m new to this forum and I thought I’d introduce myself. I’ve been writing erotic literature for one website for about 3.5 years now and have started to dabble in more mainstream writing. For now, though, the only stuff you’ll find of mine online is of a decidedly adult nature.
I’ve been using Mariner Software’s StoryMill for the better part of this past year. When I learned of Scrivener, I decided to try it out, too.
I used the demo version of Scrivener to write a story on my favorite “adult” site as a part of a monthly contest and am reasonably pleased with the results. Now that I’ve posted it, I have purchased a license for Scrivener.
I like both Scrivener and StoryMill, and I suspect, as I move forward with new writing projects (both adult and otherwise) the decision to use one or the other will depend on how I’m feeling at the time.
I do have one question. The story I wrote with Scrivener clocked in at about 8000 words. I’ve got an ongoing serial in StoryMill that’s hovering around 30,000 words in its current level of completeness. The Scrivener story is literally twice the size, in terms of storage on my hard drive, as the StoryMill one. Is this because I imported a web page into the Scrivener file?
Also, it would be nice to be able to import documents created by Apple’s Pages app directly into Scrivener without first saving them in other formats…
Thanks for trying out (and buying) Scrivener. To answer your questions:
File size: in all likelihood, the larger file size you are seeing in Scrivener is to do with the web page import, yes. Scrivener allows you to import any media type, so the file size will include any media files you import. StoryMill is text-only, and text is always a lot smaller in file size than media types. Also, Scrivener’s file format is uncompressed. If you ctrl-click on a .scriv file in the Finder and select “Show package contents”, you will be able to see the contents of the .scriv file - lots of RTFD and TXT files. This ensures that the file format is “future proof” in many ways - it’s quite open.
As for .pages import - this is an FAQ and if you search the forums I’m sure you’ll find many of my replies on this topic. I won’t repeat myself too much other than to say that I wish I could support direct .pages import and export too. However, the fact is that Apple provides developers with relatively easy methods of importing and exporting to .doc, .docx, .html, .rtf, .txt, .rtfd, .odt and so forth - but they have as yet provided no way of importing and exporting to .pages. The only way for a developer to do do this would be to write their own importer/exporter based on the file format Apple have published on their website, even though they tell developers not to rely on what is published there not changing… For a single developer such as myself you are talking about months of work just for one import/export feature that may then break if Apple decide to change the format with the next Pages release. I would recommend (and urge) you to contact Apple asking them to make it as easy for developers to support the .pages format as other formats. Even better would be for Pages not to have such poor RTF support - if it had decent RTF support then lots of programs could load fully-featured Pages documents exported to RTF. So I’m afraid that the frustration here lies more with Apple than Scrivener.
Keith, the new DevonThink Pro now imports Pages files and converts them to RTF.
DTP exports in RTF and RTFD, but Pages cannot import them.
That may be a feature that gets fixed; I’m only working with the beta.
So maybe this kind of file-swapping will become more available in the future. --D
DT have a team behind them… It is possible that they wrote their own importer. Personally, I have doubts that Apple will ever make it easy for developers to import/export to Pages - there were never any AppleWorks importers/exporters, either. I can say for certain that I won’t be writing my own importer/exporter, though, as I really would like a life away from my desk occasionally.
EDIT: I just downloaded DT Pro 2.0 to try this out, and it seems that it doesn’t convert them at all from what I can see. As far as I can see, it imports them, then uses QuickLook to display them in its editor (hence they are uneditable). Trying to export to RTF resulted in a blank file. So my guess is they haven’t written an importer but are just using QuickLook to show the contents of file types they can’t handle.
You’re right. I didn’t think to double-click on the Pages file I imported. When I did, it opened in Pages. So you’re correct, no conversion going on at all. You can place many kinds of filetypes in DTPO 2.0, but full import-export is available in only a few:
It looks as though they are using QLPreviewView to display files that aren’t fully supported such as .pages files, too. QLPreviewView is the Cocoa view used by the QuickLook window that pops up when you hit the space bar in the Finder. But get this: QLPreviewView is totally private. In other words, it is not available for developers outside of Apple to use. This is really annoying… Basically Apple provide developers with ways of telling QuickLook what it should show in preview and thumbnail mode, but no way of accessing that information about other apps themselves - it’s all completely one way. (I’m hope this will change with Snow Leopard - it’s probably just that Apple didn’t get time to polish up the QL framework for external use for Leopard.) Some folks have reverse-engineered QuickLook, though. A good example is here:
I spent a couple of hours messing around with it last night. That’s the view DT are using to show Pages files. Given that the next version of Scrivener allows you to import any file type and launch them in an external app, I had a look at using this private view so you could actually view them in Scrivener, but I got all sorts of console errors despite the fact that I was setting it up just as you should do for any normal view. Also lots of weird behaviour - it didn’t work well at all with a split view. So I won’t be implementing anything like that myself until the framework for it becomes public (the DT guys have been doing this for a lot longer than I have and have no doubt implemented a lot of fallback code and workaround logic to ensure that using these private views are safe for them).
