Scrivener, MMD and German umlauts

Hi everyone :slight_smile:

Conversion from Scrivener to LaTex via MMD3 works fine for me so far, except for the German umlauts äÄ, öÖ, üÜ and the ß.

After mmd to LaTex export they don’t show up correctly in the .tex file, and are subsequently not set correctly in LaTex. I’ve searched the web up and down, without any success.

MMD3.6, just downloaded, latest Scrivener, latest LaTex. I did not, however install fletchers support files in the texmf folder, because I simply cannot find the texmf folder anywhere on my disc. But I’, not sure that it’s the missing files that are my problem.

Can anyone help? Please?

In nearly every case you’ll need to create your own texmf folder. I’m not aware of any distributions that set one up for you when installing as that’s a user level thing. There are instructions for the path you need in the README document.

That aside, these are just boilerplates for classes. They are a separate set of the documents that Scrivener generates for you when you compile—all of those header/footer .tex files. In other words we are just using the LaTeX support documents that Fletcher created, and we will continue to keep Scrivener up to date with these as he makes changes over time, but ultimately that means that installing your own copy will of course make no difference in your output! That is there only if you wish to modify the default document class and preamble structure.

As for this problem, it sounds to me like an encoding issue. You might try using XeLaTeX to typeset, as it is much better with Unicode documents.

Talking of XeLaTeX, Ioa, does Scrivener have an export mode for RTF to LaTeX? Now that would be something!

I have noted this problem for quite a while now, and have been meaning to investigate more fully. Umlauts in UTF-8 were not a problem in MMD version 2, and I’m pretty sure they worked as expected in early versions of MMD 3. It seems to me that it happened around the release of 3.2, which was a year ago (the announcement), though I don’t remember exactly when I first noticed it.

You’ve turned up a known issue, germanguy (top of the list here, and also here, and in the docs here), but the developer hasn’t prioritized it.

I just ran some quick tests with the umlauted sentence you gave and it passes from MMD to TeX just fine. I’ll have to see if I can reduplicate the trouble I had in this area last week.

(Aside to AmberV: this is a pre-processing issue that creates the same problem in XeTeX.)

I don’t really know the nature of the problem, although I note that Fletcher made a decision to prioritize ASCII in version 3. (My year-old memory about 3.2 could be a false lead.) It would certainly be a retrograde step if backward compatibly came at the expense of compatibility with unicode, the de facto text encoding standard.

If you find a practical solution I’d be pleased to know. I’ll see what else I can discover as I look into it again myself.

I’m not sure what you mean by that. Wouldn’t rtf2latex2e do that already?

Hmm, then I wonder if perhaps using XSLT post-proc would get around the current problem? As far as I know, the old XSLT plumbing that cleaned up extended characters to ASCII is still in place.

Thanks for looking in to this further!

Thanks, Ioa.

I am a novice at LaTeX.

I tried to install rtf2latex2e on my 2009 iMac running Lion, but it wouldn’t work. To create a working install of rtf2latex2e demands the ability to run a “make” program from the OS, and MAc OS X Lion doesn’t do that. I guess I could just strip out the whatsits, instal a pair of double-downdraft Stromberg carburettors, four levels of x-code, two different kinds of Linux underpants in French and a dozen Unix subroutines, translate “mike” and “mick” to “make”, and it might work. Then again, it might not. Alas, I’m a writer, not a computer science graduate, sadly.

I ended up exporting the (huge) RTF file into XHTML (minus CSS, via Nisus Writer Pro) and tweaking it laboriously from there using BBEdit regex routines; then I found that TeX Shop does regex if you know where the secret trapdoor is, so that made things a bit easier. Except when it didn’t do what I expected, then it made it worse. They call that “the learning curve”. I’m still knee-deep in unfamiliar code.

But Scrivener is wonderful, and I tell everyone to buy it.

As you’re using NWP, it also does RegEx … it’s called Powerfind Pro. And once you’ve sorted out what you need changed, you can turn it into a macro to do it for you the next time. And of course, if you have trouble with the macro there are Martin of Nisus, Kino and Phspaelti — the Ioa-alikes of the Nisus world! — who will sort you out, I’m sure.

But of course, NWP maybe too early in your workflow.


PS Have you tried typing “make” with the appropriate code-string in Terminal?

PPS You might find twin-choke downdraft Webers work better than the Strombergs! :laughing:

You think it is any easier for the CS guys/gals?

A slightly humorous view would be that “writing a best selling novel” is as easy for the English/journalist/LA graduate as “understanding the intricacies of complex systems” is for CS folks.

Obviously not a fair comparison but you get the idea. Even our heads spin at some of the hoops and hurdles folks come up with.

PS Have you tried typing “make” with the appropriate code-string in Terminal?

Yes; the computer coughs, and says this:

 -bash: make: command not found

So I bash it, and it still says

 -bash: make: command not found


You think it is any easier for the CS guys/gals?

No, I think it’s harder for the CS guys and gals.
I don’t know much CS, but I do know just enough of that stuff to know how bewilderingly hard it is.


Generally the CS folks are just really really good pattern matchers and guessers. We can recognize patterns of similarity then, using similar information, guess at what the best solution is. Some folks actually “know stuff” but they get locked in basements to be “system administrators” or “core developers”.

Hmm… maybe I need to reevaluate my career…

So you have a couple of options, none of which really seems ideal:

  1. XCode – I avoid this.
  2. MacPorts – I avoid this.
  3. Pay for help – I avoid this.
  4. Don’t type in German – I avoid German (heck, I barely speak my native “american”).

Slightly more seriously, it might be a good idea to spend a few coins with a local mac shop. I’d avoid the apple corporate stores and look for a local reseller that also does development work (they will typically supply custom billing solutions to photo-shops and medical groups). For about 2 hours of bench time they should be able to make your problems go away.

Well, that assumes that the only problems you have are umlauts an not your neighbors. :confused: