Feature : medium : Copy paste discrepancy

When copying and pasting text which has annotations or footnotes into a rich text enable application, the result is quite nice. You get your highlights and everything. Footnotes are even parsed out into a text only version of them. However, when you paste the same content into a text only application, some things are missing that could still be there. Of course the colours and background styles will be missing, but the [Brackets around annotations] could still be included, as well as the footnotes. Instead, both are placed straight into the main text area, with no delineation.

Incidentally, it looks like the code to do this is already built. If you do a plain text export of the same document, it comes out looking the way it should with footnotes and brackets around notes.

Fixed for beta 2.


There are also some minor export bracketing issues which arise under certain conditions of placement between annotations and/or footnotes. If you are not aware of them, I can go through them in another thread.

Hmm, I’m not aware of those, no. Unless it is just that sometimes the whitespace doesn’t get trimmed. Can’t remember whether I fixed that for everything or just for RTF export. I’ll check.

Well, I played around for a while, and there is actually only one that I could reproduce. It happens only when you have a sloppy footnote that includes a newline in it, and immediately after it, an annotation. If you go the other way around, it simply just looks like a sloppy annotation. With the footnote, you get an exported result like this:

[size=75][2][color=red]This is a comment, inserted after a footnote with a newline.][/size]

And at the bottom of the page:

[size=75][2] This is a sloppy footnote.
[3] …and the following reference number will be coloured red, too.[/size]

If there is an intermediate newline in between the two, then everything is okay, though the intermediate newline gets chopped. I’m guessing you are doing this to make the reference list at the bottom of the page format nicely? But that is probably what is causing the problem here.

There is something else unrelated: It is currently impossible to make adjacent annotations without putting some separator between them. This could result in some odd exports with five spaces between the last word of a sentence and the period, for example. Perhaps you could create a little shortcut like Option-spacebar which inserts a Unicode null or something? That might get messy though, unless Scrivener displayed this special space character somehow.

That is a limitation of the annotation system and there’s not a great deal I can do about it, unfortunately. The exporter does chop whitespace around annotations, though, although you might still get some odd results.

I’ll take a look at the brackets thing. I’ve still got to do some reworking of the export anyway.

Well, it is really only a problem if somebody is sloppy with their footnotes. Generally, they would not end with a newline anyway, as most people expect a reference pointer to be placed within punctuation marks.

As for the spaces in between thing. I am still seeing spaces using a variety of different export methods, with or without annotations included in the export. Without, I get:

number of text documents   .

But this method, if it worked, would be ideal. Then one needn’t worry about whatever padding they wish to place around the annotation. I have been worrying about it, and this reduces efficiency. I’d rather just be able to plunk down thoughts with no regard for whether or not odd spaces will get inserted all over the manuscript.

Ah, I think this needs clarification: the whitespace gets trimmed from around the footnote or annotation provided the whitespace is defined as [i]part[i] of the annotation or footnote. So just get used to putting the padding inside it and everything should work fine. Hope that’s not too ugly for you - but it’s a lot easier to trim all the whitespace from around a given chunk of text (ie. a footnote and an annotation) than it is within a chunk of text (ie. where the annotation or footnote was).

No, that makes sense, I understand how it would be difficult for Scrivener to decide whether or not a space outside of the annotation region is valid or not.

Though, I am running into a problem. How do I deal with multiple annotations in one spot, without getting a lot of white space? Would it be too difficult, and could it be safely assumed that any whitespace between annotation blocks is merely decorative?

Back to the original problem that started this thread, I noticed something else today that I had not seen before. In some applications, pasting just drops footnotes and annotations completely. It seems to be any application that uses Apple’s rich text widget works fine, and everything else is nearly always going to malfunction. The ones I tested were Mellel, Tinderbox, and Ulysses. Non-Apple applications it does work in: Firefox (text entry fields), and Mulberry (the email program).

The whitespace thing is on the list. As for the most recent problem, this is actually a limitation of the programs you mention rather than of Scrivener. I just tested this out in Mellel. It turns out that Mellel reads RTF by default rather than RTFD when receiving a paste. However, it seems that whilst Mellel has enhanced RTF methods that accept footnotes when importing RTF documents, it uses Apple’s default RTF methods when receiving a paste - and thus the footnotes are lost. I tested this out by copying some text from Word that had footnotes into Mellel - and indeed, they were lost.

Programs that receive RTFD instead of RTF will get the annotations and footnotes inline. Once option would be to change it so that the annotations and footnotes get copied inline on paste even in RTF, but then again most users will probably use Word, and copying footnotes into Word works fine which means that pasting inline would just confused Word users…

You know, I’m not sure it really is safe to assume that whitespace between annotations should be removed. I can think of situations where you might, for instance, have an annotation at the end of some text, then a newline or two, then another annotation. Or an annotation at the end of one sentence, a space, and then an annotation at the beginning of another sentence. In these circumstances, removing whitespace between the annotations would not be desirable.

I think part of the problem is that I never really envisioned users wanting to add multiple annotations one after the other without a break; I think it is to do with your unique way of doing things. :slight_smile: I always figured that anything that needs to go after one chunk of text would all be contained in one annotation.

Anyway, I don’t think I can really remove whitespace between annotations on copy or export without causing problems and complications. :slight_smile:

So, I have been thinking about this quite a lot. I’ve had a number of ideas, but I imagine most of them are too difficult to implement for whatever reason. Here are the two ideas that ended up at the top of the pile:

Method 1: If the user invokes the annotation command while the cursor is directly before or after another annotation, a small, transparent image the size of a ‘•’ or something is inserted in between them. The presence of this bullet would be unmistakably a spacer, and would not suffer the complications involved in using a symbol which is otherwise rife with usage, the white-space. So, the only way it would show up is if one declared two annotations right next to each other. If the second annotation is ever deleted, the small invisible bullet would act just like a space to the user. It could be easily stripped out on export functions where annotations have been disabled, as it has a unique signature. There are a few tricky scenarios. Since it only gets created during this very specific action, there are certainly other situations where it might be needed but is not created, such as when a user manually brings two extant annotations together. Another problem is, what if the user deletes the “space” and is suddenly surprised when the two are joined – though granted, that is only a first-time surprise. One possibility is that, like soft carriage returns, there be some sort of modifier+spacebar action that adds this bullet manually.

Method 2: The second idea is a great deal more “simple,” in that it does not involved inline images, but sacrifices a bit on unique signature – plus, it is a bit more “ugly.” In this case, a forward slash character ‘/’ is automatically inserted between annotations. Of course, this also has the advantage of being really easy for the user to type in manually if they need one. Export could then strip out any forward slash directly annexed to an annotation. Originally, I thought an underscore character would do, but then quickly realised that would conflict with Markdown. Optionally, just the ‘•’ character itself could be used, but it feels a little heavy, and not everyone might know how to type it in.

For now, as a work-around, I have set up Textpander to insert a white ‘•’ when I type // (thanks to jebni for the trick – can you tell we aren’t C coders, ha.). This way, I will have a presentable Scrivener document (you[ annotation #1] should[ annotation #2] have[ seen #3] the[ annotation #4] ugly[ annotation #5] work-arounds I had been trying!), and an exported document that will not require hours of carefully removing errant white-spaces. I can just search and remove all bullets (I don’t use them for lists anyway) at once.

The only scenario this does not fix is groups of stand-alone annotations. Typically I have a cluster of comments at the beginning of a chapter or section, one per paragraph. Right now this means several inches of blank space in an export. I suppose I will just have to get used to having them all in one line, for now.

Just let me know if this is too “wish listy.” To me, it is a bug, but I understand I might be fairly unusual in what I am trying to accomplish.

I think the problem is in how you are using annotations; it is not really how I intended it. :slight_smile: Could I ask why, instead of separating your annotations using whitespace, you can’t just give the annotations different colours? This will separate visually and also prevent any export problems.

The implementation in beta 1 isn’t ideal for this, I admit, as you can only change annotation colours when outside of an annotation - otherwise the colour change affects the whole annotation. So I have changed this behaviour. You can now change the colour using the colour panel while the cursor is at the end of one annotation, which will then start a new annotation when you start typing of the same colour. Likewise, if you select a range of an annotation and change the colour, the selected range will create a new, discrete annotation rather than changinge the colour of the whole annotation in beta 2 (if you change the colour while there is no selection, it will still affect the whole annotation).

The idea was always that you would use different colours to separate annotations rather than using whitespace between them, as anything outside of an annotation is to be considered part of your document. Hopefully these minor changes should make using different colours to differentiate annotations a little easier.

You pretty much summed up why I discarded the idea of using colour. It takes a lot of jumping around to get it done successfully, in the current version. Considering how you describe the colour handling in B2, I might just be happy with that, although it might mean a wild rainbow at the end of some sections. :slight_smile: My fixation with white-space is wholly because that is the most rapid way to separate annotations right now.

Well, you don’t have to create a rainbow, as the colours only have to differ minimally. :slight_smile: In the next version you could just leave the colours palette open whilst editing annotations and click on a different colour or adjust the slider slightly to start a new annotation. Yes, I know that involves clicking, but hey. :slight_smile:

Ha, yes. I intend to just move the saturation down 1% each time. Which reminds me, some applications move the keyboard focus into the colour palette right after invoking it. Would it be to difficult to do this with Scrivener?