Scrivener 3 and Tinderbox 7.x

So does that mean you expand a JPEG and store the full image data uncompressed? I’m just trying to gauge the situation.

Of course “snappy” is relative, in this case relative to the performance I normally enjoy when using Tinderbox on the same hardware. It is not too slow to be problematic, just slower than I’d expect for a file with few notes, but 9 large images.

@entropydave may I suggest

  1. to store images in Devonthink
  2. the right click in Devonthink on the image and click “Copy Item Link …” the and then
  3. paste this in Tinderbox in $URL
  4. invoke KeyAttribute $AutoFetch
  5. check $AutoFetch
  6. Click on File --> Update Agent Now

You should see the image now in Tinderbox without receiving a way to much bloated Tinderbox-document …

One could uncheck $AutoFetch now again without the image going away.

Does that help?

1 Like

Thanks Andreas, I appreciate the suggestion. I tried it with a test DT database and test Tinderbox file. It works exactly as you say, but it makes no difference to the resulting Tinderbox file size: it is still large. Plainly TB copies the image file from DT, which is what I expected, and then expands it and stores it uncompressed. I thought maybe coming from “outside” (i.e. DT) might lead to its being stored compressed.

Different design choices have trade-offs, this is one and it seems reasonable. I’ll just bear it in mind.

This is a statement from many years ago - can I ask whether Tinderbox has ever made the jump to reading Scrivener 3 files directly? It seems (from some experimentation) that the detour via export to Scrivener 2 is still necessary. Or did I miss something?

It’s still necessary; because it works adequately, Scrivener 3 import has slipped a couple of times. Hope to get it soon.

4 Likes