--===============1880999144==
Content-Type: multipart/signed;
  boundary="nextPart1352464.kQ9go56CJ3";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1352464.kQ9go56CJ3
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 29. September 2008 13:22:58 Inge Wallin wrote:
> This discussion has diverged from the original question about should we
> keep as much of a loaded document as possible to a subthread about
> templates. But I haven't seen any reason so far that we should throw away
> valid ODF data even if we cannot show it correctly on the screen or we can
> show it but not edit it.

The main reason here is one of publishing your work; let me explain with an=
=20
example.

Consider I am a user of KOffice and I have a huge set of documents to base =
my=20
work on. I am free to copy/paste from these documents.
So I work on creating a good looking document for my client and at one poin=
t I=20
decide its done.
I then send this document to my client who uses OOo.

The effect I might encounter is that by me doing copy paste I have inserted=
=20
content of a type that I don't see on screen. Or just as bad KOffice doesn'=
t=20
honor the hiding of paragraphs property so all parags will be visible alway=
s.
In any case, the document that I created may not look the way I want to in=
=20
OOo. And thats bad ;)

So, apart from the normal usecase of working together with people there is =
a=20
clear second usecase of publishing.
The act of me sending the doc to the client is one of publishing in the sen=
se=20
that I consider the document final.
At such a time I should be able to remove any ODf data that I don't see.

This is very similar to the MSOffice concept of removing hidden data using =
a=20
special tool. Making it smaller and removing old revisions.

Next to that I would like to see a way to introspect the document and offer=
=20
suggestions to the user to improve the quality. We can check that all color=
s=20
have a strong enough contrast to their backgrounds, or check that the color=
s=20
we are showing on the beamer or paper are actually going to be visible and=
=20
not have too high a saturation.

Bottom line is that, yes, this worry is a valid concern. I don't want to go=
 as=20
far as Johannes proposed to add a dialog every time you save, I would rathe=
r=20
have a separate user action to strip the data as that fits better with the=
=20
expected workflows.
=2D-=20
Thomas Zander

--nextPart1352464.kQ9go56CJ3
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkjg8W4ACgkQCojCW6H2z/TWFACgmaFVKiZNSHlct2oEy2Zm6W0r
Qe0An2HKdHT+a56bmDDdt955Cg/JeAju
=ElXp
-----END PGP SIGNATURE-----

--nextPart1352464.kQ9go56CJ3--

--===============1880999144==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

--===============1880999144==--