On Tue, 2008-07-08 at 20:43 +0100, Dr J A Gow wrote: > On Sun, 2008-07-06 at 00:28 +0300, merKur wrote: [snip] > > There are some more on the way... ;) > > > Super! Send 'em in when they are ready, and I'll have a look.
Will do... Though, I think I'm hitting some OpenSync 0.22 bugs now... I'll probably get back to it next week. > It's base64 encoded compressed RTF. The base64 codec used is just the > standard python one. I wrote a library, 'librtfcomp' to handle > compressed RTF in both directions, and there are a set of python > bindings provided with the library. Follow the XSLT extension function > (the one your patch tried to remove :-) ) to learn more about how I > implemented this. I wonder why Opensync/evolution were not accepting those... > > We might be able to tweak the xslt to pick body if there, and fallback > > to Rtf. What do you think ? > > This might be a possibility. Let me see if I can get both WM5 and WM6 at > my end to actually emit a 'Body' field! Once I can do this, we should > have a clearer picture as to how Airsync handles the two fields. Wonderful, > > Otherwise we might need a [yet another] config flag... Yuck. > > The core problem is if data is stored in both <Body/> and <Rtf/> - how > do we combine and separate (if, indeed, we need to). I'm not sure we'll have to combine/separate those. I guess devices will use one or the other. Cheers, merKur ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
