Re: Proposed fix for #8001 RFC

Hi Roland,

> In my opinion, a documents style sheet is sacred and should
> not be implicitly altered like this. If the user wishes to
> copy styles from one document to another I think they should
> have to do this explicitly (using "import styles" for
> example).

Agreed, but only where the styles already exist in the target document.

> The result of this approach would be that if the two
> documents have different "Normal" styles defined then
> copying "Normal" text from one document to the other would
> result in the text adopting the style of the target
> document. That seems like reasonable behaviour to me.

Yes, I think that is the only correct behaviour.

>
> In the case, where a style exists in the source document but
> not the target document we'd have a couple of options:
>
> 1, Paste it with style set to "None".
> 2, Implicitly import that style only.
> 3, Paste it with style set to "Normal" (or "None" if no normal).
> 4, Adopt a nearby style.
>
> Personally, I'd be happy enough with any except no. 2.

Hm, I think no. 2 is the correct solution. Style is part of the
formating, and when I copy something that has a style associated with
it, I expect that style name to be carried over; if the style is not
defined in the target document, we need to import it. If you remove it,
it becomes a nightmare for pasting large blocks of text (and we already
have 'Edit->Paste Unformatted').

> This could more or less be achieved by asking the RTF
> importer to ignore the styles section of the RTF. However, I
> suspect that would be messy.

It should not be that hard; it just requires testing for the presence of
a style when in the clipboard mode inside HandleStyleDefintion().

> I can also envisage some
> serious problems. For example, in RTF documents it's
> possible to specify a character encoding as part of a style
> (via a font definition). If the importer just ignored such
> styles and assumed the document character encoding, the
> pasted text would be corrupted.

It does complicate matters but not that much; we have to convert the
text to ucs4 in any case, so we just need to use the encoding from the
internal stylesheet. Instead of the style table storing just style
names, it would need to store also encoding names: we need a struct
describing a style to store in there.

> It strikes me that this problem would be much easier to fix
> if abi wrote its internal format to the clipboard along
> side the existing formats: RTF, XHTML, HTML, TEXT [1]. Other
> applications receiving data from abi via the clipboard would
> of course ignore this and use RTF or HTML instead. However,
> the most common operations of copying/pasting within abi
> would no longer have to go through a messy external format
> like RTF. This might make #8001 easier to fix and might also
> avoid the likes of #8468 and #8500 in the future.
>
> Furthre, I propose that this extra data on the clipboard not
> be a complete document. It merely need contain the commands
> which define the content selected, the style names and any
> additional formatting; as if we'd saved the files and copied
> and pasted the corresponding sections of the .abw file. This
> would remove any possibility of the global document data
> (style sheet, history etc.) being altered in the target
> document.
>
> Does anyone see a problem with this approach or have a
> better idea? Feedback would be very welcome. :-)

There are some strongly held opinions on whether to place awml on the
clipboard or not. I personnally would prefer it, but the changes to the
abiword importer and exporter required for this are non-trivial, and
there are bound to be scores of bugs from this -- there is no way this
can be made before 2.4.

More significantly, it does not help with fixing this bug. As I
explained above, I think we need to import the style definition if the
target document does not contain the style.

Tomas

                
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Received on Mon May 30 16:00:19 2005