Resizing an image – specifically, reducing the number of pixels it contains while preserving the visual appearance – very much is an editing task.
2 Likes
I posted a suggestion that adding a special paste for graphics to be reduced in size in a Scrivener document would be quite useful. Surprisingly, I did not receive a single positive response, with a Scrivener official response being that, “So yes, as I say it’s very unlikely we will ever add that to the editor because that isn’t something a text editing program should be doing, and there is a very high level of likelihood that it will just get people into a pickle.” - From Ioa, taking a look at [my] feature request.
In this process I am amazed, and disappointed, that my suggestion was not considered based in large part on much misinterpretation of what my suggestion had been, or the positive benefits implied in my suggestion. Rather than continuing to argue a point that seems to be of little interest - at least to those who have responded, I would like to offer the following clarification before leaving the topic entirely.
-
The official Scrivener response was focused on not thinking adding a way to shrink a huge image file was a good idea because that might interfere with how a publisher would want to see the document at a later date. This frankly shocks me to hear as apparently, according to this opinion from Scrivener, I am the only writer who believes that part of the writing process is to do research before you write your document. I say this because, while there is a reason to place a link to a full sized image file outside of Scrivener for the purpose of publishing a document, it is also true that the compile feature allows me to select just the parts in the Binder that I want to compile. That means that, my smaller sized image files that I have used to assemble my notes, and to do my research, will not be affected in the least when I compile my Scrivener document.
-
I have heard responses that said that I was suggesting that Scrivener should be like an image editor, which is completely false. Allowing for a, “paste special” option for reducing the size of an image file is a choice, hence the term, “paste special” menu. This has nothing whatsoever to do with how a Word processor can manipulate or provide additional processing to an image. I am not suggesting changing the opacity, the color, or any image related parts of an image file. I have only suggested that reducing the size on a special paste option would be useful, as it is a well known fact that large image files will choke Scrivener.
-
Considering these comments, the question must be asked, what is Scrivener? It is certainly not a word processor like Word, Nisus, or Pages. It is not a simple text editor like plain text or Mark-up. Scrivener is a writing tool that should be a great tool for all writers. And as I have already said, that includes writing drafts including visual image cues which are sometimes in very large image files, which have no need to remain very large image files.
Please remember that Scrivener is not just a tool to get published, it is also a writers tool. And writers doing research will appreciate not always having to paste very large images, or make external image links without being able to visually reference what you are writing about.
And finally, while this may not endear me to my fellow Scrivener users, I can’t help but close my comments with the following story taken from one of my past team building programs. The following story illustrates how, at times the very idea of changing something is unthinkable, because its just not the way we have always done things here.
Five Apes or, The Way Things Are.
Start with a cage containing five apes. In the cage, hang a banana on a string and put stairs under it. Before long, an ape will go to the stairs and start to climb towards the Banana. As soon as he touches the stairs, spray all of the apes with cold water. After a while, another ape makes an attempt, with the same result-all the apes are sprayed with cold water. Turn off the cold water. If, later, another ape tries to climb the stairs, the other apes will try to prevent it, even though no water sprays them.
Now, remove one ape from the cage and replace it with a new one. The new ape sees the banana, and wants to climb the stairs. To his horror, all of the other apes attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.
Next, remove another of the original five apes and replace it with a New one. The newcomer goes to the stairs and is attacked. The previous Newcomer takes part in the punishment with enthusiasm.
Again, replace a third original ape with a new one. The new one makes it to the stairs and is attacked as well. Two of the four apes that beat him have no idea why they were not permitted to climb the stairs, or why they are participating in the beating of the newest ape.
After replacing the fourth and fifth original apes, all the apes which have been sprayed with cold water have been replaced. Nevertheless, no ape ever again approaches the stairs. Why not?
“Because that’s the way it’s always been around here.”
Sound familiar?
Because, frankly, it comes across as condescending. You are effectively assuming that there are not good reasons for the feedback you were given, while effectively accusing those people of assuming there weren’t good reasons for your feedback.
Sometimes what looks like “the way things are” actually have good solid reasons that take time to learn.
3 Likes
It’s a little strange that you chose to respond to my email on the forum, and snip out a single summary sentence without any of the supporting arguments that lead to it—but whatever, I am sure most who have participated in this discussion are already familiar with my stance on the matter.
In reviewing this thread, I see a lot of cordial response and suggestions being made for how you can better manage image handling in Scrivener, which is at odds with the aggressiveness and lack of respect found in your response here. I hope everything is okay on your side of the world.
At any rate, to close off this conversation (since it sounds like you are done), here are a few important points of clarity to what seem to be misconceptions of Scrivener’s offerings:
I am not suggesting changing the opacity, the color, or any image related parts of an image file.
This may be in response to how I suggested image resampling should be paired with techniques to repair the damage done by that, such as unsharp mask? It wasn’t my intention to suggest that you thought Scrivener should have all of the necessary tools to resample graphics. My point was that since it does not and cannot have all of that, it will never be the best place to do it.
Now you have since clarified that you never meant anything you said to be applicable to the management of assets used in the production workflow, and that is fine. One can be more sloppy and use screen-res graphics that are not retouched, if the only purpose is one’s personal reference. I don’t think anyone would disagree with that. We’re on the same page with that.
But what you are perhaps neglecting is that the same misunderstanding you’ve found to your proposal might lead to a widespread misunderstanding of the actual feature itself, were it implemented (incidentally, precisely one of the points that I made to you in email in fact, prior to encountering this discussion). That would be the obvious conclusion, would it not? If we put a destructive resampling tool in the text editor, then people would presume it to be a tool for managing their publication workflow. That’s one big reason for why we don’t have destructive resampling tools in the software (save for compiling, but that isn’t actually destructive as it only cuts overall output size, and we still only recommend the setting for proofreading usage).
So, let’s back up a bit and talk about research.
And writers doing research will appreciate not always having to paste very large images, or make external image links without being able to visually reference what you are writing about.
I am unsure of where you have come to this belief that linked images cannot be seen? All three of the mechanisms Scrivener has for linking to images do so in a way that is seamlessly identical with the result one gets by embedding the bytes of a graphics file into a text document, or importing it into the binder in the latter case:
Insert ▸ Image Linked to File...Insert ▸ Image Linked to DocumentFile ▸ Import ▸ Research Files as Aliases...- (There is also a fourth, though it’s more of a niche tool for inserting images into context where only text can be typed, like in the compile settings area. Maybe that is all you tried and gave up, thinking the rest would be similar?)
To synthesise a better approach for research-motivated image management:
- Drop your graphics into the binder, either as fully imported into the project or as aliases, using the command above. Now you have a “light table” type corkboard view of your images. You can even switch on freeform mode and push them around like you might push Polaroids around on a desk to group them by colour, theme or topic.
- Organise your research materials as you see fit. Annotate them in the Document Notes inspector sidebar. Tag them with the keywords feature. Link to them from sections that benefit from them, with the Bookmarks pane.
- If you want to embed the graphic into the context of a discussion directly, as one might do in a book, then use the second method referred to above, or simply drag and drop from the binder into the text editor (can be set to insert a linked thumbnail of the image, in the Behaviors: Drag & Drop preference pane). The result? An invisible short sentence of data basically, describing where the image is and what size to view it by, in this context, which results as a thumbnail in the editor. It’s not going to bloat your editor or cause issues because it’s not really there, it’s just being shown there. If you edit the original, then all of the preview thumbnails in your research folder update.
- You can open images out of the binder and into Acorn or whatever, and resize them or change there. This much less incentive to do so however, especially if they are aliased into the binder, since the total overhead of the image in Scrivener is a scattering of bytes, maybe a few kilobytes at most, no matter how massive the original image.
These methods are also generally superior for production graphics as well, incidentally—but for different reasons. All around, as I said to you in email: the worst way of working with graphics in Scrivener is embedding files into your text. It’s not efficient, it limits your options, and it makes any kind of editing (whether quick and dirty or professional work) more difficult and cumbersome.
Ultimately, embedded graphics are a kind of “mostly good enough” fall-back behaviour, in my opinion—and I would even argue there are probably better ways to handle the scenarios that lead to it being used, anyway. For example, when I paste graphics data into one of my Markdown-based task management tools, it doesn’t stick 450kb of raw image data into the text file itself (heaven forfend), it automatically creates a new file from the clipboard into an asset subfolder and then generates the Markdown syntax to link to the image—which renders in the software as a thumbnail. That may all sound complicated but it isn’t. At the front end side of things, I get exactly what you get in Scrivener with the Image Linked to Document feature, which is in turn as seamless and friendly to write around as embedding the graphic into a text file. However I get it that result with one simple action that everyone expects to be able to try rather than Scrivener’s multi-step approach.
That’s the kind of stuff I’d be more inclined to see improved in the software. If linked images were as easy to handle as the fall-back behaviour of embedding them into files, then we could do away with that archaic and unwieldy approach entirely.
I realise that is somewhat off the topic of what you meant, but hopefully you will see that I mean to tie together the ease with which one can “Open in External Editor” and resample something, as a better response to resizing images than a hack job in the text editor that produces sub-standard quality results, that will confuse almost everyone that encounters it into thinking it is meant as a publication tool—because generally the reason for putting graphics into a text editor is for the purposes of indicating to the designer where you want it placed in the book.
5 Likes
Ultimately the final decisions as to whether your excellent suggestion is added to Scrivener will have to be decided by computer mavens who are familiar with the gory entrails of scrivener and what their vision of what Scrivener should be. And if they decide if it is even doable without a lot of hair pulling and late night hours whilst cursing whoever it was who came up with the idea, and would the effort pay off.
So now the ball is in their court. And you can only wait and see. And let’s leave this saga for now. It may or it may never see the light of day.
Amber, sage advice. 
Is there a section in the manual that deals with this thorny topic of best practices for dealing with graphics. Or, perhaps a form focusing on this issue.
In any case I save it to Scrivener Tips book marks.
Hmm, I don’t think the manual goes too much into tactics, particularly in how one can combine various tools together to aid in research material management. The manual is long enough just describing what the corkboard is and how its features work, let alone getting into the dozens of ways it can be used as a component in a workflow. 
The closest such discussion on images is found in §15.6.5 (.6 in the Mac PDF), but that mostly covers how to avoid issues that arise from using high-res production assets in the main editor. Very close to the discussion at hand, though framed within the confines of how most people will be encountering these issues: putting lots of full-scale images into their book and running into lag issues.
We do have some people putting graphics into text editors purely for research reasons, but it is not common enough, or used heavily enough as a technique, to frequently run into performance issues, in my experience.
My fault, I think.
I learn something every day.
1 Like
Hey, it’s what keeps us from being traumatised apes in a cage.
2 Likes
May I respectfully suggest that we now drop this issue. The topic raised was put on the wishlist the developer now knows about it. It is up to them to decide if they want to grant your wish.
2 Likes
Yes, I agree. I will only close with a reiteration of what was said in my original email response, I believe, and that is that the choice to not have a destructive resampling tool in Scrivener was very deliberate, and we have strong reasons for it not being in the software (save for as a compile-only tool for reducing the size of PDFs you send to proofreaders).
1 Like