Re: Opinion poll

[Chris Bowditch]

Jeremias Maerki wrote:
I'd like to push the XML Graphics Commons idea again and therefore would
like to know what people think.
1. I think there's noone around opposing the idea of creating the common
area and making the transcoders in FOP available to the Batik team, is
there?
Fine with me.
2. Do you prefer the transfer of the transcoders to the Batik subproject
as Thomas suggested or do you think that the transcoders should be in a
separate area that is easily accessible by both teams? Or is that
particular question not so important for you?
I think Transcoders should be accessible to both sets of committers. So 
therefore in their own separate area. I seem to remember from previous 
discussions that this was difficult to achieve for technical reasons.

3. Would you be opposed to converting Batik and FOP to Subversion in
preparation for the creation of the common area? This would preserve all
history of the individual classes. Time frame: within 1 month from now.
It seems to me that the infrastructure have succeeded in making
Subversion stable now. 
I havent yet checked to see if there is an easy to use Windows client 
available.
Chris
-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Code reorganization

[Chris Bowditch]

Jeremias Maerki wrote:
We still have the two general solutions in the Wiki:
http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
Proposal 2 is clearly superior to make the dependencies clearer and the
make things easier for our users as well as the Batik team.
Chris said he preferred that the transcoders should be writable by both
teams which favors Proposal 1. It was also my first idea. But see above.
Yes, like you I wasnt keen for FOP to give up something it used to have 
control over. However, I rarely contribute any code to the project, so I'm not 
going to stand in the way of those that make regular contributions.

A proposal 2a (a kind of compromise) would involve putting the basic
Graphics2D implementations in the Commons area (no dependencies on Batik).
The transcoders themselves would go into Batik. Of course, this also
splits this part in two, possibly making it harder for the Batik team
when doing bigger improvements. But I think it would address my (and
Simon's) particular interest in the Graphics2D implementations. So my
question would be what Chris and Thomas (and everyone else, of course)
think about this variant.
This is a good compromise indeed.

Chris
-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XML Graphics Commons: last call

[Chris Bowditch]

Thomas DeWeese wrote:




   Ok so I took some time and I really don't like this model.
This is exactly the sort of thing that belongs at the application
layer not at the library layer.  The idea of 'passing data' around
the application through a config file seems really bad to me.
(it's an excellent example of a programmers hack, look at all the
cool stuff I can do, so I can also break things in really odd
unpredictable ways - that's a small price to pay for tweakability).


I don't understand why passing a configuration object around an 
application should be considered a programmer hack. It's common and well 
accepted practise. Can you elaborate a bit on why you think it's a hack?




   The problem is that I'm sure this is exactly the sort of
thing that sparked the flame wars.  I also am not going to even
come close to have the time or interest to provide a replacement.


Your reason why a flame war should result is not clear to me. If you 
can't/won't suggest an alternative then you seem to be on weak ground 
when arguing against something.





If anything, those who have a problem
with A-F should propose a viable alternative (I haven't seen one, yet)
or work with the Excalibur guys to extract the configuration subpackage
into a stand-alone lib.



   Since I have no idea what the library is and/or what you
plan to use it for I can't really provide alternatives.



   This should be done the old fashioned way, the library should export
interfaces to support configuration and the _application_ should
provide the configuration data to the library as appropriate for
the application.  I think this is really trying to do an end run
around this.  There is no clear description of the data that passes
across this interface - that's really ugly IMO.


Agreed that the application may need to provide implementations of 
anything specific - but the classes we are talking about are deemed to 
be generic.





But A-F contains a configuration subpackage [2] which is very small,
very easy to use and provides exactly what is necessary to load a
configuration tree from an XML file and to access values in a type-safe
and fail-safe manner while not having to deal with the deficiencies of a
DOM.



   The problem is that I don't care how big or small a dependency is
once the dependency is there it causes problems.


I understand the concern about adding a new dependency and agree size is 
somewhat irrelevant. The alternative is to rewrite everything yourself 
which isn't very good either.




I don't see how logging disturbs operation in interactive contexts. 



   It doesn't necessarily disturb it but it doesn't help either.


Not true. Logging is extremely helpful when debugging problems raised by 
a remote user. And since all our users are remote and supported by the 
mailing list logging is vital to supporting our users.




Do you prefer logging by System.out? Or can you do without logging? 



   I add/uncomment system.err messages (and often make use
of 'new Error("blah").printStackTrace()') as needed to track problems.
In the past I've developed elaborate logging systems (mostly C/C++)
and they can be useful for situations where build times are long
or you need to support remote clients.  But Java build times are tiny
and end users can access our source.


Well thats fine for development, but no help for supporting remote 
users. To tell a user where the source code is and they should figure it 
out themselves is not acceptable. A small percentage of users may be 
happy to do this, but most will not be java savy and will expect help 
from the developers.





I learned that I can't. Logging is a very powerful means while
debugging (dev- and deployment-time).



   As I said logging can be useful in non-interactive circumstances,
but in interactive situations you need to provide feedback through
the GUI.  In my experience logging is useless for this - the type
and style of messages that goes into logs is very different from
the GUI.  Now there are potentially non-interactive applications
for Batik components (the transcoders mostly) but right now they
handle logging/notification through the UserAgent classes.


FOP doesn't have a GUI and whilst Batik may have a GUI in some 
circumstances - there are other use cases - such as transcoders (that 
you already mentioned) and embedded use of Batik where logging is 
necessary to provide feedback of what Batik is doing.





   I'm happy to split out independent pieces but in my opinion they
are either completely separate project (independent releases possible)
or they should be one code base.  I think the 1/2 way solution is
just annoying for everyone.


You may be right here, but your earlier arguments are not related IMO.




Is that plausible?



   The current system seems like a lot of extra build nonsense
since each jar has to be built in turn so it can be used to
compile the next project, right?



Not necessarily. I don't think a separate build for each packag

Re: XML Graphics Commons: last call

[Chris Bowditch]

Hi Thomas,

thanks for clearing up the points I raised. What you are saying is now a 
lot clearer to me.


Thomas DeWeese wrote:




   AFAIKS there is no explicit documentation of what the
configuration object's interface is.  It's what ever the file
happens to contain and the library happens to want to pull out.
This interface is totally free to change at any point in time.


I understand your objection now. You mean you don't like the generic 
nature of the configuration classes.




   This is bad, IMO it's akin to global variables.  They are really
easy to manipulate 'outside' of the published interfaces can be
extremely useful, and make it impossible for the application to
have a sane view, enforce and/or lockdown he application state.

If you can't/won't suggest an alternative then you seem to be on weak 
ground when arguing against something.



   So I did suggest an alternative (it's right below), publish an
honest to goodness configuration object with a real interface.  Then
have the application layer populate that through what ever means it
chooses.  I also admitted that I was in a weak position because there
was no way I was going to rewrite the 'problem' code.


Ok. That wasn't clear before.



   But please keep in mind why we are having this discussion.  It
is because we are in the final stages of deciding how Fop and
Batik can merge development in common areas.  You will note that
in this discussion there is no issue around Batik external dependencies
because there are none.  All of our external dependencies are
pay as you go (Xalan, rhino, pdf-transcoder,...).  Batik hasn't
inflicted other projects our users without strong justification.


I seem to remember some pain relating to licensing of Rhino recently. So 
I don't completely agree here. The fact is that both projects need to 
use third party software. It's all about code re-use, ease of 
development etc.





   The problem is that I don't care how big or small a dependency is
once the dependency is there it causes problems.



I understand the concern about adding a new dependency and agree size 
is somewhat irrelevant. The alternative is to rewrite everything 
yourself which isn't very good either.



   So I'm happy to use libraries that provide significant functionality
but I don't like adding a dependency for something as silly as
configuration.  I understand that it 'makes it easy' on the programmer
to provide a broad configuration interface, but I'm fairly convinced
that this is often not a good thing.


Ok. I don't disagree with you now that you've explained your point better.



I don't see how logging disturbs operation in interactive contexts. 



   It doesn't necessarily disturb it but it doesn't help either.



Not true. Logging is extremely helpful when debugging problems raised 
by a remote user. And since all our users are remote and supported by 
the mailing list logging is vital to supporting our users.



   Come on, the way we support remote users is almost always:
Please send us a reproducible test case


Sometimes yes, but often too we ask them to specify -d at the command 
line to figure out why they have just "null" appearing on stdout.





   If they have integrated the application into a larger app then
they are Java savy and they can be asked to modify source.  Look
I'm not trying to say that Logging is useless just that it is
another example of something I would rather not introduce an
external dependency to provide.


This is a fair argument against the configuration classes, but not 
against the logging classes. There is a strong justification for logging 
in supporting users and as a development aid.


We would prefer not to remove configuration as a dependency, but I think 
we could do it as a compromise if you are prepared to accept logging as 
a dependency.





   As I said that is currently done through the UserAgent class.
The basic point I was making is that in order to support the GUI we
need something a bit higher level than logging, as long as Batik
needs that to support interactive contexts we can use it where
FOP uses logging.


So you can simply turn off logging for the interactive use case and use 
something else, which is specific to Batik and therefore won't need to 
live in xml-commons.



You may be right here, but your earlier arguments are not related IMO.



   No they weren't intended to be.  This is a separate piece of
commentary on the proposal.


OK.




I think it's simply helpful to more clearly show to
interested people what the individual parts are. 



   Isn't this better done in the documentation?  I fail to see how
introducing a bunch of extra empty directories does anything to
help comprehension.  And as long as you have one big build you
don't even get enforcement of unidirectional dependencies.



Who said anything about creating empty directories? Empty ones won't 
be helpful, but breaking up big packages into smaller ones makes the 
code easier to get to gri

Re: Mailing list for voting new committers

[Chris Bowditch]

Jeremias Maerki wrote:


On 24.08.2005 02:35:46 Christian Geisert wrote:


Hi,

In the past votes for new FOP committers happened on fop-dev and for 
Batik (I think) they were held in private.



I think you meant "in public", right?. They were actually held in public
with all the negative consequences like -1s being cast out and later
converted to a different vote. That results in a not so warm welcome for
new committers.


I think Christian meant votes were in public for FOP and private for 
Batik. Yes I remember a few awkward votes before now.






A discussion on [EMAIL PROTECTED] some weeks ago concerning the voting 
procedure for new committers [1],[2] led me to the conclusion that we 
should discuss and vote new committers on the pmc list.


What do you think?



I fully agree.


+1



BTW, this leads me to another little detail I caught during ApacheCon
when someone (I think it was Noel Bergman) said that only PMC members
get binding votes on project decisions. That's because the PMC is
responsible for the project and not the committers. That's also the
reason why for certain Apache projects (like HTTPD) the set of
committers is almost the same as the set of PMC members.


Aren't all active committers on FOP members of the PMC too?

BTW, wouldn't it be more appropriate to have this discussion on the PMC 
mailing list :-)


Chris


-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Creation of XML Graphics Commons

[Chris Bowditch]

Jeremias Maerki wrote:


It took a long time since the initial idea until today, but we finally
have a plan we can proceed with. So I'd like to call a formal vote for
the following plan:





Please cast your votes!


A big thanks to Jeremias for organising all this. You've been very 
thorough as usual!


Anyway, heres my +1


Chris


-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release FOP Trunk as FOP 0.90alpha1

[Chris Bowditch]

Jeremias Maerki wrote:


I'd like to propose to release FOP SVN Trunk as version 0.90alpha1.

+1 from me, obviously.


+1

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release FOP 0.91beta

[Chris Bowditch]

Jeremias Maerki wrote:


I like Simon's proposal of calling the new release 0.91beta. The
increase in the version number shows progress towards 1.0 and "beta"
gives an indicator about stability. FOP is certainly more stable and
usable now than an "alpha" level software. On the other side it is not
quite ready for production in every situation. Some important things
like a stable API are also not achieved, yet.

So, I branched Trunk into the "fop-0_91" branch. The legal situation is
unchanged since the last release. Everything should be in order. The
code is quite stable and has received a good number of bugfixes and only
a few new features.


Well done. You have fixed a few dozen bugs I think since the last release.



I'd like to call for a PMC vote to release FOP 0.91beta from this newly
created branch. (Votes to [EMAIL PROTECTED], please)

+1 from me, obviously.


+1 from me too.

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PMC:VOTE] Add AFP Renderer to FOP

[Chris Bowditch]

Jeremias Maerki wrote:


In November, Manuel proposed [1] to add the AFP Renderer [2] from Pete
Townsend and Joe Schmetzer to FOP's sandbox in the Trunk. We already
have 5 +1s (3 were PMC members: Chris, Clay, Jeremias), but judging from
recent discussions inside the incubator I think we should have a formal
PMC vote on this. I'm still watching for Pete's and Joe's ICLAs to come
in but something seems to have gone wrong there. Once these two things
are done we can follow down the process described at [3]. Manuel is
working to port the AFP renderer to FOP Trunk in order to prepare it for
the import.


Good work Manuel and Jeremias!

An AFP Renderer will be a fine addition to FOP's capabilities.

+1 from me.

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta

[Chris Bowditch]

Jeremias Maerki wrote:

+1 from me, obviously.

I'm not sure if it will really be the Easter weekend. It depends on the
weather. :-) Help on updating the FOP website and the distribution
mirror (FOP and setting up Commons) is welcome. I count on Andreas
handling the announcements after the release. Thanks! :-) So, any
volunteer please get to me so I can coordinate. Last time, Christian and
I were coordinating the end-game (release build, upload, verify) through
IM (Skype preferred) which was very helpful. My IM coordinates are on my
website.


+1 from me, but I can't offer any help. Sorry

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Vincent Hennebert as new committer

[Chris Bowditch]

Jeremias Maerki wrote:

Simon and I were able too meet Vincent Hennebert in person in Amsterdam
last week. He has already made an impression with his excellent work for
the GSoC. He's a very nice and intelligent guy, eager to learn and to
work on FOP. Another guy who's not afraid to jump into the depths of the
layout engine.


Its very well deserved. Don't forget before GSoC, Vincent also 
engineered a patch to integrate FORayFont into FOP.




Since the GSoC he has found a job at Anyware
(http://www.anyware-tech.com), a French company which does a lot of
Cocoon stuff. There, he has the opportunity to work around 50% on FOP
sponsored by the same customer that enabled me to invest so much time
into FOP over the last two years.

I'd like to propose Vincent as an XML Graphics committer (FOP working
set). I believe he will be a good addition to our work force.

Votes only on general@ please.

+1 from me.


+1

Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Board report for November 2006

[Chris Bowditch]

Jeremias Maerki wrote:

I've added the board report for November 2006. PMC, please add/correct
as necessary until Saturday:

http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForNovember2006


Hi Jeremias,

I hope you don't mind but I reworded your report slightly!

Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Apache XML Graphics Commons 1.1

[Chris Bowditch]

Vincent Hennebert wrote:


I'd like to start a vote on releasing Apache XML Graphics Commons 1.1.
The candidate distribution files may be found on the following page:
http://people.apache.org/~vhennebert/
They were created from the following tag:
https://svn.apache.org/repos/asf/xmlgraphics/commons/tags/commons-1_1

If the vote passes they will be moved to the main Apache website, we
will wait 24 hours for the mirrors to catch up, and then announcements
will be sent to appropriate mailing lists.


Good work Vincent1 Is there a readme file that details the changes since 
1.0?


Thanks,

Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Apache XML Graphics Commons 1.1

[Chris Bowditch]

Vincent Hennebert wrote:


Chris Bowditch a écrit :




Good work Vincent1 Is there a readme file that details the changes since
1.0?



Thanks! Yes Jeremias updated the README file at the root of the project
when preparing the release in November. BTW, thanks for that Jeremias
because there wasn't much more left to do than the merges of the changes
in the trunk and the 1.1 branch.


+1

Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fw: [VOTE] Release of FOP 0.93

[Chris Bowditch]

Simon Pepping wrote:


As Clay rightfully pointed out, I should have initiated the vote on
general@xmlgraphics.apache.org, since this is a PMC vote. I am doing
it herewith. On fop-dev@xmlgraphics.apache.org, where I started this
vote, Chris, Clay and Andreas have responded with a +1 vote.


+1 from me.

Chris





-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release of FOP 0.93

[Chris Bowditch]

Simon Pepping wrote:


On Fri, Dec 29, 2006 at 10:55:22AM +0100, Jeremias Maerki wrote:


+1 in general, but there's a little bug in the dist: fop.bat doesn't
contain the right filename for xmlgraphics-commons.jar after the JAR
update. Don't know if this needs to be fixed. At least it will have to
be documented as a known issue. Novice users on Windows will certainly
stumble over it not knowing what to fix. :-(


Well spotted Jeremias. Can I change my vote to -1 for this release now?




I think users should not be confronted with such a problem. Although
it is small, it is a stumbling block. Even experience users will be
unpleasantly surprised, and it will cost time to find the
cause. Therefore I would like to fix that. I propose to fix it in the
tag. I will update the tar and zip files. This means that the
signature and md5 files will be regenerated. How does that affect the
vote?


We will need to redo the TAR, ZIP and MD5 files and redo the vote. :(



Alternatively, we publish this release, mentioning the issue in the
announcement, and replace it with a patched release next week. Less
nice.


-1. It will cause too many complaints from users and create more work 
for us.


Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release of FOP 0.93

[Chris Bowditch]

Simon Pepping wrote:




Herewith I start a vote on this release. The vote will end in 72
hours, that is, on Sunday 7 January 2007 at 0.00hrs UTC.

If the vote passes the release files will be moved to the main Apache
website, we will wait 24 hours for the mirrors to catch up, and then
announcements will be sent to appropriate mailing lists.


+1 from me.

This time I downloaded the binary dist and ran simple.fo through and it 
worked ok!


Thanks,

Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Jay Bryant as new committer

[Chris Bowditch]

The Web Maestro wrote:


Howdy folks,

Jay Bryant has been an active member of the Apache XML Graphics
Project's fop-users@ and fop-dev@ communities for the last few years.

Aside from frequently answering newbie questions, he also submits
actual xsl-fo code to help. I'm also excited to note, that Jay
recently posted a note showing a desire to add Named Destinations for
all IDs [1]!

I'd like to propose Jay as an XML Graphics committer (FOP working
set). I believe he will be a solid addition to our work force.

Votes only on general@xmlgraphics.apache.org please.



+1.

Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] New component: DSC parser/processor

[Chris Bowditch]

Jeremias Maerki wrote:




I hope that explains what I've built. I'd like to ask if anyone has any
reservations about my adding the DSC parser to XML Graphics Commons.
After all, it's a rather large and completely new thing and therefore I
thought it necessary to ask before committing. It's probably a lot less
interesting for Batik, but it is for FOP. Since it is designed to be
used separately from FOP I thought it was best to put it in Commons.
I've also already built the resource optimization functionality for FOP
that uses the DSC parser. I can commit those changes (Commons and FOP)
as soon as we know that nobody objects.

I've made a patch containing the DSC parser available (including full
javadocs, an example and minimal documentation for the website), so you
can see what exactly we're talking about:
http://people.apache.org/~jeremias/xmlgraphics-commons-dsc-new.diff.txt


+1 from me for adding the DSC parser (obviously).


Good work Jeremias! +1 from me.



Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Google Summer of Code

[Chris Bowditch]

Vincent Hennebert wrote:


Hi All,

Jeremias Maerki a écrit :


It seems you have picked it up already. The Wiki page for the project
ideas is up: http://wiki.apache.org/general/SummerOfCode2007

If any FOP committer wants to mentor a FOP-related project, now's the
time to step up. I won't have time this year.

Deadline is March 12 I think.



Well this deadline is for the ASF to apply as a mentoring organization
IIC. If we want to propose projects we can still update the Wiki page
later. Last year I added a proposal for before-floats on that page in
end of April.

Having benefitted from mentoring last year I would have no objection to
be myself a mentor this year. Right now I don't have project ideas in
mind, but if a student comes up with a proposal I'd be happy to mentor
her/him.


One project I was considering submitting is the refactoring of the 
logging, i.e. separating out user feedback and developer debugging into 
2 separate mechanisms in a thread safe way. Not the most exciting of 
projects, but one that definitely needs to be addressed. Also one which 
whilst it touches most class files (and therefore gives the student an 
idea of how FOP works), it doesn't involve solving complex layout 
problems for which the learning time is very large.


Last year we saw how long it took Patrick just to get to grips with the 
table layout code and this meant there was very little time left for him 
to actually implement something. So whilst complex layout problems might 
be more interesting for the student, they have the risk of not being 
completed within the allowed time frame.




Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CAN YOU HELP ME

[Chris Bowditch]

ayadi ines wrote:
i want 2 generate a pdf .So i find the ExampleXML2PDF in fop-0.93\examples\embedding\java\embedding ,but when i run  the class it makes this exception 


javax.xml.transform.TransformerException: org.apache.fop.apps.FOPException: Error(Unknown 
location): No element mapping definition found for (Namespace URI: 
"http://xml.apache.org/fop/extensions";, Local Name: "destination")


First of all, I should point out that this is the wrong mailing list for 
asking questions about running FOP. In future please post such questions 
to the [EMAIL PROTECTED] list.


Now to your problem. The problem is in your FO which has the extension 
element "fox:destination" This was an extension specific to the 0.20.5 
release of FOP. In 0.93, this extension has been superceded by the 
XSL-FO element fo:bookmark. The 1.1 revision of the XSL-FO 
recommendation introduced this new element to satisfy the common 
formatting requirement.


So you will need to change your FO, replacing fox:destination elements 
with fo:bookmark equivalents.




Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JAXP missing on JDK1.3 ant build

[Chris Bowditch]

Vincent Hennebert wrote:


Jeremias Maerki a écrit :


I guess I never noticed that because I just install JAXP in Ant's lib
folder. The dependency is documented in lib/README.txt so those very few
who are going to compile Commons themselves on 1.3 will really not mind
so much, I think. But bundling JAXP would mean increasing the
distribution size a lot. And since we're likely moving away from 1.3 in
the near future, I don't think it's worth the trouble. But that's just
my opinion.



Speaking of that, BTW, why couldn't the "near future" actually be just
now? I remember we spoke of that on fop-dev a few months ago, and
basically agreed upon dropping 1.3 support after the 0.93 release, and
after having made a poll on fop-user. I think it's time to do it. Any
negative opinion?


Yes I remember the same discussion and thought we had finally decided to 
drop support for 1.3 too. I think its about time we did, so +1 from me.




Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP 0.94

[Chris Bowditch]

Vincent Hennebert wrote:


Hi guys,

Title says it all. FOP 0.93 was released the 9th of January. I think
it's time to release the next version, as many bugs have been corrected
and many exciting new features added.


Including collapsing border model ;)



Anyone against a new release?


No, I think it makes sense to do another release. Although we still cant 
name it 1.0 as we previously agreed that we should fix the problems with 
changing IPD before doing a 1.0 release.




I'd volunteer to deal with all the release process... unless someone
volunteers even more! However, I would gladly accept any help regarding
updating the documentation.


+1 from me.

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release XML Graphics Commons 1.2

[Chris Bowditch]

Vincent Hennebert wrote:


Here's my +1.


+1 from me.

Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release FOP 0.94

[Chris Bowditch]

Vincent Hennebert wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I’d like to launch a vote for releasing version 0.94 of Apache FOP. The 
candidate distribution files were created from the following tag:

https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_94/
They may be found on the following page: http://people.apache.org/~vhennebert/


Hi Vincent,

thanks for preparing the release. I did a fresh SVN Check out from the 
0.94 tags and built fop.jar. I ran the jar through the same tests that 
revealed the memory leak from a few weeks ago and the tests completed 
without memory increasing, so Jeremias/Andreas' fix has made it into the 
branch and no new memory problems have found their way into the 0.94 branch.




Given the importance of this release, I’d be grateful if as many people 
as possible could check that everything is OK. I’ll make the vote end on 
Thursay 23rd August, 12:00 CEST (10:00 UTC).


Votes only on general@ please.


+1 from me.

Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [?? Probable Spam] Moving JEuclid into Apache XMLGraphics as incubator

[Chris Bowditch]

Max Berger wrote:

Dear XMLGraphics Team,

it has been my wish for a while to integrate the JEuclid (
http://jeuclid.sf.net/ ) project as a subproject of xmlgraphics. In
the last year the project was revived and now consists of three active
developers, who are willing to continue to donate their time to make
the this THE MathML  Java implementation available on the net. The
recent release of a stable version has (re-)sparked the interest of a
diverse user-group, most of them developers themselves. The upcoming
release of the MathML 3 spec gives new directions for further
development.

Moving the code two Apache would serve several purposes:

First, the Apache brand is known for reliability and stability. The
Apache name stands for trust - Any project under the name Apache
received far more attention, and therefore a larger user and developer
base, resulting in a more mature and stable product.

Second, it would guarantee us legal safety. We could rely on the
Apache layer team to ensure that what we are doing is legally correct.

And third, it would allow us for even better integration with the
XMLGraphics core - There are several areas where code could be shared,
and reused rather than redeveloped. An example would be CSS support,
which is already superb in Batik, but non-existing in JEuclid. But
even simple items, such as parsing of color string do not have to be
re-invented for every subproject.

Of course, there are several issues to be solved on the way - the
first one would be if the xmlgraphics project would be willing to be
our sponsor, and thus this email. The second issue is that, should you
vote to accept this project, we'd need a Champion, who has to be part
of the PMC of the Sponsoring project (xmlgraphics).

Please feel free to comment and ask questions.


A big +1 from me. I think JEuclid is a great fit for the Xml graphics 
project and totally agree with the benefits thats you've listed. 
However, as Jeremias points out in his reply in April 2006 this would be 
a lot of work for someone to champion. I don't have the time or know how 
to help.


Chris




-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRAFT] Preparing a user poll for JDK 1.3 compatibility

[Chris Bowditch]

Jeremias Maerki wrote:


I said earlier that I want a user poll and a vote before changing the
minimal JDK version to support for FOP (and Batik). Now that I have more
time for XML Graphics again, I should probably follow up on that. I
would like to set up one of those online surveys to get some feedback
from the users prior to the vote. I'm thinking about putting up the
following questions:






Any other questions you want answered? Any objection to taking Batik and
Commons into the same questionaire and make the "Java 1.4 question" a
project vote rather than a subproject vote?


Looks good Jeremias: +1 from me.

I wouldn't want to add any extra questions though. If the questionnaire 
is too long, people wont bother to fill it in. I think its about as long 
as it can be without scaring people away.


As well as posting up the pool on fop-users, it might be an idea to have 
a large link to the poll just above the download link to encourage as 
much feedback as possible.


Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRAFT] Preparing a user poll for JDK 1.3 compatibility

[Chris Bowditch]

Vincent Hennebert wrote:


Cameron McCormack a écrit :



 http://java.sun.com/j2se/1.4.2/

So that’s only 9 months away.



Man, I didn’t realize this was so near. And I’d love to see enums and 
generics getting their way in the codebase, that would really ease our 
work.


There will probably be one FOP and Batik release before EOL is reached, 
and where we should keep 1.4 compatibility. Then if Sun abandons 1.4 
support I don’t see why we shouldn’t do the same.


Sorry to spoil the party, but I would be against such a move in the 
medium term. There are too many old servers and mainframe systems out 
there that are used for batch processing that cannot be upgraded. 
Getting them onto 1.4 is hard enough, with the older OS' requiring a 
long list of patches to be applied.


Now if FOP's main audience wasn't a batch processing environment then I 
feel there would be a strong case to jump to 1.5, but because it is 
mostly used in batch processing and because most large organisations 
have a lot of older mainframes and unix systems that cannot be easily 
upgraded to run Java 1.5 then FOP would lose a large % of its users by 
doing the switch.


Still the user poll will help confirm or deny that I guess :-/

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRAFT] Preparing a user poll for JDK 1.3 compatibility

[Chris Bowditch]

Jeremias Maerki wrote:

Thanks for all the feedback on the survey draft. I've tried to
incorporate everything as far as was possible with the tool I've chosen.
The survey is now launched. I'm curious about the data we gather.


Thanks for doing this Jeremias!

In addition to sending out the link to the mailing lists I think a link 
from the download page of the website would be extremely useful.


Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Adrian Cumiskey for Committer

[Chris Bowditch]

Fellow Committers,

I feel the time has come to promote Adrian to committer status. Adrian 
has submitted more than a dozen patches over the last 9 months. Amongst 
those patches are some significant features that really push FOP foward, 
e.g. auto Font Detection and PS Extensions for better duplex control and 
Print Bureau integration.


He has also been a regular poster on fop-user and dev since January 
(http://marc.info/?l=fop-user&m=116896952132526&w=2)


The FOP project is in need of good active contributors like Adrian. And 
if he is promoted to committer status, the rest of the team can spend 
less time processing patches and more time focused on developing FOP. So 
here is my vote:


+1

(Votes only on general@xmlgraphics.apache.org please.)

Well done Adrian! Keep up the good work!

Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Adrian Cumiskey for Committer

[Chris Bowditch]

Manuel Mall wrote:


On Wednesday 10 October 2007 22:35, Chris Bowditch wrote:


I feel the time has come to promote Adrian to committer status.



+1

Clearly well deserved IMO.


The Vote has been running for 5 days, so it should be concluded:

8 +1s in total (7 binding), 0 +0 and 0 -1, so the vote passes. 3 PMC 
members did not vote.


Well done Adrian!

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Adrian Cumiskey for Committer

[Chris Bowditch]

Chris Bowditch wrote:


The Vote has been running for 5 days, so it should be concluded:

8 +1s in total (7 binding), 0 +0 and 0 -1, so the vote passes. 3 PMC 
members did not vote.


Well done Adrian!


Adrian,

For the next step I need a preferred userid (with some alternatives in 
case that preference is unavailable) A list of all Apache committers can 
be seen here: http://people.apache.org/~jim/committers.html


You're ICLA is already on file, so no action is required there.

Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Adrian Cumiskey for Committer

[Chris Bowditch]

Adrian Cumiskey wrote:


Hi Chris,

My preferred userid is acumiskey, if this is not available (due to some 
bizarre scenario..) then I will take ajc.  I'm looking forward to being 
able to make further contributions in the future :).


Thanks for that Adrian - I have submitted your account request and you 
should get access in a few days. In the meantime, you might find the 
following pages helpful:


http://www.apache.org/dev/#committers

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Going for 1.4 or 1.5 as minimum Java version?

[Chris Bowditch]

Jeremias Maerki wrote:


No reactions so far. Interesting. Anyway, based on the user poll, my
opinion is to go for Java 1.4 for the moment and reevaluate Java 1.5
next summer. I mean I'd love to use generics and java.util.concurrent
but I think it is just a bit too soon to drop 1.4.


I agree. I don't want Java 1.4 dropped yet because of the type of 
environments where FOP will typically be used, i.e. Batch Processing 
environments which are often old mainframes, e.g. AS/400, or other older 
and less popular Unix flavours. Most of these older environments simply 
cannot be upgraded to newer JDKs and by excluding them we are making 
people either stay on older releases of FOP or losing potential users. 
Neither scenario sits well with me, and I fail to see the real benefit 
that generics gives us. I can still implement new functionality without 
them, no?




Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Dropping Java 1.3 support for Apache XML Graphics (lazy vote)

[Chris Bowditch]

Jeremias Maerki wrote:


Considering that we've already talked this to the ground, I would only
like to wrap this up with a vote for record keeping. I propose this to
be a lazy vote as it seems we have a major consensus here, i.e. there's
a 72 hour period for anyone who hasn't spoken up, yet, to place a -1 (veto,
explanation mandatory as always in such a case). If there are no vetoes,
the following project decisions applying to the whole of the Apache XML
Graphics Project become effective:

* Support for Java 1.3 for the Trunk of all our subprojects is dropped.
Java 1.4 becomes the new minimal Java level.
* New releases from the main development branch (usually Trunk) will be
made without support for Java 1.3. Java 1.4 becomes the new minimal Java level.
* When Sun ends the end-of-life process for Java 1.4 next year we will
restart the discussion about dropping support for Java 1.4 and instead
going for Java 1.5.


+1 from me.

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Max Berger for Committer

[Chris Bowditch]

Fellow Committers,

As you all know Max Berger is heavily involved with the JEuclid MathML 
project. However, he has also been active on fop-dev. A quick search of 
the archives shows his first post to fop-dev was over 12 months ago [1]


More importantly Max has submitted several high quality patches. Most 
recently support for compressed SVG or SVGZ. I therefore feel that Max 
would be a great addition to the FOP committer team.


Heres my +1

Chris

PS: Votes to general@ please

[1] http://marc.info/?l=fop-dev&m=114204448814129&w=2



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE RESULTS] Max Berger for Committer

[Chris Bowditch]

Hi All,

the vote has been open for 4 days, so I'm now closing the vote.

6 PMC members voted +1, 3 non binding +1s (4 if you count 1 on fop-dev), 
there were no other votes.


The vote passes. Congratulations Max!

Max - to create your account I need the following:

1) An ICLA on file. Looking at [1], I think you may have already 
submitted one under the name "Maximilian Berger" If so, the account 
creation process will be shorter :)
2) A preferred user id with at least 1 alternative Id. Check [1] to see 
the list of all current user ids, so you don't ask for one thats already 
taken.


Whilst you are waiting for your account to be setup, it would be a good 
idea to make yourself familiar with [2] and [3]


Thanks,

Chris

[1] http://people.apache.org/~jim/committers.html
[2] http://www.apache.org/dev/new-committers-guide.html
[3] http://www.apache.org/dev/committers.html



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE RESULTS] Max Berger for Committer

[Chris Bowditch]

Jeremias Maerki wrote:


On 30.10.2007 09:58:32 Chris Bowditch wrote:


1) An ICLA on file. Looking at [1], I think you may have already 
submitted one under the name "Maximilian Berger" If so, the account 
creation process will be shorter :)



Yes, that's him. The mail address matches. The ICLA is on file.


Thanks Jeremias!

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fw: [DISCUSS] PDFBox proposal

[Chris Bowditch]

Jeremias Maerki wrote:

Hi Jeremias,

sorry for the slow reply.


Yesterday, we've discussed a possible incubation of PDFBox at the ASF.
There are several projects that are interested in such a move. For us
here in the XML Graphics project, PDFBox is interesting due to its
parsing functionality. Our own PDF library doesn't have that
functionality and is instead optimized for writing PDF which PDFBox
isn't.


I agree PDFBox would be a useful complimentary library to our own.



As you may know, I've implemented a FOP plug-in that allows embedding of
PDF in newly generated PDF documents through XSL-FO. Using the same PDF
library for both tasks would be beneficial in the long-term.


Yes agreed.



Please take a look at the incubation proposal (link below) we're
currently writing. I have some questions to the XML Graphics community
in this context:

- Should the XML Graphics PMC be the sponsoring entity? [1]


Yes, but I don't have any time to support such a process.


- Can anyone besides me imagine investing time/resources to help with
the incubation, teaching PDFBox additional tricks like we need them?


Sorry I just don't have enough time to help.


- Can we imagine PDFBox becoming a subproject of XML Graphics after
successful incubation? PDF is not really an XML technology but deals
with graphical output. Newer technologies like XPS (Microsoft's XML
paper specification) and Adobe's Mars are XML-based paged document
formats. Not that they play a big role in the market, yet.


I am starting to hear clients talking about XPS.



[1] Makes sense if we have a strong interest in PDFBox. If it's just me,
then it doesn't make sense and we're going to find a different solution.

Please note: We have some functionality overlap between our PDF library
and PDFBox in any case. Examples:
- Writing PDF (org.apache.fop.pdf)


Since our library is optimized for this, we probably should just leave 
the writing to FOP's PDF Library.



- Parsing fonts (org.apache.fop.fonts, org.apache.batik.svggen.font.table)
- Font conversion (org.apache.batik.svggen.font)
- XMP metadata (org.apache.xmlgraphics.xmp)
- Image loading (org.apache.fop.image, org.apache.batik.ext.awt.image.spi)

BTW, the above table shows some spots where we could actually discuss
better cooperation within XML Graphics, i.e. between Batik & FOP.


Merging the other packages will be more of a challenge to ensure the end 
result has the best that all projects have to offer.




Thoughts?


I vote +1 in favour but as already mentioned I can't help in this process.

Chris





-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept XML syntax highlighting component grant

[Chris Bowditch]

Cameron McCormack wrote:




Tonny’s software grant form has been received, and I’m in the middle of
filling out the IP Clearance form.

+1 from me, of course.


+1

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP's new image package in Commons?

[Chris Bowditch]

Jeremias Maerki wrote:


Another important point to consider here:
The image package currently makes extensive use of Apache Commons
Logging like the rest of FOP. XML Graphics Commons still doesn't use
Commons Logging. With the migration of the PDF and EPS transcoders to
Batik a lot more code with references to Commons Logging will be
affected. Seems to me the right time to talk again about this dependency.
Would it be so bad if Commons (and, as a consequence, Batik) added this
new dependency? Is there some room for discussion and reevaluation?


Good point. I would hate to lose logging from these areas of code in 
addition to the bits we've already compromised on. Logging really helps 
to debug awkward issues AND is currently used for user feedback 
(although that should be changed at some point!)





Key features of the package:
- Image preloading: format detection and reading the intrinsic size of
the image without loading the whole image into memory (works for most
images).
- Unified API for all kinds of images.
- Image conversion facility: bitmap->Java2D, Java2D->bitmap, bitmap->PNG,
WMF->Java2D, SVG->Java2D
- Image consumers can simply tell the package what kind of images it
supports and the image library tries to provide the image in the best
possible format (possibly using automatic image conversion).
- Currently supported: All bitmap formats supported by ImageIO codecs,
SVG/WMF through Batik, EPS (only usable for PostScript output without a
PostScript interpreter in the back)


If the image package uses Batik does that mean a dependency on Batik 
from commons?



- Custom image loaders and converters can be dynamically plugged in.
- Image cache (using soft references)


Good work Jeremias. The new image package is very comprehensive and the 
idea of using it in other packages is a good one and therefore I would 
vote +1 for such a change (pending a positive answer to my question 
above :))


Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Merge new image loading framework into Trunk

[Chris Bowditch]

Jeremias Maerki wrote:

As proposed, I'd like to call for a vote to merge the new image loading
framework I originally wrote for FOP into XML Graphics Commons Trunk.
The code is found mainly in the org.apache.xmlgraphics.image.loader
package in the following branch:
https://svn.apache.org/repos/asf/xmlgraphics/commons/branches/TempNewImagePackage

I'm aware that in the current state it is not fit for adoption by Batik,
yet. But I'm confident that with a smaller effort it can be made so.
After all, that wasn't my primary focus, as at the beginning I thought
only FOP could use this and I designed it that way. It's all the more
exciting if Batik or even external projects/products find it useful.

+1 from me for the merge.


Good work. +1 from me too.

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release XML Graphics Commons 1.3

[Chris Bowditch]

Jeremias Maerki wrote:


After fighting a lot with my Ubuntu installation, I finally managed to
build Commons correctly. I thought I'd call it 1.3 from the beginning as
it's no big deal IMO if we have to do a bugfix release after the FOP RC.
Not many people will test this release separately anyway. I realized we
didn't talk about that but I didn't want to put this off any longer.

The release files is built from:
http://svn.apache.org/repos/asf/xmlgraphics/commons/tags/commons-1_3/
(revision 633259)

The files are found here:
http://people.apache.org/~jeremias/xmlgraphics-commons/preview/

abc8c7bf88320da1a374e44df25b0789  xmlgraphics-commons-1.3-bin.tar.gz
43d4eba6f99628353cf508a5588f62b2  xmlgraphics-commons-1.3-bin.zip
cf2af2e250af4422d48cdaf53aeffaf4  xmlgraphics-commons-1.3-src.tar.gz
bc992022828509aa84c945ca8671713c  xmlgraphics-commons-1.3-src.zip

Please review and cast your votes.

+1 from me.



Good work. +1 from me.

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java

[Chris Bowditch]

Jeremias Maerki wrote:


Hi Vincent,

these alternatives are only taken as a last resort before mentioning
that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
Otherwise, I wouldn't have made the change. The change is also not about
replacing minus for a hyphen, but for the other way around. I can of
course add a warning if an alternative glyph is used. But I guess some
people would find the warning welcome while others might find it a
nuisance. Can we get some additional opinions to reach an informed
decision, please?


Thanks for the explanation. I was also thinking about this yesterday 
afternoon. I don't like the idea of the warning, because that makes 
users think there is something wrong when in fact there isn't but maybe 
an info level event instead to help make the process more transparent.


Does this glyph relationship apply to XSL-FO and SVG Text or just SVG 
text? I think making the whole SVG Text process more transparent would 
really help as it seems quite mystical. I know you made some further 
notes on this process yesterday, but some more details about Font 
substitution and glyph relations would be useful.


BTW, XEP does the same glyph substitution, so I guessed there must be 
some standard dictating this behaviour.


Regards,

Chris



On 02.12.2008 12:22:29 Vincent Hennebert wrote:


Hi Jeremias,



Author: jeremias
Date: Mon Dec  1 08:00:50 2008
New Revision: 722108

URL: http://svn.apache.org/viewvc?rev=722108&view=rev
Log:
Added "minus" as an alternative for "hyphen" & Co.


Why? minus has nothing to do with hyphen, and the result is likely to
look terrible. I think I would prefer to have a warning rather than
a silent replacement. Anyway, if a font doesn’t even define a glyph for
hyphen, then I doubt it will define one for the true minus.



Vincent





Jeremias Maerki


-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java

[Chris Bowditch]

Jeremias Maerki wrote:


On 02.12.2008 13:51:06 Chris Bowditch wrote:





I think making the whole SVG Text process more transparent would 
really help as it seems quite mystical. I know you made some further 
notes on this process yesterday, but some more details about Font 
substitution and glyph relations would be useful.



That stuff is not mystical, just complicated because by now we have so
much functionality and support so many different output formats which
all have slightly different facilities. Furthermore, when I refactored
the SVG/PDF text painting I didn't have enough time to improve Batik's
font support so we it would be possible to plug FOP's font support into
Batik. Add to that the fact that, for example, PostScript and AFP still
have inferior text handling for SVG graphics which causes a higher
percentage of SVG text to be painted as shapes.

I'm not sure how to make the documentation much clearer. Font
substitution itself is well documented. I'm hesitant to go in the
details of glyph relations because the best approach would be to
document all the substitutions we make and if that data is not generated
from the same source as the functionality in the code we always risk
losing synchronization. And that's a lot of work for little gain.


You mentioned that Dialog gets translated to Times, why that happens is 
not clear to me. If there are a set of hard coded Font substitutions 
then they should be documented. If it's something the AWT classes do 
then a sentence that says Fonts may be substituted as per rules 
documented in X would be helpful.


You misunderstood me when I said to document glyph substitutions. I was 
thinking more along the lines of a sentence that said "glyphs are 
subject to substitution as per the Unicode standard Annex 14 " or 
similar.


Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java

[Chris Bowditch]

Jeremias Maerki wrote:


On 02.12.2008 18:40:21 Vincent Hennebert wrote:


FWIW, I am happy with the glyph substitution the way Jeremias has 
implemented it.





Hi Jeremias,

Jeremias Maerki wrote:

Plus, while it makes sense to replace
minus-sign with hyphen-minus when minus-sign is not available, the other
way around is not acceptable. Anyway, since in practice this will
probably never happen, the whole thing can probably be simplified.



Not acceptable under whose authority? You're stating your opinion.

Hey, this is just a mechanism that tries to get a reasonable result if a
glyph in a font is missing. If someone is not happy with the result,
he's free to use a different font.


This is exactly the use case I'm concerned about. Font designers doing 
things the user doesn't expect. I think it would be unfortunate if FOP 
blindly followed a spec in this case at the detriment of the user. It's 
not easy to get a Font changed.


Thanks,

Chris



-
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mailing List Moderation

[Chris Bowditch]

Jeremias Maerki wrote:

Hi Jeremias,

I'm happy to volunteer for this as I check the lists a few times a day. 
However I don't check at weekends, so maybe not quite good enough?


Thanks,

Chris


Houston, we have a problem (I think). Posts don't get moderated within
reasonable time lately when I'm not around. The Batik side is pretty
much OK but not general@ and the FOP side. When I was away for a week in
January, a number of posts piled up. And the two posts I've just
moderated through were in the queue for almost 24 hours. Yes, that's
probably not much (and I might have high expectations here) but since
it's not the first time it makes me a bit concerned. Therefore, can I
ask for one or two additional moderators? And would the existing
moderators please ask themselves if they still have time to do this?
It's no shame to say that you don't have enough time to still be a
moderator. Circumstances change. I'm just trying to make sure that
moderation works even if I'm not constantly monitoring my mail account.

Thanks a lot,
Jeremias Maerki


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org








-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Mailing List Moderation

[Chris Bowditch]

Jeremias Maerki wrote:


I can't remove you but I've placed the request.

A hint for the new moderators: 
http://apache.org/dev/committers.html#mail-moderate
contains some resources around mailing list moderations. The most
important part: you can simply ignore spam mails, you just have to
actively accept the good ones.


Thanks Jeremias - the link is helpful.

Chris





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Image Cache: behaviour for failed URIs

[Chris Bowditch]

Jeremias Maerki wrote:


I've been made aware that the current way failed URIs are handled in the
image cache may not be ideal: If a URI is only temporarily unavailable,
the image identified by this URI will remain invalid until the JVM is
restarted or the cache is cleared explicitely.

The reason for the failed set is that FOP accesses an image twice for a
single document (FO stage and rendering stage). For a slow connection,
that would slow down the formatter quite a bit.

How about this? Each entry in the failure set gets a time stamp and a
timeout will invalidate the entry, forcing a retry next time the URI is
accessed. The timeout could be set to 0, which would effectively disable
that failed set. A value > 0 would set the timeout to n seconds. And a
negative value equals to infinity which would represent the current
behaviour.


I like this proposal, so +1.

Just to provide some context, imagine you are batch processing 1000 
documents and they all use the same image. If the images are served by a 
remote servlet and a network glitch causes the 500th document to fail to 
retrieve the image then documents 501-1000 will all fail. Really only 
document 500 should fail.


Providing such a configuration setting lets the user decide whether to 
scarifice performance in favour of robustness.




If nobody sees a problem with that I'll implement that shortly.


Thanks,

Chris




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Thanks to Jeremias

[Chris Bowditch]

Jeremias Maerki wrote:

Woah, I'm totally blushing here. Thanks a lot! That was very unexpected.


I concur with Simon that a deep hearted thanks is owed to Jeremias by 
all those who benefit from FOP (myself included). Thanks for all those 
magnificant features you have implemented over the years.


Thanks,

Chris



Let me then just take the occasion and thank Simon again for stepping up.
I know the various places and things the PMC chair has to know can
probably be overwhelming at first but it's really just half as bad. I'll
be there to help out should you need it.

On 25.05.2009 22:26:38 Simon Pepping wrote:


Hi,

I want to take this occasion to look back at the large role Jeremias
played in XML graphics and FOP over the last few years.

When Jeremias started to work full-time on FOP (Jan. 2005), the
project had not seen a release for a couple of years. The old release,
0.20.5, was still the stable release used by thousands of users. We
had received the Knuth algorithm for FOP from Luca Furini, but a
number of important features were still lacking. Jeremias' first task
was the implementation of tables. Next he implemented a few other
important features that were still lacking, and made the new FOP code
ready for its first release. This release was numbered version
0.90alpha1 (23 November 2005), and was followed by more or less
regular releases up to the current version 0.95.

Jeremias contributed many other features. First of all a test
framework based on the intermediate area tree (XML renderer). Together
with Luca he implemented the Knuth algorithm for page breaking. He
added PDF/A-1b support, complete with XMP handling (in XML Graphics
Commons). He developed the FOP factory, which improves reuse of
configuration data on subsequent FOP runs in the same application. He
added an event notification mechanism, which decouples event
notifications for users from logging for developers. He added another
intermediate area tree mechanism (MIME_FOP_IF), which adds speed gains
and a new interface for rendering. He added many improvements in image
handling, a.o. a new image loading framework.

Much of this work could be done because Jeremias tirelessly worked to
interest a number of corporate users of FOP in contributing to the
project.

Jeremias also initiated and advocated the creation of the XML Graphics
project as a top level project in the ASF, comprising FOP and Batik
(Oct. 2004). Since the creation he has been its champion and the chair
of its PMC. He was elected a Member of the ASF in December 2004.

Jeremias is a creative and passionate developer, with a great
knowledge and understanding of page description languages like PDF and
PostScript, of printing, computer graphics and image formats. Passions
have their ups and downs. In a serious downturn Jeremias decided to
step down as PMC chairman, and more importantly, take a time-out from
FOP development. This is a great loss for the project, and I hope he
soon regains his pleasure in XML graphics and FOP development. I thank
Jeremias deeply for all his contributions.

Simon Pepping
home page: http://www.leverkruid.eu





Thanks,
Jeremias Maerki


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org








-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Status report for August 2009

[Chris Bowditch]

Vincent Hennebert wrote:

Hi Simon,


Hi Simon, Vincent,



The report looks good. Just a thing about the ChangingIPD hack: actually
it is still undecided whether it should be merged back to Trunk or not.

My main concern about that is that it will get in the way when
implementing the new approach. I will basically have to start with
reverting all the changes made for the hack.

My idea was to actively maintain the branch in sync with the Trunk.
Releases could then be made from the branch. But this may actually turn
out to be more work than reverting all the changes in one go. Plus it
has been mentioned to me that this may create difficulties for users who
regularly take snapshots of the Trunk (the branch will always lag
a little bit behind).

Any opinion about this is welcome. Meanwhile, I’ll modify the status
report.


Thanks for bringing this up Vincent. I am a little reluctant to be 
working off a branch as we regularly take build snapshots from trunk. 
This creates a lot of extra work keeping the branch in sync.


I think we all acknowledge that the changing IPD hack is just that and 
therefore code quality may be sub optimal. However, since Vincent is 
working on a totally new layout engine then we expect this code to be 
replaced a year or so down the line anyway. Therefore if the only reason 
for not putting this change into trunk is to save effort at the point 
when the new layout algorithm is introduced then I think this hack 
should be merged with trunk. This is because it will be more time 
consuming to do a 100 or so merges over a 1-2 year period than to remove 
changes from trunk in a one time exercise.


Thanks,

Chris



Thanks,
Vincent


Simon Pepping wrote:


The August report needs to be submitted by 16 August. I've
written an initial draft. Please add/fix/update/improve until Friday
15 August night (CET).

http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForMay2009

I tried to get some numbers on activity. I have come up with the
activity on the mailing lists during May, June and July, as can be
derived from the Apache archives:

fop commits: 88
batik commits: 5
xmlgraphics commits: 15 (minus deployment of the web site)
fop-dev: 311
fop-users: 610
batik-dev: 112
batik-users: 243
general: 48

Nice graphs can be seen at markmail: http://fop.markmail.org/,
http://fop-dev.markmail.org/, http://fop-user.markmail.org/,
http://batik.markmail.org/, http://batik-dev.markmail.org/,
http://batik-user.markmail.org/,
http://xmlgraphics.markmail.org/search/?q=#query:list%3Aorg.apache.xmlgraphics.general+page:1+state:facets

Regards, Simon




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org








-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE] Helder Magalhães for Committer

[Chris Bowditch]

The Web Maestro wrote:

Fellow Committers,

As you all know, Helder Magalhães has been actively contributing to
the Batik lists since 2008, helping users and cleaning up bugzilla.

Although Helder hasn't yet exhibited his Java coding prowess, he has
demonstrated a willingness to help others get the most out of Batik,
and for that I'd like his efforts to be rewarded.

The Apache XML Graphics Project, and the Apache Batik Project in
particular, are a better place because of active contributors like
Helder. So here is my vote:

+1

(Votes only on gene...@... please.)

Well done Helder! Keep up the good work!


I haven't followed Batik, so can only vote +0.

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE] Pascal Sancho for Committer

[Chris Bowditch]

Adrian Cumiskey wrote:

Although there haven't been any code contributions of which I am aware,
Pascal has made many contributions to the FOP user mailing lists and
followed up bugzilla entries over a long period of time (number of years).
He has also demonstrated a good knowledge of FOP, XSL:FO and digital
typography in general.  He is a valuable contributor to this community,
maybe committership will inspire some code... :)

So my vote is +1.


+1 from me too. Well done Pascal.

Thanks,

Chris



Adrian.

2009/12/9 Max Berger 


Hi *,

I don't see the advantage of having commit rights if you do not submit
any code. But I do like the answers and bugzilla entries of Sancho.

+0.5

Max

2009/12/9 The Web Maestro :

Fellow Committers,

As you all know, Pascal Sancho has been actively contributing to the
FOP lists since 2004, helping users and cleaning up bugzilla to boot!.

Although Pascal hasn't been actively contributing code, he has helped
many on the FOP & XML Graphics lists, and for that I think his efforts
should be rewarded.

The Apache XML Graphics Project, and the Apache FOP Project in
particular, are a better place because of active contributors like
Pascal. So here is my vote:

+1

(Votes only on gene...@... please.)

Well done Pascal! Thank you for your efforts!

Thanks,

Clay
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org








-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: XML Graphics Commons release 1.4

[Chris Bowditch]

Simon Pepping wrote:

Release for 1.4 is now ready for review and the release vote.


Hi Simon,

thanks for preparing the release. I downloaded the new xgc.jar and built 
fop with it. It built fine and I was able to run some test FOs.


So +1 from me.

Chris



The release files are built from:
http://svn.apache.org/repos/asf/xmlgraphics/commons/tags/commons-1_4
(created in revision 959957).

The release files are found here: http://people.apache.org/~spepping/:

b15d5b4cebd2c7fa04342b6922aa189e  xmlgraphics-commons-1.4-bin.tar.gz
d2b56a1671d2ca63480e38acd9629ea7  xmlgraphics-commons-1.4-src.tar.gz
8715bfe10e8db0fc2bc16bde88178647  xmlgraphics-commons-1.4-bin.zip
d6012008d92c42f2ddc43856fd02b2d5  xmlgraphics-commons-1.4-src.zip
1c36c31e4ffa4a5293828adb41ac8788  xmlgraphics-commons-1.4-bundle.jar

As mentioned earlier, I used the following workaround:

jdk6:  ant distclean, docs
jdk14: ant dist-src, dist-bin (which runs the docs target again), 
maven-artifacts

This uses the trick that forrest is run each time, but does not clean
out its target directory.

For your perusal I uploaded the build log: build-2010-07-02.log

Please, review and cast your votes before Wed 7 July 13:00h UTC.

+1 from me.

Simon




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Switching to Java 1.5

[Chris Bowditch]

Hi All,

On 21/10/2010 06:34, Jeremias Maerki wrote:

I agree its time to move to 1.5 but its too early for 1.6. As Jeremias 
said what are the benefits of 1.6 over 1.5? Better performing JVM is the 
key improvement. If we compile on 1.5 people can still get this benefit 
by running on 1.6.


We have to support a number of cross platform environments and most are 
stuck with 1.5. If we raise the bar to 1.6 then I believe we will be 
turning away a lot of potential users.


Thanks,

Chris


By now, I agree that Java 1.4 as a minimum requirement doesn't make much
sense anymore. We have given people enough of a transition period. Many
Apache projects including many Commons components and also PDFBox have
moved to Java 1.5 in the meantime, raising the bar for people still
lagging behind in their environment.

What I don't support is jumping to Java 6 just now. Most Apache projects
have moved from 1.4 to 1.5 but not necessarily 6. Platform support for 6
is not yet as good as for 1.5. Plus I'd like to hear why 6 is supposed
to be technically better for XML Graphics (on the class library level,
not the JVM). A few new convenience methods alone don't warrant the jump
and the risk to alienate certain users.

On 20.10.2010 20:53:28 Vincent Hennebert wrote:

Hi,

The topic has already been mentioned several times in the past, at least
in the FOP area. The latest discussion we had was in August 2009:
http://markmail.org/message/y7iwptehnzujcuxm
It was decided then to release FOP 1.0 with Java 1.4 support, and do
a user community poll shortly afterwards.

More than a year has passed now and I’d like to re-visit that topic,
with two modifications:
• make the decision at the project level. Homogenizing things a bit
   wouldn’t hurt IMO. Specifically, Commons and FOP Trunk would switch to
   1.5 now, Batik would switch after the 1.8 release (which is about to
   happen IIUC).
• I’m not sure that a poll still is necessary. It’s been almost 2 years
   now that Java 1.4 has reached end of life. We are in the same
   situation as when we dropped support for Java 1.3.

Moreover, I think sticking to 1.4 is a growing impediment to the
development of the project. Simon ran into trouble when releasing 1.0:
http://markmail.org/message/ivlwk2dcmuk25woy
Proper internationalization can only be achieved starting from 1.5:
http://markmail.org/message/6n2w5tefarqp76iv
We recently upgraded Checkstyle to version 5.1 in FOP and that requires
Java 1.5.

Using retroweaving tools is doable but adds complexity to the build and
is a hassle that I don’t think we can live with due to our limited
resources.

I think it’s time to move on. If anybody really feels that a user poll
still is necessary, please speak up now. Otherwise, just wait a few days
that I launch an official vote on this.

Thanks,
Vincent


Jeremias Maerki


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE] The Apache XML Graphics project to switch to J2SE 1.5 as minimum environment

[Chris Bowditch]

On 25/10/2010 09:38, Jeremias Maerki wrote:

[X] +1 Approve J2SE 1.5 as minimum environment



-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE] Peter Hancock for committer

[Chris Bowditch]

Fellow Committers,

As you all know Peter Hancock has been actively participating in the 
mailing lists since 2009, see: 
http://marc.info/?l=fop-user&m=125778454424550&w=2


Peter has also submitted several patches, some of which have been 
committed. A quick search of bugzilla identified the following patches 
submitted by Peter: 48636, 48954, 48955, 49097, 49893, 49913, 50391, and 
50909


Here's my +1

Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE SUMMARY] Peter Hancock for committer

[Chris Bowditch]

On 10/03/2011 14:45, Chris Bowditch wrote:

Fellow Committers,


The vote has been running for 5 days now so it's time to sum up the votes.


As you all know Peter Hancock has been actively participating in the 
mailing lists since 2009, see: 
http://marc.info/?l=fop-user&m=125778454424550&w=2


Peter has also submitted several patches, some of which have been 
committed. A quick search of bugzilla identified the following patches 
submitted by Peter: 48636, 48954, 48955, 49097, 49893, 49913, 50391, 
and 50909


Here's my +1


There were 8 +1s, no 0's or vetos.

Congratulations Peter on becoming a committer. Please send me your 
preferred login ID so I can create your account. The following page will 
help with the task of making sure you pick a unique ID: 
http://people.apache.org/committer-index.html


Thanks,

Chris



Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE SUMMARY] Peter Hancock for committer

[Chris Bowditch]

On 15/03/2011 10:39, Peter Hancock wrote:

Thanks for all your votes!

It is a great privilege to join the fantastic team FOP to
work with you all on this challenging project!

I hope my newbie credentials are partially offset by my background in
mathematics (PhD in mathematical biology)
and growing interests in OO and functional sytles of software design.

I wish to go with the highly original login id of phancock.


Hi Peter,

ok - I have submitted a new account request and I will let you know when 
it has been setup.


In the meantime, please read the following: 
http://apache.org/dev/new-committers-guide.html


Thanks,

Chris


Peter

On Tue, Mar 15, 2011 at 10:05 AM, Chris Bowditch
  wrote:

On 10/03/2011 14:45, Chris Bowditch wrote:

Fellow Committers,

The vote has been running for 5 days now so it's time to sum up the votes.

As you all know Peter Hancock has been actively participating in the
mailing lists since 2009, see:
http://marc.info/?l=fop-user&m=125778454424550&w=2

Peter has also submitted several patches, some of which have been
committed. A quick search of bugzilla identified the following patches
submitted by Peter: 48636, 48954, 48955, 49097, 49893, 49913, 50391, and
50909

Here's my +1

There were 8 +1s, no 0's or vetos.

Congratulations Peter on becoming a committer. Please send me your preferred
login ID so I can create your account. The following page will help with the
task of making sure you pick a unique ID:
http://people.apache.org/committer-index.html

Thanks,

Chris


Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE] Mehdi Houshmand for FOP committer

[Chris Bowditch]

Dear FOP committers,

Mehdi has submitted dozens of high quality patches and regularly 
participates on the mailing lists. Mehdi is already an official FOP 
Contributor. I propose Mehdi Houshmand as a FOP committer.


I vote +1

Replies to general@ please.

Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE] Mehdi Houshmand for FOP committer

[Chris Bowditch]

On 10/11/2011 14:30, Pascal Sancho wrote:

Hi Pascal,


I vote +1 too.
Note that Peter and I are not in general, so, as Simon did for Glenn's 
vote, I put Peter and I in copy on apache addresses.


Thanks, but as a committer you should be subscribed to general@. You are 
not subscribed to private@ since you are not a PMC member, but that 
doesn't preclude you from general@.


Thanks,

Chris



Le 10/11/2011 15:18, Chris Bowditch a écrit :

Dear FOP committers,

Mehdi has submitted dozens of high quality patches and regularly
participates on the mailing lists. Mehdi is already an official FOP
Contributor. I propose Mehdi Houshmand as a FOP committer.

I vote +1

Replies to general@ please.

Thanks,

Chris





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE SUMMARY] Mehdi Houshmand for FOP committer

[Chris Bowditch]

On 10/11/2011 14:18, Chris Bowditch wrote:

Dear FOP committers,


The vote has been running for 6 days now so it's time to sum up the votes.


Mehdi has submitted dozens of high quality patches and regularly 
participates on the mailing lists. Mehdi is already an official FOP 
Contributor. I propose Mehdi Houshmand as a FOP committer.


I vote +1


There were 6 +1s, no 0's or vetos, so the vote passes.

Congratulations Mehdi on becoming a committer. Please send me your 
preferred login ID so I can create your account. The following page will 
help with the task of making sure you pick a unique ID:


http://people.apache.org/committer-index.html

Thanks,

Chris



Replies to general@ please.

Thanks,

Chris





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE SUMMARY] Mehdi Houshmand for FOP committer

[Chris Bowditch]

On 16/11/2011 09:59, mehdi houshmand wrote:

Hi Chris,


Hi Mehdi,



mehdi isn't taken, so if you could set me up with that ID.


Sure, we will request "Mehdi" as your ID


Thank you all for your positive messages, I'll endeavour to ensure FOP
remains the high quality product you have developed.


Whilst you are waiting for your account to be setup, I suggest you have 
a read through the following page:


http://apache.org/dev/committers.html



Mehdi

Thanks,

Chris




On 16 November 2011 09:35, Chris Bowditch  wrote:

On 10/11/2011 14:18, Chris Bowditch wrote:

Dear FOP committers,

The vote has been running for 6 days now so it's time to sum up the votes.

Mehdi has submitted dozens of high quality patches and regularly
participates on the mailing lists. Mehdi is already an official FOP
Contributor. I propose Mehdi Houshmand as a FOP committer.

I vote +1

There were 6 +1s, no 0's or vetos, so the vote passes.

Congratulations Mehdi on becoming a committer. Please send me your preferred
login ID so I can create your account. The following page will help with the
task of making sure you pick a unique ID:

http://people.apache.org/committer-index.html

Thanks,

Chris


Replies to general@ please.

Thanks,

Chris









-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Chris Bowditch is the new PMC Chair

[Chris Bowditch]

On 22/12/2011 08:13, Simon Pepping wrote:

Hi Simon,


I am pleased to inform you that Chris Bowditch is the new PMC chair of
the XML Graphics project.





I wish Chris success in this position.


Many thanks for your kind message. Thanks also for your time as PMC Chair.

Thanks,

Chris



Simon Pepping

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Chris Bowditch is the new PMC Chair

[Chris Bowditch]

On 25/12/2011 19:34, Clay Leeds wrote:

Congratulations Chris! And thank you for your service Simon!

Happy Holidays all, and best wishes for a safe and productive New Year!


Thanks Clay. Happy holidays to you too!

Chris



Web Maestro Clay

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Dec 22, 2011, at 12:13 AM, Simon Pepping  wrote:


I am pleased to inform you that Chris Bowditch is the new PMC chair of
the XML Graphics project.

I wish Chris success in this position.

Simon Pepping

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Board Report

[Chris Bowditch]

Hi All,

We need to submit a report to the board at the start of February. I have 
posted a draft here: 
http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForFebruary2012


Please send me any feedback or comments during the next few days. I will 
submit it next week.


Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Checkstyle, Reloaded

[Chris Bowditch]

On 03/02/2012 21:20, Glenn Adams wrote:

Hi Glen,


which version of checkstyle are you using? there are two errors in parsing
the proposed checkstyle file with 5.1;


Vincent says checkstyle v5.5 was used in his original e-mail.






once i fixed the checkstyle file to work with 5.1, i see that 4935 and
31935 new warnings/errors are introduced in trunk and in my i18n branches,
respectively; clearly, this is going to require a large amount of editing
to allow use of the proposed rules;

I agree that seems way too many new warnings/errors.

Chris


many of the new errors I notice (in both trunk and my i18n branches) have
to do with whitespace before or after '(', ')', and cast operations; i do
not agree with enforcing the presence or absence of whitespace around these
constructs; i happen to always use whitespace before and after parens,
e.g., the following should produce no checkstyle warning:

public int foo ( int a, int b, int c ) {
   return bar ( a, b, c );
};

i would like whitespace after '{' and before '}' in an array
initialization, e.g., both of the following should be permitted:

int[] a = new int[] { 1, 2, 3 };
int[] a = new int[] {1, 2, 3};

i would like SimplifyBooleanReturn to be removed;

i would like whitespace after BNOT produce a warning, e.g. both ! foo and
!foo should be accepted without warning;

i would like whitespace after DOT operator to be permissible, e.g., both
x.y and x . y should be permitted;

i would like empty blocks to be permissible, e.g., the following should be
permitted:

if ( test ) {
   /* TBD - handle test is true */
} else {
   /* TBD - handle test is false */
}

i would like the arbitrary line length rule to be removed; i do not agree
to 110 line length; or if you insist, i could accept 150;

i do not agree with including MultipleVariableDeclarations rule; i
routinely define multiple local variables in one statement, e.g., int x, y;

i do not agree with requiring LocalFinalVariableName to match
'^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$';
instead, it should continue to match the currently used
pattern "^[a-z][a-zA-Z0-9]*$";

why are there two NoWhitespaceAfter rules?

 
   
 

   
   
 

if you fix the above problems, then i will re-run on trunk and my i18n
branch to check if there are any other issues that need to be resolved;

On Fri, Feb 3, 2012 at 10:45 AM, Vincent Hennebertwrote:


Hi All,

it is well-known that people are not happy with the Checkstyle file we
have in FOP. And there’s no point enforcing the application of
Checkstyle rules if we don’t agree with them in the first place.

I’ve finally taken on me to create a new Checkstyle file that follows
modern development practices. I’ve been testing it on my own projects
for a few months now and I’m happy with it, so I’d like to share it with
the community. The idea is that once we’ve reached consensus on the
Checkstyle rules we want to apply, we could set up a no warning policy
and enforce it by running Checkstyle in CI.

I’m also taking this as an opportunity to propose that we adopt a common
Checkstyle policy to all the sub-projects of XML Graphics. So once we’ve
agreed on a set of rules we would apply them to FOP and XGC immediately,
and eventually also to Batik, and keep them in sync.

We would also apply the rules to the test files as well as the main
code. Tests are as important as the actual code and there is no reason
why they shouldn’t be checked.

It is likely that the current code will not be compliant with the new
rules. However, most of them are really just about the syntax, so
I believe it should be fairly straightforward to make the code at least
90% compliant just by applying Eclipse’s command-line code formatter.

Please find the Checkstyle file attached. It is based on Checkstyle 5.5
and basically follows Sun’s recommendations for Java styling with a few
adaptations. What’s noteworthy is the following:

• Removed checks for Javadoc. What we want is quality Javadoc, and that
  is not something that Checkstyle can check. Having Javadoc checks is
  counter-productive as it forces us to put {@inheritDoc} everywhere, or
  to create truly useless doc like the following:
  /**
   * Returns the thing.
   * @return the thing
   */
  public Thing getThing() {
  return thing;
  }
  This is just clutter really. I think it should be left to peer review
  to check whether a Javadoc comment is properly written, or whether the
  lack thereof is justified. There’s an excellent blog entry from
  Torsten Curdt about this:
  http://vafer.org/blog/20050323095453/
• Removed check for file and method lengths. I don’t think it makes
  sense to define a maximum size for files and methods. Sometimes
  a 10-line method is way too big, sometimes it makes sense to have it
  reach 20 lines. Same for files: it’s ok to reach 1000 lines if the
  class contains several inner classes. If it doesn’t, then it’s
  probably too big. I don’t think there is any definite figure we can
  agree on and

Re: Checkstyle, Reloaded

[Chris Bowditch]

On 03/02/2012 17:45, Vincent Hennebert wrote:

Hi All,


Hi Vincent,



it is well-known that people are not happy with the Checkstyle file we
have in FOP. And there’s no point enforcing the application of
Checkstyle rules if we don’t agree with them in the first place.


Agreed.


I’ve finally taken on me to create a new Checkstyle file that follows
modern development practices. I’ve been testing it on my own projects
for a few months now and I’m happy with it, so I’d like to share it with
the community. The idea is that once we’ve reached consensus on the
Checkstyle rules we want to apply, we could set up a no warning policy
and enforce it by running Checkstyle in CI.

Sounds good so far.



I’m also taking this as an opportunity to propose that we adopt a common
Checkstyle policy to all the sub-projects of XML Graphics. So once we’ve
agreed on a set of rules we would apply them to FOP and XGC immediately,
and eventually also to Batik, and keep them in sync.

We would also apply the rules to the test files as well as the main
code. Tests are as important as the actual code and there is no reason
why they shouldn’t be checked.

It is likely that the current code will not be compliant with the new
rules. However, most of them are really just about the syntax, so
I believe it should be fairly straightforward to make the code at least
90% compliant just by applying Eclipse’s command-line code formatter.
I'm not comfortable with that. Automated tools don't always fully grasp 
the code that they are changing, so there is a risk of introducing 
regressions.




Please find the Checkstyle file attached. It is based on Checkstyle 5.5
and basically follows Sun’s recommendations for Java styling with a few
adaptations. What’s noteworthy is the following:

• Removed checks for Javadoc. What we want is quality Javadoc, and that
   is not something that Checkstyle can check. Having Javadoc checks is
   counter-productive as it forces us to put {@inheritDoc} everywhere, or
   to create truly useless doc like the following:
   /**
* Returns the thing.
* @return the thing
*/
   public Thing getThing() {
   return thing;
   }
   This is just clutter really. I think it should be left to peer review
   to check whether a Javadoc comment is properly written, or whether the
   lack thereof is justified. There’s an excellent blog entry from
   Torsten Curdt about this:
   http://vafer.org/blog/20050323095453/
• Removed check for file and method lengths. I don’t think it makes
   sense to define a maximum size for files and methods. Sometimes
   a 10-line method is way too big, sometimes it makes sense to have it
   reach 20 lines. Same for files: it’s ok to reach 1000 lines if the
   class contains several inner classes. If it doesn’t, then it’s
   probably too big. I don’t think there is any definite figure we can
   agree on and blindly follow, so I think sizes should be left to peer
   review.
• However, I left the check for maximum line length because unreasonably
   long lines make the code hard to follow. I increased it to 110
   though to follow the evolution of monitor sizes. But as Peter
   suggested me, we probably want to keep it low in order to make
   side-by-side comparison easy.
• I added a check for the order of imports; this is to reduce noise in
   diffs when committing. I think most of us have configured their IDE to
   automatically organise imports when saving changes to a file. This is
   a great feature because it allows to keep the list of imports
   up-to-date. But in order to avoid constant back and forth changes when
   different committers change the same file, I think it makes sense that
   we all have the same configuration. I modeled this list after
   Jeremias’ one, that I progressively inferred from his commits.

Please let me know what you think. I’m inclined to follow lazy consensus
on this, and apply the proposed changes if nobody has objected within
2 weeks. If anybody feels that a formal vote is necessary, feel free to
say so.


Can you provide a breakdown of the new warnings identified by Glenn by 
rule type? I do object to introducing so many new warnings and I'm not 
comfortable with using automated tools to correct the files, without 
understanding exactly which warnings will be fixed in an automated way.


Thanks,

Chris


Thanks,
Vincent


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Checkstyle, Reloaded

[Chris Bowditch]

On 06/02/2012 22:57, Alexios Giotis wrote:

Hi,


Hi Alexios,


I can't see a point having checkstyle rules and then adding CSOFF on new files 
to disable them. It is faster to read, debug or fix source code when there is  
uniformity rather than every file having the personal style of the initial 
author. It would be helpful to additionally have configurations for popular 
Java IDEs so that developers write code, press the format keyboard shortcut and 
know that the output is acceptable for a patch. Eclipse calls them code 
formatter profiles and they can be exported and imported.


You raise a very good point and I agree that CSOFF isn't a practical 
option. Having CSOFF everywhere in the code adds clutter and makes it 
harder to read. We need to try and reach consenus on the checkstyle 
rules, by abandoning some but not too many of the rules. Glenn, would 
you be able to list the rules you object with in an order of priority, 
with the ones that would inconvience you the most at the top of the list 
with the least annoying ones at the bottom? I think that would help us 
arrive at some sort of compromise.


Related to line length, I would go for a maximum of 100. As already said, there 
is a limit on the amount of information that can be easily understood per line. 
More than this typically indicates methods with too many arguments or deep 
nesting that should be refactored into methods. Also, I really hate working 
with my laptop or going with it to a customer site for support and having to 
horizontally scroll in file diffs.


Thanks,

Chris



Alexios Giotis



On Feb 6, 2012, at 7:58 PM, Glenn Adams wrote:


overall, the i believe the issue of whitespace usage is a matter of
personal style, and should not be subject to strict rule enforcement; as
long as i can use CSOFF to disable rules on source files i create, then i
can accept rules which encode different usage patterns;

i believe it is more important to preserve the style of the original author
of a given source file rather than attempt to follow an arbitrary usage
pattern in this regard; i don't mind using rules that differ from mine when
those source files were authored by those different usage patterns; but i
do not agree with enforcing them in my own style for a variety of reasons:

   - it slows me down
   - it makes it harder for me to read my own code, since i am accustomed
   to reading my style

ideally, i believe you should craft rules that are sufficiently flexible in
the area of personal style choices that accommodate all of our preferences;
however, if it is acceptable to deal with exceptions using CSOFF, etc.,
then that would be sufficient for me

On Mon, Feb 6, 2012 at 10:09 AM, Vincent Hennebertwrote:


Hi Glenn,

Thanks for taking the time to look at this. Looks like we should be able
to reach a consensus without too much difficulty.

On 03/02/12 21:20, Glenn Adams wrote:

which version of checkstyle are you using? there are two errors in

parsing

the proposed checkstyle file with 5.1;

   
   


once i fixed the checkstyle file to work with 5.1, i see that 4935 and
31935 new warnings/errors are introduced in trunk and in my i18n

branches,

respectively; clearly, this is going to require a large amount of editing
to allow use of the proposed rules;

Like I said most of them are purely about syntax and are easily solved
with a code formatting tool. Obviously I’m happy to run such a tool on
your own Git branches and submit a patch if that can help you.


i prefer not to use automatic tools to make fixups in this case for the
reasons that chris outlined



many of the new errors I notice (in both trunk and my i18n branches) have
to do with whitespace before or after '(', ')', and cast operations; i do
not agree with enforcing the presence or absence of whitespace around

these

constructs; i happen to always use whitespace before and after parens,
e.g., the following should produce no checkstyle warning:

public int foo ( int a, int b, int c ) {
  return bar ( a, b, c );
};

I’d rather keep the rule, as it enforces standard Java style that will
be easily recognized by any Java developer. I also find the variation in
the use of whitespace to be one of the most distracting things when
reading code.

That said, if that really bothers you I would be ok with relaxing the
rule, except for the whitespace between a method call and the left
parenthesis, to make it clear that it’s a method call.


i prefer my style of using whitespace;

if you are not insisting that no CSOFF declarations appear in source code,
then I can accept your proposal, provided I can use CSOFF to disable this
rule for source files that i create (for those i didn't create, i can
adhere to the rule)



i would like whitespace after '{' and before '}' in an array
initialization, e.g., both of the following should be permitted:

int[] a = new int[] { 1, 2, 3 };
int[] a = new int[] {1, 2, 3};

Yep, no problem.



i would like SimplifyBooleanReturn to be removed;

Hmmm. 

Re: Checkstyle, Reloaded

[Chris Bowditch]

On 08/02/2012 20:51, Vincent Hennebert wrote:

Hi Chris,


Hi Vincent,



Can you provide a breakdown of the new warnings identified by Glenn by rule
type? I do object to introducing so many new warnings and I'm not comfortable
with using automated tools to correct the files, without understanding exactly
which warnings will be fixed in an automated way.

Here is the list of rule violations that I get when running the new
Checkstyle file on the latest trunk with Checkstyle 5.5:
   1 FinalClassCheck
   1 GenericWhitespaceCheck
   1 NoWhitespaceBeforeCheck
   2 DefaultComesLastCheck
   4 RedundantModifierCheck
   4 RightCurlyCheck
   5 OneStatementPerLineCheck
   8 RedundantImportCheck
   8 RegexpSinglelineCheck
  33 ConstantNameCheck
  37 MultipleVariableDeclarationsCheck
  47 UnusedImportsCheck
  71 EmptyBlockCheck
 113 NewlineAtEndOfFileCheck
 128 NoWhitespaceAfterCheck
 182 LineLengthCheck
 249 ImportOrderCheck
 321 ParenPadCheck
 392 MethodParamPadCheck
 806 ExplicitInitializationCheck
2231 WhitespaceAfterCheck


Thanks for preparing the breakdown. I've reviewed them and agree with 
your analysis. Most of the ones that occur frequently are easily fixed 
by the Eclipse Formatter, with the exceptions you've raised below. 
Although the formatter may break long lines at unfavourable places? I 
propose that we remove this rule as Glenn suggests and it will avoid 
lines being broken in awkward places too.


Thanks,

Chris



A description of the rules sorted by alphabetic order can be found here:
http://checkstyle.sourceforge.net/availablechecks.html

ImportOrderCheck and UnusedImportsCheck are easily fixed by bulk-running
Eclipse’s import organizer.

ConstantNameCheck and MultipleVariableDeclarationsCheck will have to be
fixed by hand but the number remains reasonable.

ExplicitInitializationCheck can’t be automatically fixed by Eclipse
AFAICT. We may have to drop this rule as fixing it manually would be too
much work.

For the rest, either they are automatically fixed by the code formatter,
or the number of occurrences is small enough to be manageable by hand.


Vincent

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE] Glenn Adams for committer

[Chris Bowditch]

Hi All,

Glenn Adams is the author of the Complex Scripts branch for FOP. He has 
been developing it for over 1 year now, providing regular updates to the 
patch as well as support for it via the fop-users Mailing List. I 
therefore propose Glenn is made a committer as reward for his dedication 
to the FOP project. Glenn is an expert in eastern languages (amonst 
other things) and will bring a wealth of valuable knowledge to the FOP 
development team.


+1 from me.

Votes on general@ only please.

Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE RESULTS] Glenn Adams for committer

[Chris Bowditch]

On 20/02/2012 09:16, Chris Bowditch wrote:

Hi All,

Glenn Adams is the author of the Complex Scripts branch for FOP. He 
has been developing it for over 1 year now, providing regular updates 
to the patch as well as support for it via the fop-users Mailing List. 
I therefore propose Glenn is made a committer as reward for his 
dedication to the FOP project. Glenn is an expert in eastern languages 
(amonst other things) and will bring a wealth of valuable knowledge to 
the FOP development team.


+1 from me.


I meant to say when I opened the vote that I planned to conclude it 
today. I think all active committers have voted anyway. The results are:


9 +1s, no other votes. Therefore the vote passes.

Congratulations Glenn and welcome to the team. Glenn sent me his 
preferred ID offlist and we already have an ICLA on file, so I will file 
a new account request.


Thanks,

Chris




Votes on general@ only please.

Thanks,

Chris





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE RESULTS] Glenn Adams for committer

[Chris Bowditch]

On 24/02/2012 11:06, Chris Bowditch wrote:

Glenn,

Your account has been created quicker than I expected. I have now 
granted you karma to FOP's SVN, so you should be all set. Please have a 
read of [1] and [2]


Thanks,

Chris

[1] http://www.apache.org/dev/new-committers-guide.html
[2] http://www.apache.org/dev/committers.html


On 20/02/2012 09:16, Chris Bowditch wrote:

Hi All,

Glenn Adams is the author of the Complex Scripts branch for FOP. He 
has been developing it for over 1 year now, providing regular updates 
to the patch as well as support for it via the fop-users Mailing 
List. I therefore propose Glenn is made a committer as reward for his 
dedication to the FOP project. Glenn is an expert in eastern 
languages (amonst other things) and will bring a wealth of valuable 
knowledge to the FOP development team.


+1 from me.


I meant to say when I opened the vote that I planned to conclude it 
today. I think all active committers have voted anyway. The results are:


9 +1s, no other votes. Therefore the vote passes.

Congratulations Glenn and welcome to the team. Glenn sent me his 
preferred ID offlist and we already have an ICLA on file, so I will 
file a new account request.


Thanks,

Chris




Votes on general@ only please.

Thanks,

Chris









-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE] Include Jeremias' PDF plug-in library as a new sub project

[Chris Bowditch]

Fellow PMC Members and committers,

As you are all aware, Jeremias currently hosts a PDF plug-in for loading 
PDFs as images within FOP. The download for the plug-in is available on 
Jeremias' website. Some of our committers including (but not limited to) 
Mehdi and Peter have needed to make some improvements to the plug-in. So 
we did that to a local copy of the code downloaded from Jeremias' 
website a couple of years ago. We sent the changes back to Jeremias, but 
ran into some problems since our copy is now behind Jeremias' copy. 
Jeremias agreed to make the repository public at apache-extras.org. This 
strikes me as a sub-optimal solution. FOP and PDFBox both live in 
Apache, so why can't we have the plug-in code as a 4th sub project of 
XML Graphics? I suggested this to Jeremias and he has agreed to donate 
the code to Apache. I therefore table a vote on this motion.


Here's my +1.

The vote will run for 7 days until 10am 16th March.

Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Incorporating TM into Project logos

[Chris Bowditch]

Hi All,

As part of the Apache Branding compliance we have to update the XML 
Graphics, FOP, Batik and Commons logos to include the TM symbol after 
the Apache word. I had a go at doing this for the Apache Project logo, 
but my image editing skills are limited. Are there any willing 
volunteers to do this? I've attached my attempt to do this so you can 
see what needs to be done.


Thanks,

Chris


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Incorporating TM into Project logos

[Chris Bowditch]

On 09/03/2012 13:52, Clay Leeds wrote:

Hi Clay,

I'll see what I can do I had a hand in creating a logo or two some time ago, 
and I attempted to use SVG ;-)


Thanks for the offer. I think the board are going to audit our website 
real soon :-/


BTW, I did attach the logo I mentioned but it got blocked by the list.

Looking again at the project websites; I think it is only the XML 
Graphics Project logo that we need to change. The FOP and Batik ones are 
secondary images in the page underneath the project logo, so we probably 
don't need to change them.


Thanks,

Chris


"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Mar 9, 2012, at 3:02 AM, Chris Bowditch  wrote:


Hi All,

As part of the Apache Branding compliance we have to update the XML Graphics, 
FOP, Batik and Commons logos to include the TM symbol after the Apache word. I 
had a go at doing this for the Apache Project logo, but my image editing skills 
are limited. Are there any willing volunteers to do this? I've attached my 
attempt to do this so you can see what needs to be done.

Thanks,

Chris


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Incorporating TM into Project logos

[Chris Bowditch]

On 12/03/2012 01:46, Clay Leeds wrote:

Hi Clay,

I committed replacement 'group-logo.gif files for XML Graphics&  FOP. I also 
committed SCG, JPG&  PNG versions. ;-)


Many thanks for the fast turnaround. I've downloaded the new images and 
they look great. Better than my attempt!


Thanks,

Chris



"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Mar 9, 2012, at 6:44 AM, Chris Bowditch  wrote:


On 09/03/2012 13:52, Clay Leeds wrote:

Hi Clay,

I'll see what I can do I had a hand in creating a logo or two some time ago, 
and I attempted to use SVG ;-)

Thanks for the offer. I think the board are going to audit our website real 
soon :-/

BTW, I did attach the logo I mentioned but it got blocked by the list.

Looking again at the project websites; I think it is only the XML Graphics 
Project logo that we need to change. The FOP and Batik ones are secondary 
images in the page underneath the project logo, so we probably don't need to 
change them.

Thanks,

Chris

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Mar 9, 2012, at 3:02 AM, Chris Bowditch   wrote:


Hi All,

As part of the Apache Branding compliance we have to update the XML Graphics, 
FOP, Batik and Commons logos to include the TM symbol after the Apache word. I 
had a go at doing this for the Apache Project logo, but my image editing skills 
are limited. Are there any willing volunteers to do this? I've attached my 
attempt to do this so you can see what needs to be done.

Thanks,

Chris


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE RESULTS] Include Jeremias' PDF plug-in library as a new sub project

[Chris Bowditch]

On 09/03/2012 09:47, Chris Bowditch wrote:

Fellow PMC Members and committers,






Here's my +1.

The vote will run for 7 days until 10am 16th March.


There were 9 +1s and no other votes therefore the vote passes.

Thanks,

Chris



Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE RESULTS] Include Jeremias' PDF plug-in library as a new sub project

[Chris Bowditch]

On 20/03/2012 08:35, Jeremias Maerki wrote:

I'll work on setting up the new subproject ASAP.


Thanks for volunteering Jeremias - I was going to research what was 
involved but don't have time today. Let me know if I can help.


Thanks,

Chris



On 19.03.2012 13:20:53 Chris Bowditch wrote:

On 09/03/2012 09:47, Chris Bowditch wrote:

Fellow PMC Members and committers,





Here's my +1.

The vote will run for 7 days until 10am 16th March.

There were 9 +1s and no other votes therefore the vote passes.

Thanks,

Chris



Jeremias Maerki


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: [VOTE RESULTS] Include Jeremias' PDF plug-in library as a new sub project

[Chris Bowditch]

On 23/03/2012 16:19, Jeremias Maerki wrote:

Hi Jeremias,


Almost forgot...


Great work and very efficient too! This should make maintenance of the 
PDF plug-in a whole lot easier.




A little note on the legal side:
There have been three contributors to the plug-in: me, Vincent
Hennebert and Krister Wicksell. The first two have an ICLA on file, and
Krister Wicksell's contribution was just a 3-liner which we can safely
put under section 5 ALv2. That's why I'm skipping the software grant.


Thanks,

Chris


On 23.03.2012 17:13:25 Jeremias Maerki wrote:

I've done the initial import to:
https://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images

The commit message redirect to fop-commits is in the process of being
set up.

On 20.03.2012 10:01:48 Chris Bowditch wrote:

On 20/03/2012 08:35, Jeremias Maerki wrote:

I'll work on setting up the new subproject ASAP.

Thanks for volunteering Jeremias - I was going to research what was
involved but don't have time today. Let me know if I can help.

Thanks,

Chris


On 19.03.2012 13:20:53 Chris Bowditch wrote:

On 09/03/2012 09:47, Chris Bowditch wrote:

Fellow PMC Members and committers,





Here's my +1.

The vote will run for 7 days until 10am 16th March.

There were 9 +1s and no other votes therefore the vote passes.

Thanks,

Chris





Jeremias Maerki


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: requesting bugzilla admin access for fop project

[Chris Bowditch]

On 08/04/2012 06:00, Glenn Adams wrote:

Hi Glenn,


i'd like to request bugzilla admin privileges for the fop project in order
to make various administrative changes, such as adding/editing versions,
components, etc.


I'm fine with you having access, but isn't this the wrong place to 
request it? I think you need to request it on infrastructure@ At least I 
have no idea how to action this and am not an Admin of Bugzilla myself. 
So even if infrastructure@ isn't the right place they will tell you 
where to get this actioned.


Thanks,

Chris



regards,
glenn




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: moving from bugzilla to jira?

[Chris Bowditch]

On 14/04/2012 15:45, Glenn Adams wrote:

Hi Glenn,


Fop and XMLGraphicsCommons appear to be two of the few Apache products
still using Bugzilla instead of JIRA. I propose we migrate to JIRA. Any
objection?


You said most of the work would be done on infra@. But I'm guessing that 
someone from the XML Graphics PMC would need to help in some way, or is 
it as simple as opening a Infra JIRA to ask them to do the migration? We 
would need one of the committers to update all the website pages. There 
are several links to Bugzilla there.


I'm happy to move from BZ to JIRA as long as it doesn't take time away 
from other important tasks. Do you volunteer to oversee the conversion?


Thanks,

Chris



Regards,
Glenn




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: moving from bugzilla to jira?

[Chris Bowditch]

On 16/04/2012 10:46, Glenn Adams wrote:

On Mon, Apr 16, 2012 at 2:59 AM, Chris Bowditch
wrote:



You said most of the work would be done on infra@. But I'm guessing that
someone from the XML Graphics PMC would need to help in some way, or is it
as simple as opening a Infra JIRA to ask them to do the migration? We would
need one of the committers to update all the website pages. There are
several links to Bugzilla there.

I'm happy to move from BZ to JIRA as long as it doesn't take time away
from other important tasks. Do you volunteer to oversee the conversion?


yes

Great thanks Glenn :-)


-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE] Switch from Bugzilla to JIRA

[Chris Bowditch]

Hi All,

We need to have a formal vote to decide if the XML Graphics project and 
all sub projects should switch the bug tracking system from Bugzilla to 
JIRA. The main benefits of which are:


1. JIRA has a more modern look and feel
2. Infrastructure are not equiped to support Bugzilla anymore as most 
Apache projects are based on JIRA. Therefore should be more able to 
respond to requests for changes.


The downside is that someone will have to work with infra@ to organize 
the import of bugs from BZ to JIRA. We then need to update the website 
links to point to JIRA instead of BZ. Glenn Adams has kindly volunteered 
to oversee the migration.


Heres my +1

The vote runs until 24th April.

Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: on changing fop documentation sources to markdown

[Chris Bowditch]

On 15/04/2012 19:52, The Web Maestro wrote:
I just added most of the nav for FOP Development (0.95, 1.0, trunk/ 
and 'dev'):

Hi Clay,


http://xmlgraphics.staging.apache.org/

As mentioned, there are likely missing things (like java-docs, 
download.cgi, Batik's DEMO, etc.)... It'd be great if folks could take 
a look... I haven't figured out how to add other content, but It Might 
Just Work(tm) if weupload it there via SVN...


Many thanks for working on this.



Come to think of it, we should probably move this to 
general@xmlgraphics.apache.org 
. Or is there a better mailing 
list? I'll refrain from sending to other lists, until we figure out 
where it should go.


Any ideas where this discussion should move, since it entails changes 
to all XML Graphics Project web docs?


Yes this discussion should move to general@ as it will affect all sub 
projects of XML Graphics.


Thanks,

Chris



Kind regards,

Clay Leeds
--
mailto:the.webmaes...@gmail.com>> - 


My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Sat, Apr 14, 2012 at 11:53 PM, The Web Maestro 
mailto:the.webmaes...@gmail.com>> wrote:


I've updated the docs a bit, and gotten much (but not all!) of the
FOP, Batik & Commons content into the CMS...

We're still missing an adequate navigation system, so I did a
preliminary job of getting a few links in the sidenav, but it's
incomplete and ugly as sin. We'll need to build a mechanism to
hide (collapse?) non-relevant links, but that shouldn't be too hard.

We also need to figure out java-docs, download.cgi, and perhaps
some other issues...

Without further ado:

http://xmlgraphics.staging.apache.org/


Kind regards,

Clay Leeds
--
mailto:the.webmaes...@gmail.com>> -

My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Thu, Apr 12, 2012 at 10:03 PM, Clay Leeds
mailto:the.webmaes...@gmail.com>> wrote:

On Apr 12, 2012, at 6:41 AM, Glenn Adams mailto:gl...@skynav.com>> wrote:
> Agreed that removing forrest dependency is desirable.
However, presumably the current xdocs would need to be
converted to MD, in which case someone will need to construct
an XSLT to do so. That begs the question of whether it would
be necessary (at this time) to convert the source format to
MD, or if an additional step in the CMS based process could
merely perform that step automatically. If so, then it should
not be necessary to change the authoring format at this time.
It could be done as a separate step later.

I am using Forrest 0.8 w markdown plugin. Conversion could be
scripted, but that would negate the benefit of the CMS.

> What I don't know yet is what we will lose from the
conversion to MD in terms of ability to markup our source
docs. Clearly, MD is not as semantically or syntactically rich
as an XML based source. But do we lose anything of
consequence? I don't know yet.
>
> One thing we may lose if we don't convert to MD is the
ability to use CMS in-page editing. So that is a
consideration. Perhaps that option is sufficient to justify
other potential negatives in converting.
>
> G.

One of my goals, was to see some discussion in the DEVers,
before I complete the task of converting the docs. The
MarkDown format is not nearly as semantic as xdoc, but it
serves a different purpose.

It'll take some time, and I'm still prepared to take it on.
But I was hoping for some discussion ;-)






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: on changing fop documentation sources to markdown

[Chris Bowditch]

On 17/04/2012 14:59, Clay Leeds wrote:

NOTE: Moving discussion to general@. Please make all further responses to 
general@.


Hi Clay,

Thanks for moving to general@


BACKGROUND:
We are discussing moving XML Graphics web site to ASF-CMS. You can see progress 
here:

http://xmlgraphics.staging.apache.org/


I realize its work in progress but it appears like you used an old 
snapshot without the "TM" marks in the content or the new logo that you 
designed. Also the links need to include License, Sponsorship, Thanks 
and Security as per the branding guidelines. This content is now live on 
the main site, so I guess you just started with a snapshot from a few 
weeks ago?


ToDo:
- Lots.
- Style&  templating work
- Non-HTML content (figure out how to handle java-docs, download.cgi, demo 
stuff, etc.--might not be too difficult, just a matter of committing to CMS 
content/ dirs?)

Done:
- most HTML content

Thanks,

Chris


Clay

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Apr 17, 2012, at 1:19 AM, Chris Bowditch  wrote:


On 15/04/2012 19:52, The Web Maestro wrote:

I just added most of the nav for FOP Development (0.95, 1.0, trunk/ and 'dev'):

Hi Clay,

http://xmlgraphics.staging.apache.org/

As mentioned, there are likely missing things (like java-docs, download.cgi, 
Batik's DEMO, etc.)... It'd be great if folks could take a look... I haven't 
figured out how to add other content, but It Might Just Work(tm) if weupload it 
there via SVN...

Many thanks for working on this.


Come to think of it, we should probably move this to 
general@xmlgraphics.apache.org<mailto:general@xmlgraphics.apache.org>. Or is 
there a better mailing list? I'll refrain from sending to other lists, until we 
figure out where it should go.

Any ideas where this discussion should move, since it entails changes to all 
XML Graphics Project web docs?

Yes this discussion should move to general@ as it will affect all sub projects 
of XML Graphics.

Thanks,

Chris


Kind regards,

Clay Leeds
--
mailto:the.webmaes...@gmail.com>>  
-<http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Sat, Apr 14, 2012 at 11:53 PM, The Web 
Maestromailto:the.webmaes...@gmail.com>>  wrote:

I've updated the docs a bit, and gotten much (but not all!) of the
FOP, Batik&  Commons content into the CMS...

We're still missing an adequate navigation system, so I did a
preliminary job of getting a few links in the sidenav, but it's
incomplete and ugly as sin. We'll need to build a mechanism to
hide (collapse?) non-relevant links, but that shouldn't be too hard.

We also need to figure out java-docs, download.cgi, and perhaps
some other issues...

Without further ado:

http://xmlgraphics.staging.apache.org/


Kind regards,

Clay Leeds
--
mailto:the.webmaes...@gmail.com>>  -
<http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Thu, Apr 12, 2012 at 10:03 PM, Clay Leeds
mailto:the.webmaes...@gmail.com>>  wrote:

On Apr 12, 2012, at 6:41 AM, Glenn Adamsmailto:gl...@skynav.com>>  wrote:
>  Agreed that removing forrest dependency is desirable.
However, presumably the current xdocs would need to be
converted to MD, in which case someone will need to construct
an XSLT to do so. That begs the question of whether it would
be necessary (at this time) to convert the source format to
MD, or if an additional step in the CMS based process could
merely perform that step automatically. If so, then it should
not be necessary to change the authoring format at this time.
It could be done as a separate step later.

I am using Forrest 0.8 w markdown plugin. Conversion could be
scripted, but that would negate the benefit of the CMS.

>  What I don't know yet is what we will lose from the
conversion to MD in terms of ability to markup our source
docs. Clearly, MD is not as semantically or syntactically rich
as an XML based source. But do we lose anything of
consequence? I don't know yet.
>
>  One thing we may lose if we don't convert to MD is the
ability to use CMS in-page editing. So that is a
consideration. Perhaps that option is sufficient to justify
other potential negatives in converting.
>
>  G.

One of my goals, was to see some discussion in the DEVers,
before I complete the task of converting the docs. The
MarkDown format is not nearly as semantic as xdoc, but it
serves a different purpose.

It'll take some time, and I'm still prepared to tak

Re: on changing fop documentation sources to markdown

[Chris Bowditch]

On 18/04/2012 07:24, The Web Maestro wrote:

Hi Clay,

On Tue, Apr 17, 2012 at 7:52 AM, Chris Bowditch 
mailto:bowditch_ch...@hotmail.com>> wrote:


BACKGROUND:
We are discussing moving XML Graphics web site to ASF-CMS. You
can see progress here:

http://xmlgraphics.staging.apache.org/


I realize its work in progress but it appears like you used an old
snapshot without the "TM" marks in the content or the new logo
that you designed. Also the links need to include License,
Sponsorship, Thanks and Security as per the branding guidelines.
This content is now live on the main site, so I guess you just
started with a snapshot from a few weeks ago?


I added the logo (in GIF, JPG, PNG & SVG formats... ;-)


Thanks, but I don't yet see it on the staging website. Is there a delay 
before that appears?




Sponsorship & Thanks were already there. License is on the Legal page, 
which is there, but I've added it to the sidebar as well, along with 
the Security page. ;-)


Thanks. I can now see the 4 required links.



I also got the Compliance table working. Unfortunately, the CMS is 
stripping the 'class="ForrestTable"', so the coloring is 
White-On-White (but if you select the text, you'll see the content and 
layout is there).


As for the navigation menu, I'd like it to collapse most of the links, 
except the section you're in. Anyone have a favorite jQuery menu they 
like for this? If not, I'll see about finding one...


All the "TM" logos are missing from the content and headers though. It 
took me quite some time to add them to all the pages. Will you be able 
to re-sync the content with the latest xdocs as it would take quite some 
time to re-apply them and I want to tell the board that FOP, Commons and 
XML Graphics sites are now brand compliant in the upcoming report.


Thanks,

Chris



Clay



-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: on changing fop documentation sources to markdown

[Chris Bowditch]

On 18/04/2012 13:52, Clay Leeds wrote:

On Apr 18, 2012, at 5:12 AM, Chris Bowditch  wrote:

On 18/04/2012 07:24, The Web Maestro wrote:

Hi Clay,


I added the logo (in GIF, JPG, PNG&  SVG formats... ;-)

Thanks, but I don't yet see it on the staging website. Is there a delay before 
that appears?


Hi Clay,


Strange. The new logo showed up when I refreshed it. Perhaps it's your cache? 
Try loading only the logo.


Yes you are right. It was my browser cache. I can now see the updated logo.




Sponsorship&  Thanks were already there. License is on the Legal page, which is 
there, but I've added it to the sidebar as well, along with the Security page. ;-)

Thanks. I can now see the 4 required links.


I also got the Compliance table working. Unfortunately, the CMS is stripping the 
'class="ForrestTable"', so the coloring is White-On-White (but if you select 
the text, you'll see the content and layout is there).

As for the navigation menu, I'd like it to collapse most of the links, except 
the section you're in. Anyone have a favorite jQuery menu they like for this? 
If not, I'll see about finding one...

All the "TM" logos are missing from the content and headers though. It took me 
quite some time to add them to all the pages. Will you be able to re-sync the content 
with the latest xdocs as it would take quite some time to re-apply them and I want to 
tell the board that FOP, Commons and XML Graphics sites are now brand compliant in the 
upcoming report.

The current LIVE site has it, so we should be good informing the board it's 
there, no?

Weird. When I added the content, I did an `svn up` to ensure it was recent 
content. I'm sure I'll have to re-synch, anyway, so we'll see. I wish it were a 
caching thing!


I can see the TM logos in most of the content after clearing the cache. 
Just the XML Graphics top page doesn't appear to have them now.


Thanks,

Chris




Thanks,

Chris





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: on changing fop documentation sources to markdown

[Chris Bowditch]

On 19/04/2012 02:02, Clay Leeds wrote:

I replaced the logo for all sites a month or so ago.


Thanks Clay - I can see the new logo fine. I was referring to the "TM" 
characters in the text. I can see it everywhere except the top level XML 
Graphics home page, which is a page I definitely changed.


I'm not at a place I can publish, but if someone can publish the PRODUCTION 
sites, the logo will show up (be sure to clear cache!).


Cache definitely cleared. I know its only 1 page, but since its the top 
page it's important that it adheres to Apache Branding rules.


Thanks,

Chris



Clay

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Apr 18, 2012, at 7:09 AM, Chris Bowditch  wrote:


On 18/04/2012 13:52, Clay Leeds wrote:

On Apr 18, 2012, at 5:12 AM, Chris Bowditch   wrote:

On 18/04/2012 07:24, The Web Maestro wrote:

Hi Clay,


I added the logo (in GIF, JPG, PNG&   SVG formats... ;-)

Thanks, but I don't yet see it on the staging website. Is there a delay before 
that appears?

Hi Clay,


Strange. The new logo showed up when I refreshed it. Perhaps it's your cache? 
Try loading only the logo.

Yes you are right. It was my browser cache. I can now see the updated logo.


Sponsorship&   Thanks were already there. License is on the Legal page, which 
is there, but I've added it to the sidebar as well, along with the Security page. 
;-)

Thanks. I can now see the 4 required links.


I also got the Compliance table working. Unfortunately, the CMS is stripping the 
'class="ForrestTable"', so the coloring is White-On-White (but if you select 
the text, you'll see the content and layout is there).

As for the navigation menu, I'd like it to collapse most of the links, except 
the section you're in. Anyone have a favorite jQuery menu they like for this? 
If not, I'll see about finding one...

All the "TM" logos are missing from the content and headers though. It took me 
quite some time to add them to all the pages. Will you be able to re-sync the content 
with the latest xdocs as it would take quite some time to re-apply them and I want to 
tell the board that FOP, Commons and XML Graphics sites are now brand compliant in the 
upcoming report.

The current LIVE site has it, so we should be good informing the board it's 
there, no?

Weird. When I added the content, I did an `svn up` to ensure it was recent 
content. I'm sure I'll have to re-synch, anyway, so we'll see. I wish it were a 
caching thing!

I can see the TM logos in most of the content after clearing the cache. Just 
the XML Graphics top page doesn't appear to have them now.

Thanks,

Chris


Thanks,

Chris

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Board Report due in 2 weeks

[Chris Bowditch]

Hi All,

It might be a couple of weeks until the report is due, but there's been 
quite a bit of activity this quarter, and I had a few minutes spare to 
draft a report. This is just my view of activity over the last quarter 
and it could well be that I missed something important. So please review 
the draft report on the Wiki [1] and give me feedback.


Thanks,

Chris

[1] http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForMay2012

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Board Report due in 2 weeks

[Chris Bowditch]

On 20/04/2012 19:13, Glenn Adams wrote:

Hi Glenn,


I made a few minor improvements/corrections and added a bullet on possible
JIRA transition. It was easier to simply edit in-place... hope you don't
mind. Feel free to change.


Thanks. I knew I had forgotten something. I'm fine with you updating the 
page directly.


Thanks,

Chris



On Fri, Apr 20, 2012 at 10:24 AM, Chris Bowditch
wrote:
Hi All,

It might be a couple of weeks until the report is due, but there's been
quite a bit of activity this quarter, and I had a few minutes spare to
draft a report. This is just my view of activity over the last quarter and
it could well be that I missed something important. So please review the
draft report on the Wiki [1] and give me feedback.

Thanks,

Chris

[1] http://wiki.apache.org/**xmlgraphics/StatusReports/**
StatusReportForMay2012<http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForMay2012>

--**--**-
To unsubscribe, e-mail: 
general-unsubscribe@**xmlgraphics.apache.org
For additional commands, e-mail: 
general-help@xmlgraphics.**apache.org





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

[VOTE RESULTS] Switch from Bugzilla to JIRA

[Chris Bowditch]

On 23/04/2012 00:38, Helder Magalhães wrote:

Hi All,

There were 6 +1 votes from committers on general@ (And some non binding 
votes on fop-dev)


The vote passes.

Glenn, you have permission to proceed with the switch when you are ready.

Thanks,

Chris


Hi everyone,


We need to have a formal vote to decide if the XML Graphics project and
all sub projects should switch the bug tracking system from Bugzilla to
JIRA.

My experience with JIRA is quite smaller compared to  Bugzilla, given
the latter it's widely used in the OSS community. However, I also feel
that JIRA fells more polished and, I Apache projects are mostly
moving, so should we! :-)

+1 from me.



Thanks Glenn for moving this forward.

And another thanks to Glenn... ;-)


Cheers,
  Helder


--
Helder "Lthere" Magalhães
http://heldermagalhaes.com/

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: JIRA Project Keywords

[Chris Bowditch]

On 25/04/2012 16:50, Glenn Adams wrote:

Hi Glenn,

In order to request the transition from BZ to JIRA, we need to select a
"project key" for each BZ product (step 4 of [1]):

*Step four: Pick project key(s)*

- The project key will be the prefix of every issue, for example,
infrastructure's key is "INFRA" and issues are INFRA-1, INFRA-2, etc...
This should be unique, but not too long. If you will have multiple
projects, think about possible multiple keys.

[1] http://wiki.apache.org/general/ApacheBugzillaToJiraMigration

I propose the following keys:

"BATIK" - Batik BZ Product
"FOP" - Fop BZ Product
"XGC" - XMLGraphicsCommons BZ Product


I'm happy with your suggestions above. However, the list is missing 1 
sub component; the recently added pdf-plugin library. It may be smaller 
than others but we need to cater for it.


Thanks,

Chris


Any objection or suggested change?




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: JIRA Project Keywords

[Chris Bowditch]

On 25/04/2012 17:23, Glenn Adams wrote:

Hi Glenn,

On Wed, Apr 25, 2012 at 10:09 AM, Chris Bowditch
wrote:
I'm happy with your suggestions above. However, the list is missing 1 sub
component; the recently added pdf-plugin library. It may be smaller than
others but we need to cater for it.


At present, there is no Bugzilla product or component associated with this
(AFAICT). The question is whether we would want to have separate JIRA
project for this or not. Or should it be handled in JIRA as a "component"
or as a "project". I would suggest it be handled as a component under
either the FOP or XGC project. In any case, we can create this project or
component after the initial BZ to JIRA transition since there aren't any
existing BZ issues filed.


Yes that's right. There is no Bugzilla product or component for PDF 
Plugin because the component was only added to SVN within the last 2 
weeks. There has been plenty of discussions about enhancements to it on 
fop-dev recently between Mehdi and Craig Ringer, so its only a matter of 
time until we need to raise issues against it. I'll leave it up to you, 
but whilst you are adding the others, adding a fourth would seem like no 
extra effort.


Thanks,

Chris





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Initial JIRA Developers List for XMLGraphics Projects

[Chris Bowditch]

On 25/04/2012 20:49, Glenn Adams wrote:

Hi Glenn,

I need to submit a list of developers for the xmlgraphics projects (batik,
fop, xgc) for the JIRA transition. In particular, I need to provide a JIRA
user name for each developer where the associated email account is the same
as that used in Bugzilla. If the developer doesn't have a JIRA account or
if their Bugzilla email is different, then they need to change their
Bugzilla email account to match their JIRA account or create a new JIRA
account with a matching email.


Thanks for preparing the list below. See my comments inline below:


I've checked the current committers/contributors, and it appears that the
following already satisfy these requirements with the following listed JIRA
account info (*JIRA user name*, *JIRA email*):

- Glenn Adams (gadams, gadams at apache dot org)
- Luis Bernardo (lmpmbernardo, lmpmbernardo at gmail dot com)
    - Chris Bowditch (cbowditch, bowditch_chris at hotmail dot com)
- Adrian Cumiskey (dev at cumiskey dot com, dev at cumiskey dot com)
- Georg Datterl (gd at geneon dot de, gd at geneon dot de)
Georg is no longer available at that e-mail address. Also, since he's a 
Contributor rather than a committer I suggest you do not add Georg at 
this time.

- Thomas Deweese (deweese, deweese at apache dot org)
- Peter Hancock (phancock, peter dot hancock at gmail dot com)
- Vincent Hennebert (vhennebert, vhennebert at gmail dot com)
- Mehdi Houshmand (med1985 at gmail dot com, med1985 at gmail dot com)
- Clay Leeds (the_webmaestro, the dot webmaestro at gmail dot com)
- Jeremias Maerki (jeremias at apache dot org, jeremias at apache dot
org)
- Cameron McCormack (cam, cam at apache dot org)
- Simon Pepping (spepping, spepping at apache dot org)
- Joerg Pietschmann (j322ptm at yahoo dot de, j322ptm at yahoo dot de)
- Dieter van Holten (dvholten, info at dvholten dot de)

Could you please confirm this information is correct? If I don't hear from
you by May 1, I will use the above information.

The following committers/contributors do not appear to have a JIRA account.
I will need you to create an account at [1], where you use the same email
account as you are using in Bugzilla, which I list below:

- Andreas Delmelle (adelmelle at apache dot org)
- Helder Magalhaes (helder dot magalhaes at gmail dot com)
- Louis Masters (louis dot masters at log hyphen net dot com)
Louis is a contributor rather than a committer and I don't believe I've 
seen him active for a few months. Please don't add him at this time.

- Venkat Reddy (vanukuri dot venkat at googlemail dot com)
Venkat was a Contributor who used to work on FOP for Thunderhead, but 
left over a year ago. He has not been active since then and I have since 
removed him as an active Contributor from the team page. Please don't 
add him at this time.

- Pascal Sancho (pascal dot sancho at takoma dot fr)

Please create your JIRA account by May 1 and send me a confirmation along
with the user name you used.
I've checked the team pages of FOP and Batik and don't believe you've 
missed any committer from the above list.


Thanks,

Chris


[1] https://issues.apache.org/jira/secure/Signup!default.jspa

Thanks,
Glenn




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: XML Graphics on staging CMS progress

[Chris Bowditch]

On 08/05/2012 13:57, Clay Leeds wrote:

Hi Clay,

Whoop! Should've sent this to general@

Please respond here...

The CMS site is coming along nicely. I have mainly been focusing on stylistic 
enhancements, getting the NAV to collapse. I'd like to get it to be self-aware, 
so it expands to the current location's link.


Many thanks for taking the lead with the move to CMS web hosting.


Am I on the right track with the design?


I'm not very good at website design, so I'm probably not the best person 
to ask. Hopefully some of the others will give you some feedback on 
general@.


Did you mean for the navigator to be on the right? That surprised me at 
first, but it's not necessarily wrong. The text (titles and paragraphs) 
seem smaller than in the current website.


Thanks,

Chris



http://xmlgraphics.staging.apache.org/

Clay

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet



-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: XML Graphics on staging CMS progress

[Chris Bowditch]

On 16/05/2012 05:57, The Web Maestro wrote:

Hi Clay,

So, I need to do more testing, but I've fixed the SideNav issues I was
having. They presently collapse globally, and then expand, showing and
highlighting the currently active page (based on location.href).
Many thanks for your efforst so far. You've made some good progress. One 
thing I don't like about the current behaviour of the side bar is the 
fact that it expands the entire FOP sub project and you then have to 
scroll for ages to find the right section. Is there no way to have it 
function like a tree, only expanding those nodes which you ask to expand 
by clicking?




I'm open to hearing constructive criticism from the crew.

http://xmlgraphics.staging.apache.org/

Brief list of Issues:
- the page design is missing something (perhaps remove the logo from
the top-left of page and leave it in the top of the sidenav?)
- get more graphics involved in the design (page graphics? batik graphics? etc.)
Yes, it is a requirement for sub projects to have their own logo. FOP 
and Batik both have a logo already, I suggest re-using them in the new site.

- have a solution for non-HTML stuff (Batik demo, javadoc, etc.)
- fix styling of Compliance.html (perhaps using jQuery to style items
in table w innerHTML = 'yes'?)
- improve page title rendering

Yes I would like it be a little larger/bolder.


Once we are ready to actually deploy, there are other issues:
- sync page updates (status, faqs, etc.)
- determine Ideal location from which to deploy (perhaps where it is
in xmlgraphics/site/trunk)
Also we need a page that documents the process of making website updates 
and re-deploying. Hopefully it will be a lot simpler using the CMS approach.


NOTE: I don't think we need to spend *hours* on the Compliance table
issue--I think I can handle it via jQuery.

Kind regards,

Thanks,

Chris


Clay Leeds
--
  -<http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Tue, May 8, 2012 at 4:24 PM, The Web Maestro
  wrote:

On Tue, May 8, 2012 at 6:25 AM, Chris Bowditch
  wrote:

On 08/05/2012 13:57, Clay Leeds wrote:

Am I on the right track with the design?

I'm not very good at website design, so I'm probably not the best person to
ask. Hopefully some of the others will give you some feedback on general@.

Did you mean for the navigator to be on the right? That surprised me at
first, but it's not necessarily wrong. The text (titles and paragraphs) seem
smaller than in the current website.

Thanks,

Chris

Yup! I stuck it on the right on purpose. I had it on the left at
first, but I got bored, so I moved it to the right. A couple of lines
of CSS can move it back, but I kind of like it on the right.

I just noticed that Apache Batik is missing it's subnav. It's actually
there, but it disappeared. I'll work on bringing that back.

Here're some of my thoughts/plans:
- move the XML Graphics logo to the top of the nav box
- Make the content have a minimum width of ~300 pixels (in case an
iPhone/Smartphone user is using it)
- put a hidden link-to-content to skip the nav
- need to add jQuery so nav block collapses everything *except* the
section you're in

Of course, we also need to sync the CMS with any recent changes, but I
should be able to make an SVN 'find' all changes since I started this
folly...

Clay

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: Enabling Incoming Mail from JIRA

[Chris Bowditch]

On 17/05/2012 13:13, Christian Geisert wrote:

Glenn Adams schrieb:


Hi Glenn, Christian,

I am a list moderator and will take care of this. Thanks for the hint 
Christian.


Chris

After the infrastructure team transitions from BZ to JIRA, we will need to
enable incoming notifications from j...@apache.org on the following mail
lists:

- general@xmlgraphics.apache.org
- fop-...@xmlgraphics.apache.org
- batik-...@xmlgraphics.apache.org

Does anybody know how to add j...@apache.org as a legitimate mail origin
for these MLs? It should be enabled for incoming mail only; i.e., mail sent
to these MLs should not be reflected to this address.

j...@apache.org needs to be added to the "allow" list.

This can be done by the list moderator. See
http://www.apache.org/dev/committers.html#mail-moderate for details
(short: admin should hit reply-all on the first jira mail)

Christian

-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: new xgc release required for fop 1.1 release?

[Chris Bowditch]

On 31/05/2012 03:55, The Web Maestro wrote:

Hi Glenn, Clay,

On Wed, May 30, 2012 at 8:18 AM, Pascal Sancho  wrote:

Hi Glenn,

1.1rc1 sounds good for me.
If further RC is required, the only final digit needs to be incremented.
In addition, this version name indicates by itself that this version should
not be used in prod.

So I think that would be:

- fop-1.1rc (svn-tag: fop-1_1rc)
- commons-1.5rc (svn-tag: commons-1_5rc)


This is the format I've seen used at other Apache projects and FOP in 
the past. +1 from me.


Thanks,

Chris



Should this be on general@?

Kind regards,

Clay Leeds
--
  -
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet





-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org

Re: checkstyle-5.5 online for xgc

[Chris Bowditch]

On 03/06/2012 16:58, Glenn Adams wrote:

Hi Glenn,


I've completed updating XGC to use the same checkstyle-5.5 configuration
that is currently being used with FOP (trunk). Because a number of XGC
files do not follow these style conventions, and would produce hundreds of
warnings were they to be imposed, I have in these cases selectively
disabled specific rules by inserting CSOFF declarations into the files. I
believe that is a better approach than making wide scale code changes to
significantly alter the originally authored conventions.


FYI: Vincent is on holiday this week. I expect he will have some 
feedback on this topic. In the meantime I will provide my thoughts on 
this. I personally don't like the use of CSON and CSOFF declarations and 
prefer to fix the code where the number of reported issues is not too 
high or remove the rule from the checkstyle configuration with a TODO 
comment to revisit it later for those rules where the number of 
breakages is too high to consider manually changing the code right now.




For moving forward, i.e., adding new files, we should endeavor to follow
the rules when acceptable. However, as a reminder, the goal of using
checkstyle is to improve coding consistency when there is general agreement
to use some convention. Nevertheless, there remain some style rules for
which there is not general agreement. In those cases, I would expect the
default (currently specified) rule to apply unless a particular developer
wishes to diverge from the default, in which case I have no problem with
using CSOFF/CSOK declarations as desired. Personally, I do not agree with a
number of the whitespace related (and other) style conventions that are
presently encoded in the default rules; as a consequence, I will likely
make use of CSOFF declarations in files that I author in order to disable
certain rules.

I view this use of checkstyle and style rule enforcement as a recommended,
but optional process that we developers agree to follow when we can do so
and when we agree. I am opposed to any view that would consider these rules
to be mandatory or absolute. We represent a community of diverse interests,
experiences, and preferences. Imposing a single set of rules in an absolute
manner would, IMO, be detrimental to creating a healthy, dynamic community
whose opinions do not always coincide. That being said, I think we should
also respect the styles used by specific authors; i.e., for cases where
there is not unanimous consent to use a specific style rule, we should not
change the styles used in a specific file simply because we don't like it.


I agree that it is difficult to reach consensus in a diverse community. 
The rules that go into the final checkstyle file should be only those 
style aspects which have been agreed upon at the time. I know from 
previous discussions that whilst we disagreed on some topics we did 
reach agreement on others. Those which have been agreed should go into 
the the checkstyle file, whilst those which we did not reach consensus 
on should be removed.




For my part, I will henceforth run checkstyle and fix any reported warnings
before committing to XGC. I hope that other developers will do this as well.


I agree that once everyone has signed up to the agreed set of checkstyle 
rules that everyone should adhere to this policy.


Thanks,

Chris


Regards, Glenn




-
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org