headers
Manuel Mall | 1 Aug 2005 01:28
Picon

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

Clay,

On Mon, 1 Aug 2005 02:39 am, The Web Maestro wrote:
> Manuel,
>
> First of all, thanks loads for helping out with this!
>
> On Jul 30, 2005, at 11:32 PM, Manuel Mall wrote:
...
>
> We currently use Forrest 0.6. Forrest 0.7 was recently released, and it
> was on my personal ToDo list to convert to 0.7.
>
I am using 0.7 and there was no conversion required. I could try to take the 
pelt skin and to modify it to address the HTML 4.01 compatibility issues. 
However, I am not sure if that would be time well spent.
>
> > Another observation: FOP being a project under the XML family
> > shouldn't we
> > have an XHTML compliant site? I am guessing that this is a Forrest
> > skin issue
> > as well?
>
> That would be great. I believe that 0.7 brings Forrest closer to that
> XHTML reality. In order to make the site XHTML compliant, we may have
> to convert the site to either forrest 0.7 or 0.8-dev (not yet
> released).
>
There is no effort involved in converting the site to 0.7. I just seems to 
work. Making it XHTML would probably involve even more skin and possibly XSLT
(Continue reading)

Permalink | Reply | 3 comments |
headers
The Web Maestro | 1 Aug 2005 03:09
Picon
Gravatar

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

On Jul 31, 2005, at 4:28 PM, Manuel Mall wrote:
> I am using 0.7 and there was no conversion required. I could try to 
> take the
> pelt skin and to modify it to address the HTML 4.01 compatibility 
> issues.
> However, I am not sure if that would be time well spent.

Likely all that is needed to 'convert' to Forrest 0.7 is to ensure that 
skinconf.xml & forrest.properties match the 0.7 format (compare against 
their counterparts from a 'forrest seed' run).

<snip>

>> True. The Compliance page is actually an 'ihtml' page. I used this,
>> because Forrest had significant difficulties with the FOP Compliance
>> page. I essentially created an HTML page, and then passed it through
>> Forrest unmodified.
>
> I seems originally the compliance page was created using some XSLT
> transformations (see src/documentation/resources/stylesheets). Has this
> approach been abandoned? I can't find the input file.

I believe it was originally, however that broke and I wasted many hours 
of time trying to get it to work. It's likely that the file 
compliance.xml is a good starting point (in xdocs/)

>>> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Manuel Mall | 1 Aug 2005 03:18
Picon

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

On Mon, 1 Aug 2005 09:09 am, The Web Maestro wrote:
> On Jul 31, 2005, at 4:28 PM, Manuel Mall wrote:
...
> > I seems originally the compliance page was created using some XSLT
> > transformations (see src/documentation/resources/stylesheets). Has this
> > approach been abandoned? I can't find the input file.
>
> I believe it was originally, however that broke and I wasted many hours
> of time trying to get it to work. It's likely that the file
> compliance.xml is a good starting point (in xdocs/)
>
Do you mean src/documentation/content/xdocs? I can't find a compliance.xml 
there in SVN. Never mind, I'll take your advice that its broken any way and 
will edit the compliance.ihtml.
Permalink | Reply | 0 comments |
headers
Manuel Mall | 1 Aug 2005 05:32
Picon

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

On Mon, 1 Aug 2005 09:09 am, The Web Maestro wrote:
> On Jul 31, 2005, at 4:28 PM, 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.
>
> Someone else can probably best answer that ;-), but my sense is that
> those come from the xsl-fo spec.
>
Had a first go and just changed the "XSL-FO Object Support Table" table. 
Removed the 3 columns 'Basic', 'Extended', and 'Complete' and replaced them 
with a column 'Compliance Level' instead. The 0.20.5 and 1.0dev have been 
given their own column. Can you guys have a look 
(http://www.arcus.com.au/fop/compliance.html) and see if that format is OK 
before I apply it to the properties section.

Obviously the whole site as generated with Forrest 0.7 is available from 
http://www.arcus.com.au/fop. While I am at it if anyone has suggestions for 
other changes apart from the compliance page post it on the list.

Manuel
Permalink | Reply | 0 comments |
headers
Manuel Mall | 1 Aug 2005 11:37
Picon

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

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] :-)
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Bowditch | 1 Aug 2005 11:58
Picon
Favicon

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

Manuel Mall wrote:

<snip/>

> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
The Web Maestro | 1 Aug 2005 16:17
Picon
Gravatar

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

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
--

-- 
<the.webmaestro <at> gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Bowditch | 1 Aug 2005 16:44
Picon
Favicon

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

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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
guillaume | 1 Aug 2005 16:57
Favicon

rtflib independance from FOP

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas L Delmelle | 1 Aug 2005 18:31
Picon

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

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane