Another user's feedback

Hello forum (hello Keith)

I thought I ought to poke my head up and add my feedback, since it’s what the forum encourages.

I moved over to Scrivener earlier this year, and it’s been great. Favourite-app-on-my Mac great. Previously I’d been using an unequal mix of Pages and Tinderbox; each a little too much of what I didn’t need. (Unexpectedly, switching was precipitated by running into a very specific limitation of Pages that annoyed me so much I had to use something else). It took me about a day to organise everything and move it across – finding the “Split at Selection” option in the Documents menu, which uses the selected text as the new document’s title, was the precise moment I was won over. “Goodness,” I thought, “Scrivener knew I would want to do that.”

And from then on it’s been a joy.

For this particular project, I am working on four separate books that are deeply interwtingled. This resulted in four windows (plus an extra scratch one) being open in Pages, with lots of switching between. In Scrivener, I put each one in its own folder in the Draft, and then put all the (short) chapters as a documents into those. An essential part of how I am using Scrivener is that Compile Draft allows me to choose one of those folders as the root, so I can compile each one individually. Like many of Scrivener’s details, it’s a small feature that you wouldn’t notice if you never need it, but when you do it’s as if Keith had peered into the future and seen how you were going to want to work. That’s how design is supposed to work.

I am using LaTeX because I am a nerd as well as a writer, and for this particular project I’m concerned with the final layout and typesetting as well as the content. There’s a lot about the .tex that the Compile Draft (via multimarkdown) produces by default which doesn’t suit my requirements. I could address this by providing my own XSLT, but XSLT is such a horrible, unwieldy beast that I much prefer to munge the .tex file with my own Perl script afterwards. That script replaces much of the preamble with my own, as well as making lots of specific little fixes (for example, some of the LaTeX for inserting the illustrations). The key thing is that I can go from Scrivener through to print-ready PDF automatically, which is particularly appealing for me: from Scrivener, the text goes through multimarkdown to .tex through Perl to TeXShop to PDF.

Particularly handsome features that I really appreciate:

Full screen mode. Just write, dammit!
Edit Scrivenings. Utterly marvellous. In particular, it’s especially helpful that the default behaviour for a folder is to suck in all that folder’s documents as the Scrivenings. It’s a simple but super-sensible default. I find I also use Edit Scrivenings as a handy way to limit the scope of search-and-replaces.
Backup to zip. Not only is it essential (I backup off-site daily) but the sensible default filename is good (uh, although I’d prefer underscores rather than spaces in there: I’m old school and it makes things a wee bit easier on the command line).

I use the split screen from time to time, and bung things into Research (including the Perl script itself so it’s included in the backup zip).

About the only thing that could have been easier was dropping raw LaTeX into the text – and that’s not really Scrivener’s problem anyway. I know (from snooping around in the forum) that one way to do this would be to edit the XSLT in order to pass it through as HTML comments. But I’m loathe to change the XSLT since that’s the sort of thing that I would worry about losing in the event of an upgrade; so instead I get my Perl to unescape LaTeX source that ends up escaped in the .tex that Compile Draft spits out.

So there you go. Without doubt such a fantastic work environment has improved my productivity. It’s also the best reason for sticking with the Mac. A long round of applause to Keith. I particularly appreciate how much of Scrivener’s default behaviour is sensible: it’s simply well thought out. Bravo.


PS the project I’ve been working on is: The Knot-Shop Man

You can install MultiMarkdown separately in ~/Library/Application Support/ which would take precedence over the installation that comes with Scrivener. The default XSLT file for LaTeX is memoir.xslt (also loads xhtml2latex.xslt). There’s a basic template in the Scrivener Wiki, that might be helpful in case you want to “roll your own”.

Your website looks terrific.

I posted this trick a long time ago, but its been so long I might as well post it again. In addition to what signinstranger suggests, (which all MMD folk should do in only for the fact that the version shipped with Scrivener is a slightly older beta than the latest MMD release) I keep my modified XSLT and Perl scripts in an entirely separate location in my development folder. Then I symlink to the originals from the MMD folder in Application Support. Then whenever MMD is updated (which lately the release cycle has been long) I diff the modified files with the new version to make sure I don’t break anything and then run a Ruby script which scans my development folder and regenerates the symlinks.

I have a pretty heavily modified MMD workflow these days, with my own control scripts that do a lot of syntax parsing and so on. Like you I try to solve things without XSLT first, but have written a few XSLTs as well for MediaWiki and BBCode. It’s a pain, but once its done it is done and everything is 100% automatic from that point forward.

Helo signinstranger and AmberV

Thank you both for that… As is often the case, by strenuously avoiding “fixing” the problem in the right place, all I’ve really done is turn it into a slightly different problem and pushed it somewhere else. Heh. However, I’d rather work with Perl than XSLT any day, so from my point of view it was a comfortable albeit bodgey solution. But I hadn’t thought of installing MMD separately, and it’s good to know the things you both suggest so one day I can do it more beautifully.

It’s obvious with hindsight – now that I am changing pretty much all of the .tex file that Scrivener is spitting out – but really there’s no good reason why I’m using the .tex at all: I ought to just Compile Draft to MultiMarkdown and take it from there. Then raw LaTeX certainly would pass through without a problem. But in my defence I was making this up as I was going along. Oh, and, er, concentrating on the writing…

AmberV said:

And in a pokey way that is where I have ended up, so I am happy. :slight_smile:


Hi Dave,

[Takes a bow.] Thank you very much for your kind words - much appreciated. Your site looks great. Out of interest, what feature of Pages was it that made you abandon it in frustration?

I have to pass out credit where it’s due, too, as I believe that the “Split with Selection as Title” and the “Choose Compile Group” features were both great user suggestions early on in Scrivener’s life that clearly belonged in the program.

All the features you like, by the way, are even better in 2.0. :slight_smile:

Many thanks again and all the best,

Keith asked:

Short answer: export to HTML. It wasn’t just poor, it was destructive and caused me a lot of grief.

Long answer: I was running Pages 1.0.2. I’d enjoyed the unfussy “I’m Not Word” inferface, and was generally happy with it.

But then I needed to dump the whole text so that an editor in the US could see it on her Kindle. Since we were just talking about the typsescript I wasn’t interested in any presentational stuff, except headings and italics. I know a wee bit about how Kindle works, and basically a simple HTML file is the cleanest, safest way to go. Kindle users think the Kindle can show .doc files, but actually the files are translated on the fly into the native format which is fundamentally HTML. I wasn’t happy about trusting the .doc-from-Pages format as an intermediate stage particularly because I was not in a position to check that it looked OK on the target device (here in the UK I have no Kindle. Don’t want one either, because of Amazon’s appalling, secret DRMish behaviour on their e-books, but that’s another story). Also .doc would by necessity make pagination decisions which the Kindle might or might not subsequently handle correctly; I had no way of checking. So HTML was the obvious, safe and simple way to go. Plain text would loose heading and more importantly italics; HTML is easy to inspect and easy to strip down to bare, simple markup.

Of course I understand that automatic conversion to HTML is at best a black art as far as precise layout and styling is concerned, but I didn’t care about that. I just wanted to preserve the italics and headings. I was happy to strip out (using Perl’s regexps) all the tags apart from paragraph, headings and italics.

What I wasn’t ready for was that the export to HTML process did a very naughty thing. Specifically, it put tags around text that it remembered as having been edited later. If these were separate paragraphs, fine. But sometimes it was within a word. For example, a word such as “annoying” might turn up in the text as annoying if it had not been typed in one session. Obviously those spans had some styling (style=“blah”), which made sense, but those were always identical since all my text was the same anyway. It was a wee bit odd, but since I was stripping s out anyway, not a problem. Except… Except the export was putting whitespace between those spans. It was inserting whitespace into words.

It was by luck that I spotted the first one. I thought, hmm. So I looked and found another. Then another.

I tried to use regexps to fix it intelligently, but it was algorithmically impossible because sometimes the whitespace was genuine, and from the original document. In a document of about 140,000 words, you can’t be casually about fixing a problem like this. Basically Pages had scattered spaces through the document, breaking up a few words – maybe about one every three or four pages. Just enough to be rotten.

I guessed it was to do with whatever Pages was doing internally with edited text, so I tried things like selecting the whole document, cutting it, pushing it through a new document and then pasting the whole thing back in, but I never found a way to “flatten” it.

It was extremely annoying for two reasons: firstly – the inevitable thing, I suppose – was that I was rushing to get this done to a deadline so didn’t expect to have to mess around on this level. But secondly, which was more upsetting, was that this text had been carefully and thoroughly made good by a proofreader (also in the US). You don’t go through all that effort of being proofread to have your software – paid-for Apple software – spew random errors back into it.

In my panic I thought maybe the new version of Pages fixed the problem. It had. Pages 2.0 doesn’t have export to HTML at all. That was the final straw, an admission of crappiness, and it pushed me into sending you your money :slight_smile: Haven’t looked back.

I still use Pages for pretty stuff if it needs to go to, say, PDF. But for working with text, rather than word processing, it simply isn’t the right tool. To be fair, perhaps it never claimed to be. But for export to HTML to insert spaces into words to me is a QA failure. It’s not a style or layout issue if it’s breaking words; it’s breaking things semantically.

There you go. Told you it was a long answer. It also serves little to no use as a warning to others, because as I say, the latest Pages doesn’t have this problem, because it doesn’t export to HTML at all.

I am aware, by the way, the MultiMarkdown is exactly the sort of thing that solves this, since it’s plain text but with the simple things I needed – chapter headings and italics – preserved.

By the way, if you have nothing better to do and a cup of latte to hand, I’ve written a little bit about my relationship with my proofreader here (skip to part 2. if you like, for this project), which perhaps makes it clearer why in this particular case I was so frustrated by having her work compromised by bad software.


I had the time, if not the coffee, for the read. Your relationship with Judith moved me in many ways, and I sit with freshly lubricated eyes.
Thank you for the reminder of the joys in life. The little things are sometimes all that count.
Thank you.

For me, the best format for shared files is PDF. That way, your readers see exactly what you’ve created. The Kindle does accept and read PDFs. You have to run through a conversion service, but it’s free. See … he-kindle/

Another possibility: posting the PDF file on, also free. But then your reader is better off with a web browser. I gotta say, you are awfully generous to an editor who insists on reading only via a Kindle!

To nom, thanks for that.

To druid – thanks for pointing that out, and you’re quite right that PDFs are good for sharing files, but that’s provided both parties can display them. The Kindle emphatically cannot display PDFs <edit: um, it does now – see following post!>, it converts them to its internal format (which actually is basically a stripped-down HTML with some of its own features added). The problem is that, due to the nature of the PDF format’s internals, there can never really be a clean conversion from PDF to something like HTML because they describe subtly different things. A case in point with the Kindle is pagination, but there are also issues with fonts and layout and, well, almost everything. So basically I wouldn’t trust it further than I could spit it, but especially so if I can’t check what it looks like on the target device. Verified HTML was the only thing I could be 100% confident about (and that was because it was so plain and simple).

So although I agree with you and generally use PDF – in this case there was no way I was going to trust a PDF-HTML convertor not to screw things up. After all, this time it wasn’t about presentation, it was just about the text. And you’re quite right, I was also going out of my way to be generous!


Oops! I said:

…and I have already discovered I am wrong: the new Kindle DX does indeed have an internal PDF viewer so, druid, you are now entirely vindicated. Sorry.

But there wasn’t when I was doing this, honest :neutral_face:


I just noticed today that Bean, the free word processor, exports to HTML, with and without tags. So maybe if you pass the original files to Bean, that would create for you a better workflow.

As for being entirely vindicated, please pass that good news to vic-k, who sometimes doubts me veracity, despite our common border heritage. :open_mouth:

Shame on you! I feel I must take you to task, over that wholly unwarranted accusation. Im not so presumptuous, as to call into question the veracity of your utterances, or indeed, of anyone elses. I wouldnt dream of casting such aspersions tards another crew member.
I`m cut to the quick.

Dave, take no notice of him, he`s lying through his back teeth.

Like nom, I too was quite moved when reading the account of your relationship with Judith. She sounds like one of lifes hidden gems. People like Judith always leave a huge hole in our lives, when theyre no longer with us. You`ll miss her.
Take care