allow scripts to copy rtf data

Dear Devon-friends,

I’m trying to write a script that will “zap” an rtf file between my two computers. I am finding as I do so that there seems to be no way to move an styled text data via applescript and recreate it on the other machine. The text becomes plain text when I do so. Leaving out the remote machine issue, you can see this as follows. Place the selection in three pane view on an rich text document with some formatting (bold, italic, etc) and then run this script:


tell application "DEVONthink Pro"
	set the_sel to selection
	set the_item to first item in the_sel
	set the_parent to first parent of the_item
	set rich_text to rich text of the_item
	
	set the_rec to create record with {name:"test", type:rtf, rich text:rich_text} in the_parent
end tell

It will strip any formatting from the document :frowning:

I thought maybe this could be worked around by copying the raw data, i.e. something like this:



tell application "DEVONthink Pro"
	set the_sel to selection
	set the_item to first item in the_sel
	set the_parent to first parent of the_item
	set the_data to data of the_item
	set the_rec to create record with {name:"test", type:rtf, rich text:""} in the_parent
	set rich_text to rich text of the_item
	set data of the_rec to the_data
end tell


Seems to me like the first one is a bug, and I can report it one the ticket system if that would be useful. Seems to me the second one should work for rtfs just as it does for webarchives, and that too is a bug, though I could imagine viewing that as an unimplemented feature.

For reasons that have been expressed in another thread, it would be nice if one of these methods worked. If the first method worked, and an AS variable could hold the RTF data, then it could be exported to the a file and manipulated elsewhere (through python for example). But if that doesn’t work, it would be soooo nice to still be able to so.

I’m hoping that these are not bugs, but just me not understanding something about applescript’s variable handling. If there is another way to inject the raw data property from one record to another, I’d be grateful to know it. If not, is it possible to implement it (sometime) (soonish)?

cheers,

Erico

I cc-ed this to Wooden Brain, as I thought he might know the answer to this…

Unfortunately I don’t currently have the time to look at this closely, but I can say that DevonSync (which maybe you should try as it seems to correspond to what you’re doing?) uses the file system and export/import instead of trying to, as it were, copy & paste record properties across systems. In fact, one of the reasons it takes this approach is there are other quirks of a similar nature that make doing this a bit unpredictable.

As you probably know, when you export a record, DT also saves some metadata to a file, which is imported nicely whether you import manually or via an AppleScript. Again not sure exactly what is contained in that without looking again, but my guess is there are other elements that would be lost too that aren’t record properties revealed in the AS dictionary.

I plan to do a bit of an all-around compatibility upgrade to DevonSync for Snow Leopard and DEVONThink Pro 2.x some time in October, but I have tested the current version on Snow Leopard with DTP 2.0b6 at a basic level and it still works.

Thanks wooden brain,

I see, I hadn’t realized Devonsync was taking everything through the file system. I would probably use devonsync for this particular task, but for the fact that I literally just want to send one file at a time. I’m also not very worried about the additional metadata on the RTF files I’m using, as I am editing them in DTPRO for convenience until I get to the point where I really need stylesheets and word.

So I’m hoping that maybe there is still a way to make either method one or two work. Method one would be nice because it would also allow for a more robust merge document command to be written through applescript. Method two would be nice because it would allow for the “quick zap” of documents through AE remote events.

Hopefully, Christian will enlighten us…

cheers,

Erico

erico
As an aside about method 2: Apple seems to have improved snow leopard’s applescript both in terms of speed and robustness, that I have hope that sending, say, 300Kb or even 1.5 MB through AppleEvents might actually not break pipes this time. It’ll be interesting to see…

-erico

Rich text scripting (no matter if DEVONthink Pro, TextEdit or any other application) is still limited to visible views/windows and the visible rich text can be only transferred within the same application (e.g. from document 1 to document 2 of TextEdit). Therefore the only workaround is to export the record, transfer the file and import it on the other machine.

It’s currently only supported for PDF documents, images and web archives. The next beta will support rich text too.

Thanks Christian!

It’ll be awesome to have RTF work through the data method. I very much look forward to it, and will post my “zap across” script here once that is implemented.

The RTF /rich texts issues have undoubtedly improved a great deal in the last while, and I assume that the difficulties are literally issues of frameworks in apple’s API and how internal data is stored. I do look forward to the day when the text suite can be called simply on variables, rather than requiring a window, but it sounds like that is either impossible, or at least largely in Apple’s hands.[footnote1]

I might mention that one work around that would be useful for scripting is to add a devonthink option that would allow a window to be opened as invisible. (i.e. open window for record x with {invisiblity:true}). This would allow a script to get to that rich text goodness without having the window “flash” up on the screen, or allow a stray click to mess up a text change in progress. Someday, maybe.

But for now all I should say is, thanks again, Christian. DT scripting is so powerful I forget sometimes all that it can do. (I had forgotten for example, that one has been able for a while to copy the raw data of a pdf from one machine to another, or to download it from source and insert it into a pdf.[footnote2] This is really nice–i’ve been using it for the last year and had forgotten that my “fetch pdf” script uses it all the time. The more file types that scripting can recreate through the raw data field, the better, because it allows real flexibility. Every one of these little feature tweaks is greatly appreciated.

best,

Eric O

[1]I’m only a rank novice cocoa programmer, and way over my head, but I assume the impossibility of geting the rich text data into a variable is related to the kind of issue described here–that apple is inconsisent in how it represents rich text: (http://www.google.com/url?q=http://www.omnigroup.com/mailman/archive/macosx-dev/2007-February/059969.html&sa=U&ei=A260SrrpOoPqtAO6uaTYCw&ct=res&cd=5&usg=AFQjCNHWpg5cF77jVMnYwjuKS0qTEgcB8Q. I ask because I could imagine, if I knew the right way to express it, trying to mount a campaign with apple to get them to fix the API so that an applescript command could get the rich text of a record, put it in a variable, and manipulate it without having to have the window be open to do so.

[2]In case anyone else is reading this and is wondering how to duplicate a PDF using the data method, I had forgotten this works too. If you try to create an empty record or supply the data property to a “PDF” record devonthink’s “create record” command will return “missing value”: (e.g. create record with {name:“test”, type:PDF,data:the_data} will not work). However, if you create an empty “picture” and then stick in the data, it will work, and i will figure out that it is a pdf. See code below…

I thought I would document this for future scripters (or for myself if that’s the case) :slight_smile:.



tell application "DEVONthink Pro"
	set the_sel to selection
	set the_item to first item in the_sel
	set the_parent to first parent of the_item
	set the_data to data of the_item
	set the_rec to create record with {name:"test", type:picture} in the_parent
	set data of the_rec to the_data
end tell



I don’t think so but I’ll check this.