I’m not fond of making a note to myself red (so I’d like to change the color), and it’s hard to read the first & last letter in the annotations due to the corners being so rounded.
IIRC, all you need to do to change the colour of annotations is to change the colour in one. ie, Highlight some text, cmd-shift-a to make it an annotation, then cmd-shift-c to bring up the colour picker. Choose your new colour and it will persist for new annotations until you change it again.
It won’t retrospectively change previous annotations though (for obvious reasons). To do that I think you’ll have to use Edit > Find > Find by Formatting (ctl-opt-cmd-F) and choose ‘Inline Annotations’ then a colour. It will select the first annotation it finds with that colour, for you to change with the colour picker. Shift-opt-cmd-G takes you to the next one.
The only thing I think you can do about the rounded border is to select an additional space around the text.
At Scrivener Preferences (Mac) > Formatting > With “Do not color the text of inline annotations (faster)” ticked and a space before and after the text:
I have a habit of leading and following a comment with a space to keep the bubble from crowding the text.
Thank you, that works perfectly on the color front.
That does help make it easier to see things. Though in a way it bothers me not having the text colored, but that’s not so bad.
The adding a space before and after each annotation doesn’t work well for me. I use them as comments, but also for text I might change/reword/etc. Many of the annotations I make are added after I typed everything (when I’m reading back through later I highlight something and turn it into an annotation) and many more annotations will be turned back to normal text later. Having to add then later remove spaces is cumbersome/annoying.
That is true, when using annotations as a “soft delete” you do need to be more strict about the spacing. I use them for that purpose as well—and what I find there is that there is usually one space that needs to be part of the deletion (so a sentence doesn’t have two spaces in the middle of it for example) and often the end is around a punctuation mark, where crowding isn’t a problem.
It is unfortunate, but kind of unavoidable given how it is a kind of formatting rather than an actual object inserted into the text. Having padding (that isn’t actual formatting like some kind of tracking kludge that would end up in the printed output) around the bubble would be as impossible as adding padding around a range of bold text.
I should note that at the moment if you decide to go with that highlight option vs text colour that recolouring is flipped around because it is a highlight. The Shift-Cmd-C shortcut no longer works, and you need to use the Format/Highlight/Show Colors… menu (or right-click on the highlight tool in the Format Bar) to change colours. We’ll be fixing that inconsistency in 3.0—but for now it’s a downside to the form factor if you use a lot of colours.
The padding depends on the rending engine. In html, inline elements can’t have padding (even if you set it, you won’t see it), but block and inline-block elements can and often do have padding. I would often get a certain client complaining that it looks like the word at the end of some italics would “need a space” after it because the slant of their font made it look like there wasn’t a space character there, when there was. So I set all 's to be inline-block and have right side padding because I got tired of listening to them complain (“you removed the space, you did it wrong, don’t change the copy” and etc. like I broke it or did something wrong when the problem was the font they provided).
(and for any other web-dorks out there, it was not because it was the name of books, places, etc. - not something to put emphasis on, just something to be set in italics)
Though if padding is impossible, what about just removing the rounded corners? Or making them like 1-2px instead of being so big. That would help as well.
Of course, and in LaTeX you can make a command that inserts \hspace{x} buffers around a block of text—but in the context of an RTF engine it doesn’t have concept of internal padding around ranges of text, like these box-model based layout engines would do. Like I say, the best you could probably do is some tracking thing—but then you have weird tracking in your text, that would be worse than superfluous spaces.
By the way, you mentioned using Markdown to write in another post. One nice thing about that format is that you don’t have to worry so much about superfluous spaces in your text—like HTML they will be collapsed, and so you can be a bit more sloppy with annotation edges (I am!) in many cases.
You can see what that looks like with the Format/Formatting/Preserve Formatting command. The line still comes up right along the edge of the letter though, so with some fonts like the sans font you are using, it may still be cramped.
But, if you do like that better you’ll have that alternative in v3. Styles will have an option to apply a block highlight with a dashed border, just like that (though you can choose the colour), and styles can themselves be set to omit their text when compiling just like annotations. So ultimately, at that point we’re talking full customisation of what “annotations” look like, since you can then make them look like whatever the text engine is capable of doing and storing into a style.
Thanks AmberV, as always you’re spot on and super helpful 