From koffice-devel Sun Jun 14 20:56:48 2009 From: Thomas Zander Date: Sun, 14 Jun 2009 20:56:48 +0000 To: koffice-devel Subject: Re: Review Request: Add "extract" option to already present Message-Id: <200906142256.55365.zander () kde ! org> X-MARC-Message: https://marc.info/?l=koffice-devel&m=124501307225654 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0321830156==" --===============0321830156== Content-Type: multipart/signed; boundary="nextPart1921409.Sm9y5v4S9y"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1921409.Sm9y5v4S9y Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 14. June 2009 21.09.46 Jaroslaw S wrote: > Please let me start by asking: how can we handle the unit tests that > check contents of generated, say, contents.xml? What we should do is have a way for koconverter to work without a GUI. So=20 any filter that has a dialog should be changed to be able to have decent=20 defaults and not show that dialog if we start koconverter with a special=20 flag. But thats a long standing wishlist item already and not really on topic=20 here. What you can do is easy; koconverter is a command that you can call like; koconverter foo.txt bar.odt and after it returns you can unzip the odt and inspect the results. > E.g. we are comparing > the fine with an expected pattern? there are various ways to do the actual automated test for correctness. The strategy you want to take depends a lot on the implementation of the=20 filter. The majority of the filters now generate their own XML. Either in = odt=20 or in kwd format. So I think we should have a simple way to compare xmls=20 and do it more advanced than just comparing it as text. For example by=20 writing a tool that loads two xmls into a QDomDocument and it does some=20 smart comparisons. Another strategy sounds better long term to me but it requires the filter t= o=20 do things differently. The strategy would load the document we want to convert (.doc etc) into the= =20 KoText library and then call save on it afterwards to save it out as odt. On the KoText document we can use the same strategy that we do in the unit= =20 tests in kotext/opendocument/tests. I prefer this solution since its much more robust and maintainable and on=20 top of that avoids the whole exporting to ODF when testing. Or, in other=20 words, it avoids each filter to understand ODF. Less to test. =2D-=20 Thomas Zander --nextPart1921409.Sm9y5v4S9y 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) iEYEABECAAYFAko1ZBMACgkQCojCW6H2z/TtkACeLtxx3xBwJhnm33ijev9mnR21 grUAn1jZQFrIga/R1N60v109TYRpBhi+ =jpA1 -----END PGP SIGNATURE----- --nextPart1921409.Sm9y5v4S9y-- --===============0321830156== 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 --===============0321830156==--