Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

On Tue, 2 Aug 2005 04:52 pm, Jeremias Maerki wrote: > On 02.08.2005 03:18:44 Manuel Mall wrote: ... > > ii) Change the layout to a single column per version and indicate > > in a single separate column at which conformance level a particular > > FO object or property "lives" (For a sample see the

Re: API discussion (was: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class)

On Aug 2, 2005, at 11:14, Jeremias Maerki wrote: On 01.08.2005 18:31:35 Andreas L Delmelle wrote: ... Right now, the Driver would have to be wrapped around the main-class, which is something I do NOT like :-/ I doesn't have to. The Fop class is so light-weight (if you think the main() metho

Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class

Manuel Mall wrote: [snip] Makes sense to me. Actually this is exactly what the 0.20.5 Fop.java does. Well, I'd rather refrain from reintroducing a ComandLineOptions like class. I'd still say the most intuitive setup would be - API classes as usual (FO processor, configuration, maybe interfaces

Re: Element list generation for tables (special case)

Thanks Simon. Now I understand. I've just committed the general fix for the problem (I think), but have hard-coded the penalty value to 900 for the moment. I think your idea might be interesting but I'm a little clueless about the right formula to calculate an appropriate penalty value. I'll leave

Re: [EMAIL PROTECTED] KO?

Interesting. [EMAIL PROTECTED] never existed. At first, it was fop-dev@xml.apache.org and now it's [EMAIL PROTECTED] Maybe you need to notify the GMANE admins. I don't know how this works. I'm not using it but I heard others being happy with GMANE (but on other mailing lists). On 02.08.2005 17:19:

[EMAIL PROTECTED] KO?

It seems that [EMAIL PROTECTED], which is what gmane.org uses (see http://gmane.org/list-address.php?group=gmane.text.xml.fop.devel), does not exist anymore...--- Begin Message --- Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following ad

Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0

I've put all this on the Wiki. http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback On 02.08.2005 11:36:59 Luca Furini wrote: > Jeremias Maerki wrote: > > >I agree with the actual concept but I actually want something more > >general in the long-term. There are various aspects that I'd like

Re: rtflib independance from FOP

On 02.08.2005 12:22:02 guillaume wrote: > > Uhm, I don't think we have current CVS snapshots anymore since we moved > > to Subversion some time ago. Seems to be a left-over that we need to get > > Well, I took it from http://svn.apache.org/snapshots/ so the name would be > quite misleading. And i

Re: rtflib independance from FOP (continued) + JAFOG

Uhm, oops, yeah, sorry! Of course. Thanks for spotting that mistake. On 02.08.2005 12:36:41 Chris Bowditch wrote: > Jeremias Maerki wrote: > > > > >>And also I am not really sure whether the most up-to-date version of > >>rtflib lies in FOP or in JFOR... Could someone please clarify this? > >>(

Re: rtflib independance from FOP (continued) + JAFOG

Jeremias Maerki wrote: And also I am not really sure whether the most up-to-date version of rtflib lies in FOP or in JFOR... Could someone please clarify this? (Bertrand?) JFOR has been integrated in FOP, so FOP is not the most up-to-date version. Is this a typo, or did you mean to say FO

Re: rtflib independance from FOP

> Uhm, I don't think we have current CVS snapshots anymore since we moved > to Subversion some time ago. Seems to be a left-over that we need to get Well, I took it from http://svn.apache.org/snapshots/ so the name would be quite misleading. And it seems not to be left-over as cocoon-2.2 is also f

Re: rtflib independance from FOP (continued) + JAFOG

On 02.08.2005 11:44:23 guillaume wrote: > 1) > > > - in rtfdoc.BorderAttributesConverter: > > - fo.properties.CommonBorderPaddingBackground is imported but is only > > used by makeBorder(), which is not used anywhere in rtflib.**, so > > perhaps this could be alleviated too... >

DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

rtflib independance from FOP (continued) + JAFOG

1) > - in rtfdoc.BorderAttributesConverter: > - fo.properties.CommonBorderPaddingBackground is imported but is only > used by makeBorder(), which is not used anywhere in rtflib.**, so > perhaps this could be alleviated too... The same goes for the render.rtf.FOPRtfAttributes impo

Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0

Jeremias Maerki wrote: I agree with the actual concept but I actually want something more general in the long-term. There are various aspects that I'd like to provide to embedders: - Number of pages over all and Number of pages for every page-sequence (obviously) - Callbacks on layout problem

Re: svn commit: r226973

On 02.08.2005 11:18:18 Luca Furini wrote: > > >Adjusting verticals spaces (coming from space-before and space-after > >properties) > >in order to fill the region, whenever possible > > I have done a few tests before committing, with spaces on blocks and on > lists (both in the list-block and i

Re: RTF rendering

On 01.08.2005 20:05:20 Andreas L Delmelle wrote: > On Aug 1, 2005, at 18:57, Sergey Simonchik wrote: > > Hi, > > > Currently I work on upgrading FOP's RTF rendering. We need it as a > > part of another project. > > And now some patches to RTF-rendering with test cases are available. > > So I hav

Re: rtflib independance from FOP

On 01.08.2005 16:57:28 guillaume wrote: > Hello, > > While looking for a RTF text encoder (for accentuated characters), I gave > a closer look at rtflib (in xml-fop_20050717162512.tar.gz). Uhm, I don't think we have current CVS snapshots anymore since we moved to Subversion some time ago. Seems

Re: svn commit: r226973

Adjusting verticals spaces (coming from space-before and space-after properties) in order to fill the region, whenever possible I have done a few tests before committing, with spaces on blocks and on lists (both in the list-block and in the list-items) and it seems to work; should you find b

Re: API discussion (was: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class)

On 01.08.2005 18:31:35 Andreas L Delmelle wrote: > On Aug 1, 2005, at 11:37, Manuel Mall wrote: > > > no argument from me against what you are proposing and also Joerg in > > [1]. We > > can still have a Driver.java for backwards compatibility for those who > > want > > to "plug and play" eithe

Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

On 02.08.2005 03:18:44 Manuel Mall wrote: > Gentlemen, > > can we agree on the following? > > 1. The compliance page must be able to handle multiple FOP versions. Two, at most. > 2. Which versions are shown at any point in time and how they are called > will be decided on a case by case basi

Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

I agree with Victor. The conformance level is uninteresting for most people anyway, and we can't currently claim full support for any particular conformance level. It's all a big mix. Keep it as simple as possible to get fast results. If we want something more sophisticated we can do that later. A

Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0

On 31.07.2005 11:55:00 Simon Pepping wrote: > On Sat, Jul 30, 2005 at 03:35:07PM +0200, [EMAIL PROTECTED] wrote: > > --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 15:35 --- > > Patch applied with some little modifications. Thanks a lot, Manuel! > > > > http://svn.apache.org/v

Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

Manuel Mall wrote: Gentlemen, can we agree on the following? 1. The compliance page must be able to handle multiple FOP versions. What I was saying was this is true for the special case of having two very different FOP versions, but once 0.20.5 is gone, this will no longer be true. So ple