Spinning beach ball with image files


I’m a PhD student in Humanities and I have a few graduate school friends who bought Scrivener upon my recommendation. Two of them who come from the domains of Museology and Sociology suggested some modifications for your future versions, and I would here like to speak on behalf of them.

For scholars who work in research domains in which images files (jpg., pdf., etc.) are frequently consulted (for example, Art History, Sociology–for historical references–, Photography, Cinema, Museology, etc.), the spinning beach ball appears when there are more than ten image files (even though their frame size shrunken into 300, for example) in a single note. This seems, to me, as a problem of optimization. For example, it does not happen in other word processors such as MS Word or Mac Pages. My friends have tried to divide into multiple notes to solve this problem. However, it is unsatisfactory since the beachball appears again when the scrivener file size exceeds 1GB (cf. even 1/10 of a doctoral thesis file easily reaches 1GB in these domains). We believe that the Scrivener team may rescue us by enhancing the optimization for image files in their further updates.

We love Scrivener: it helps us tremendously when writing a thesis; however, we have not enough time to play with spinning beachballs when we still have hundreds of pages to write.

We have very limited capabilities for low-level optimisations like this, unfortunately, as the text engine is Apple’s core text editing component. If you’ve ever used TextEdit, then you’ve seen the core editor from Scrivener, albeit in a simple wrapper program. I would speculate that part of the problem is that Apple’s text engine does not support true RTF standards for embedding images (they use RTFD files), and so they likely never designed the system under the assumption that anyone would be throwing gigabytes of data into the rich text editor component! :slight_smile: We do not expect you to do that either, though it may seem natural.

I would highly recommend, if you have that many heavy-duty illustrations in your thesis, that you use linked images instead of fully embedded images. You will want to use Edit/Insert/Image Linked to File… (and likely assign a custom keyboard shortcut) to do that, or you can use text-based placeholders that refer to the images either on the file system, or elsewhere in the Binder (as discretely imported files, rather than embedded into text files).

Are you referring to double-clicking on the image and changing the size of it in Scrivener? If so that won’t help you out with this particular issue—that operation does not discard pixels, but rather merely changes the image’s display properties (as in Photoshop, the lower half of the scaling dialogue, where one sets the physical display dimensions and resulting DPI, with the resampling capability disabled). In other words, you are packing the same amount of raw information into a smaller space. That has nothing to do with the fact that you still have a 1gb disk write burden with every auto-save event.

As a bit of an aside, what is your target output for this, and have the graphics been optimised yet for that output? I ask because 10 files bloating a text document to 1gb would mean these files are, what, 16-bit/channel RAW format straight out of a professional Nikon camera, or something along those lines? I would not expect someone creating even a high-quality full colour coffee table sized art book to be hitting numbers like that with so few images—especially if one is using JPEG. We would expect to see several hundred individual figures before getting anywhere near the territory of 1gb.

Part of the answer may be to get the graphics baked down to press-quality specs before working with them in a text editing context. As they say though, “YMMV”. :wink:

[size=120]Further reading[/size]

  • §15.5, Inline Images in general, pg. 217 of the user manual PDF.
  • §15.5.3, Linked Inline Images, pg. 219.
  • §15.5.4, Image Placeholder Tags, pg. 220.