feature and limitation lists
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
AW: feature and limitation lists
>>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
AW: feature and limitation lists
Title: RE: feature and limitation lists -Ursprüngliche Nachricht-Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Gesendet: Donnerstag, 21. März 2002 14:44An: [EMAIL PROTECTED]Betreff: RE: feature and limitation lists Hello, > 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. If you have a nice editor, you can use the DTD resp. XSchema while editing. Benoit suggested to use an XSchema instead of a DTD for enabling nice reports. So I change my suggestion: fop.xsd instead of fop.dtd (and fo.xsd instead of fo.dtd) ;-) Regards, Jens [Fries, Markus, fiscus GmbH, Bonn] Well, probably my Emacs can do that too. But I usually write rarely complete XSL-FO prototypes before doing the real XSL scripts. And when doing s.th. like implementing keeps in the very end, I have to touch a lot of stuff again. On the other hand, I had read the feature and limitation list first, and did not find any restrictions on that. Regards, Markus
AW: AW: feature and limitation lists
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 >
AW: feature and limitation lists
Hi, I think these should be added as well for fop-0.20.3-2002-03-04: not implemented yet: fo:block visibility="hidden" page-position="last" But what about "wrong" implementations? Example: markers, or wrap-option="wrap" This works fine, if spaces are existing. But it should wrap long lines with no spaces at the boundaries as well. It would make sense to add javadoc like comments to the dtd's or xsd's. You did not publish your "small xslt" yet? Regards Markus Fries -Ursprüngliche Nachricht- Von: MAISONNY Benoit [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 9. April 2002 11:33 An: '[EMAIL PROTECTED]' Betreff: RE: feature and limitation lists Here are some early results. All elements are listed, but only unimplemented attributes & child elements are shown within the elements. Attributes values are not checked yet; additional comments regarding partial implementation are not there yet neither. Obviously it needs some clean-up, but I will probably not continue until 1-2 weeks from now (holidays :-). As Chuck wrote, it is not 100% correct. I noticed white-space- and linefeed-treatment are claimed implemented, though I thought they were not yet. Also, I think that fo:float is not implemented neither. But I didn't check, maybe it is in 0.20.3. This is just a "proof of concept", so I don't care too much about accuracy just yet. I did it using Chuck's DTD, not schema: I wrote a small XSLT that walks through FO.dtd (converted to xsd) and checks if corresponding element/attribute exists in FOP.dtd (xsd). (Actually, this generates an XML file looking like a XSchema, which is then converted to HTML.) Chuck: a question about your xsd file: you grouped the attribute types into xs:simpleType elements. But are we sure that a given attribute is always implemented the same way in all elements that has it? Comments welcome. Benoit P.S. For the record, I am not doing this on behalf of Eurocontrol, despite me using that email address. > -Original Message- > From: MAISONNY Benoit [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 02, 2002 12:05 PM > To: '[EMAIL PROTECTED]' > Subject: RE: feature and limitation lists > > > Thanks for your 2 emails (that I couldn't read until today, sorry). > > As I wrote earlier, I will investigate how to automatically generate > "unimplemented features" documentation. > > Benoit > > > > -Original Message- > > From: Chuck Paussa [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 25, 2002 6:42 PM > > To: [EMAIL PROTECTED] > > Subject: Re: feature and limitation lists > > > > > > Here's an FOP specific xsd. I sent the segregated DTD in a > previous > > response on this same thread. It's a pain to make a usable > XSD from a > > DTD because the conversion tools tend to explode everything > > out and you > > get enormous repeating elements. Anyway. Here it is for what > > it's worth. > > > > Chuck Paussa > > > > MAISONNY Benoit wrote: > > > > >Say we have an FO schema (possibly converted from that > > fo.dtd) and from that > > >we remove what FOP doesn't do yet. Then we can easily > > compare both schemas > > >with XSLT and generate a nice report. (I would volunteer to > > try and write > > >that XSLT/report if people think it can be useful). > > > > > >Then we can add comments or annotations to tell about > > workarounds and about > > >what is implemented BUT still is not working as expected. > > > > > >However, I suppose it would be a lot of work to remove > > unimplemented things > > >from fo.dtd or fo.xsd. What do you think? > > > > > >Benoit > > > > > > > > >-Original Message- > > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > >Sent: Thursday, March 21, 2002 1:33 PM > > >To: [EMAIL PROTECTED] > > >Subject: RE: feature and limitation lists > > > > > > > > >Hello, > > >Markus wrote: > > > > > >>If you have any suggestions about how to do this easily then > > >>share your ideas with us. > > >> > > >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. > > >E.g.: > > >fo.dtd" (I know that there's no official fo.dtd, I took the > > one created by > > >Nikolai Grigoriev <[EMAIL PROTECTED]>): > > >-8X8X--- > > > > > clip CDATA #IMPLIED > > > [..] > > >"> > > >[ ... block-properties is an entity based (indirectly) on > > area-properties > > >... ] > > > > %basic-inlines; | > > >%basic-blocks; | %out-of-lines; | %wrappers;)*> > > > > > %block-properties; > > > > > >-8X8X--- > > > > > > > > >FOP.dtd: > > >-8X8X--- > > > > > > > > [..] > > >"> > > >[ ... block-properties is an entity based (indirectly) on > > area-properties > > >... ] > > > > %basic-inlines; | > > >%basic-blocks; | %out-of-lines; | %wrappers;)*> > > > > > %b
drawing a table with different line-widths
Hi, I have to layout a table like this: = -- = = -header - = = -- = = -- = = -- = =--= . . . = - last - = = -- = My first try was to define border properties on the header, the body and around all cells. I thought I got it, but when I printed in postscript the lines were stacked in each other. I used PDF first and that was fine. I need to get PS though. Now my second try looks like this ... middle cell Name results in a gap between header and body. And of course I still have to fix the bottom line. I tried fop 0.20.2 and 0.20.3-2002-03-04. I think it might have s.th. to do with the border-collapse property, but as it seems fop or I do not understand the spec. Can anybody help please? Best regards Markus Fries
