3 Problems: Force Close, Endnotes, Script-writing

Scrivener Scrivener for Windows
1

*Sorry, I put this in the Technical Support Forum, first, thinking I’d put it here.

I just uploaded a project template on the Scrivener Tips board, and I wanted to let someone know of a few problems I found while creating it. I’m not sure if it’s just my copy of Scrivener that is doing this, but I can’t think of a reason why it would just be my machine with these problems.

The first problem has to do with the script-writing function. I found this while using the Undergraduate Essay template to mess around with block quotes, but it happens with other script-writing elements in other templates. I found that if you’ve got a quote with a citation in parentheses after the period (such as you’d find in a block quote), and you change the element to something else, the closing parenthesis disappears. It does this no matter what element you were previously in, or what element you change to. This isn’t as annoying as the other bugs I found, since all you have to do is type a single closing parenthesis to fix it after changing elements, but it still shouldn’t be happening.

The second problem is with footnotes and endnotes, and has two parts. The first part: When I compile to .doc, inspector footnotes don’t convert to endnotes properly. When I choose to export the footnotes as footnotes, they show up at the bottom of each page, with correct numbering and correct text. However, if I export as endnotes, things go wonky. Instead of arabic numerals, like you get with the footnotes, the endnotes get roman numerals. And, instead of getting the text that is in the inspector footnote box, the word and punctuation that was immediately before the footnote/endnote marker get(s) excised and placed at the end as the endnote. For instance, if I have the following sentence (with the footnote marker in brackets since I don’t know how else to show it on here):

The dragon ran down the hill as fast as he could manage.[*]

The same sentence after compile becomes:

The dragon ran down the hill as fast as he could[i] (again, the endnote number is in brackets because I can’t do superscript here)

With an endnote of:

i manage.

If I try the same thing for converting to .pdf, the endnotes show up right where they’re supposed to be, with the correct numerals and the correct text, without removing any text from the document.

The second part: When compiling to .doc, if I “Mark end of text” in the compile settings with “###”, the “###” gets a footnote, with the same text as the last-created footnote. Compiling to .rtf has the same effect, and it doesn’t do this when I compile to .pdf. These endnote/footnote problems are more annoying than the script-writing one, since I would need to go through the document and manually fix every endnote marker and retype the text in the endnotes at the end.

The last problem is the biggest, since it involves Scrivener force closing. The way to get it to happen is to create a bulleted list inside an inspector comment, and then try and drag the document containing that inspector comment anywhere else. I can right-click the document, nothing happens, click and hold, nothing happens, but as soon as I click and drag one pixel, Scrivener closes immediately. No error message, no nothing, just goodbye. If you have multiple projects open, all of them close.

For reference, in case it matters, I’m using Windows 7 Ultimate x64, Scrivener 1.5.3.0. I was able to replicate all of these problems in multiple projects. Hopefully my explanations were clear enough to follow.

Cheers

2

I’m brand-new to Scrivener, still testing it out, so I haven’t experienced much of what you describe, Sanguinius. But I just tried it, and I can confirm that the last-mentioned error, the force close, happens exactly as you describe. Scary and calamitous if you don’t know it’s coming! I closed down the real project I was working on before trying this out on a meaningless test project. Curiously, when I restarted Scrivener the real project (perfectly intact, of course) was the only one that opened. I reopened the test project manually and (because of 2-second saving) it also was intact, altough (unlike the real one) its window was resized to the default smallish size.

Regarding the other issues, I just want to comment on “Instead of arabic numerals, like you get with the footnotes, the endnotes get roman numerals.” I’ve had this happen when exporting to MS Word from other software (haven’t tried it in Scrivener yet). I use Nota Bene (http://www.notabene.com) as my word processor, and there have been times when exporting from it to RTF and then importing the RTF into Word and saving as .DOC has turned arabic-numeral notes into roman-numeral ones. I had to fix it using Word’s none-too-easy footnote function. So it’s possible that there’s an RTF/Word issue going on here that’s outside Scrivener’s province.

3

Thanks for the reports. Most of this has already been fixed for the next release, which we’re hoping to have out shortly, so just to go through quickly:

  1. Deleted parenthesis in script mode: I was able to reproduce this when switching to an element that has built-in parentheses in the format and then to one that does not–basically, Scrivener sees the end parenthesis and does not duplicate it when converting to the element that is enclosed in parentheses, so when then switching to another element that does not have these, the opening and closing parentheses are removed, resulting in that final intentional parenthesis being deleted. So for instance, in the Screenplay format if I
  1. type “Hello, world! (Hi!)” formatted as an Action element and
  2. use the footer elements menu to change that paragraph to the Character element, the parenthesis remains. If I then
  3. use the footer menu to change the paragraph to the Parenthetical element, a new parenthesis is added to the beginning of the line, but a second one is not added to the end, so it now reads: “(Hello, world! (Hi!)” At that point, I can
  4. use the footer menu to change the paragraph to the Action format again, and the final (and opening) parenthesis is removed, so the line reads: “Hello, world! (Hi!”

This was the only way I could get the parenthesis to disappear, however, which seems more specific than what you experienced. Could you please provide exact steps to replicate the issue so I can better test this?

2a) Compiling endnotes to RTF/DOC: This is fixed so the correct text is used for the note and the main text is not truncated, with the marker appearing where it should, as in your example. The Roman numeral numbering for endnotes is common (it’s the default endnotes marker in Word), hence its appearance here. I’m not sure what program you’re using, but it’s simple to adjust this in Word 2010 by opening the Footnotes & Endnotes panel and then changing the endnote numbering format from the dropdown:

I imagine that most word processors that support footnotes and endnotes should have a similar means of converting the format. Down the road, we plan to allow users to choose the marker within the compile pane, which will make this still simpler.

2b) End of Text marker: Could you please provide steps to reproduce this? I tried several compiles with the marker on but haven’t seen it acquire a footnote as you’re describing. A lot of work has gone into the footnotes, separators, and custom markers like this for the next release, so it may already be fixed, but I’d like to be able to test it out and confirm. If you could let me know how to recreate this from a blank document and what compile settings I need to see it, that would be great.

  1. Crash due to list formatting in comments/annotations: This has been fixed for the next update. In 1.5.3 the bulleted list format in the notes also causes a crash when trying to compile those notes to margin comments, likewise fixed for the next update.
4

It actually took me awhile to remember how to replicate the problems that I found for you, but I figured it out.

  1. (Parenthesis disappearing)
    I got the same results as you when following your instructions, which I’ve found is a workaround to the problem. However, the problem is still there. To get it to happen, you have to have part of the element selected (highlighted). This is the only way the bug works. If the text isn’t selected, the parentheses don’t disappear (except in the parenthetical switch, which you saw). But, if you highlight so much as a single character within the element, and then change it to a different element, that closing parenthesis goes away. I was able to replicate this in brand new projects from the blank, fiction, and non-fiction templates.

2b. (End of Text marker) Steps:

  1. Create new project.
  2. In empty document, type “This is a test of the footnote bug that I found.”
  3. In inspector “Notes” pane, create new footnote with text “Test footnote”.
  4. In compile settings, start with default settings (Original):
    a. Transformations - Tick the box “Mark end of text with:” (You can leave it as “Ends”, it doesn’t matter)
    b. Footnotes/Comments - Export to RTF as: Footnotes
    c. Compile as .doc or .rtf (Works for both)
    d. Open in Word
  5. Your resulting page looks this:
    Scriv Bug Shot.png
    Scriv Bug Shot.png2760×2336 144 KB

I suppose that this might be something to do with Word, since you said the other footnote rtf export problem I found was actually a Word problem. Though the changing from arabic to roman numerals thing is still a little strange, as it only has a problem with endnotes, not footnotes.

I don’t know if it’s helpful, but I’m attaching a copy of the brand new project I created to test this, and a copy of the compile settings from the appdata folder.

Thanks for the response, and I’m glad to hear some of this stuff is already fixed and waiting to roll.

Scriv Bug Test.zip (11.9 KB)

5

Got them both now, thanks! The bug with the end of text marker looks like the marker is picking up the footnote formatting from the inspector note, which it shouldn’t do of course; this isn’t a Word issue but a compile bug.

6

Happy to help!

7

I’m using the latest Scrivener for Windows release (1.5.3.0), and I’m still having problem 2a mentioned in this thread as fixed. In my Scrivener document I have a quote, which I use as anchor text for a footnote (the source of the quote). This all displays correctly in Scrivener, with the quote highlighted in gray in th Editor and the footnote appearing in the Inspector containing the source citation for the quote. When I compile, however, the anchor text disappears from the document, and instead shows up as the footnote, while the footnote (the source citation) has disappeared altogether. If it makes any difference, I have it set to compile footnotes as endnotes.

Am I doing something wrong with a setting somewhere? Or is this bug still there in Windows 1.5.3.0? Any suggestions for a fix/workaround?

Thanks! :smiley:

8

This was reported with 1.5.3 and fixed for the upcoming release, so you haven’t missed anything yet. It’ll be out shortly. In the meanwhile, if you need to compile urgently, compile as footnotes rather than endnotes, then convert them to endnotes in your word processor after the fact to avoid the issue. Alternatively, you could convert the inspector notes to inline notes and compile as endnotes, but unless you only have a couple notes I suspect doing the footnote to endnote conversion in Word or such during post-processing will be faster.

9

Oh, that explains it! Thanks much for the info and the workaround suggestions! :smiley:

10

I like the fixes that I’ve found so far in the new update, but I just wanted to comment that not everything I mentioned in my first post of this thread has been fixed correctly.

  1. The closing paragraph bug still happens just as it did in 1.5.3.
  2. The exporting footnotes as endnotes bug is slightly fixed, but not completely. The problem with the replacement of the note text with the last word before the note marker is good now, but there’s still a slight problem. The word just before the marker gets compiled as Courier New, rather than the font that I have chosen for the rest of the text, which seems to compile just fine. This happens regardless of the “Override font” that I choose, but I think that option only applies to the actual footnote text that appears under the separator line.

The force close issue is gone, though, and the remaining footnote issue is more easily fixed in Word, so I’m happy overall, though hoping that these will eventually be fixed in the next update/upgrade.

Thanks.

11

We weren’t able to get the chance for the script parenthesis issue in for the update, no. It’s related to how Scrivener identifies the different elements and makes changes when converting from one form to another, and it was actually an issue then on both the Mac and Windows platforms. I brought it up with both developers and it should be at least amended for a later update, but there’s some fancy logic involved and it just didn’t get done for 1.5.5.

I see what’s going on now with the text in the Courier New font; thanks for catching that. We were fighting with the endnotes up to the end so that must’ve reverted in one of the last builds and we missed it. Fortunately it appears limited to compiling inspector footnotes as endnotes in the RTF/DOC formats and should be easy to clean up after the fact, as you say, but it’s definitely something that shouldn’t be happening and I’ve written it up for Lee’s attention.

12

Hi
Version 1.9.7.
Compilation of footnotes works not really well and clear still.
If compilation goes to *.docx with the choice of “Footnote”, then the Arab numbers are inserted.
But at the same time touch between number of a footnote in the text and subtext record is lost.
If compilation with the choice of “Endnote”, then the Roman numbers are inserted, but communication between number of a footnote in the text and subtext record remains.

It would be desirable:
1.

  1. That at compilation in *.docx with the choice of “Footnote” or with the choice of “Endnote”, communication between number of a footnote in the text and subtext record remained. And that it was possible to change style of footnotes (Footnote/Endnote) in Word.
    It is desirable that at compilation in *.docx Scrivener did the necessary work from beginning to end - without the need for additional editing by means of Word.