Hi, I had some troubles because entities were used before being declared. Furthermore one entity was labeled fo:forgotItsName which is not legal. I changed your dtd accordingly.
Still the following remains: nearly all width properties are reported being wrong: The legal values are too little and different stuff is missing "em", ... This is of course a problem with dtd technology. I will try your schema tomorrow. Are you sure that the following validation errors should occur? Error: Attribute "border-color" must be declared for element type "fo:block". Error: Attribute "border-style" must be declared for element type "fo:block". My experience says that these things work fine with 0.20.2 and 0.20.3: Error: Attribute "border-width" must be declared for element type "fo:block". Error: Attribute "space-after" must be declared for element type "fo:block". Error: Attribute "font-weight" must be declared for element type "fo:table-row". Error: Attribute "space-before" must be declared for element type "fo:block". For which version of fop should the dtd be correct? Regards Markus Fries -----Ursprüngliche Nachricht----- Von: Chuck Paussa [mailto:[EMAIL PROTECTED] Gesendet: Montag, 25. März 2002 18:33 An: [EMAIL PROTECTED] Betreff: Re: AW: feature and limitation lists Here's a DTD segregated by FOP imlemented and non-implemented features. The implemented and non-implemented values have not been segregated. Chuck Paussa Fries, Markus, fiscus GmbH, Bonn wrote: >>>On 2002.03.21 09:47 "Fries, Markus, fiscus GmbH, Bonn" wrote: >>>Hi, >>> >>>a lot of questions on this list are caused by properties which are not >>>implemented. Often there are workarounds though. I think it would make >>>sense to put some real effort into >>>http://xml.apache.org/fop/limitations.html and >>>http://xml.apache.org/fop/implemented.html. Or maybe there is such a >>>collection already of which I don't know? >>> >>>Regards, >>> >>>Markus Fries >>> >>Hi, >> >>If you have any suggestions about how to do this easily then share your >>ideas with us. >> >>Do you have some volunteers in mind to put the real effort into getting >>this done? >> > >Hi, > >I can think of one volunteer so far :). I have to do some documentation on >that stuff for my project anyway and if my supervisor does not mind I can >share that. > > > >Jens: > >>I've suggested (or asked) to create a special fop.dtd (not a fo.dtd). >>This wouldn't regard all limitation and no workarounds, but it would be a >> >very good tool for imlementing applications using FOP. > >>... >>A fop.dtd will answer all these question like: Feature XYZ is not working, >> >is it a bug in my FO > >>document or a missing FOP feature. Maybe workarounds can be mentioned in >> >the fop.dtd, too. > >>Since fo.dtd exists, it wouldn't be too much work to add these comments. >> > >Yes, I think this would be very helpful. But it has one drawback though. >You realize only after >implementing that s.th. doesn't work and expensive rework is necessary. >Anyway the fop.dtd sounds >like a very good start. When it gets running we can think of rearranging >the collected information >in addiditional documentation. > >What do you think? > >Best regards > >Markus Fries >