Element change of multiple non-contiguous selection

In Screenplay mode import an rtf file formatted as a screenplay. The format will look right, but in fact everything gets imported as General Text. (This isn’t the bug I’m reporting here – separation into individual elements on import would however be a very desirable feature).

Use the Command Key to create a multiple non-contiguous selection of several separate paragraphs. Activate Text/Font/Underline and notice that the selected text is all now underlined. This is the correct and expected behaviour.

In the same way discontiguously select a number of Character dialogue headers from your imported text. Now use the element selector (bottom right, in the status bar) to change the selection to Character. Only the first section of the multiple non-contiguous selection is converted to a Character element. Insofar as the expected behaviour would be as for the underline experiment above, I would class this as a bug.


Chris

I’ll add it to the list, though it’s a trivial one so will be low priority. I’m not even sure I would class this as a bug, as there quite a few things in the Apple text system that only operate on the first selected range. But the behaviour you expect would be desirable and it shouldn’t be too hard to change, so like I say, I have added it to the list.

Element recognition depends on the format of the imported elements being identical to that which Scrivener expects. In 1.04 you will be able to modify the format of the elements, so it should be possible to get Scrivener’s elements to match those of the program from which you are importing, which would mean that they would be recognised.

All the best,
Keith

Keith, that must be a world record for response to a bug report. I’ve had longer latency from automated response systems. :slight_smile:

Point taken, but I wouldn’t promote the Apple Cocoa team to ultimate arbiters of what does or doesn’t constitute a bug. The class “bug” is a superset that includes the class “quirk”. :slight_smile:

Excellent news. But I can see that this might still involve quite a lot of twiddling on the part of the user. Would it be poss to loosen up on the element specs for incoming text, so that, say, a par with a margin in excess of x but less than y is read as Dialogue, and a par with a margin that is in excess of z and is also in CAPs gets read as a Char element?


Chris

It would only require twiddling on the part of one user - the first to do it. As long as that user were to share the formatting template, other users could use it. So it would just be a matter of knowing that you’re importing from, say, Final Draft, and then either starting a new project based on a Final Draft Screenplay project template, or in a blank project going to the Scipt Settings… panel and loading a Final Draft Screenplay xml template. You would then import your script as RTF and have it recognised. Hopefully. But like I say, theoretical at the moment, as I am so far only partway through this, and the new Leopard seed has really ****ed up my development at the moment. :frowning:

Best,
Keith

Ah, OK. We must wait and see how that goes.

Bad as that, eh?

I’m guessing that four-star word begins with f. Probably “fouled”. :slight_smile:


Chris