From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Mon Jun 30 2003 - 03:02:39 EDT
--- tomasfrydrych@yahoo.co.uk wrote: >
> Hi guys,
Hi Tomas.
> first of all to respond to Alan: I am not suggesting
> 'demoting' the rtf format, and I do understand why
> it was chosen for the clipboard. The problem is with
> the way MS handles bidi-rectional text, and how it
> is stored in the RTF format. In order to be able to
> reproduce the same layout of text in an RTF document
> as the user gets in Word, we have to insert explicit
> direction overrides over certain characters
I still don't understand why we "have to insert
explicit characters". I understand that Word does
things differently and that we *have to* work with it.
But I don't understand why inserting these characters
"has to" be the solution. It seems to have a larger
and larger flow-on effect for us yet for MS Word it
can save and load RTF files just fine without the use
of these characters. Why can't we solve the problem
more in the way that MS does?
Or are you saying that MS Word RTF files are special
in this regard or that MS Word .doc files work fine
but their RTF doesn't even work for themselves?
I'd really appreciate a technical explanation on why
ours is the only or the best solution and why we have
to go to these lengths when it appears MS does not.
Sorry if I sound naive but that's why I'd like to
understand better.
Andrew Dunbar.
> (common stuff, like punctuation), and there is a
> corresponding problem in the reversed direction. The
> consequence is that if you create an AW bidi
> document save it into RTF and reload it, you have a
> slightly different document, with explicit direction
> overrides at places, which you did not key in. These
> can be a nuisance, but that is the price we pay for
> getting Word rtf docs layout in an idenctical way as
> in Word and it cannot be helped. Unfortunately, you
> get the same problem doing copy/paste _within_ AW,
> which is unacceptable. Now, if we had AW formatted
> text on the clipboard alongside rtf, we would not
> need to rely on the RTF for internal copy/paste.
>
> Martin wrote:
> > I should have pointed this out earlier.
> > You can extend RTF to make lossless cut and paste
> > by making {\*\abikeyword ....} extensions.
> I thought about this for a while, but then having AW
> clipboard seemed as a much cleaner solution that
> would resolve any similar issues in the future. But
> I will have another look at this, as it would also
> make it possible to avoid the same problem if
someone
> insists in using rtf with AW.
>
> > It is certainly easier
> > than debugging native abw cut and paste on all the
> > various platforms we support plus the inevitable
> > bugs that will show up in xp cut and paste. It has
> > the added advantage of forcing us to make perfect
> > RTF export/import filters.
> As far as debugging, this is purely XP issue, it is
> simply a matter of making the XML and AW importers
> capable of reading from clipboard instead of a file
> and working in editing rather than loading mode. It
> is is mostly a matter of calling insert methods
> instead of append methods.
> There was a clear intention to have a framework for
> this is in the base importer class, but
> unfortunately the copy/paste in RTF importer
> makes no use of this xp code, which means the
> framework was never developed and debugged to a
> usable level.
>
> Tomas
=====
http://linguaphile.sourceforge.net/cgi-bin/translator.pl http://www.abisource.com
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
This archive was generated by hypermail 2.1.4 : Mon Jun 30 2003 - 03:14:32 EDT