I have an issue with czech quotation marks in the end of the quotation. I google it and I’m lost.
If I’m writing and ending quotation with punctation before it (as czech language need for proper grammar) it take the quotation mark and put it on new line alone. I can’t find a way how to fix it.
On mac I make quotation with command+shift+N and quotation end with command+shift+H
I have the same problem in different software (affinity publisher) and i fix it by instalation czech dictionare for punctation? (I don’t remember - there was a czech guid step by step.)
Affinity might be a little different, because I think a lot of their code is cross-platform. For normal Mac programs you should not have to download anything, you would want to search for how to set up Czech style smart quotes in your System Settings or Preferences, for your version of macOS (Apple moves them around). I should think with that set up right, you would then get proper punctuation by only typing with the one quote key on the keyboard (⇧Ů).
This works for me anyway, if I set my keyboard to Czech in the Keyboard settings area, and then use the „abc“ setting for double quotes, then back in Scrivener, making sure smart quotes are turned on (Edit ▸ Substitutions ▸ Smart Quotes), I can then type and the software changes the quote direction automatically.
I don’t know if that will solve what you are seeing though, because I’m pretty sure ⇧⌥N and H make the same exact characters (it would be bad if they did not!).
Smart quotation works as you mention, but even then it makes same issue. I might not be so cleare with my explanation and I’m really sorry about that.
I will try show here on example text, what is happening with czech closing quotation mark in the longer text:
Něco sem napíšu: „tohle je text, na kterém chci ukázat, co dělají uvozovky na konci řádku.
“
The closing quotation mark, when it’s on the ending of the line, jumps separately on the next line alone (but there is no space between punctation and quotation).
I hope that this explanation works better and example shows what i mean.
Okay! I now understand what you mean better—I was thinking that it was always breaking to a new line after the closing quote, even if it was at the beginning of a line. So the problem is that word wrap itself does not correctly see that this is punctuation that should “stick” to the punctuation beside it, in those rare cases where there isn’t enough space for the the two punctuation marks.
Yes, I am seeing that now, and unfortunately I see the same exact thing in Apple’s free TextEdit program, which uses the same text editor that Scrivener does. That means we can’t fix it ourselves, it is an Apple bug. Sometimes things like this happen where a feature in Scrivener is messing up the text editor (for example, something complicated like the line numbering feature), and we can try to make things work together better. But if both Scrivener and TextEdit act the same, it is like trying to change the words on a sheet of paper by only using the magnifying glass you are looking at them through.
On the bright side, it is only cosmetic. Word wrapping is not something that exports or compiles. So when you open the file in Word, or whatever you use after Scrivener, it should be fine.
I’m working on a doc in German and the quotation marks are different: „Hello world.“
Sometimes the end-quote gets wrapped to the beginning of the next line instead of being kept with the end of the quotation. (example below) I assume this is because the program thinks that it’s a starting quotation mark (like in English) rather than an ending quotation mark. Is there a document setting that can fix this?
(This happens both in the regular editor and in the compilation. I’m more concerned about the compilation, if there’s a difference.)
All I know is that »those« (and ›those‹) quotation marks don’t cause this and other confusion-based issues. I guess that’s no big help if you prefer the other ones.
In that case you could write »this way« and let the Compiler automatically convert the quotations marks. There’s no ambiguity, so it’s a straight forward replacement. But then the compiled output problem remains (or resurfaces).
Are you compiling directly to PDF? Scrivener gets the job done, but unfortunately it’s no replacement for more sophisticated typesetting. (E.g. generating the PDF from MS Word or LibreOffice Writer could already be good enough, at least it’s worth a try.)
In the compile replacements, you could replace the closing quote with a combination word joiner character (Unicode 2060) and closing quote, to force the quote mark to stick with the preceding text.
I see the same behavior when I open the compiled PDF in Preview and in an ePub in both Apple Books. But the ePub in Calibre works OK. All that supports what you said about it being an Apple bug, I just thought it was worth noting that it does potentially persist into the compiled version.
To clarify, the second part of my statement there is perhaps the most important: the condition is that the output is some form of editable document intended to bring the work into finishing or display environments—or outside of where the bug would exist (unless you open it in TextEdit I suppose! But presumably it would be LibreOffice, Word, InDesign or whatever). Put simply: the bug is purely in how text is rendered into a rectangle, be that a window or a page, it is not in the text itself. Another window, using a different code base, is going to do everything different likely, down to the kerning of the fonts.
ePub is a small exception in how I phrased that, in that while it isn’t thought of as “editable” (setting aside tools like Calibre and Sigil), unlike PDF its text layout is not set in stone and is dictated entirely by what you view it with—more like how a web page works. The web page itself doesn’t say where to word wrap anything, that’s all down to the browser. That Apple’s ebook reader doesn’t have the same bug does make sense as it seems to be in the text editing system, not the completely different web display engine—that is what Apple Books would be using to render the text.
PDF on the other hand can be more thought of as drawing a picture of the text into a white rectangle—which is part of why it is so portable. So if the bug is in the text layout engine creating the PDF, it will be faithfully reproduced everywhere you look at it, bugs and all.
