Re: Help Refactoring the Website

2007-07-30 Thread Chris Bowditch

The Web Maestro wrote:


On 7/29/07, Andreas L Delmelle [EMAIL PROTECTED] wrote:


On Jul 27, 2007, at 18:36, Andreas L Delmelle wrote:


it would be good to refactor
the website before the release and, in particular, remove the 0.20.5
tab.


This could maybe still be done before the release, but I started
wondering...



I'd like to call for help on this, as this is not a small task.
I'll try to do as much as possible on the WE, but that would be
great if
we could share the work. Any volunteers?
Some tasks I can think of right now:
- update the introduction page (latest stable release, version of the
 recommendation implemented...)
- add a small news section on the home page? this would make the site
 look more live. It could simply list the latest versions released.
- correct/update/simplify other pages


Wouldn't it be better, FTM, to focus on making the site 0.94-ready,
and do any serious restyling afterwards? It's just that a release by
itself already takes some work and preparation... Just a thought.



I'll spend some time looking into what it'll take to refactor,
although I agree with Andreas that it would be better to focus on
getting 0.94 ready and do any necessary 'purging' of fop-0.20.5 after
that, if that's what's deemed best.

I'm not actually convinced eradicating it from the FOP site is the
best route, as there will be some who can't upgrade (namely users of
AIX 4.1 and/or others who can't upgrade to a Java Run-time Environment
newer than 1.3)... I would think the fop-0.20.5 information should
remain accessible somewhere other than on http://archive.org/. The
good part is, that the content will likely never change and would
exist on a separate TAB, out of the way. That's not to say I'm firmly
in the trench of keeping the content, but I don't see how it'd hurt to
retain it.



Hi Clay,

0.93 and 0.94 are still compatible with Java 1.3 so AIX 4.1 users will 
still be able to use it. We have clients running AIX who use Java 1.4, 
so I didn't realise AIX couldn't run 1.4. Maybe its down to exact o/s 
version. In either case, we decided to drop support for 1.3 after 0.94. 
So if 1.3 is still needed in the future users can download 0.94. And I 
think the website should reflect this.


The reason why 0.20.5 should be removed from the website is that 
fop-users is still receiving several posts per week relating to it. 
There is now very little knowledge of it within our development team, so 
supporting it is not something we would like to continue. Therefore, 
users should be actively discouraged from downloading it. Looking at the 
website today, I get the impression that 0.20.5 and 0.94 are two 
separate development streams which both receive active maintenance. 
However, we all know that is not the case. 0.9x is a direct replacement 
for the 0.20.x series.


It made sense to keep 0.20.5 on the website for a couple of years after 
the initial 0.9x release to give folk a chance to upgrade. But 0.9x has 
been around for a couple of years and now I believe it is time to start 
encouraging users to switch over.


Chris





DO NOT REPLY [Bug 42971] - [PATCH] AFP Font Reader improvements

2007-07-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=42971.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42971


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-07-30 05:22 ---
Patch Applied. Thanks Adrian!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


Re: More about the effects of the PropertyCache

2007-07-30 Thread J.Pietschmann

Andreas L Delmelle wrote:
The CommonBorderPaddingBackground is still a memory eater, but I'll have 
to take a look at LengthRangeProperty and CondLengthProperty first for 
that.


The trick is probably to split it BPBs in a set of
specified data which can be cached and the resolved
data.

Another idea I pursued (without success) in 0.20: some
properties can only have a very limited set of values,
in particular text-decoration, keeps, and a few others,
which can probably implemented as singletons instead of
using a cache. For properties like hyphenation-ladder-count
which are likely to have only a few values from a potentially
unlimited domain, a mix of pre-fabricated singletons for the
most likely used values and a list in case another value
is specified, without pruning during rendering, might provide
the best balance between memory efficacy and performance.

J.Pietschmann


[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed

2007-07-30 Thread Sam Ruby
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop :  XSL-FO (Formatting Objects) processor


Full details are available at:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/classes]
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html
Work Name: build_xml-fop_xml-fop (Type: Build)
Work ended in a state of : Failed
Elapsed: 26 secs
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only package 
[Working Directory: /srv/gump/public/workspace/xml-fop]
CLASSPATH: 
/usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xmlgraphics-commons/build/xmlgraphics-commons-30072007.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-xml.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-script.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-parser.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-30072007/lib/batik-gvt.jar:/srv/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-30072007.jar:/srv/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-30072007.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-30072007.jar:/srv/gump/public/workspace/apache-commons/io/build/commons-io-30072007.jar:/srv/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-30072007.jar
-
[javac] NoOperation noOp = new NoOperation(content);
[javac] ^
[javac] 
/srv/gump/public/workspace/xml-fop/src/java/org/apache/fop/render/afp/modca/AbstractPageObject.java:366:
 cannot find symbol
[javac] symbol  : class NoOperation
[javac] location: class org.apache.fop.render.afp.modca.AbstractPageObject
[javac] NoOperation noOp = new NoOperation(content);
[javac]^
[javac] 
/srv/gump/public/workspace/xml-fop/src/java/org/apache/fop/render/ps/PSRenderer.java:516:
 warning: [deprecation] useRGBColor(java.awt.Color) in 
org.apache.xmlgraphics.ps.PSGenerator has been deprecated
[javac] gen.useRGBColor(col);
[javac]^
[javac] 

Re: Help Refactoring the Website

2007-07-30 Thread The Web Maestro
On 7/30/07, Chris Bowditch [EMAIL PROTECTED] wrote:
 Hi Clay,

 0.93 and 0.94 are still compatible with Java 1.3 so AIX 4.1 users will
 still be able to use it. We have clients running AIX who use Java 1.4,
 so I didn't realise AIX couldn't run 1.4. Maybe its down to exact o/s
 version. In either case, we decided to drop support for 1.3 after 0.94.
 So if 1.3 is still needed in the future users can download 0.94. And I
 think the website should reflect this.

 The reason why 0.20.5 should be removed from the website is that
 fop-users is still receiving several posts per week relating to it.
 There is now very little knowledge of it within our development team, so
 supporting it is not something we would like to continue. Therefore,
 users should be actively discouraged from downloading it. Looking at the
 website today, I get the impression that 0.20.5 and 0.94 are two
 separate development streams which both receive active maintenance.
 However, we all know that is not the case. 0.9x is a direct replacement
 for the 0.20.x series.

 It made sense to keep 0.20.5 on the website for a couple of years after
 the initial 0.9x release to give folk a chance to upgrade. But 0.9x has
 been around for a couple of years and now I believe it is time to start
 encouraging users to switch over.

 Chris

Thanks Chris! I'll look into what I can to help re-factor the site to
remove the 0.20.5 references. I agree, that with 0.93  0.94, the 0.20
branch information is no longer necessary.

Web Maestro Clay
-- 
Regards,

The Web Maestro
-- 
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet