I am using latest version of Scrivener and El Capitan.
I was working on a project with many notes. These notes have been converted to use the font Baskerville. This morning editing some notes I added a dingbat from another font to mark a point inside these footnotes. It was working fine. I closed the project and when I reopened it all the text of the edited footnotes disappeared (hours of work): the non-edited where intact. No way to recuperate them. The footnote was still there (the marker in the text and the inspector space) but the text of the footnote in itself has vanished. I suppose that this has to do with mixing fonts (so do not do it) or it is a bug.
This version of Scrivener has issues that makes me of thinking of abandoning it…
What was the wingding that you added? I would likely need to do things precisely as you did in order to see the problem manifest on my system. Can you describe the process by starting from a blank project, adding just enough text to test a couple of footnotes, and instructions on which wingding to insert? My guess is that the character you chose is confusing the footnote reader, cause the text to not display—likely the text is still there though.
Thank you for the answer.
I was using Baskerville for footnotes and I used a wingding (a fleur) from Adobe Garamond Premier Pro., the top in this image:
fr.academic.ru/pictures/frwiki/6 … apf%29.png
I was working on a project and I tried Composition Mode. I closed the file, and when I opened it the footnotes with the wingding had vanished, leaving one line of empty space.
I hope this was an isolated accident, and maybe only on my system.
Tell me If I can be more precise.
Hmm, still no luck reproducing it. I have tried with Baskerville and added a “☙” character (just with Unicode, I don’t have the font you are using, how did you select that character and insert it, by the way?), then closed and reopened the project, but everything was fine.
Would it be possible to send a copy of the project to support? If so, be sure to copy and paste this thread URL in the message, and provide guidance on which footnote to take a look at. If that’s not an option, I can try to walk you through the steps I would take to examine it.
I have made a rude screen-cast (I am not good on this) and posted here:
I have also included two scrivener projects: the original and the modified.
I used Fontexplorer to insert the character (I suppose you can also use FontBook or PopChar).
Please let me know.
PS. The above link will expire in 48 hours! The file (a zip) is about 80 mega (so I cannot mail it).
Have a good day.
Thanks, I will take a look at this and let you know what I discover—hopefully your edits are intact and just need to have the symbol fixed or something.
I’ve edited your post to remove the URL; wasn’t sure if you meant to share that with the world.
All right so the bad news is that the sample project with blanked out footnotes is truly empty of footnotes. So I’m afraid these edits you made are lost, and you should step back to an earlier project backup prior to inserting the symbols (if you’ve never done that before, go into the Backup preference pane, where you will find a button that loads the backup folder).
The “good” new is that I was able to reproduce the problem even without the font. I found a similar font and selected the same character address (different glyph but that doesn’t matter, it’s just the code that matters) and pasted that into a footnote. Before closing and re-opening, I compared the footnote code between that and another example I created using the basic Unicode “Rotated Floral Heart Bullet” symbol.
One thing that I noticed, when you selected the font in FontExplorer, is that the glyph itself didn’t have a Unicode address, and just seemed to be some internal glyph for the font itself. To be clear, mixing fonts in footnotes is fine—but there is something about how that glyph must be displayed, or how FontExplorer copies it, that inserts some “garbage” characters into the footnote code. It is, I suspect, these garbage characters that are confusing Scrivener and causing it to fail. When I manually deleted them while the project was closed and then opened the project, the footnote content remained, but the character was replaced by a “non-printable character” warning glyph (this is what you would get if you tried pasting into the main text editor instead of the footnote field; though it will vanish upon reload, at least it doesn’t wipe out the main text content).
[size=80]The second line contains the glyph from FontExplorer[/size]
I’ll report this as a bug and see if there is a way we can reliably detect and work around that (though the symbol itself may not work correctly either way).
So for now I recommend using the Unicode character (U+2767) instead. The Minion version of it looks good. In the attached project, I’ve created a line using the glyph alternate from FontExplorer and a footnote, and on the second line the heart bullet character. You should find the glyph alternate has vanished (and destoyed the footnote), but the heart character works fine in both places, even with an alternate font for the bullet.
Dear Amber thank you for taking all this time for this minute issue. For me it is not a big problem: I may use something like XxxX and then after compiling etc. I may find/change this garbage with the symbol I like, etc.
Still remains a little problematic that something so small it is capable of deleting (DELETING!) an entire paragraph. How is this possible? I do not understand the mechanics of it (but I am not a specialist in coding etc.): insert a character and it “eats” an entire footnote of many lines?
I have noticed that the character was missing the unicode id, etc. In Nisus for instance doing the same action (copying the character from Fontexplorer and pasting) I get an X (a non printable character) whereas in Textedit the character was copied ok.
Without making a big fuss, I think that you should investigate how it is possible that Scrivener “eats” text! The correct behavior should be or a window saying that you cannot paste the character, or pasting it and transforming in a non printable character, or a X, or whatever. But it is not acceptable that one loses his/her work.
Have a nice day.
Well I wouldn’t consider any bug that can delete content a minute issue. While we might not be able to display the character properly, it should at least gracefully fail to do so. My guess is that the thing that reads footnotes into the sidebar when you click on a file is getting jammed by characters that are invalid in the context they are stored within (XML). That aborts the XML reader, which results in a cascade of bad reactions where you end up with wiped out footnotes (since they couldn’t be read in)—and that condition gets turned into a stored condition once autosave happens. So I would guess, either on the paste side or the read side, some error detection needs to occur. Well enough coding jargon.
I tried the same thing in Nisus as well and noted that one gets the warning character when trying; forgot to mention that. What has me confused is how TextEdit works, since technically speaking, that’s the same engine Scrivener uses. That does give me hope that there is a solution.
The notion of using some placeholder like “@@” sounds good to me.
Oh, and I forgot to post the example .scriv with a symbol that does work fine.
glyph.zip (24.5 KB)
Just to let you know that this is fixed for the next free update. The problem is caused by what seems to be a minor bug in the OS X text system. Essentially, RTF files are ASCII plain text files with lots of mark-up. All Unicode characters are represented by escape sequences in the RTF. In this case, where a non-Unicode glyph was being inserted, the OS X text system was saving it as garbage binary in the RTF. For comments, the RTF is embedded as a string value in an XML file, so the string is first read from the XML, converted to data, and then read into rich text using standard RTF reading methods. But the trouble was that the garbage data was causing OS X’s string-to-data methods to fail when trying to create it as ASCII data (even though RTF should always be ASCII). So, I have added a fall-back: if the data cannot be created as ASCII, I create it as UTF-8, which seems to solve the issue.
In other words, it was rather arcane, but is fixed.
Thanks and all the best,
Very arcane, indeed!
Have a wonderful day.
Actually, it turned out even worse. I had to build 2.x on 10.10, and fixed it there. But after replying, I then tested on El Capitan, and that makes the bug even worse. It seems that the text system’s standard RTF saving method just returns nil data if there is one of those glyphs in there. Very odd! There is another RTF saving method that does work, though. So I will most likely have to switch over to that. I’m still testing…
I’m not sure if this works in footnotes, but try using the “Replacements” tab of compile to search for XxxX or whatever you use and replace it with the unicode character of your choice. If it works, then you don’t have to do an extra step after compiling.