On Wed, Aug 20, 2014 at 8:11 AM, Prannoy Pilligundla <prannoy.b...@gmail.com > wrote:
> ᐧ > On Wed, Aug 20, 2014 at 12:00 AM, Scott Kostyshak <skost...@lyx.org> > 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 [1] See http://en.wikipedia.org/wiki/Test-driven_development. Or pick any of the books by Kent Beck for a good introduction. "Test-Driven Development by Example" is a step by step introduction with lots of examples in Python. If you are willing to learn a bit of Smalltalk (strongly recommended), the free book Pharo by Example" (http://pharobyexample.org/) has a short section on unit testing that you may find useful. -- __________________________________________________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
