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
>


Reply via email to