Soft Return

Hi, there.
I write scripts in Chinese.
When I segmented the text with a ‘soft return’ (⌘+⌥+Return), the show results was correct.


But when I saved and reopened the project, the ‘soft return’ disappeared. :frowning:

I tried both in scriptwriting mode and normal prose mode, It’s the same problem.

scrivener version: 3.0.2
Mac OS 10.13.4

I didn’t have any luck trying to reproduce this. It may be that I am just not doing the right things, or have the right settings to see things as you do. It might help to send us a short sample so that we can take a look at it. These screenshots can help us see where to insert the line breaks. Did you add them after the fact, or as you were typing (or does it not matter)?

Thank you for your reply.
There is a short sample and script settings,
I’m working hard on my English, so I can only record this video as an explanation. :open_mouth: youtu.be/L0uowi6i8p8

Thanks.
Chinese Script Template by Kinsemn.xml.zip (1.84 KB)
Fast Bullet.scriv.zip (108 KB)

Thank you! I can see the problem using this sample very easily. I will send it to the developer.

The bad news is that it may not be something we can fix. I copied and pasted the sample into TextEdit and inserted a line break, then saved the file as RTF and closed and reopened it. The line break was lost there was well. So it looks like a Mac text bug—but if it is, we have enough to easily report it to Apple.

Ioa, Kinsemn,

Not really my place to intervene, but I too tried putting a soft return in Kinsemn’s Chinese text in FastBullet.scriv, closed the project and reopened it and the soft-return had disappeared, I tried this using both Chinese and English input systems.
However, I then created my own little scene, first of all using English—though the script controls are still in Chinese—breaking a line up with a soft return. I closed the project and re-opened it and the soft return is still there.
I wondered if perhaps the problem was to be found in the Chinese entry system. So, I then switched to Chinese (pinyin) input—though my MacOS is UK English—and wrote a continuation in—very bad … I have to apologise Kinsemn!—Chinese including a soft return. Again, I closed the project and re-opened it … and the soft return is preserved.
So, where can the difference lie? Most importantly, I did not use the “Chinese Script Template by Kinsemn.xml” as I have no idea how to import that into Scrivener, but just relied on what was provided in the project, using Cmd-N to create the new scene. Apart from that, I cannot explain why the soft returns should be preserved in my scene, but not in Kinsemn’s.

If it will help, I attach my ghastly modification of FastBullet.scriv!

Fast Bullet 2.scriv.zip (106 KB)

:slight_smile:

Mark

NB: I’m now on MacOS 10.13.4, if that’s of any significance.

Thanks for looking into that, Mark. I too was trying with the Pinyin input method in my initial tests, and never saw it with that. Interestingly, with the sample file tests I did not use any form of Chinese entry—I just opened the project and using the English input system, hit the ⌥⌘↩ shortcut to insert a line break into a spot that looked similar to the screenshot samples above.

It might have to do with the font somehow. I tried monitoring the RTF file used to store the data on the disk, and if I simply put my cursor into the existing line and hit the ⌥⌘↩ key, then what gets inserted into the file on the disk is, in technical terms, a “Carriage Return” character.[size=80][1][/size] The interesting thing about this is that this CR character is not lost. It is saved into the file and it remains on the disk even after the project is closed and reloaded. The problem is that the Mac text engine is not programmed to parse for these CR characters and do anything with them—they become invisible control characters.

What should be happening, rather than inserting a bare control code like that, is the insertion of an encoded symbol to represent the line separator character (I know you probably have fond memories of that whole nightmare of encoded vs unencoded characters in RTF files!). And that does happen even in the sample file—but only if you switch the font to something else, like Courier Prime, and then hit the shortcut to insert a line break. There is something about inserting that character into this font it seems. I can reproduce the same problem in English text, by putting my cursor in the middle of a line, changing the font to Hiragino Sans GB and inserting the line break. If I do that, then the RTF file on the disk has the naked character inserted, and reloading the document results in a breaking of the formatting.

It’s good to know it occurs on 10.13 as well. I was testing from 10.12.

[size=80][1] For the sake of context, this is opposed to a “Line Feed” character, which is ordinarily used to indicate new lines in a file of this nature. Signifying the end of a line with a CR all by itself is an ancient Mac text file method from the classic OS days—LF is the modern method on a Mac, while CRLF (two characters) is the Windows method.[/size]

Thank you so much Mark, and AmberV.
I downloaded and opened your project (fast bullet 2), the soft return was preserved.
I reset all Scrivener settings, created a new file, all the soft return was OK.
According to Mark’s test, maybe I know where the problem is. ‘Chinese fonts’ I thought.
Please see another video I made. https://youtu.be/fwyOh3VudtM

I tried several Chinese fonts again, Some of the Chinese fonts had problems, but ‘Simsun’ and ‘PingFang SC’ (a type of Chinese fonts) had no problems.
I think this may be an issue that Scrivener can’t solve. It’s related to Mac. :open_mouth:

Actually, If the setting of a paragraph spacing becomes more diverse in scriptwriting mode, Chinese script do not even need a ‘soft return’. :slight_smile:

Thank you for your attention to this matter. :stuck_out_tongue:

On my system, the default Chinese font is PingFang SC, which is the font used by FastBullet.scriv, and therefore FastBullet 2.scriv on my machine. I actually set Songti SC as the font for all Chinese work I do; it goes better with Libertinus Serif my current default Roman font in Scrivener.

I switched the Chinese to Songti SC in both your first scene and my scene, deleted the 。 and the 须臾 and retyped them with a soft return in between, closed and re-opened … and the soft return had disappeared. So yes, it seems entirely related to what code/character is attached to Opt-Cmd-Return in the various Chinese fonts.

Which font or fonts have you found, apart from PingFang SC which retain the soft return? I prefer working with a Song type serif font to the non-serif PingFang SC—which I presume is the MacOS 10.12/13 system font for Chinese—and will go through all the Chinese fonts I have installed to check, but I’d be interested to know what you’ve found. The only two I’ve found—I don’t have SimSun—are HYXiDengXianF and FZXiDengXian-Z60, both of which are sans serif fonts, though lighter than PingFang SC.

I can only thank you for bringing this up; it’s good to bring these problems into the open, even though they are down to the Mac system or more likely the font producers.

:slight_smile:

Mark

I have a related question:
Is it possible to compile and convert a Scrivener file with Chinese and English text to .docx and retain the Chinese text? I am trying out Scrivener 3 on my mac (OS 10) but whatever I do, can’t seem to produce a compiled docx file that keeps the Chinese characters. They just come out as empty squares and they can’t even be changed into a Chinese font once in the docx file.
I have tried changing the Chinese font to Songti TC and other fonts IN Scrivener before compiling, but still doesn’t work.

Thanks for any help in this. Using the trial version, but if I can’t fix this quickly will have to give up on it. Too bad as I was liking the interface for my dissertation work.

There are a couple of threads reporting this happening in Korean … this one gives a link to the other—
https://forum.literatureandlatte.com/t/exporting-broken-korean-docs/44062/1
—so it’s likely it is the same known problem with the system Java and the third-party converter that is used. Scrivener’s native format is RTF, and when you compile, your text is first compiled to RTF and then passed to the Aspose converter to be recoded as DOCX.

The simplest way round it—until the problem is finally solved, and even then, I do this anyway—is to compile to RTF and open that in Word then save as DOCX from Word. This by-passes the need for a third party utility. Yes, it’s an extra step, but a useful one, as reading your text under a different interface brings to light typos and other infelicities that your eye has passed over in their usual context. And you get to check the pagination and other layout features before printing or sending it off.

:slight_smile:

Mark

Thanks Mark, That worked!
The font that i used originally changed (both the English and the Chinese) but I can deal with that.

Thanks for your quick reply!