Re: About testing
On Mon, 09 Jul 2001 12:47:02 Arved Sandstrom wrote: Not only all of the above, but we need to ensure that areas actually have all the properties they are supposed to have. OK, there is still the question, do you really want to add a property to foproperties.xml just so you can print it out, even if it's essentially unused, and I don't have a good answer to that one, because it could result in confusion. But I am thinking more of things like area-class, generated-by, returned-by, is-reference-area, is-last, is-first...all things on which we are really spotty. Of course I just added all the properties (String only) to the foproperties.xml a moment before. I figured its such a pain to read them all it would be better to have them all in there. If need be we could comment them out or change the type to NotImplemented or something. I am probably going to be adding is-first and is-last because I need it in some spots anyway, for fixing a situation that causes errors with break-before=page and break-after=page. Just as a heads up, I am going to be writing some test validation scripts for pagination test cases. My thought is to use a single XML in conjunction with XSLT to run all of the actual test cases (I prefer to leave the current pagination examples as examples, and not use them in tests), and then to write some simple, efficient Perl and/or Python to process the area tree. Any guidance on how you would like to see stuff organized is welcome. It sounds like you are talking about some post-processing of the area tree output with a particular focus on pages (numbering, layout ...). My immediate thought is that we could take full advantage of the xml structure. For example, using xpath to make selections on the xml and verify parts of the data. In this way we could have markers in the xml which help with the selection. It would be good if the testsuite.dtd could be followed if it is appropriate in this case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: About testing
Keiron Liddle wrote: On Fri, 06 Jul 2001 23:33:21 Karen Lease wrote: Hi Keiron, Problem: For some reason, certainly relating to ClassLoader behavior, if I run build.sh test in my xml-fop directory, the version checking code in RunTest is finding the ./conf/config.xml file locally before it finds the one in the test/reference/jar. The result is that it refuses the version since it's FOP @version@ and not FOP 0.19.0-CVS or whatever. I find if I hide the conf/config.xml file, it uses the one in the jar and everything works fine. I did have this problem when an empty CLASSPATH value was added to the classpath. Do you by any chance have any of the following in your CLASSPATH - . - - xml-fop dir [Karen] You were right about the classpath. After testing a few things, I noticed that my classpath in build.sh ended in :, which was acting like .. Getting rid of that fixed the problem. Maybe we should not add the CLASSPATH variable to the classpath in build.sh, as far as I know it has no problems with only the CP set in build.sh. (and the same for build.bat) [Karen] Agreed, since the LOCALCLASSPATH has all we need for FOP. Question: I see that the XML rendering doesn't have lots of traits, no Area Container positioning for example, no line-height information etc. Is it a reasonable thing to enhance the output format to include (eventually) all the traits which are supposed to be on areas? Yes, this output should definitely contain all the information for the area tree. So that in theory you could read in the area tree xml and render the information (probably not very useful in practice). This includes all things such as: - areas generated - viewports (clipping, alignment etc.) - attributes (position, colour, fonts etc.) - pages [Karen] OK, that's what I figured. That way, if I change table borders, we can actually see the difference. I think that at this stage it may be more useful to get a cleaner interface to the area tree. Then from that it will be easier to read all the area tree information. You're right. I'm just trying to fix the table row borders right now (in border-collapse mode), because it's a pain not to have it and I'm in the table code anyway. At least some of what I'm doing will be useable in the new layout architecture. But I do intend to get back to the layout stuff after that. Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: About testing
At 11:33 PM 7/6/01 +0200, Karen Lease wrote: Question: I see that the XML rendering doesn't have lots of traits, no Area Container positioning for example, no line-height information etc. Is it a reasonable thing to enhance the output format to include (eventually) all the traits which are supposed to be on areas? I would support having everything. After all, I don't think it is really meant to be read by humans - the XML output should be post-processed. AntennaHouse XSLFormatter prints out practically everything. I think we could have several levels of detail (which I think I might have put in there already to some degree); someone may not be interested in levels below regions, someone else might want down to blocks, someone else may want everything right down to inlines in agonizing detail. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
