stefano franchi wrote:
On Wed, Aug 20, 2014 at 8:11 AM, Prannoy Pilligundla
<[email protected] <mailto:[email protected]>> wrote:
ᐧ
On Wed, Aug 20, 2014 at 12:00 AM, Scott Kostyshak <[email protected]
<mailto:[email protected]>> wrote:
The actual problem is because of the difference in ODT syntax
that tex4ht uses and that the latest versions of Libre Office
or Open Office uses. Suppose we just open the ODT generated by
tex4ht, make a slight change and save it there are large number
of differences in all the xml files before and after saving. So
I guess it becomes difficult for us to take an example file in
these kind of cases and compare them. And as our main aim was
semanticity, even verifying semanticity becomes very difficult
to verify keeping in mind all these constraints.
Did you mean to email this to me and not the list? We try to keep
things on the list as much as possible.
Oh Sorry, just realized that I just mailed you and not the list. I
wanted to reply to all but maybe I clicked on reply by mistake. Again,
I am sorry, will be careful from next time on.
I think we're talking about different kinds of tests. The kind I
have in mind are the following: suppose you make a change to the
ODT export. How can you be sure that that change doesn't break
anything? One way to address this is to have tests. You would not
need to open Libre Office or in fact even have it installed. The
tests would just check that nothing changed in the other exports
(it would do this just like tex2lyx by comparing a saved exported
file to the new exported file and checking that they're identical).
Of course, it might be expected that the tests change. In this
case, you would want to check the new exported files manually and
then save the new files as the files to compare to. Does that make
sense? It shouldn't take much time to implement (although I know
that even a little time can be hard to find and prioritize). You
just run ODT export on a .lyx file, say test1.lyx, then save that
.odt, test1.save.odt. Then suppose you change ODT export. You would
have a script that exports test1.lyx to test1.odt and then compare
test1.odt to test1.save.odt to see if they are identical. If they
are not identical, then manual inspection would be needed to see if
the differences are legitimate. If they are, rename test1.odt to
test1.save.odt (overwriting) and explain the changes in the commit
message.
Does that make sense?
Thanks, now I understood what you meant. Ya, I guess this should not
take much time to implement. I didn't do this sort of testing in LyX to
ODT as I was not touching any of tex4ht's post-processors. I was only
configuring some new styles and fixing issues with some old ones, so we
can say all were kind of independent changes which don't effect each
other(provided mk4ht doesn't raise any error while running). Whenever I
write a wrong XML syntax, the generated ODT doesn't have a content.xml
at all, so I used this as feedback manytimes. But recently, when I
tried converting a real life lyx doc, then the resultant ODT file
turned out to be corrupt. I was not able to find out why the file was
corrupt and I am still wondering on how to fix these kind of issues.
Hi Prannoy,
are you familiar with test-driven development [1]? This is what Scott is
referring to (or almost).
The basic idea is to write the tests first and then code until your code
passes the all the tests (even those you haven't touched in your last
iterations).
We almost did that in the first phase of the project, but in a very
informal manner. I guess Scott is pushing for a more structured and
automated testing procedure (which is indeed what test-driven development
requires to be effective).
I would be very happy to see it happen, at least for the text4ht part. Let
me know if you need any help.
Cheers,
Stefano
The challenge here is that we cannot really verify that the output document
is correct (because that would require a detailed specification). However,
we can inspect the output manually once, and then use it as a reference
against unexpected changes, as suggested earlier.
This may not sound as convincing as actual output verification, but it is
really very helpful in practice, and easy to set up.
--
Regards,
Cyrille Artho - http://artho.com/
The human mind treats a new idea the way the body treats
a strange protein -- it rejects it.
-- P. Medawar
