Compiling to PDF seems to silently modify some characters when the two “Convert Markdown to Rich Text” options are enabled (yes, I do want that). Unfortunately before the “before” replacement has a chance to catch those cases. Example:
»This is a test!«
›What’s wrong?‹
becomes
‘This is a test!’
“What’s wrong?”
It’s a bit unfortunate, since the original quotation marks are already what I need. And then they get thrown away. The “” quotations marks are easy to fix via the “after” (or rather during) compile replacements. But the single closing one is a problem. Same character as apostrophe.
Is there some kind of “no no”-switch to prevent or modify the conversion to begin with? Some secret setting, command line parameter or system tweak? Maybe Scrivener isn’t even the primary cause (it probably isn’t, but something does the unwanted conversion).
Yep. I have no idea 1) why the MD → RTF conversion replaces smart quotes with other smart quotes (it clearly recognizes them as such), and 2) why the wrong ones. Probably some default setting. Hopefully not hardwired.
MultiMarkdown is oblivious to System Preferences, by the way, and that may be the actual source of the problem rather than Scrivener. As for what you need to ensure proper quotation formatting for your locale, make sure to set the MMD language option in the Sharing: Export preferences tab. This inserts a standard directive into the MMD metadata block (to use German/Guillemets as an example):
Quotes Language: germanguillemets
I haven’t tested it, but I’m almost positive that’s what is happening. Use of that directive will even take English-style dumb quotes and convert them appropriately to the target locale, last I checked.
If that doesn’t work, there is something else I can think to try.
Thanks. I had already tried this setting, and now several other languages for testing purposes, but it makes no difference at all. What’s your other idea?
Hold up, I read your initial configuration backwards. I actually have no idea what’s going on in that case. There are too many lossy conversion layers involved in that procedure, and no way to step into any of them and see where it happens.
You’re saying you need this, but I’m not sure what benefit you get from that approach, over compiling to MMD→ODT and using LibreOffice to get a PDF, or even just installing a minimal LaTeX setup purely for the direct PDF output.
I don’t know what else to suggest at the moment though. The only other thing you can do is change System Preferences to use a quote style you don’t write with, so Scrivener doesn’t know what these symbols are—but I can’t imagine that’s viable if you depend upon the setting rather than typing them in directly.
Same problem this way, but if that would’ve worked (it doesn’t), it may have been a good enough solution.
The benefit would be not having to rely on or install or even having to master yet another software (e.g. TeX) to fix a weird behavior. On top of the complex Compiler. I mean… it should work out of the box, right? I understand that the built-in PDF output isn’t meant to replace proper typesetting. But such basics?
At times this can be really frustrating. But thanks for your quick response!
Sure, for simple proofing I can see the speed/workflow advantage if one doesn’t have LaTeX installed (although I don’t think you’d really even have to learn a single thing about it, since it generates a PDF straight out of Scrivener—but I realise that could potentially be bit like an airline pilot saying you won’t have to learn much to fly a general aviation single-prop).
I mean… it should work out of the box, right?
Conceptually it should, which is why I’ve changed the classification of the post to a bug, but I can’t speak to whether it is actually something Scrivener is doing or if not, if the system’s bug can be patched around.
Same problem this way, but if that would’ve worked (it doesn’t), it may have been a good enough solution.
I have tried everything I can think of to break quotations with direct MMD output and have had no luck. This attachment shows a project test, with its compiled PDF imported into Research.
A language setting in Compile is definitely needed, especially when Markdown is the output or the intermediate format.
Because if no language is defined in a document the default is English, at least in software/formats coming from the Western hemisphere. To go for English as the default is absolutely understandable but it necessitates a comfortable way for non-English writers to set other languages.
No language/English for non-English text not only affects quotation marks like the aforementioned Reversed Guillemets but also causes word processors to underline all text in red. And it impedes looking up words easily on e-book readers. Reference managers, say in LaTeX, might reference to “p. 202” instead of “S. 202” (“S” for “Seite”, “page”). And so forth.
At least, at this point, you have to learn that all of the Compiler voodoo tweaking done before was basically for nothing (because you have to do it again in another software).
Thanks, this works, now I remember why I abandoned this approach.: It doesn’t change the quotation marks, it just throws all of the formatting out of the window. Sorry for the confusion.
But maybe it helps to understand what’s going on. “This kind” of MMD → RTF (I suppose) conversion (e.g. MMD → ODT) doesn’t produce the same problem. But the “MD to Rich Text” options in the Compile settings do.
So there are either two different methods or different settings involved. Do you know what I mean?
But maybe it helps to understand what’s going on. “This kind” of MMD → RTF (I suppose) conversion (e.g. MMD → ODT) doesn’t produce the same problem. But the “MD to Rich Text” options in the Compile settings do.
That’s what I was saying earlier in how I misread you and was only trying MMD output and not seeing any problems. Just to clarify, at this point I have everything I need to write up the issue, it is very easy to reproduce if you use Scrivener instead of Markdown to generate the final document.
@AmberV By the way: On the MMD → ODT route, blockquotes ("> ") are transformed into a blockquote style. But not in the conversion that precedes Scrivener’s PDF output. Is this a related issue or did I just forget to set it up correctly?
That’s just one of the limitations with using that workflow. Given all of the conversion layers I mentioned, it does not support the full specification, and some things will get lost in the translation.
The 
Do you know what I mean?