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

[Victor Mote]

Manuel Mall wrote:

> I managed to revive the color coding (see 
> http://www.arcus.com.au/fop/compliance.html). It was a CSS 
> issue in that the FOP custom stylesheet rules were less 
> specific than the Forrest default CSS rules and therefore not 
> applied on the table elements.

The original intent is seen in the properties section there, but not in the
objects (which you have adapted to the new scheme). The color coding in
objects is useful also, just in a different way. The original idea was
intended somewhat as a benefit to developers, almost a checklist. I probably
did not fully grasp at the time that 0.20.5 had been completely abandoned.
With that in mind, abandoning the basic / extended / complete information in
favor of the progression between the two releases is  probably good, since
you only have 2 dimensions on the page to work with. And the user can still
infer the same information from the data presented, it just won't be as
visually obvious.

Victor Mote

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

[Manuel Mall]

Victor,

thanks for the background information.

On Tue, 2 Aug 2005 09:19 am, Victor Mote wrote:
> Manuel Mall wrote:
> > BTW, why do we have the 3 columns Basic | Extended | Complete?
> > Every row will only have one cell out of those 3 filled out.
> > Wouldn't it make more sense to have a single column called
> > Compliance or Core with the values Basic, Extended or Complete?
> > That would save valuable screen space and give us room to add
> > columns for each release.
>
> The original compliance page had each cell color-coded to indicate
> compliance with each of the three levels. So, if feature A is
> required for "Extended" support and was not supported by FOP, the
> "Basic" column would have the "compliant" color, while the "Extended"
> and "Complete" columns would have the "non-compliant" color.
>
...
I managed to revive the color coding (see 
http://www.arcus.com.au/fop/compliance.html). It was a CSS issue in 
that the FOP custom stylesheet rules were less specific than the 
Forrest default CSS rules and therefore not applied on the table 
elements.

Manuel
> Victor Mote

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

[Manuel Mall]

Gentlemen,

can we agree on the following?

1. The compliance page must be able to handle multiple FOP versions. 

2. Which versions are shown at any point in time and how they are called 
will be decided on a case by case basis. Currently we are talking only 
about the last official release (0.20.5) and the current work in 
progress (1.0dev, 0.9pr, ...) but down the track versions may be added 
or removed at a frequency we don't know yet.

From my perspective, as I have put my hand up to do this, this raises 
two issues.

a) What is the appropriate visual design for the compliance page to 
achieve 1.?
Two proposals have been made:
i) Maintain the current 3 column layout of
  
Basic | Extended | Complete
  and replicate
  
Basic | Extended | Complete | Basic | Extended | Complete
This solution allows to quickly see by scanning down a column if a 
particular version is conformant at a particular level. However, it 
doesn't scale very well. Even with two versions only it will be very 
"squished" on the screen. Adding more than 2 will most likely be 
looking fairly awkward.

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 XSL-FO Object Support 
Table at http://www.arcus.com.au/fop/compliance.html). This solution 
scales better as it is more compact but it is harder to see if a 
particular version is conformant at a particular level.

b) What is the appropriate technical solution to achieve 2.?
i) Manually edit the HTML
ii) Use some WYSIWYG tool which can produce Forrest compliant output 
(OpenOffice was suggested)
iii) Revive the generation of the page from XML input (does someone have 
the original compliance.xml file - I can't find it in SVN?)

I am happy to investigate and implement (if needed) the technical 
solution but I would like to get FOP committer feedback on the look & 
feel of the page as this is part of the projects public face.

Cheers

Manuel

On Mon, 1 Aug 2005 10:44 pm, Chris Bowditch wrote:
> The Web Maestro wrote:
> > On Aug 1, 2005, at 2:58 AM, Chris Bowditch wrote:
> >> I don't think adding/removing releases from the compliance page is
> >> something we plan on doing frequently.  A side by side comparsion
> >> is only required now because the Trunk code is a complete
> >> re-write.
> >>
> >> Once the trunk code has stablized and its being used in
> >> production, everything relating to the maintanance branch can
> >> probably be removed from the website. When further releases are
> >> made from the Trunk, it will simply be a matter of updating the
> >> compliance page to reflect what the latest release supports.
> >>
> >> Chris
> >
> > Actually, I think we'll probably leave the 0.20.5 release online
> > (although, we haven't discussed this yet). One thing about 0.20.5
> > and previous versions is that, presumably, they support more
> > systems than the one about to be released. IIRC, 0.9/1.0dev will
> > require Java 1.4 or 1.5, neither of which are supported by AIX 4.1
> > (JRE 1.3 max). For this reason, it makes sense (to me) to at least
> > maintain a comparison page (if we don't leave that
> > maintenance-branch info on the FOP Compliance Page).
>
> Clay - 0.9pr will support JDK 1.3. I have long been arguging the need
> to maintain support for it. I believe Jeremias applied a patch
> recently to fix the issues with building 0.9pr on 1.3. So it should
> be okay now?
>
> So I don't think 0.20.5 will have any advantage once 0.9 has become
> stable. Hence why I think we should stop promoting it once 0.9 is
> thorouhly tested and in production.
>
> Chris

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

[Victor Mote]

Manuel Mall wrote:

> BTW, why do we have the 3 columns Basic | Extended | Complete? Every 
> row will only have one cell out of those 3 filled out. Wouldn't it 
> make more sense to have a single column called Compliance or Core with 
> the values Basic, Extended or Complete? That would save valuable 
> screen space and give us room to add columns for each release.

The original compliance page had each cell color-coded to indicate
compliance with each of the three levels. So, if feature A is required for
"Extended" support and was not supported by FOP, the "Basic" column would
have the "compliant" color, while the "Extended" and "Complete" columns
would have the "non-compliant" color.

I built this just slightly before we converted to Forrest. Since we
converted to Forrest, the custom XSLT required for the above has been a
pain, and I think it has been eliminated. I just looked at the published
page, and it looks like you still have the three columns, but not the
color-coding, so combining the three as you suggest makes good sense.

(Sorry for the slow response. My email is being bounced as spam).

Victor Mote

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

[Manuel Mall]

On Tue, 2 Aug 2005 12:31 am, 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" either in the product, or in a separate jar
> > (fop-compat.jar?), or just here in BugZilla.
>
> Well, I've thought about that as well --keeping the Driver FTM as a
> sort of 'deprecated proxy' that simply forwards the method-calls to
> the respective components in the new API, but...
> IMO this is not an absolute necessity. If we decide on discontinuing
> support for the 0.20.5 API, then we may as well do it now.

No problem for me as can easily have my private fop-compat.jar as long 
as nobody introduces an incompatible Driver.java into the trunk.
>
> The main point is however, that with the current design, implementing
> such a proxy looks rather clumsy --this has absolutely nothing to do
> with your coding, but is a consequence of the merging of component
> and standalone app... Right now, the Driver would have to be wrapped
> around the main-class, which is something I do NOT like :-/
>
> The following may make little sense to you, but just in case there
> are others following this thread:
> I feel that the class that will be used for running FOP from the
> command line should be an example in itself, in that it should use
> the component in the same way an embedding user would. Only
> difference is that the configuration will be created based on the
> command line parameters.
>
> Our CommandLineOptions class should build a Configuration which the
> main-class can then pass into the configure() method of the
> component. It really does not need to --or stronger: it shouldn't--
> concern itself with initializing the OutputStream, for example.
>
> Roughly its tasks should be limited to:
> - tell the CommandLineOptions to construct a Configuration based on
> the parameters specified on the command line
> - tell the component to configure itself with that Configuration
> object - tell the component to go about its business (start() or
> run())
>
> That class should, if I estimate correctly, be about 50 lines of
> code. Right now, we have a main() method in the Fop class at line
> 300+, which seems fishy to say the least.
>
Makes sense to me. Actually this is exactly what the 0.20.5 Fop.java 
does. It just has one main method of less than 30 lines. The question 
is where should the API reside. In 0.20.5 it resides in Driver.java but 
in the current trunk its in Fop.java coupled with the CLI which is what 
you (rightly so in my opinion) criticize. May be factoring it out, 
however not into Driver (if I recall correctly people didn't like the 
name), but into another API only class (FOProcessor.java ?) is a 
solution?

Manuel
>
> Greetz,
>
> Andreas

Re: RTF rendering

[Andreas L Delmelle]

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 have two questions:
1) Would you be so kind to tell your intention about RTF support?


Well, there has been some talk --I think it was very early this year-- 
about doing a release off the trunk that only supported RTF rendering 
(since the other renderers weren't ready yet), so I guess you could say 
that we're quite sure RTF support will be available in the next 
release.


Question for other devs: the Ant build indicates that the RTF renderer 
is 'still very very alpha'. Can that warning be removed or is it still 
too early?



2) What do you think about commiting these patches?


Well, all help is welcome, but it's difficult to say what we think if 
you don't show us the patches. :-) If you don't have any objection, 
just enter a Bugzilla report[1] describing the enhancements your 
patches offer, attach the diff(s) and testcases, and we'll certainly 
get back to you.


TIA!


Cheers,

Andreas

[1] http://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop

Re: Element list generation for tables (special case)

[Andreas L Delmelle]

Merely FYI: slight correction needed...


On 30.07.2005 15:14:04 Andreas L Delmelle wrote:


Currently, I don't think we already have a mapping of these
object->applicable_props anywhere, ...


We do have such a map in org.apache.fop.fo.PropertySets, but I don't 
get the impression that it is equipped to allow lookup of whether a 
given property is applicable for a given formatting object...



Cheers,

Andreas

RTF rendering

[Sergey Simonchik]

Greeting.

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 have two questions:
1) Would you be so kind to tell your intention about RTF support?
2) What do you think about commiting these patches?

Thanks for attention.

Good success!

---
Sergey Simonchik.

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

[Andreas L Delmelle]

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" either in the product, or in a separate jar
(fop-compat.jar?), or just here in BugZilla.


Well, I've thought about that as well --keeping the Driver FTM as a 
sort of 'deprecated proxy' that simply forwards the method-calls to the 
respective components in the new API, but...
IMO this is not an absolute necessity. If we decide on discontinuing 
support for the 0.20.5 API, then we may as well do it now.


The main point is however, that with the current design, implementing 
such a proxy looks rather clumsy --this has absolutely nothing to do 
with your coding, but is a consequence of the merging of component and 
standalone app... Right now, the Driver would have to be wrapped around 
the main-class, which is something I do NOT like :-/


The following may make little sense to you, but just in case there are 
others following this thread:
I feel that the class that will be used for running FOP from the 
command line should be an example in itself, in that it should use the 
component in the same way an embedding user would. Only difference is 
that the configuration will be created based on the command line 
parameters.


Our CommandLineOptions class should build a Configuration which the 
main-class can then pass into the configure() method of the component. 
It really does not need to --or stronger: it shouldn't-- concern itself 
with initializing the OutputStream, for example.


Roughly its tasks should be limited to:
- tell the CommandLineOptions to construct a Configuration based on the 
parameters specified on the command line

- tell the component to configure itself with that Configuration object
- tell the component to go about its business (start() or run())

That class should, if I estimate correctly, be about 50 lines of code. 
Right now, we have a main() method in the Fop class at line 300+, which 
seems fishy to say the least.



Greetz,

Andreas

rtflib independance from FOP

[guillaume]

Hello,

While looking for a RTF text encoder (for accentuated characters), I gave
a closer look at rtflib (in xml-fop_20050717162512.tar.gz).

It seems that here still a few dependancies on FOP in it. I understand it
is not a priority for the FOP-Team right now, but if it can help in some
way, here they are:

 - in rtfdoc.RtfGenerator there is a call to Fop.getVersion() juste to
print the FOP version, and that obviously pulls all the FOP classes: this
could easily be removed by adding a "generator" String parameter on the
constructor (as the generator RTF metadata is optional, one could even
keep the old constructor for compatibility)
 - in rtfdoc.BorderAttributesConverter:
- fo.Constants is imported but it seems acceptable as it brings no other
  dependancy
- 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...

Sorry my dependancies checks are not fool-proof as I had neither eclipse
nor grep to check, only Windows and few spare time to do it...

I must had that I do not need a self-contained rtflib anymore right now,
as what I needed is nicely self-contained in rtfdoc.RtfStringConverter:
keep it that way if you can! :)

Good luck for the upcoming release!
   G.D.

P.S.: Please respond also to my address if possible as I have not
subscribed to this list...

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

[Chris Bowditch]

The Web Maestro wrote:


On Aug 1, 2005, at 2:58 AM, Chris Bowditch wrote:

I don't think adding/removing releases from the compliance page is 
something we plan on doing frequently.  A side by side comparsion is 
only required now because the Trunk code is a complete re-write.


Once the trunk code has stablized and its being used in production, 
everything relating to the maintanance branch can probably be removed 
from the website. When further releases are made from the Trunk, it 
will simply be a matter of updating the compliance page to reflect 
what the latest release supports.


Chris



Actually, I think we'll probably leave the 0.20.5 release online 
(although, we haven't discussed this yet). One thing about 0.20.5 and 
previous versions is that, presumably, they support more systems than 
the one about to be released. IIRC, 0.9/1.0dev will require Java 1.4 or 
1.5, neither of which are supported by AIX 4.1 (JRE 1.3 max). For this 
reason, it makes sense (to me) to at least maintain a comparison page 
(if we don't leave that maintenance-branch info on the FOP Compliance 
Page).


Clay - 0.9pr will support JDK 1.3. I have long been arguging the need to 
maintain support for it. I believe Jeremias applied a patch recently to 
fix the issues with building 0.9pr on 1.3. So it should be okay now?


So I don't think 0.20.5 will have any advantage once 0.9 has become 
stable. Hence why I think we should stop promoting it once 0.9 is 
thorouhly tested and in production.


Chris

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

[The Web Maestro]

On Aug 1, 2005, at 2:58 AM, Chris Bowditch wrote:
I don't think adding/removing releases from the compliance page is 
something we plan on doing frequently.  A side by side comparsion is 
only required now because the Trunk code is a complete re-write.


Once the trunk code has stablized and its being used in production, 
everything relating to the maintanance branch can probably be removed 
from the website. When further releases are made from the Trunk, it 
will simply be a matter of updating the compliance page to reflect 
what the latest release supports.


Chris


Actually, I think we'll probably leave the 0.20.5 release online 
(although, we haven't discussed this yet). One thing about 0.20.5 and 
previous versions is that, presumably, they support more systems than 
the one about to be released. IIRC, 0.9/1.0dev will require Java 1.4 or 
1.5, neither of which are supported by AIX 4.1 (JRE 1.3 max). For this 
reason, it makes sense (to me) to at least maintain a comparison page 
(if we don't leave that maintenance-branch info on the FOP Compliance 
Page).


Regards,

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

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

[Chris Bowditch]

Manuel Mall wrote:



Back to the compliance page. I assume what is required is some indication of 
1.0dev compliance vs 0.20.5 compliance. To achieve that we could:

a) Add extra columns, eg.
 Support (0.20.5)|Support (1.0dev)
Basic | Extended | Complete | Basic | Extended | Complete
...


This is my preference.

We aren't planning on calling the first release 1.0dev, but in recent 
discussions I thought 0.9pr was the agreed release name. So we should 
probably call it that on the compliance page.



b) Add extra columns like
   Support
 Basic  |  Extended | Complete
0.20.5| 1.0Dev | 0.20.5| 1.0Dev | 0.20.5| 1.0Dev |
...
c) Leave the column structure as is and record it in the column values, i.e. 
instead of "Yes" we could have a list of version numbers eg. "0.20.5, 
1.0dev". If its partial its indicated in brackets behind the version number.


Option c) is probably the easiest to manage as the table structure doesn't 
change as we add/remove releases from the table. b) is probably the easiest 
on the eye for a quick visual comparison but with each release added/removed 
the whole table structure changes making it work intensive to maintain.


I don't think adding/removing releases from the compliance page is 
something we plan on doing frequently.  A side by side comparsion is 
only required now because the Trunk code is a complete re-write.


Once the trunk code has stablized and its being used in production, 
everything relating to the maintanance branch can probably be removed 
from the website. When further releases are made from the Trunk, it will 
simply be a matter of updating the compliance page to reflect what the 
latest release supports.


Chris

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

[Manuel Mall]

Andreas,

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" either in the product, or in a separate jar 
(fop-compat.jar?), or just here in BugZilla.

Manuel

[1] http://marc.theaimsgroup.com/?l=fop-dev&m=108947697611032&w=2

On Mon, 1 Aug 2005 02:20 am, Andreas L Delmelle wrote:
> On Jul 30, 2005, at 17:34, Manuel Mall wrote (on bugzilla):
>
> Manuel,
> Devs,
>
> > To be able to simply replace a 0.20.5 fop.jar with 1.0dev fop.jar I
> > have written
> > a backwards compatible apps.Driver.java class. Everything in the class
> > has been
> > labelled as deprecated.
>
> FWIW: Personally, besides the compatibility issue, I'm not too happy
> with the current situation where the very same class is used for both
> command-line and embedded use (Fop.java) --one class acts both as a
> standalone application and as a component.
> That's considered an anti-pattern they call "Subversion of Control" in
> Avalon terminology[1] :-)
>
> I've been checking the discussion on fop-dev concerning the removal of
> Driver[2]. From the looks of it, at least one developer had similar
> reservations about removing it. It's a pity the discussion itself
> remained rather superficial.
>
>
> Cheers,
>
> Andreas
>
> [1] http://excalibur.apache.org/framework/component-design.html
> [2] http://marc.theaimsgroup.com/?l=fop-dev&m=108942539604883&w=2