Re: FOP Release

[Luis Bernardo]

I think that maven will be embraced as soon as there is a volunteer to 
do the transition.


On 4/22/15 6:13 PM, Glenn Adams wrote:



On Wed, Apr 22, 2015 at 9:40 AM, Chris Bowditch 
mailto:bowditch_ch...@hotmail.com>> wrote:


I agree, but as Simon pointed out PDFBox is not a dependency of
FOP, but of PDF plug-in, which is a separate project with a
separate release cycle. The PDF plug-in project is an optional
dependency of FOP, not required for core functionality.

So the proposal is just to release the FOP project, not PDF
plug-in. This means anyone wishing to use PDF-plugin with the new
release of FOP would need to build it from source code using a
PDFBox snaphot. Not ideal, but we are long overdue a FOP release,
and only a small number of users are using the PDF plug-in. So I'm
+1 to this proposal.


ok; that works for me... on another point, when can we transition to 
maven? our ant configurations are difficult to maintain and 
understand; we should modernize



Thanks,

Chris

On 22/04/2015 14:28, Glenn Adams wrote:

I'm not comfortable requiring use of a snapshot dependency.
For example, that would prevent deployment to maven central.

On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch
mailto:bowditch_ch...@hotmail.com>
<mailto:bowditch_ch...@hotmail.com
<mailto:bowditch_ch...@hotmail.com>>> wrote:

Hi Glen,

Its expected that a -1 vote includes a justification. You
may well
be right, but we are not mind readers and have no idea
what you
are thinking...

Thanks,

Chris

On 21/04/2015 16:32, Glenn Adams wrote:

-1

On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner
mailto:simonsteiner1...@gmail.com>
<mailto:simonsteiner1...@gmail.com
<mailto:simonsteiner1...@gmail.com>>
<mailto:simonsteiner1...@gmail.com
<mailto:simonsteiner1...@gmail.com>
<mailto:simonsteiner1...@gmail.com
<mailto:simonsteiner1...@gmail.com>>>> wrote:

Hi,

Since Batik and XGC have been released, are we
ready to
release FOP?

It has been said we can’t release PDF plugin using
a snapshot
release of PDFBox 2.0. PDFBox 1.8 is missing font
parsing
libraries we need for font merging.

We could make release a PDF plugin beta release using
snapshot of
PDFBox or ask user to use PDF plugin snapshot
version with
FOP 2.0.

Thanks

Re: FOP Release

[Glenn Adams]

On Wed, Apr 22, 2015 at 9:40 AM, Chris Bowditch 
wrote:

> I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but
> of PDF plug-in, which is a separate project with a separate release cycle.
> The PDF plug-in project is an optional dependency of FOP, not required for
> core functionality.
>
> So the proposal is just to release the FOP project, not PDF plug-in. This
> means anyone wishing to use PDF-plugin with the new release of FOP would
> need to build it from source code using a PDFBox snaphot. Not ideal, but we
> are long overdue a FOP release, and only a small number of users are using
> the PDF plug-in. So I'm +1 to this proposal.
>

ok; that works for me... on another point, when can we transition to maven?
our ant configurations are difficult to maintain and understand; we should
modernize


>
> Thanks,
>
> Chris
>
> On 22/04/2015 14:28, Glenn Adams wrote:
>
>> I'm not comfortable requiring use of a snapshot dependency. For example,
>> that would prevent deployment to maven central.
>>
>> On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch <
>> bowditch_ch...@hotmail.com <mailto:bowditch_ch...@hotmail.com>> wrote:
>>
>> Hi Glen,
>>
>> Its expected that a -1 vote includes a justification. You may well
>> be right, but we are not mind readers and have no idea what you
>> are thinking...
>>
>> Thanks,
>>
>> Chris
>>
>> On 21/04/2015 16:32, Glenn Adams wrote:
>>
>> -1
>>
>> On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner
>> > <mailto:simonsteiner1...@gmail.com>
>> <mailto:simonsteiner1...@gmail.com
>> <mailto:simonsteiner1...@gmail.com>>> wrote:
>>
>> Hi,
>>
>> Since Batik and XGC have been released, are we ready to
>> release FOP?
>>
>> It has been said we can’t release PDF plugin using a snapshot
>> release of PDFBox 2.0. PDFBox 1.8 is missing font parsing
>> libraries we need for font merging.
>>
>> We could make release a PDF plugin beta release using
>> snapshot of
>> PDFBox or ask user to use PDF plugin snapshot version with
>> FOP 2.0.
>>
>> Thanks
>>
>>
>>
>>
>>
>

Re: FOP Release

[Chris Bowditch]

I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but 
of PDF plug-in, which is a separate project with a separate release 
cycle. The PDF plug-in project is an optional dependency of FOP, not 
required for core functionality.


So the proposal is just to release the FOP project, not PDF plug-in. 
This means anyone wishing to use PDF-plugin with the new release of FOP 
would need to build it from source code using a PDFBox snaphot. Not 
ideal, but we are long overdue a FOP release, and only a small number of 
users are using the PDF plug-in. So I'm +1 to this proposal.


Thanks,

Chris

On 22/04/2015 14:28, Glenn Adams wrote:
I'm not comfortable requiring use of a snapshot dependency. For 
example, that would prevent deployment to maven central.


On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch 
mailto:bowditch_ch...@hotmail.com>> wrote:


Hi Glen,

Its expected that a -1 vote includes a justification. You may well
be right, but we are not mind readers and have no idea what you
are thinking...

Thanks,

Chris

On 21/04/2015 16:32, Glenn Adams wrote:

-1

On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner
mailto:simonsteiner1...@gmail.com>
<mailto:simonsteiner1...@gmail.com
<mailto:simonsteiner1...@gmail.com>>> wrote:

Hi,

Since Batik and XGC have been released, are we ready to
release FOP?

It has been said we can’t release PDF plugin using a snapshot
release of PDFBox 2.0. PDFBox 1.8 is missing font parsing
libraries we need for font merging.

We could make release a PDF plugin beta release using
snapshot of
PDFBox or ask user to use PDF plugin snapshot version with
FOP 2.0.

Thanks

Re: FOP Release

[Glenn Adams]

I'm not comfortable requiring use of a snapshot dependency. For example,
that would prevent deployment to maven central.

On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch 
wrote:

> Hi Glen,
>
> Its expected that a -1 vote includes a justification. You may well be
> right, but we are not mind readers and have no idea what you are thinking...
>
> Thanks,
>
> Chris
>
> On 21/04/2015 16:32, Glenn Adams wrote:
>
>> -1
>>
>> On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner <
>> simonsteiner1...@gmail.com > wrote:
>>
>> Hi,
>>
>> Since Batik and XGC have been released, are we ready to release FOP?
>>
>> It has been said we can’t release PDF plugin using a snapshot
>> release of PDFBox 2.0. PDFBox 1.8 is missing font parsing
>> libraries we need for font merging.
>>
>> We could make release a PDF plugin beta release using snapshot of
>> PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0.
>>
>> Thanks
>>
>>
>>
>

Re: FOP Release

[Luis Bernardo]

When I suggested releasing Batik back in December, Glenn mentioned that 
he wanted to fix some issues (namely 
https://issues.apache.org/jira/browse/FOP-2391) before releasing FOP 
2.0. I assume this is the reason for -1, but I agree that a 
justification would help since not everyone may remember what was 
discussed in December.


On 4/22/15 9:18 AM, Chris Bowditch wrote:

Hi Glen,

Its expected that a -1 vote includes a justification. You may well be 
right, but we are not mind readers and have no idea what you are 
thinking...


Thanks,

Chris

On 21/04/2015 16:32, Glenn Adams wrote:

-1

On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner 
mailto:simonsteiner1...@gmail.com>> wrote:


Hi,

Since Batik and XGC have been released, are we ready to release FOP?

It has been said we can’t release PDF plugin using a snapshot
release of PDFBox 2.0. PDFBox 1.8 is missing font parsing
libraries we need for font merging.

We could make release a PDF plugin beta release using snapshot of
PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0.

Thanks

Re: FOP Release

[Chris Bowditch]

Hi Glen,

Its expected that a -1 vote includes a justification. You may well be 
right, but we are not mind readers and have no idea what you are thinking...


Thanks,

Chris

On 21/04/2015 16:32, Glenn Adams wrote:

-1

On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner 
mailto:simonsteiner1...@gmail.com>> wrote:


Hi,

Since Batik and XGC have been released, are we ready to release FOP?

It has been said we can’t release PDF plugin using a snapshot
release of PDFBox 2.0. PDFBox 1.8 is missing font parsing
libraries we need for font merging.

We could make release a PDF plugin beta release using snapshot of
PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0.

Thanks

RE: FOP Release

[Simon Steiner]

Hi,

 

Its listed here

https://xmlgraphics.apache.org/fop/trunk/running.html

 

Thanks

 

From: Clay Leeds [mailto:the.webmaes...@gmail.com] 
Sent: 21 April 2015 21:23
To: Apache FOP
Subject: Re: FOP Release

 

One of the changes for PDFBox 2.0.0 (from what I gather from the PDFBox ‘Ideas’ 
page), is a switch to Java 1.6.

 

We discussed a switch for FOP that required a higher version of Java (I believe 
it was 1.6, but don’t recall).

 

But I can’t find anywhere on our site that indicates what the minimum Java 
requirement actually is. I’d like to update the site to include the minimum 
requirements if someone can let me know what those are… ;-)

 

Clay

 

On Apr 21, 2015, at 8:21 AM, Simon Steiner mailto:simonsteiner1...@gmail.com> > wrote:

 

Hi,

 

Since Batik and XGC have been released, are we ready to release FOP?

 

It has been said we can’t release PDF plugin using a snapshot release of PDFBox 
2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging.

We could make release a PDF plugin beta release using snapshot of PDFBox or ask 
user to use PDF plugin snapshot version with FOP 2.0.

 

Thanks

 

Re: FOP Release

[Clay Leeds]

One of the changes for PDFBox 2.0.0 (from what I gather from the PDFBox ‘Ideas’ 
page), is a switch to Java 1.6.

We discussed a switch for FOP that required a higher version of Java (I believe 
it was 1.6, but don’t recall).

But I can’t find anywhere on our site that indicates what the minimum Java 
requirement actually is. I’d like to update the site to include the minimum 
requirements if someone can let me know what those are… ;-)

Clay

> On Apr 21, 2015, at 8:21 AM, Simon Steiner  wrote:
> 
> Hi,
>  
> Since Batik and XGC have been released, are we ready to release FOP?
>  
> It has been said we can’t release PDF plugin using a snapshot release of 
> PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font 
> merging.
> We could make release a PDF plugin beta release using snapshot of PDFBox or 
> ask user to use PDF plugin snapshot version with FOP 2.0.
>  
> Thanks

Re: FOP Release

[Glenn Adams]

-1

On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner 
wrote:

> Hi,
>
>
>
> Since Batik and XGC have been released, are we ready to release FOP?
>
>
>
> It has been said we can’t release PDF plugin using a snapshot release of
> PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font
> merging.
>
> We could make release a PDF plugin beta release using snapshot of PDFBox
> or ask user to use PDF plugin snapshot version with FOP 2.0.
>
>
>
> Thanks
>

FOP Release

[Simon Steiner]

Hi,

 

Since Batik and XGC have been released, are we ready to release FOP?

 

It has been said we can't release PDF plugin using a snapshot release of
PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font
merging.

We could make release a PDF plugin beta release using snapshot of PDFBox or
ask user to use PDF plugin snapshot version with FOP 2.0.

 

Thanks

Re: Question on FOP release schedule

[Jacopo Cappellato]

Hi Chris,

the only reason I have asked for a bug fix release for 1.1 is because it may be 
easier to approve/publish. But if you are already planning the new 2.0 release 
then great. Is there a tentative plan for it already?

Thanks,

Jacopo

On Oct 7, 2014, at 2:36 PM, Chris Bowditch  wrote:

> Hi Jacopo,
> 
> Thanks for your contribution. I wonder why you ask for a bug fix release of 
> 1.1? v2.0 will include all bug fixes since the v1.1 release, there are no 
> plans for a 1.1.2 release or similar. We are working towards a v2.0 release 
> of FOP. We've just released XML Graphics Commons v2.0, but the FOP release is 
> dependent on other libraries being released first.
> 
> Thanks,
> 
> Chris
> 
> On 03/10/2014 06:49, Jacopo Cappellato wrote:
>> Thank you Luis,
>> 
>> I have attached to Jira a Junit test for the CompareUtil.equal method that 
>> should prove the issue we are facing and should confirm that the fix I am 
>> proposing should work ok.
>> As regards the bug fix release, at the moment this is the only issue that I 
>> am aware of that is causing some pain to OFBiz and having a bug fix release 
>> for it would be great; however I know that the release workflow requires a 
>> good amount of work and I am wondering if I or other OFBiz committers may be 
>> of any help in the release process (e.g. we could help the FOP community to 
>> maintain a release branch for 1.1 by backporting fixes to it and testing it).
>> I am wide open to any suggestions. Of course OFBiz will upgrade to the new 
>> release 2.0 as soon as this will be available and we will help you to test 
>> that as well. All in all I am just trying to give something back to the FOP 
>> community, since the OFBiz community has been a rather silent and passive 
>> user of your amazing tool :-)
>> 
>> Regards,
>> 
>> Jacopo
>> 
>> On Oct 3, 2014, at 1:15 AM, Luis Bernardo  wrote:
>> 
>>> I can apply your patch although I do not have the environment to test it.
>>> 
>>> Regarding the question about a bug fix for 1.1, the answer is that there is 
>>> nothing planned but if there is interest from the FOP users I think that 
>>> can be accommodated. Is there any other bug your would like to see fixed in 
>>> a 1.1+ release?
>>> 
>>> On 10/2/14, 7:22 PM, Jacopo Cappellato wrote:
>>>> Hi all,
>>>> 
>>>> I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for 
>>>> this amazing product).
>>>> 
>>>> I hope this is the right list to get some information about the release 
>>>> process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to 
>>>> release a bug fix release for 1.1?
>>>> For example, we may be specifically interested in getting a new release 
>>>> with this issue resolved:
>>>> https://issues.apache.org/jira/browse/FOP-2157
>>>> 
>>>> (in the ticket I have attached a fix for the same).
>>>> 
>>>> Is there something we could do to support you in the process?
>>>> 
>>>> Thank you,
>>>> 
>>>> Jacopo
>> 
>> 
> 

Re: Question on FOP release schedule

[Chris Bowditch]

Hi Jacopo,

Thanks for your contribution. I wonder why you ask for a bug fix release 
of 1.1? v2.0 will include all bug fixes since the v1.1 release, there 
are no plans for a 1.1.2 release or similar. We are working towards a 
v2.0 release of FOP. We've just released XML Graphics Commons v2.0, but 
the FOP release is dependent on other libraries being released first.


Thanks,

Chris

On 03/10/2014 06:49, Jacopo Cappellato wrote:

Thank you Luis,

I have attached to Jira a Junit test for the CompareUtil.equal method that 
should prove the issue we are facing and should confirm that the fix I am 
proposing should work ok.
As regards the bug fix release, at the moment this is the only issue that I am 
aware of that is causing some pain to OFBiz and having a bug fix release for it 
would be great; however I know that the release workflow requires a good amount 
of work and I am wondering if I or other OFBiz committers may be of any help in 
the release process (e.g. we could help the FOP community to maintain a release 
branch for 1.1 by backporting fixes to it and testing it).
I am wide open to any suggestions. Of course OFBiz will upgrade to the new 
release 2.0 as soon as this will be available and we will help you to test that 
as well. All in all I am just trying to give something back to the FOP 
community, since the OFBiz community has been a rather silent and passive user 
of your amazing tool :-)

Regards,

Jacopo

On Oct 3, 2014, at 1:15 AM, Luis Bernardo  wrote:


I can apply your patch although I do not have the environment to test it.

Regarding the question about a bug fix for 1.1, the answer is that there is 
nothing planned but if there is interest from the FOP users I think that can be 
accommodated. Is there any other bug your would like to see fixed in a 1.1+ 
release?

On 10/2/14, 7:22 PM, Jacopo Cappellato wrote:

Hi all,

I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this 
amazing product).

I hope this is the right list to get some information about the release process 
and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a 
bug fix release for 1.1?
For example, we may be specifically interested in getting a new release with 
this issue resolved:
https://issues.apache.org/jira/browse/FOP-2157

(in the ticket I have attached a fix for the same).

Is there something we could do to support you in the process?

Thank you,

Jacopo

Re: Question on FOP release schedule

[Jacopo Cappellato]

Thank you Luis,

I have attached to Jira a Junit test for the CompareUtil.equal method that 
should prove the issue we are facing and should confirm that the fix I am 
proposing should work ok.
As regards the bug fix release, at the moment this is the only issue that I am 
aware of that is causing some pain to OFBiz and having a bug fix release for it 
would be great; however I know that the release workflow requires a good amount 
of work and I am wondering if I or other OFBiz committers may be of any help in 
the release process (e.g. we could help the FOP community to maintain a release 
branch for 1.1 by backporting fixes to it and testing it).
I am wide open to any suggestions. Of course OFBiz will upgrade to the new 
release 2.0 as soon as this will be available and we will help you to test that 
as well. All in all I am just trying to give something back to the FOP 
community, since the OFBiz community has been a rather silent and passive user 
of your amazing tool :-)

Regards,

Jacopo

On Oct 3, 2014, at 1:15 AM, Luis Bernardo  wrote:

> 
> I can apply your patch although I do not have the environment to test it.
> 
> Regarding the question about a bug fix for 1.1, the answer is that there is 
> nothing planned but if there is interest from the FOP users I think that can 
> be accommodated. Is there any other bug your would like to see fixed in a 
> 1.1+ release?
> 
> On 10/2/14, 7:22 PM, Jacopo Cappellato wrote:
>> Hi all,
>> 
>> I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for 
>> this amazing product).
>> 
>> I hope this is the right list to get some information about the release 
>> process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to 
>> release a bug fix release for 1.1?
>> For example, we may be specifically interested in getting a new release with 
>> this issue resolved:
>> https://issues.apache.org/jira/browse/FOP-2157
>> 
>> (in the ticket I have attached a fix for the same).
>> 
>> Is there something we could do to support you in the process?
>> 
>> Thank you,
>> 
>> Jacopo
> 

Re: Question on FOP release schedule

[Luis Bernardo]

I can apply your patch although I do not have the environment to test it.

Regarding the question about a bug fix for 1.1, the answer is that there 
is nothing planned but if there is interest from the FOP users I think 
that can be accommodated. Is there any other bug your would like to see 
fixed in a 1.1+ release?


On 10/2/14, 7:22 PM, Jacopo Cappellato wrote:

Hi all,

I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this 
amazing product).

I hope this is the right list to get some information about the release process 
and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a 
bug fix release for 1.1?
For example, we may be specifically interested in getting a new release with 
this issue resolved:
https://issues.apache.org/jira/browse/FOP-2157

(in the ticket I have attached a fix for the same).

Is there something we could do to support you in the process?

Thank you,

Jacopo

Question on FOP release schedule

[Jacopo Cappellato]

Hi all,

I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this 
amazing product).

I hope this is the right list to get some information about the release process 
and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a 
bug fix release for 1.1?
For example, we may be specifically interested in getting a new release with 
this issue resolved:
https://issues.apache.org/jira/browse/FOP-2157

(in the ticket I have attached a fix for the same).

Is there something we could do to support you in the process?

Thank you,

Jacopo

Re: New FOP Release [was: Re: FOP Release Automation]

[Chris Bowditch]

Hi Glenn,

The original plan was for Robert Meyer to handle the release. I've moved 
him to a different project for a while, so I then decided Vincent should 
be our volunteer ;-)


However, it came to light that there is an unwritten policy that 
releases can't depend on snapshots of other projects. So that's causing 
us a problem for the pdf-plugin and font merging enhancement, which is 
one of several key features in this release. The PMC needs to decide if 
a snapshot dependency is acceptable or whether we should wait for PDFBox 
v2.0 to be released.


Vincent is currently looking additional bugs to fix before the release. 
Can we continue this discussion on general@ please, since this affects 
all projects, not just FOP


Thanks,

Chris

On 16/07/2014 18:33, Glenn Adams wrote:




On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert 
mailto:vhenneb...@gmail.com>> wrote:


On 16/07/14 17:42, Simon Steiner wrote:

Hi,

I switched fop back to fontbox 1.8, so its only the pdfplugin
that uses 2.0 and the user would delete 1.8 jar if copying
pdfplugin to fop.


Thanks Simon. That’s great because that means that we can start the
release process of FOP as soon as we are ready.


It would be nice to share the following info:

  * who is going to take the lead on performing the release?
  * what is a tentative schedule for release, e.g., when should last
changes be integrated?
  * what additional integrations (if known) are planned before release?



Vincent


Thanks

-Original Message-
From: Vincent Hennebert [mailto:vhenneb...@gmail.com
<mailto:vhenneb...@gmail.com>]
Sent: 16 July 2014 12:56
To: fop-dev@xmlgraphics.apache.org
<mailto:fop-dev@xmlgraphics.apache.org>
Subject: New FOP Release [was: Re: FOP Release Automation]

Hi,

On 15/07/14 16:53, Clay Leeds wrote:

On Jul 15, 2014, at 7:46 AM, Glenn Adams mailto:gl...@skynav.com>> wrote:

I suppose it depends on whether or not we need to hack
perl to use the facility. If there is any alternative
that doesn't use perl, then that would be preferable.

Frankly, I've never been happy with the new MD based
documentation, though Clay has spent an inordinate
amount of time tweaking it.


Yeah... It's not my favorite either, but at least edits
are pretty quick, saved to SVN and we've got a solution to
incorporate javadoc, etc.

In the meantime, please let me know when we're ready to
update the
documentation for the Release. It doesn't take me very
long to go
through the code to make these types of batch edits.



Clay, your offer to help would be greatly appreciated!

And since you’re mentioning it, maybe it’s time to think about
making a new release of FOP. Although now that the font
merging code has been merged to trunk, and introduces a
dependency on FontBox 2.0.0, we would have to wait that
FontBox 2.0.0 is released first. Or adapt the code to keep the
former 1.8.5 dependency (or the newer 1.8.6 released version).

In the meantime, can anybody think of features that should
definitely be implemented before the release, or bugs fixed?
Remember that due to API changes, that release will have to be
called 2.0.

Thanks,
Vincent

Re: New FOP Release [was: Re: FOP Release Automation]

[Glenn Adams]

On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert 
wrote:

> On 16/07/14 17:42, Simon Steiner wrote:
>
>> Hi,
>>
>> I switched fop back to fontbox 1.8, so its only the pdfplugin that uses
>> 2.0 and the user would delete 1.8 jar if copying pdfplugin to fop.
>>
>
> Thanks Simon. That’s great because that means that we can start the
> release process of FOP as soon as we are ready.
>

It would be nice to share the following info:

   - who is going to take the lead on performing the release?
   - what is a tentative schedule for release, e.g., when should last
   changes be integrated?
   - what additional integrations (if known) are planned before release?




>
> Vincent
>
>
>  Thanks
>>
>> -Original Message-
>> From: Vincent Hennebert [mailto:vhenneb...@gmail.com]
>> Sent: 16 July 2014 12:56
>> To: fop-dev@xmlgraphics.apache.org
>> Subject: New FOP Release [was: Re: FOP Release Automation]
>>
>> Hi,
>>
>> On 15/07/14 16:53, Clay Leeds wrote:
>>
>>> On Jul 15, 2014, at 7:46 AM, Glenn Adams  wrote:
>>>
>>>> I suppose it depends on whether or not we need to hack perl to use the
>>>> facility. If there is any alternative that doesn't use perl, then that
>>>> would be preferable.
>>>>
>>>> Frankly, I've never been happy with the new MD based documentation,
>>>> though Clay has spent an inordinate amount of time tweaking it.
>>>>
>>>
>>> Yeah... It's not my favorite either, but at least edits are pretty
>>> quick, saved to SVN and we've got a solution to incorporate javadoc, etc.
>>>
>>> In the meantime, please let me know when we're ready to update the
>>> documentation for the Release. It doesn't take me very long to go
>>> through the code to make these types of batch edits.
>>>
>> 
>>
>> Clay, your offer to help would be greatly appreciated!
>>
>> And since you’re mentioning it, maybe it’s time to think about making a
>> new release of FOP. Although now that the font merging code has been merged
>> to trunk, and introduces a dependency on FontBox 2.0.0, we would have to
>> wait that FontBox 2.0.0 is released first. Or adapt the code to keep the
>> former 1.8.5 dependency (or the newer 1.8.6 released version).
>>
>> In the meantime, can anybody think of features that should definitely be
>> implemented before the release, or bugs fixed? Remember that due to API
>> changes, that release will have to be called 2.0.
>>
>> Thanks,
>> Vincent
>>
>>

Re: New FOP Release [was: Re: FOP Release Automation]

[Vincent Hennebert]

On 16/07/14 17:42, Simon Steiner wrote:

Hi,

I switched fop back to fontbox 1.8, so its only the pdfplugin that uses 2.0 and 
the user would delete 1.8 jar if copying pdfplugin to fop.


Thanks Simon. That’s great because that means that we can start the
release process of FOP as soon as we are ready.

Vincent



Thanks

-Original Message-
From: Vincent Hennebert [mailto:vhenneb...@gmail.com]
Sent: 16 July 2014 12:56
To: fop-dev@xmlgraphics.apache.org
Subject: New FOP Release [was: Re: FOP Release Automation]

Hi,

On 15/07/14 16:53, Clay Leeds wrote:

On Jul 15, 2014, at 7:46 AM, Glenn Adams  wrote:

I suppose it depends on whether or not we need to hack perl to use the 
facility. If there is any alternative that doesn't use perl, then that would be 
preferable.

Frankly, I've never been happy with the new MD based documentation, though Clay 
has spent an inordinate amount of time tweaking it.


Yeah... It's not my favorite either, but at least edits are pretty quick, saved 
to SVN and we've got a solution to incorporate javadoc, etc.

In the meantime, please let me know when we're ready to update the
documentation for the Release. It doesn't take me very long to go
through the code to make these types of batch edits.



Clay, your offer to help would be greatly appreciated!

And since you’re mentioning it, maybe it’s time to think about making a new 
release of FOP. Although now that the font merging code has been merged to 
trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that 
FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 
dependency (or the newer 1.8.6 released version).

In the meantime, can anybody think of features that should definitely be 
implemented before the release, or bugs fixed? Remember that due to API 
changes, that release will have to be called 2.0.

Thanks,
Vincent

RE: New FOP Release [was: Re: FOP Release Automation]

[Simon Steiner]

Hi,

I switched fop back to fontbox 1.8, so its only the pdfplugin that uses 2.0 and 
the user would delete 1.8 jar if copying pdfplugin to fop.

Thanks

-Original Message-
From: Vincent Hennebert [mailto:vhenneb...@gmail.com] 
Sent: 16 July 2014 12:56
To: fop-dev@xmlgraphics.apache.org
Subject: New FOP Release [was: Re: FOP Release Automation]

Hi,

On 15/07/14 16:53, Clay Leeds wrote:
> On Jul 15, 2014, at 7:46 AM, Glenn Adams  wrote:
>> I suppose it depends on whether or not we need to hack perl to use the 
>> facility. If there is any alternative that doesn't use perl, then that would 
>> be preferable.
>>
>> Frankly, I've never been happy with the new MD based documentation, though 
>> Clay has spent an inordinate amount of time tweaking it.
>
> Yeah... It's not my favorite either, but at least edits are pretty quick, 
> saved to SVN and we've got a solution to incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to update the 
> documentation for the Release. It doesn't take me very long to go 
> through the code to make these types of batch edits.


Clay, your offer to help would be greatly appreciated!

And since you’re mentioning it, maybe it’s time to think about making a new 
release of FOP. Although now that the font merging code has been merged to 
trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that 
FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 
dependency (or the newer 1.8.6 released version).

In the meantime, can anybody think of features that should definitely be 
implemented before the release, or bugs fixed? Remember that due to API 
changes, that release will have to be called 2.0.

Thanks,
Vincent

New FOP Release [was: Re: FOP Release Automation]

[Vincent Hennebert]

Hi,

On 15/07/14 16:53, Clay Leeds wrote:

On Jul 15, 2014, at 7:46 AM, Glenn Adams  wrote:

I suppose it depends on whether or not we need to hack perl to use the 
facility. If there is any alternative that doesn't use perl, then that would be 
preferable.

Frankly, I've never been happy with the new MD based documentation, though Clay 
has spent an inordinate amount of time tweaking it.


Yeah... It's not my favorite either, but at least edits are pretty quick, saved 
to SVN and we've got a solution to incorporate javadoc, etc.

In the meantime, please let me know when we're ready to update the
documentation for the Release. It doesn't take me very long to go
through the code to make these types of batch edits.



Clay, your offer to help would be greatly appreciated!

And since you’re mentioning it, maybe it’s time to think about making
a new release of FOP. Although now that the font merging code has been
merged to trunk, and introduces a dependency on FontBox 2.0.0, we would
have to wait that FontBox 2.0.0 is released first. Or adapt the code to
keep the former 1.8.5 dependency (or the newer 1.8.6 released version).

In the meantime, can anybody think of features that should definitely be
implemented before the release, or bugs fixed? Remember that due to API
changes, that release will have to be called 2.0.

Thanks,
Vincent

RE: FOP Release Automation

[Robert Meyer]

To use this utility it will require modification of our own Perl modules found 
on the FOP SVN site. Whether that requires just a change to the patterns 
(path.pm file) or the more complicated requirement of writing our own pattern 
subroutine (in the view.pm) I am not yet sure. Unfortunately though I'll have 
to park this as I currently have no more time I can spend on it but as I said 
will keep my eye on it and let you know if anything progresses.

In the meantime I am guessing there will be a vote to release fairly soon which 
will result in the documentation needing to be updated.

> Subject: Re: FOP Release Automation
> From: the.webmaes...@gmail.com
> Date: Tue, 15 Jul 2014 07:53:19 -0700
> To: fop-dev@xmlgraphics.apache.org
> 
> On Jul 15, 2014, at 7:46 AM, Glenn Adams  wrote:
> > I suppose it depends on whether or not we need to hack perl to use the 
> > facility. If there is any alternative that doesn't use perl, then that 
> > would be preferable.
> > 
> > Frankly, I've never been happy with the new MD based documentation, though 
> > Clay has spent an inordinate amount of time tweaking it.
> 
> Yeah... It's not my favorite either, but at least edits are pretty quick, 
> saved to SVN and we've got a solution to incorporate javadoc, etc. 
> 
> In the meantime, please let me know when we're ready to update the 
> documentation for the Release. It doesn't take me very long to go through the 
> code to make these types of batch edits. I'm good at this, and who knows, I 
> might even spend the time to write some bash script to help us with the 
> deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I 
> think that's how to write a smiley with a tongue-in-cheek? :-D)
  

Re: FOP Release Automation

[Glenn Adams]

I prefer python but bash is fine. OTOH, anything written by Larry Wall
should be avoided like the plague.


On Tue, Jul 15, 2014 at 8:53 AM, Clay Leeds 
wrote:

> On Jul 15, 2014, at 7:46 AM, Glenn Adams  wrote:
> > I suppose it depends on whether or not we need to hack perl to use the
> facility. If there is any alternative that doesn't use perl, then that
> would be preferable.
> >
> > Frankly, I've never been happy with the new MD based documentation,
> though Clay has spent an inordinate amount of time tweaking it.
>
> Yeah... It's not my favorite either, but at least edits are pretty quick,
> saved to SVN and we've got a solution to incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to update the
> documentation for the Release. It doesn't take me very long to go through
> the code to make these types of batch edits. I'm good at this, and who
> knows, I might even spend the time to write some bash script to help us
> with the deployment! (you don't have anything against BASH, do ya Glenn?)
> :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)

Re: FOP Release Automation

[Clay Leeds]

On Jul 15, 2014, at 7:46 AM, Glenn Adams  wrote:
> I suppose it depends on whether or not we need to hack perl to use the 
> facility. If there is any alternative that doesn't use perl, then that would 
> be preferable.
> 
> Frankly, I've never been happy with the new MD based documentation, though 
> Clay has spent an inordinate amount of time tweaking it.

Yeah... It's not my favorite either, but at least edits are pretty quick, saved 
to SVN and we've got a solution to incorporate javadoc, etc. 

In the meantime, please let me know when we're ready to update the 
documentation for the Release. It doesn't take me very long to go through the 
code to make these types of batch edits. I'm good at this, and who knows, I 
might even spend the time to write some bash script to help us with the 
deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I think 
that's how to write a smiley with a tongue-in-cheek? :-D)

Re: FOP Release Automation

[Glenn Adams]

I suppose it depends on whether or not we need to hack perl to use the
facility. If there is any alternative that doesn't use perl, then that
would be preferable.

Frankly, I've never been happy with the new MD based documentation, though
Clay has spent an inordinate amount of time tweaking it.


On Tue, Jul 15, 2014 at 8:30 AM, Clay Leeds 
wrote:

> Considering ASF-CMS is written in Perl, I wouldn't discount Perl
> out-of-hand. However, IMFO (sorry! Typo, but I could t bring myself to
> change it! ;-) I would think a solution blessed by infra@ would be
> acceptable, especially if they'll bless and/or maintain it!
>
> Cheers!
>
> Clay
>
> --
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
>
> On Jul 15, 2014, at 7:01 AM, Glenn Adams  wrote:
>
> I will -1 any proposal that involves using Perl.
>
>
> On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer 
> wrote:
>
>> Hi All,
>>
>> This is an update into my investigations on automating the release
>> process for FOP. As we're nearing release it looks as though version 2.0
>> will remain a manual process for the time being. That's not to say that it
>> will forever remain like that but at present unless a breakthrough occurs
>> or I receive some feedback from the infrastructure team, I don't currently
>> have the necessary knowledge on the Apache infrastructure (or Perl know
>> how) to achieve the desired result despite my efforts.
>>
>> During the time since my last message I found a solution using a markdown
>> extension. This appeared to fulfil all of our requirements and after
>> writing and testing one, it seemed to simply be a case of installing it.
>> Due to the nature of Apache's websites this was not something I could do
>> myself as we don't have control over the CMS. After raising a ticket with
>> the infrastructure team about doing this, I was pointed to another project
>> called Thrift. Their site appeared to provide tag replacement using
>> preexisting functionality found in the perl modules of the Apache CMS.
>>
>> After reading the documentation and experimenting I've reached somewhat
>> of an impasse due to a number of reasons. Firstly the documentation on
>> customizing these patterns is limited and covers only basic patterns.
>> Second, my own experience with Perl is lacking and as such makes it hard to
>> debug and understand some of the more complicated required modules and
>> sections of the CMS. Finally during my testing the errors I was getting
>> were extremely unhelpful and provide next to no clues as to where the
>> problem lay in my own code. Instead they point to the Perl CMS libraries
>> highlighting missing expected characters and at a guess incompatibilities
>> between the markdown we're using and what's expected by the pattern's own
>> subroutine.
>>
>> I have tried to follow and utilize the code found in the Thrift project
>> with little luck. I have posted on the infrastructure mailing list for help
>> but as of yet have not had any responses. I am guessing this is not a
>> commonly used feature and as such knowledge on the subject may be in short
>> supply. As such and without possibility of using the markdown extension
>> we're left with the manual process for the time being. I will keep an eye
>> out on the infrastructure page and prod them occasionally to see if I can
>> move things along.
>>
>> Apologies for the long e-mail but just wanted to keep you all updated.
>>
>> Robert Meyer
>>
>> > Date: Mon, 2 Jun 2014 14:44:58 +0100
>> > From: bowditch_ch...@hotmail.com
>> > To: fop-dev@xmlgraphics.apache.org
>> > Subject: Re: FOP Release Automation
>> >
>> > Hi All,
>> >
>> > I certainly use the web interface when making small tweaks to the docs.
>> > As you know users occasionally report small mistakes that require minor
>> > tweaks. I'd like to streamline the updating of the website for release
>> > purposes but I don't want to disable/prevent the current web
>> > interface which works well when all you want to do is make a minor
>> > adjustment in response to a user e-mail.
>> >
>> > Rob is away this week, but he will continue the investigation into
>> > scripting the website updates when he returns.
>> >
>> > Thanks for the ideas so far, a few promising leads.
>> >
>> > Thanks,
>> >
>> > Chris
>> >
>> > On 30/05/2014 17:23, Clay Leeds wrote:
>> >

Re: FOP Release Automation

[Clay Leeds]

Considering ASF-CMS is written in Perl, I wouldn't discount Perl out-of-hand. 
However, IMFO (sorry! Typo, but I could t bring myself to change it! ;-) I 
would think a solution blessed by infra@ would be acceptable, especially if 
they'll bless and/or maintain it!
Cheers!

Clay

--

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

> On Jul 15, 2014, at 7:01 AM, Glenn Adams  wrote:
> 
> I will -1 any proposal that involves using Perl.
> 
> 
>> On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer  wrote:
>> Hi All,
>> 
>> This is an update into my investigations on automating the release process 
>> for FOP. As we're nearing release it looks as though version 2.0 will remain 
>> a manual process for the time being. That's not to say that it will forever 
>> remain like that but at present unless a breakthrough occurs or I receive 
>> some feedback from the infrastructure team, I don't currently have the 
>> necessary knowledge on the Apache infrastructure (or Perl know how) to 
>> achieve the desired result despite my efforts.
>> 
>> During the time since my last message I found a solution using a markdown 
>> extension. This appeared to fulfil all of our requirements and after writing 
>> and testing one, it seemed to simply be a case of installing it. Due to the 
>> nature of Apache's websites this was not something I could do myself as we 
>> don't have control over the CMS. After raising a ticket with the 
>> infrastructure team about doing this, I was pointed to another project 
>> called Thrift. Their site appeared to provide tag replacement using 
>> preexisting functionality found in the perl modules of the Apache CMS.
>> 
>> After reading the documentation and experimenting I've reached somewhat of 
>> an impasse due to a number of reasons. Firstly the documentation on 
>> customizing these patterns is limited and covers only basic patterns. 
>> Second, my own experience with Perl is lacking and as such makes it hard to 
>> debug and understand some of the more complicated required modules and 
>> sections of the CMS. Finally during my testing the errors I was getting were 
>> extremely unhelpful and provide next to no clues as to where the problem lay 
>> in my own code. Instead they point to the Perl CMS libraries highlighting 
>> missing expected characters and at a guess incompatibilities between the 
>> markdown we're using and what's expected by the pattern's own subroutine.
>> 
>> I have tried to follow and utilize the code found in the Thrift project with 
>> little luck. I have posted on the infrastructure mailing list for help but 
>> as of yet have not had any responses. I am guessing this is not a commonly 
>> used feature and as such knowledge on the subject may be in short supply. As 
>> such and without possibility of using the markdown extension we're left with 
>> the manual process for the time being. I will keep an eye out on the 
>> infrastructure page and prod them occasionally to see if I can move things 
>> along.
>> 
>> Apologies for the long e-mail but just wanted to keep you all updated.
>> 
>> Robert Meyer
>> 
>> > Date: Mon, 2 Jun 2014 14:44:58 +0100
>> > From: bowditch_ch...@hotmail.com
>> > To: fop-dev@xmlgraphics.apache.org
>> > Subject: Re: FOP Release Automation
>> > 
>> > Hi All,
>> > 
>> > I certainly use the web interface when making small tweaks to the docs. 
>> > As you know users occasionally report small mistakes that require minor 
>> > tweaks. I'd like to streamline the updating of the website for release 
>> > purposes but I don't want to disable/prevent the current web
>> > interface which works well when all you want to do is make a minor 
>> > adjustment in response to a user e-mail.
>> > 
>> > Rob is away this week, but he will continue the investigation into 
>> > scripting the website updates when he returns.
>> > 
>> > Thanks for the ideas so far, a few promising leads.
>> > 
>> > Thanks,
>> > 
>> > Chris
>> > 
>> > On 30/05/2014 17:23, Clay Leeds wrote:
>> > > Agreed, ‘some’ people wouldn’t be happy with that. ;-)
>> > >
>> > > I wonder if the CMS Web interface could be extended to allow for a few 
>> > > keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
>> > >
>> > > The CMS tool's WYSIWYG interface indicates it uses the Wysiwym 
>> > > MarkDown Edi

Re: FOP Release Automation

[Glenn Adams]

I will -1 any proposal that involves using Perl.


On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer  wrote:

> Hi All,
>
> This is an update into my investigations on automating the release process
> for FOP. As we're nearing release it looks as though version 2.0 will
> remain a manual process for the time being. That's not to say that it will
> forever remain like that but at present unless a breakthrough occurs or I
> receive some feedback from the infrastructure team, I don't currently have
> the necessary knowledge on the Apache infrastructure (or Perl know how) to
> achieve the desired result despite my efforts.
>
> During the time since my last message I found a solution using a markdown
> extension. This appeared to fulfil all of our requirements and after
> writing and testing one, it seemed to simply be a case of installing it.
> Due to the nature of Apache's websites this was not something I could do
> myself as we don't have control over the CMS. After raising a ticket with
> the infrastructure team about doing this, I was pointed to another project
> called Thrift. Their site appeared to provide tag replacement using
> preexisting functionality found in the perl modules of the Apache CMS.
>
> After reading the documentation and experimenting I've reached somewhat of
> an impasse due to a number of reasons. Firstly the documentation on
> customizing these patterns is limited and covers only basic patterns.
> Second, my own experience with Perl is lacking and as such makes it hard to
> debug and understand some of the more complicated required modules and
> sections of the CMS. Finally during my testing the errors I was getting
> were extremely unhelpful and provide next to no clues as to where the
> problem lay in my own code. Instead they point to the Perl CMS libraries
> highlighting missing expected characters and at a guess incompatibilities
> between the markdown we're using and what's expected by the pattern's own
> subroutine.
>
> I have tried to follow and utilize the code found in the Thrift project
> with little luck. I have posted on the infrastructure mailing list for help
> but as of yet have not had any responses. I am guessing this is not a
> commonly used feature and as such knowledge on the subject may be in short
> supply. As such and without possibility of using the markdown extension
> we're left with the manual process for the time being. I will keep an eye
> out on the infrastructure page and prod them occasionally to see if I can
> move things along.
>
> Apologies for the long e-mail but just wanted to keep you all updated.
>
> Robert Meyer
>
> > Date: Mon, 2 Jun 2014 14:44:58 +0100
> > From: bowditch_ch...@hotmail.com
> > To: fop-dev@xmlgraphics.apache.org
> > Subject: Re: FOP Release Automation
> >
> > Hi All,
> >
> > I certainly use the web interface when making small tweaks to the docs.
> > As you know users occasionally report small mistakes that require minor
> > tweaks. I'd like to streamline the updating of the website for release
> > purposes but I don't want to disable/prevent the current web
> > interface which works well when all you want to do is make a minor
> > adjustment in response to a user e-mail.
> >
> > Rob is away this week, but he will continue the investigation into
> > scripting the website updates when he returns.
> >
> > Thanks for the ideas so far, a few promising leads.
> >
> > Thanks,
> >
> > Chris
> >
> > On 30/05/2014 17:23, Clay Leeds wrote:
> > > Agreed, ‘some’ people wouldn’t be happy with that. ;-)
> > >
> > > I wonder if the CMS Web interface could be extended to allow for a few
> > > keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
> > >
> > > The CMS tool's WYSIWYG interface indicates it uses the Wysiwym
> > > MarkDown Editor, which is extensible:
> > >
> > > https://web.archive.org/web/20110121060932/http://wmd-editor.com/
> > >
> > > (site’s down & hasn’t been updated since 2011)...
> > >
> > > or
> > >
> > > https://code.google.com/p/wmd/
> > >
> > > We might still need to do some ANT hanky panky, but at least if we
> > > could leverage WMD’s extensibility it would help us get where we’re
> > > trying to go?
> > >
> > > Clay
> > >
> > > On May 30, 2014, at 7:19 AM, Robert Meyer  > > <mailto:rme...@hotmail.co.uk>> wrote:
> > >> Hi,
> > >>
> > >> I like the simplicity of your idea, but the web interface is not so
> >

RE: FOP Release Automation

[Robert Meyer]

Hi All,

This is an update into my investigations on automating the release process for 
FOP. As we're nearing release it looks as though version 2.0 will remain a 
manual process for the time being. That's not to say that it will forever 
remain like that but at present unless a breakthrough occurs or I receive some 
feedback from the infrastructure team, I don't currently have the necessary 
knowledge on the Apache infrastructure (or Perl know how) to achieve the 
desired result despite my efforts.

During the time since my last message I found a solution using a markdown 
extension. This appeared to fulfil all of our requirements and after writing 
and testing one, it seemed to simply be a case of installing it. Due to the 
nature of Apache's websites this was not something I could do myself as we 
don't have control over the CMS. After raising a ticket with the infrastructure 
team about doing this, I was pointed to another project called Thrift. Their 
site appeared to provide tag replacement using preexisting functionality found 
in the perl modules of the Apache CMS.

After reading the documentation and experimenting I've reached somewhat of an 
impasse due to a number of reasons. Firstly the documentation on customizing 
these patterns is limited and covers only basic patterns. Second, my own 
experience with Perl is lacking and as such makes it hard to debug and 
understand some of the more complicated required modules and sections of the 
CMS. Finally during my testing the errors I was getting were extremely 
unhelpful and provide next to no clues as to where the problem lay in my own 
code. Instead they point to the Perl CMS libraries highlighting missing 
expected characters and at a guess incompatibilities between the markdown we're 
using and what's expected by the pattern's own subroutine.

I have tried to follow and utilize the code found in the Thrift project with 
little luck. I have posted on the infrastructure mailing list for help but as 
of yet have not had any responses. I am guessing this is not a commonly used 
feature and as such knowledge on the subject may be in short supply. As such 
and without possibility of using the markdown extension we're left with the 
manual process for the time being. I will keep an eye out on the infrastructure 
page and prod them occasionally to see if I can move things along.

Apologies for the long e-mail but just wanted to keep you all updated.

Robert Meyer

> Date: Mon, 2 Jun 2014 14:44:58 +0100
> From: bowditch_ch...@hotmail.com
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: FOP Release Automation
> 
> Hi All,
> 
> I certainly use the web interface when making small tweaks to the docs. 
> As you know users occasionally report small mistakes that require minor 
> tweaks. I'd like to streamline the updating of the website for release 
> purposes but I don't want to disable/prevent the current web
> interface which works well when all you want to do is make a minor 
> adjustment in response to a user e-mail.
> 
> Rob is away this week, but he will continue the investigation into 
> scripting the website updates when he returns.
> 
> Thanks for the ideas so far, a few promising leads.
> 
> Thanks,
> 
> Chris
> 
> On 30/05/2014 17:23, Clay Leeds wrote:
> > Agreed, ‘some’ people wouldn’t be happy with that. ;-)
> >
> > I wonder if the CMS Web interface could be extended to allow for a few 
> > keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
> >
> > The CMS tool's WYSIWYG interface indicates it uses the Wysiwym 
> > MarkDown Editor, which is extensible:
> >
> > https://web.archive.org/web/20110121060932/http://wmd-editor.com/
> >
> > (site’s down & hasn’t been updated since 2011)...
> >
> > or
> >
> > https://code.google.com/p/wmd/
> >
> > We might still need to do some ANT hanky panky, but at least if we 
> > could leverage WMD’s extensibility it would help us get where we’re 
> > trying to go?
> >
> > Clay
> >
> > On May 30, 2014, at 7:19 AM, Robert Meyer  > <mailto:rme...@hotmail.co.uk>> wrote:
> >> Hi,
> >>
> >> I like the simplicity of your idea, but the web interface is not so 
> >> easy to dismiss unfortunately.
> >>
> >> If you do have a copy with those tags in, if any changes are made on 
> >> the web interface then that copy would become out of date.
> >>
> >> We could always shutdown the web interface, but I don't think too 
> >> many people would be happy with that ;-)
> >>
> >> Regards,
> >>
> >> Robert
> >>
> >> 
> 

Re: FOP Release Automation

[Chris Bowditch]

Hi All,

I certainly use the web interface when making small tweaks to the docs. 
As you know users occasionally report small mistakes that require minor 
tweaks. I'd like to streamline the updating of the website for release 
purposes but I don't want to disable/prevent the current web
interface which works well when all you want to do is make a minor 
adjustment in response to a user e-mail.


Rob is away this week, but he will continue the investigation into 
scripting the website updates when he returns.


Thanks for the ideas so far, a few promising leads.

Thanks,

Chris

On 30/05/2014 17:23, Clay Leeds wrote:

Agreed, ‘some’ people wouldn’t be happy with that. ;-)

I wonder if the CMS Web interface could be extended to allow for a few 
keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.


The CMS tool's WYSIWYG interface indicates it uses the Wysiwym 
MarkDown Editor, which is extensible:


https://web.archive.org/web/20110121060932/http://wmd-editor.com/

(site’s down & hasn’t been updated since 2011)...

or

https://code.google.com/p/wmd/

We might still need to do some ANT hanky panky, but at least if we 
could leverage WMD’s extensibility it would help us get where we’re 
trying to go?


Clay

On May 30, 2014, at 7:19 AM, Robert Meyer <mailto:rme...@hotmail.co.uk>> wrote:

Hi,

I like the simplicity of your idea, but the web interface is not so 
easy to dismiss unfortunately.


If you do have a copy with those tags in, if any changes are made on 
the web interface then that copy would become out of date.


We could always shutdown the web interface, but I don't think too 
many people would be happy with that ;-)


Regards,

Robert


From: simonsteiner1...@gmail.com <mailto:simonsteiner1...@gmail.com>
To: fop-dev@xmlgraphics.apache.org 
<mailto:fop-dev@xmlgraphics.apache.org>

Subject: RE: FOP Release Automation
Date: Fri, 30 May 2014 14:48:15 +0100

Hi,

Simple way is to store docs inside fop repo:

Fop/docs/index.markdown

Inside markdown file you reference ant properties eg:
${version}

Then you call which does ant expandproperties and calls markdown to 
html tool:

ant docs

Then you call which does a zip, scp and unzip of html files to web 
server:

ant upload-docs

This method doesn’t support web interface of editing files but I 
don’t see how this is really needed.
If I submit a patch to fop it should also contain doc changes rather 
than having separate repo and patch for that.


Thanks

*From:*Robert Meyer [mailto:rme...@hotmail.co.uk]
*Sent:*30 May 2014 14:05
*To:*fop-dev@xmlgraphics.apache.org 
<mailto:fop-dev@xmlgraphics.apache.org>

*Subject:*RE: FOP Release Automation

Hi,

After investigating your suggestions Clay I have found that svn-hooks 
can't be used for the purpose we require unfortunately as it may lead 
to problems with how SVN operates and also may have some unexpected 
results with files being committed. This is stated in the 
documentation under "Creating Repository Hooks" highlighted in the 
warning red box further down:


http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html 
<http://www-inst.eecs.berkeley.edu/%7Ecs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html>


Pascal, I agree that the process is fairly straightforward, but I 
have been asked to automate this further so am just looking into 
ideas presently.


I think a possible way forward then would be to use your suggestion 
Pascal of placing the versioned docs for the site inside the FOP 
repository for their associated version. These can then be referenced 
using the svn-externals from the main site repository.


In addition to this, the main site files (which would need to be 
updated) could contain tags for the last three versions which would 
be replaced using Clay's markdown pre-processor suggestion. The 
pre-processor would replace the tags with values stored in a 
properties file in the main site repository.


To create a release, the user would need to update the svn-external 
references to account for the new version and update the properties 
file for tag replacement. When the properties file is pushed it will 
be read by the custom markdown pre-processor and display the new 
version when rendered.


Those two stages could be done using a single script to simplify 
things further, but the main complication is getting the markdown 
pre-processor working. From looking at this page:


http://www.apache.org/dev/cmsref.html#markdown

I am guessing we use PyPy (Python Markdown) which supports 
extensions, so I will look at this shortly to try out a small example 
and investigate the feasibility of doing this. There is also the 
matter of updating the versioned documents for each FOP when a new 
version is released, but maybe this could be done with the 
pre-processor as well.


Anyway, let me know what you think.

Regards,

Robert

Re: FOP Release Automation

[Pascal Sancho]

Hi,

If we go to an svn:externals set in CMS repo, pointing to FOP trunk
doc, and 2 last FOP tagged doc, we should take care about having no
change in TAGs. Perhaps a pre-commit hook can do the job here, warning
the committer, or forbidding the commit propagation.

2014-05-30 23:34 GMT+02:00 Robert Meyer :
> I'll definitely look into those. I'm going to be away on holiday now for a
> week or so but will continue once I get back.
>
> Many thanks!
>
> Robert
> 
> From: Clay Leeds
> Sent: ‎5/‎30/‎2014 17:24
> To: Apache FOP
>
> Subject: Re: FOP Release Automation
>
> Agreed, ‘some’ people wouldn’t be happy with that. ;-)
>
> I wonder if the CMS Web interface could be extended to allow for a few
> keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
>
> The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown
> Editor, which is extensible:
>
> https://web.archive.org/web/20110121060932/http://wmd-editor.com/
>
> (site’s down & hasn’t been updated since 2011)...
>
> or
>
> https://code.google.com/p/wmd/
>
> We might still need to do some ANT hanky panky, but at least if we could
> leverage WMD’s extensibility it would help us get where we’re trying to go?
>
> Clay
>
> On May 30, 2014, at 7:19 AM, Robert Meyer  wrote:
>
> Hi,
>
> I like the simplicity of your idea, but the web interface is not so easy to
> dismiss unfortunately.
>
> If you do have a copy with those tags in, if any changes are made on the web
> interface then that copy would become out of date.
>
> We could always shutdown the web interface, but I don't think too many
> people would be happy with that ;-)
>
> Regards,
>
> Robert
>
> 
> From: simonsteiner1...@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
> Date: Fri, 30 May 2014 14:48:15 +0100
>
> Hi,
>
>
>
> Simple way is to store docs inside fop repo:
>
>
>
> Fop/docs/index.markdown
>
>
>
> Inside markdown file you reference ant properties eg:
> ${version}
>
>
>
> Then you call which does ant expandproperties and calls markdown to html
> tool:
> ant docs
>
>
>
> Then you call which does a zip, scp and unzip of html files to web server:
> ant upload-docs
>
>
>
> This method doesn’t support web interface of editing files but I don’t see
> how this is really needed.
> If I submit a patch to fop it should also contain doc changes rather than
> having separate repo and patch for that.
>
>
>
> Thanks
>
>
>
> From: Robert Meyer [mailto:rme...@hotmail.co.uk]
> Sent: 30 May 2014 14:05
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
>
>
>
> Hi,
>
> After investigating your suggestions Clay I have found that svn-hooks can't
> be used for the purpose we require unfortunately as it may lead to problems
> with how SVN operates and also may have some unexpected results with files
> being committed. This is stated in the documentation under "Creating
> Repository Hooks" highlighted in the warning red box further down:
>
> http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
>
> Pascal, I agree that the process is fairly straightforward, but I have been
> asked to automate this further so am just looking into ideas presently.
>
> I think a possible way forward then would be to use your suggestion Pascal
> of placing the versioned docs for the site inside the FOP repository for
> their associated version. These can then be referenced using the
> svn-externals from the main site repository.
>
> In addition to this, the main site files (which would need to be updated)
> could contain tags for the last three versions which would be replaced using
> Clay's markdown pre-processor suggestion. The pre-processor would replace
> the tags with values stored in a properties file in the main site
> repository.
>
> To create a release, the user would need to update the svn-external
> references to account for the new version and update the properties file for
> tag replacement. When the properties file is pushed it will be read by the
> custom markdown pre-processor and display the new version when rendered.
>
> Those two stages could be done using a single script to simplify things
> further, but the main complication is getting the markdown pre-processor
> working. From looking at this page:
>
> http://www.apache.org/dev/cmsref.html#markdown
>
> I am guessing we use PyPy (Python Markdown) which supports extensions, so I
> will look at this shortly to try out a small example and investigate the
> feasibility of doing this. There is also the matter of updating the
> versioned documents for each FOP when a new version is released, but maybe
> this could be done with the pre-processor as well.
>
> Anyway, let me know what you think.
>
> Regards,
>
> Robert
>
>



-- 
pascal

RE: FOP Release Automation

[Robert Meyer]

I'll definitely look into those. I'm going to be away on holiday now for a week 
or so but will continue once I get back.

Many thanks!

Robert

From: Clay Leeds<mailto:the.webmaes...@gmail.com>
Sent: ‎5/‎30/‎2014 17:24
To: Apache FOP<mailto:fop-dev@xmlgraphics.apache.org>
Subject: Re: FOP Release Automation

Agreed, ‘some’ people wouldn’t be happy with that. ;-)

I wonder if the CMS Web interface could be extended to allow for a few keywords 
like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.

The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown Editor, 
which is extensible:

https://web.archive.org/web/20110121060932/http://wmd-editor.com/

(site’s down & hasn’t been updated since 2011)...

or

https://code.google.com/p/wmd/

We might still need to do some ANT hanky panky, but at least if we could 
leverage WMD’s extensibility it would help us get where we’re trying to go?

Clay

On May 30, 2014, at 7:19 AM, Robert Meyer  wrote:
> Hi,
>
> I like the simplicity of your idea, but the web interface is not so easy to 
> dismiss unfortunately.
>
> If you do have a copy with those tags in, if any changes are made on the web 
> interface then that copy would become out of date.
>
> We could always shutdown the web interface, but I don't think too many people 
> would be happy with that ;-)
>
> Regards,
>
> Robert
>
> From: simonsteiner1...@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
> Date: Fri, 30 May 2014 14:48:15 +0100
>
> Hi,
>
> Simple way is to store docs inside fop repo:
>
> Fop/docs/index.markdown
>
> Inside markdown file you reference ant properties eg:
> ${version}
>
> Then you call which does ant expandproperties and calls markdown to html tool:
> ant docs
>
> Then you call which does a zip, scp and unzip of html files to web server:
> ant upload-docs
>
> This method doesn’t support web interface of editing files but I don’t see 
> how this is really needed.
> If I submit a patch to fop it should also contain doc changes rather than 
> having separate repo and patch for that.
>
> Thanks
>
> From: Robert Meyer [mailto:rme...@hotmail.co.uk]
> Sent: 30 May 2014 14:05
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
>
> Hi,
>
> After investigating your suggestions Clay I have found that svn-hooks can't 
> be used for the purpose we require unfortunately as it may lead to problems 
> with how SVN operates and also may have some unexpected results with files 
> being committed. This is stated in the documentation under "Creating 
> Repository Hooks" highlighted in the warning red box further down:
>
> http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
>
> Pascal, I agree that the process is fairly straightforward, but I have been 
> asked to automate this further so am just looking into ideas presently.
>
> I think a possible way forward then would be to use your suggestion Pascal of 
> placing the versioned docs for the site inside the FOP repository for their 
> associated version. These can then be referenced using the svn-externals from 
> the main site repository.
>
> In addition to this, the main site files (which would need to be updated) 
> could contain tags for the last three versions which would be replaced using 
> Clay's markdown pre-processor suggestion. The pre-processor would replace the 
> tags with values stored in a properties file in the main site repository.
>
> To create a release, the user would need to update the svn-external 
> references to account for the new version and update the properties file for 
> tag replacement. When the properties file is pushed it will be read by the 
> custom markdown pre-processor and display the new version when rendered.
>
> Those two stages could be done using a single script to simplify things 
> further, but the main complication is getting the markdown pre-processor 
> working. From looking at this page:
>
> http://www.apache.org/dev/cmsref.html#markdown
>
> I am guessing we use PyPy (Python Markdown) which supports extensions, so I 
> will look at this shortly to try out a small example and investigate the 
> feasibility of doing this. There is also the matter of updating the versioned 
> documents for each FOP when a new version is released, but maybe this could 
> be done with the pre-processor as well.
>
> Anyway, let me know what you think.
>
> Regards,
>
> Robert

Re: FOP Release Automation

[Clay Leeds]

Agreed, ‘some’ people wouldn’t be happy with that. ;-)

I wonder if the CMS Web interface could be extended to allow for a few keywords 
like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.

The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown Editor, 
which is extensible:

https://web.archive.org/web/20110121060932/http://wmd-editor.com/

(site’s down & hasn’t been updated since 2011)...

or

https://code.google.com/p/wmd/

We might still need to do some ANT hanky panky, but at least if we could 
leverage WMD’s extensibility it would help us get where we’re trying to go?

Clay

On May 30, 2014, at 7:19 AM, Robert Meyer  wrote:
> Hi,
> 
> I like the simplicity of your idea, but the web interface is not so easy to 
> dismiss unfortunately.
> 
> If you do have a copy with those tags in, if any changes are made on the web 
> interface then that copy would become out of date.
> 
> We could always shutdown the web interface, but I don't think too many people 
> would be happy with that ;-)
> 
> Regards,
> 
> Robert
> 
> From: simonsteiner1...@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
> Date: Fri, 30 May 2014 14:48:15 +0100
> 
> Hi,
>  
> Simple way is to store docs inside fop repo:
>  
> Fop/docs/index.markdown
>  
> Inside markdown file you reference ant properties eg:
> ${version}
>  
> Then you call which does ant expandproperties and calls markdown to html tool:
> ant docs
>  
> Then you call which does a zip, scp and unzip of html files to web server:
> ant upload-docs
>  
> This method doesn’t support web interface of editing files but I don’t see 
> how this is really needed.
> If I submit a patch to fop it should also contain doc changes rather than 
> having separate repo and patch for that.
>  
> Thanks
>  
> From: Robert Meyer [mailto:rme...@hotmail.co.uk] 
> Sent: 30 May 2014 14:05
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
>  
> Hi,
> 
> After investigating your suggestions Clay I have found that svn-hooks can't 
> be used for the purpose we require unfortunately as it may lead to problems 
> with how SVN operates and also may have some unexpected results with files 
> being committed. This is stated in the documentation under "Creating 
> Repository Hooks" highlighted in the warning red box further down:
> 
> http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
> 
> Pascal, I agree that the process is fairly straightforward, but I have been 
> asked to automate this further so am just looking into ideas presently.
> 
> I think a possible way forward then would be to use your suggestion Pascal of 
> placing the versioned docs for the site inside the FOP repository for their 
> associated version. These can then be referenced using the svn-externals from 
> the main site repository.
> 
> In addition to this, the main site files (which would need to be updated) 
> could contain tags for the last three versions which would be replaced using 
> Clay's markdown pre-processor suggestion. The pre-processor would replace the 
> tags with values stored in a properties file in the main site repository.
> 
> To create a release, the user would need to update the svn-external 
> references to account for the new version and update the properties file for 
> tag replacement. When the properties file is pushed it will be read by the 
> custom markdown pre-processor and display the new version when rendered.
> 
> Those two stages could be done using a single script to simplify things 
> further, but the main complication is getting the markdown pre-processor 
> working. From looking at this page:
> 
> http://www.apache.org/dev/cmsref.html#markdown
> 
> I am guessing we use PyPy (Python Markdown) which supports extensions, so I 
> will look at this shortly to try out a small example and investigate the 
> feasibility of doing this. There is also the matter of updating the versioned 
> documents for each FOP when a new version is released, but maybe this could 
> be done with the pre-processor as well.
> 
> Anyway, let me know what you think.
> 
> Regards,
> 
> Robert

RE: FOP Release Automation

[Robert Meyer]

Hi,

I like the simplicity of your idea, but the web interface is not so easy to 
dismiss unfortunately.

If you do have a copy with those tags in, if any changes are made on the web 
interface then that copy would become out of date.

We could always shutdown the web interface, but I don't think too many people 
would be happy with that ;-)

Regards,

Robert

From: simonsteiner1...@gmail.com
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Date: Fri, 30 May 2014 14:48:15 +0100

Hi, Simple way is to store docs inside fop repo: Fop/docs/index.markdown Inside 
markdown file you reference ant properties eg:${version} Then you call which 
does ant expandproperties and calls markdown to html tool:ant docs Then you 
call which does a zip, scp and unzip of html files to web server:ant 
upload-docs This method doesn’t support web interface of editing files but I 
don’t see how this is really needed.If I submit a patch to fop it should also 
contain doc changes rather than having separate repo and patch for that. Thanks 
From: Robert Meyer [mailto:rme...@hotmail.co.uk] 
Sent: 30 May 2014 14:05
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation Hi,

After investigating your suggestions Clay I have found that svn-hooks can't be 
used for the purpose we require unfortunately as it may lead to problems with 
how SVN operates and also may have some unexpected results with files being 
committed. This is stated in the documentation under "Creating Repository 
Hooks" highlighted in the warning red box further down:

http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html

Pascal, I agree that the process is fairly straightforward, but I have been 
asked to automate this further so am just looking into ideas presently.

I think a possible way forward then would be to use your suggestion Pascal of 
placing the versioned docs for the site inside the FOP repository for their 
associated version. These can then be referenced using the svn-externals from 
the main site repository.

In addition to this, the main site files (which would need to be updated) could 
contain tags for the last three versions which would be replaced using Clay's 
markdown pre-processor suggestion. The pre-processor would replace the tags 
with values stored in a properties file in the main site repository.

To create a release, the user would need to update the svn-external references 
to account for the new version and update the properties file for tag 
replacement. When the properties file is pushed it will be read by the custom 
markdown pre-processor and display the new version when rendered.

Those two stages could be done using a single script to simplify things 
further, but the main complication is getting the markdown pre-processor 
working. From looking at this page:

http://www.apache.org/dev/cmsref.html#markdown

I am guessing we use PyPy (Python Markdown) which supports extensions, so I 
will look at this shortly to try out a small example and investigate the 
feasibility of doing this. There is also the matter of updating the versioned 
documents for each FOP when a new version is released, but maybe this could be 
done with the pre-processor as well.

Anyway, let me know what you think.

Regards,

Robert

RE: FOP Release Automation

[Simon Steiner]

Hi,

 

Simple way is to store docs inside fop repo:

 

Fop/docs/index.markdown

 

Inside markdown file you reference ant properties eg:

${version}

 

Then you call which does ant expandproperties and calls markdown to html
tool:

ant docs

 

Then you call which does a zip, scp and unzip of html files to web server:

ant upload-docs

 

This method doesn't support web interface of editing files but I don't see
how this is really needed.

If I submit a patch to fop it should also contain doc changes rather than
having separate repo and patch for that.

 

Thanks

 

From: Robert Meyer [mailto:rme...@hotmail.co.uk] 
Sent: 30 May 2014 14:05
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation

 

Hi,

After investigating your suggestions Clay I have found that svn-hooks can't
be used for the purpose we require unfortunately as it may lead to problems
with how SVN operates and also may have some unexpected results with files
being committed. This is stated in the documentation under "Creating
Repository Hooks" highlighted in the warning red box further down:

http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.r
eposadmin.create.html

Pascal, I agree that the process is fairly straightforward, but I have been
asked to automate this further so am just looking into ideas presently.

I think a possible way forward then would be to use your suggestion Pascal
of placing the versioned docs for the site inside the FOP repository for
their associated version. These can then be referenced using the
svn-externals from the main site repository.

In addition to this, the main site files (which would need to be updated)
could contain tags for the last three versions which would be replaced using
Clay's markdown pre-processor suggestion. The pre-processor would replace
the tags with values stored in a properties file in the main site
repository.

To create a release, the user would need to update the svn-external
references to account for the new version and update the properties file for
tag replacement. When the properties file is pushed it will be read by the
custom markdown pre-processor and display the new version when rendered.

Those two stages could be done using a single script to simplify things
further, but the main complication is getting the markdown pre-processor
working. From looking at this page:

http://www.apache.org/dev/cmsref.html#markdown

I am guessing we use PyPy (Python Markdown) which supports extensions, so I
will look at this shortly to try out a small example and investigate the
feasibility of doing this. There is also the matter of updating the
versioned documents for each FOP when a new version is released, but maybe
this could be done with the pre-processor as well.

Anyway, let me know what you think.

Regards,

Robert

RE: FOP Release Automation

[Robert Meyer]

Hi,

After investigating your suggestions Clay I have found that svn-hooks can't be 
used for the purpose we require unfortunately as it may lead to problems with 
how SVN operates and also may have some unexpected results with files being 
committed. This is stated in the documentation under "Creating Repository 
Hooks" highlighted in the warning red box further down:

http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html

Pascal, I agree that the process is fairly straightforward, but I have been 
asked to automate this further so am just looking into ideas presently.

I think a possible way forward then would be to use your suggestion Pascal of 
placing the versioned docs for the site inside the FOP repository for their 
associated version. These can then be referenced using the svn-externals from 
the main site repository.

In addition to this, the main site files (which would need to be updated) could 
contain tags for the last three versions which would be replaced using Clay's 
markdown pre-processor suggestion. The pre-processor would replace the tags 
with values stored in a properties file in the main site repository.

To create a release, the user would need to update the svn-external references 
to account for the new version and update the properties file for tag 
replacement. When the properties file is pushed it will be read by the custom 
markdown pre-processor and display the new version when rendered.

Those two stages could be done using a single script to simplify things 
further, but the main complication is getting the markdown pre-processor 
working. From looking at this page:

http://www.apache.org/dev/cmsref.html#markdown

I am guessing we use PyPy (Python Markdown) which supports extensions, so I 
will look at this shortly to try out a small example and investigate the 
feasibility of doing this. There is also the matter of updating the versioned 
documents for each FOP when a new version is released, but maybe this could be 
done with the pre-processor as well.

Anyway, let me know what you think.

Regards,

Robert
  

Re: FOP Release Automation

[Pascal Sancho]

Hi,

I didn't remember that I've rewritten the release page [1] (only
refactor, no content change except website update).

So, reading it back can figure how simple such task should be.

Comments?

[1] http://xmlgraphics.apache.org/fop/dev/release.html#cms

2014-05-28 10:57 GMT+02:00 Robert Meyer :
> Hi Clay and Pascal,
>
> Sorry for my late reply with this.
>
> Pascal your idea makes a lot of sense as that will keep all versioned docs
> with their associated FOP version. I haven't had much of a chance to look at
> this over the last couple of days but am planning on spending some time in
> the coming days.
>
> Clay, both of what you mention sound intriguing so I'll take a look at
> those. I think updating it manually will be a last resort as even just
> writing an ant script would be preferable! If it does come to a script, the
> idea of copying the trunk folder and doing a find / replace on say "trunk"
> and replacing with "2.0" would be an option (with some caveats), but I'll
> investigate the other methods first.
>
> I'll keep you posted.
>
> Regards,
>
> Robert Meyer
>
>> Subject: Re: FOP Release Automation
>> From: the.webmaes...@gmail.com
>> Date: Tue, 27 May 2014 21:33:32 -0700
>> To: fop-dev@xmlgraphics.apache.org
>
>>
>> Hi,
>>
>> I thought I'd give an update on my research of speeding the RELEASE
>> process...
>>
>> I've spent some time researching, and I've asked for some assistance from
>> site-dev@...
>>
>> Among the ideas I've been researching are:
>> - MarkDown PreProcessor[1]
>> - svn hook
>>
>> I'm not married to either of these solutions, but they look interesting.
>>
>> Of course, another idea, is to do it the OLD way, and I'd be happy to go
>> through and update the MarkDown files with the latest/updated version.
>>
>> MarkDown PreProcessor (a sample I thought was interesting)
>> [1]
>> http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown
>>
>> More inline...
>>
>> On May 23, 2014, at 1:00 AM, Pascal Sancho  wrote:
>> > Hi,
>> >
>> > The FOP package should not embed the whole website, but only the
>> > documentation part, more precisely only the relevant version folder.
>> >
>> > Currently, FOP doc folder is referenced as svn:externals in FOP repo,
>> > resulting on extra irrelevant info, such as other versions,
>> > miscellaneous processes, general info, etc.
>> >
>> > IMHO, FOP versionned doc should be in FOP repo, and Website repo
>> > should refer to each FOP versionned doc through svn:externals prop.
>> >
>> > WDYT?
>>
>> +1 Pascal... Makes sense to me. There's a lot of cruft in there...
>>
>> We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or
>> adjust the site a bit to move the OLD versions somewhere 'out of the way'...
>> (And then add 301 redirects... ;-)
>>
>> Cheers!
>>
>> Clay Leeds @ the.webmaes...@gmail.com
>> "My religion is simple. My religion is kindness."
>> HH the Dalai Lama of Tibet
>>



-- 
pascal

RE: FOP Release Automation

[Robert Meyer]

Hi Clay and Pascal,

Sorry for my late reply with this. 

Pascal your idea makes a lot of sense as that will keep all versioned docs with 
their associated FOP version. I haven't had much of a chance to look at this 
over the last couple of days but am planning on spending some time in the 
coming days.

Clay, both of what you mention sound intriguing so I'll take a look at those. I 
think updating it manually will be a last resort as even just writing an ant 
script would be preferable! If it does come to a script, the idea of copying 
the trunk folder and doing a find / replace on say "trunk" and replacing with 
"2.0" would be an option (with some caveats), but I'll investigate the other 
methods first.

I'll keep you posted.

Regards,

Robert Meyer

> Subject: Re: FOP Release Automation
> From: the.webmaes...@gmail.com
> Date: Tue, 27 May 2014 21:33:32 -0700
> To: fop-dev@xmlgraphics.apache.org
> 
> Hi,
> 
> I thought I'd give an update on my research of speeding the RELEASE process...
> 
> I've spent some time researching, and I've asked for some assistance from 
> site-dev@...
> 
> Among the ideas I've been researching are:
> - MarkDown PreProcessor[1]
> - svn hook
> 
> I'm not married to either of these solutions, but they look interesting.
> 
> Of course, another idea, is to do it the OLD way, and I'd be happy to go 
> through and update the MarkDown files with the latest/updated version.
> 
> MarkDown PreProcessor (a sample I thought was interesting)
> [1] 
> http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown
> 
> More inline...
> 
> On May 23, 2014, at 1:00 AM, Pascal Sancho  wrote:
> > Hi,
> > 
> > The FOP package should not embed the whole website, but only the
> > documentation part, more precisely only the relevant version folder.
> > 
> > Currently, FOP doc folder is referenced as svn:externals in FOP repo,
> > resulting on extra irrelevant info, such as other versions,
> > miscellaneous processes, general info, etc.
> > 
> > IMHO, FOP versionned doc should be in FOP repo, and Website repo
> > should refer to each FOP versionned doc through svn:externals prop.
> > 
> > WDYT?
> 
> +1 Pascal... Makes sense to me. There's a lot of cruft in there...
> 
> We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or 
> adjust the site a bit to move the OLD versions somewhere 'out of the way'... 
> (And then add 301 redirects... ;-)
> 
> Cheers!
> 
> Clay Leeds  @  the.webmaes...@gmail.com
> "My religion is simple. My religion is kindness."
> HH the Dalai Lama of Tibet
> 
  

Re: FOP Release Automation

[Pascal Sancho]

in released versions until v1.1, whole website was included in
src/documentation, using the old Forrest schema.
So, until v1.1, the website repo may embed directly versionned doc.
I don't think we need to remove them, just adding or removing a link
in sidenav will be sufficient (0.95 doc is always on website).
Beginning with fop-next, ie current trunk, we could move trunk doc
into fop trunk repos and apply svn:externals in website repo.

Attached, I've listed links to versionned doc in CMS FOP -- I like grepwin ;-).
Note that for links to latest version, we used variables at the top of
MDtext, for easier update during release process.

I see no need to redirect anything, just change some values in 5 files.

2014-05-28 6:33 GMT+02:00 Clay Leeds :
> Hi,
>
> I thought I'd give an update on my research of speeding the RELEASE process...
>
> I've spent some time researching, and I've asked for some assistance from 
> site-dev@...
>
> Among the ideas I've been researching are:
> - MarkDown PreProcessor[1]
> - svn hook
>
> I'm not married to either of these solutions, but they look interesting.
>
> Of course, another idea, is to do it the OLD way, and I'd be happy to go 
> through and update the MarkDown files with the latest/updated version.
>
> MarkDown PreProcessor (a sample I thought was interesting)
> [1] 
> http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown
>
> More inline...
>
> On May 23, 2014, at 1:00 AM, Pascal Sancho  wrote:
>> Hi,
>>
>> The FOP package should not embed the whole website, but only the
>> documentation part, more precisely only the relevant version folder.
>>
>> Currently, FOP doc folder is referenced as svn:externals in FOP repo,
>> resulting on extra irrelevant info, such as other versions,
>> miscellaneous processes, general info, etc.
>>
>> IMHO, FOP versionned doc should be in FOP repo, and Website repo
>> should refer to each FOP versionned doc through svn:externals prop.
>>
>> WDYT?
>
> +1 Pascal... Makes sense to me. There's a lot of cruft in there...
>
> We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or 
> adjust the site a bit to move the OLD versions somewhere 'out of the way'... 
> (And then add 301 redirects... ;-)


-- 
pascal
fop\dev\design\parsing.mdtext
../../trunk/embedding.html
../../trunk/extensions.html
fop\dev\extensions.mdtext
../trunk/extensions.html
fop\dev\faq.mdtext
../trunk/compiling.html
fop\dev\svg.mdtext
../trunk/graphics.html
fop\dev\tools.mdtext
../trunk/compiling.html
fop\faq.mdtext
[currentFop_config_general]:   
1.1/configuration.html#general-elements
[currentFop_embedding_configExt]:  1.1/embedding.html#config-external
[currentFop_embedding_configInt]:  1.1/embedding.html#config-internal
[currentFop_embedding_multithreading]: 1.1/embedding.html#multithreading
[currentFop_fonts]:1.1/fonts.html
[currentFop_graphics]: 1.1/graphics.html
[currentFop_graphics_batik]:   1.1/graphics.html#batik
[currentFop_graphics_resol]:   1.1/graphics.html#resolution
[currentFop_graphics_svgPdfText]:  1.1/graphics.html#svg-pdf-text
[currentFop_graphics_svgScaling]:  1.1/graphics.html#svg-scaling
[currentFop_hyphenation_support]:  1.1/hyphenation.html#support
[currentFop_metadata]: 1.1/metadata.html
[currentFop_output_generalFonts]:  1.1/output.html#general-fonts
[currentFop_output_pdfFonts]:  1.1/output.html#pdf-fonts
[currentFop_output_pdfPostProcess]:1.1/output.html#pdf-postprocess
[currentFop_output_pdfWatermark]:  1.1/output.html#pdf-watermark
[currentFop_pdfencryption]:1.1/pdfencryption.html
[currentFop_running_memory]:   1.1/running.html#memory
[currentFop_servlets]: 1.1/servlets.html#servlet
[currentFop_servlets_engine]:  1.1/servlets.html#servlet-engine
[currentFop_servlets_ie]:  1.1/servlets.html#ie
[currentFop_servlets_xslt]:1.1/servlets.html#xslt
fop\fo.mdtext
[fopLatest_config]: 1.1/configuration.html
fop\index.mdtext
[fopLatest]:   1.1/
[fopLatest_ouput]: 1.1/output.html
fop\maillist.mdtext
[fopLatest-runningXalan]: 1.1/running.html#check-input
fop\quickstartguide.mdtext
[currentFop_compile]: 1.1/compiling.html
[currentFop_config]: 1.1/configuration.html
[currentFop_running]: 1.1/running.html
[currentFop_embedding]: 1.1/embedding.html
[currentFop_servlets]: 1.1/servlets.html
[currentFop_anttask]: 1.1/anttask.html
[currentFop_index]: 1.1/index.html

Re: FOP Release Automation

[Clay Leeds]

Hi,

I thought I'd give an update on my research of speeding the RELEASE process...

I've spent some time researching, and I've asked for some assistance from 
site-dev@...

Among the ideas I've been researching are:
- MarkDown PreProcessor[1]
- svn hook

I'm not married to either of these solutions, but they look interesting.

Of course, another idea, is to do it the OLD way, and I'd be happy to go 
through and update the MarkDown files with the latest/updated version.

MarkDown PreProcessor (a sample I thought was interesting)
[1] http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown

More inline...

On May 23, 2014, at 1:00 AM, Pascal Sancho  wrote:
> Hi,
> 
> The FOP package should not embed the whole website, but only the
> documentation part, more precisely only the relevant version folder.
> 
> Currently, FOP doc folder is referenced as svn:externals in FOP repo,
> resulting on extra irrelevant info, such as other versions,
> miscellaneous processes, general info, etc.
> 
> IMHO, FOP versionned doc should be in FOP repo, and Website repo
> should refer to each FOP versionned doc through svn:externals prop.
> 
> WDYT?

+1 Pascal... Makes sense to me. There's a lot of cruft in there...

We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or 
adjust the site a bit to move the OLD versions somewhere 'out of the way'... 
(And then add 301 redirects... ;-)

Cheers!

Clay Leeds  @  the.webmaes...@gmail.com
"My religion is simple. My religion is kindness."
HH the Dalai Lama of Tibet

Re: FOP Release Automation

[Pascal Sancho]

Hi,

The FOP package should not embed the whole website, but only the
documentation part, more precisely only the relevant version folder.

Currently, FOP doc folder is referenced as svn:externals in FOP repo,
resulting on extra irrelevant info, such as other versions,
miscellaneous processes, general info, etc.

IMHO, FOP versionned doc should be in FOP repo, and Website repo
should refer to each FOP versionned doc through svn:externals prop.

WDYT?


2014-05-23 5:15 GMT+02:00 Clay Leeds :
> Thank you for looking at this, Robert. I'll take a look at MarkDown
> solutions as well.
>
> Cheers!
>
> Clay
>
> --
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
>
> On May 21, 2014, at 2:24 AM, Robert Meyer  wrote:
>
> Hi All,
>
> I've been asked to look at a way to automate the FOP release process with
> regards the website documentation. At the moment every new release requires
> the following:
>
> 1) Download the site from SVN
> 2) Copy the folder containing the latest version's markdown files (1.1 for
> example) and rename to the new version
> 3) Go through all the files manually and update all the references from the
> old to the new version
> 4) Update any markdown files in the main directory with regard to the
> current and previous versions.
> 5) Delete the oldest version folder as we need only mantain the last 3.
> 6) Check and resubmit all files back to SVN
>
> My initial thought would to have a master copy in a separate directory. That
> copy would contain a tag in place where the version is given which could be
> substituted by a script of some kind (ant has a facility to do this). The
> ant script would also perform all of the above tasks so the only thing left
> to the user will be to check the output and push the new files. The problem
> I have with this is that SVN is not the only way in which the files can be
> edited as there is the web interface. If someone were to edit the files from
> there, the master copies would become out of date and worse, if someone were
> to perform a release it would overwrite all those changes.
>
> I've been recommended to look at markdown extensions but if anyone else has
> any ideas on the best way to go about this it would be much appreciated.
>
> Thanks,
>
> Robert Meyer



-- 
pascal

Re: FOP Release Automation

[Clay Leeds]

Thank you for looking at this, Robert. I'll take a look at MarkDown solutions 
as well. 

Cheers!
Clay

--

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

> On May 21, 2014, at 2:24 AM, Robert Meyer  wrote:
> 
> Hi All,
> 
> I've been asked to look at a way to automate the FOP release process with 
> regards the website documentation. At the moment every new release requires 
> the following:
> 
> 1) Download the site from SVN
> 2) Copy the folder containing the latest version's markdown files (1.1 for 
> example) and rename to the new version
> 3) Go through all the files manually and update all the references from the 
> old to the new version
> 4) Update any markdown files in the main directory with regard to the current 
> and previous versions.
> 5) Delete the oldest version folder as we need only mantain the last 3.
> 6) Check and resubmit all files back to SVN
> 
> My initial thought would to have a master copy in a separate directory. That 
> copy would contain a tag in place where the version is given which could be 
> substituted by a script of some kind (ant has a facility to do this). The ant 
> script would also perform all of the above tasks so the only thing left to 
> the user will be to check the output and push the new files. The problem I 
> have with this is that SVN is not the only way in which the files can be 
> edited as there is the web interface. If someone were to edit the files from 
> there, the master copies would become out of date and worse, if someone were 
> to perform a release it would overwrite all those changes.
> 
> I've been recommended to look at markdown extensions but if anyone else has 
> any ideas on the best way to go about this it would be much appreciated.
> 
> Thanks,
> 
> Robert Meyer

FOP Release Automation

[Robert Meyer]

Hi All,

I've been asked to look at a way to automate the FOP release process with 
regards the website documentation. At the moment every new release requires the 
following:

1) Download the site from SVN
2) Copy the folder containing the latest version's markdown files (1.1 for 
example) and rename to the new version
3) Go through all the files manually and update all the references from the old 
to the new version
4) Update any markdown files in the main directory with regard to the current 
and previous versions.
5) Delete the oldest version folder as we need only mantain the last 3.
6) Check and resubmit all files back to SVN

My initial thought would to have a master copy in a separate directory. That 
copy would contain a tag in place where the version is given which could be 
substituted by a script of some kind (ant has a facility to do this). The ant 
script would also perform all of the above tasks so the only thing left to the 
user will be to check the output and push the new files. The problem I have 
with this is that SVN is not the only way in which the files can be edited as 
there is the web interface. If someone were to edit the files from there, the 
master copies would become out of date and worse, if someone were to perform a 
release it would overwrite all those changes.

I've been recommended to look at markdown extensions but if anyone else has any 
ideas on the best way to go about this it would be much appreciated.

Thanks,

Robert Meyer
  

Fop release 1.0 in the press

[Simon Pepping]

I found three news items about FOP 1.0 release:

- 
http://www.h-online.com/open/news/item/Apache-FOP-gets-a-1-0-release-1042748.html
- 
http://www.heise.de/newsticker/meldung/FOP-1-0-XML-fast-beliebig-drucken-1043077.html
- 
http://java.dzone.com/news/fop-10-rounds-out-apache-xml?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fcss+%28CSS+Zone%29

All three made up their own texts, picking from the press release and
adding other information.

Simon

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

Re: Updating the FOP release plan

[Jeremias Maerki]

Looks like there won't be any more voices. The majority seems to favor a
1.0 release. That's fine by me as long as we can break the 0.x curse.
I'm surprised and grateful that we can finally move forward
version-number-wise.

I think we'll need to announce that release (codename "Curse Breaker" ;-))
carefully so people don't suddenly assume we have a 100% implementation
of XSL 1.0 or something. I think it'll make sense to work with the PRC
to do this right. After all, this particular release will create its
ripples even if on a technical level the jump isn't that big.

So my proposal would be to work towards a beta release early next year.
By then the AFP and newIF branches should be merged with trunk.
Hopefully it shouldn't take us another half year to release the final
1.0 after the beta. The previous beta-phase was really much too long.

On 19.11.2008 09:37:41 Jeremias Maerki wrote:
> On a serious note (as opposed to my outburst on fop-users), I think we
> should really discuss the FOP release plan which we haven't updated in a
> while. I would hate to see FOP in 0.x mode after 10 years of existence.
> Let's assume 0.20.5 was actually FOP 1.0, and FOP 0.95 was actually FOP
> 2.0. How about calling the next version 2.009 (to be released in early
> 2009). Skip 1.0 entirely since that would only let the expectations rise
> into the sky. FOP had a major redesign which warrants at least a version
> jump of one major version. Not calling it 2.0 means it's not a first
> release from a fresh development branch. That will carry the message
> along that FOP is stable and usable in a productive environment. Hell,
> it's used in production by so many people for so many years.
> OhpointXitis is really bad.
> 
> I know we still have about one item left on our pre-1.0 list:
> http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
> But that's still going to take a while. I want to revisit this list and
> see what today's view is.
> 
> Flame away.
> 
> Jeremias Maerki
> 




Jeremias Maerki

Re: Updating the FOP release plan

[Jeremias Maerki]

On 21.11.2008 02:46:55 [EMAIL PROTECTED] wrote:
> Thanx ;)
> 
> I do believe that the plan called for a 3 months of beta before making 
> it version 1...

Although that turned out to be 6 months last time.

> The last release was 0.95... in August... and not beta...
> 
> So, my only question is... if this release isn't version 1, then, what 
> is missing that you all feel it should be included/corrected? (that plan 
> pre-dates 2005)

The list is on http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning 
(scroll down to "To be done before a 1.0 release"). That's what was
created after I wanted to do a 1.0 release in June 2006. And now I'm
forcing everyone to revisit it.

> Make the list, work on it... and release the "next version"...

If it were that simple, we'd already have 100% coverage of the XSL 1.0
spec. Resources, complexity, Real-Life If FOP got more volunteers,
maybe

> And you can call it the "Cloud Document Generator", after all, seams to 
> exist a new crazy around the computer wannabes (meaning marketeers of 
> IT) to call everything new "Cloud" (Cloud FOP?)
>
> Because, from my point of view, and my tests with it, its more then 
> ready... hehehe

That's right.

> ;)
> 
> 
> Jeremias Maerki wrote:
> > Luis,
> >
> > feedback from users is very welcome. Always. So no need to apologize.
> >
> > If you want to know what we're working on (long-term), take a look at
> > http://wiki.apache.org/xmlgraphics-fop/RoadMap. Some of us note our
> > priorities there. Of course, there are always smaller short-term tasks 
> > (bugs and new features) that pop up on short notice and get done as
> > quickly. http://xmlgraphics.apache.org/fop/changes.html tells you what
> > has been worked on in Trunk.
> >
> > On 20.11.2008 17:52:49 Luis Ferro wrote:
> >   
> >> Sorry to mingle into this, but even if releasing a 1.0 is important (and
> >> IMHO it should be done with current crop as it is recognized as stable for
> >> it), a more important thing would be to update the empty space that appears
> >> on the "future"...
> >>
> >> I do believe that most current users and prospective users would like to 
> >> see
> >> what is in the road ahead... [i would hehehe]
> >>
> >> ;)
> >>
> >> [no vote due to, well... i'm more a user then a dev of FOP hehehe]
> >>
> >>
> >> On Thu, Nov 20, 2008 at 4:29 PM, Dario Laera <[EMAIL PROTECTED]> wrote:
> >>
> >> 
> >>> Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
> >>>
> >>>  How about calling the next version 2.009 (to be released in early
> >>>   
>  2009).
> 
>  
> >>> 
> >>> You may choose to compose a strange number like Knuth is doing with $\pi$
> >>> for \TeX versioning. What about $\sqrt{2}$? :P
> >>> 
> >>>
> >>>   
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >   
> 




Jeremias Maerki

Re: Updating the FOP release plan

[[EMAIL PROTECTED]]

Thanx ;)

I do believe that the plan called for a 3 months of beta before making 
it version 1...


The last release was 0.95... in August... and not beta...

So, my only question is... if this release isn't version 1, then, what 
is missing that you all feel it should be included/corrected? (that plan 
pre-dates 2005)


Make the list, work on it... and release the "next version"...

And you can call it the "Cloud Document Generator", after all, seams to 
exist a new crazy around the computer wannabes (meaning marketeers of 
IT) to call everything new "Cloud" (Cloud FOP?)


Because, from my point of view, and my tests with it, its more then 
ready... hehehe


;)


Jeremias Maerki wrote:

Luis,

feedback from users is very welcome. Always. So no need to apologize.

If you want to know what we're working on (long-term), take a look at
http://wiki.apache.org/xmlgraphics-fop/RoadMap. Some of us note our
priorities there. Of course, there are always smaller short-term tasks 
(bugs and new features) that pop up on short notice and get done as

quickly. http://xmlgraphics.apache.org/fop/changes.html tells you what
has been worked on in Trunk.

On 20.11.2008 17:52:49 Luis Ferro wrote:
  

Sorry to mingle into this, but even if releasing a 1.0 is important (and
IMHO it should be done with current crop as it is recognized as stable for
it), a more important thing would be to update the empty space that appears
on the "future"...

I do believe that most current users and prospective users would like to see
what is in the road ahead... [i would hehehe]

;)

[no vote due to, well... i'm more a user then a dev of FOP hehehe]


On Thu, Nov 20, 2008 at 4:29 PM, Dario Laera <[EMAIL PROTECTED]> wrote:



Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:

 How about calling the next version 2.009 (to be released in early
  

2009).




You may choose to compose a strange number like Knuth is doing with $\pi$
for \TeX versioning. What about $\sqrt{2}$? :P


  





Jeremias Maerki

  

Re: Updating the FOP release plan

[Jeremias Maerki]

Luis,

feedback from users is very welcome. Always. So no need to apologize.

If you want to know what we're working on (long-term), take a look at
http://wiki.apache.org/xmlgraphics-fop/RoadMap. Some of us note our
priorities there. Of course, there are always smaller short-term tasks 
(bugs and new features) that pop up on short notice and get done as
quickly. http://xmlgraphics.apache.org/fop/changes.html tells you what
has been worked on in Trunk.

On 20.11.2008 17:52:49 Luis Ferro wrote:
> Sorry to mingle into this, but even if releasing a 1.0 is important (and
> IMHO it should be done with current crop as it is recognized as stable for
> it), a more important thing would be to update the empty space that appears
> on the "future"...
> 
> I do believe that most current users and prospective users would like to see
> what is in the road ahead... [i would hehehe]
> 
> ;)
> 
> [no vote due to, well... i'm more a user then a dev of FOP hehehe]
> 
> 
> On Thu, Nov 20, 2008 at 4:29 PM, Dario Laera <[EMAIL PROTECTED]> wrote:
> 
> > Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
> >
> >  How about calling the next version 2.009 (to be released in early
> >> 2009).
> >>
> >
> > 
> > You may choose to compose a strange number like Knuth is doing with $\pi$
> > for \TeX versioning. What about $\sqrt{2}$? :P
> > 
> >




Jeremias Maerki

Re: Updating the FOP release plan

[Vincent Hennebert]

Andreas Delmelle wrote:

On 20 Nov 2008, at 18:55, Vincent Hennebert wrote:


Come on, guys, this is a serious topic.


Oops... I'd better withdraw from the discussion, then. ;-)


Wait! I come with you.



BTW: 'FOP phi' (golden ratio) does have a nice ring to it.


Indeed. But insofar as it will never reach phi, can we still call it
FOP phi?


Vincent

Re: Updating the FOP release plan

[Andreas Delmelle]

On 20 Nov 2008, at 18:55, Vincent Hennebert wrote:


Come on, guys, this is a serious topic.


Oops... I'd better withdraw from the discussion, then. ;-)

BTW: 'FOP phi' (golden ratio) does have a nice ring to it.


Cheers

Andreas

Re: Updating the FOP release plan

[Vincent Hennebert]

Come on, guys, this is a serious topic.

Andreas Delmelle wrote:

On 20 Nov 2008, at 17:29, Dario Laera wrote:


Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:


How about calling the next version 2.009 (to be released in early
2009).



You may choose to compose a strange number like Knuth is doing with 
$\pi$ for \TeX versioning. What about $\sqrt{2}$? :P




Now there's an idea... Doing something with Euler's famous formula, 
perhaps:

\$-(e^(i*pi))\$  (=1.0) :-)

Just sticking to an 'ordinary' version number seems to dull anyway. I 
don't mind if anyone is confused, quite on the contrary.


The least we can do is to use the golden number [1]:
(1 + sqrt(5))/2 ≈ 1.6180339887

Incidentally this number has been used in book design for many years
[2]. Actually...

[1] http://en.wikipedia.org/wiki/Golden_ratio
[2] http://en.wikipedia.org/wiki/Golden_ratio#Book_design


Vincent

Re: Updating the FOP release plan

[Andreas Delmelle]

On 20 Nov 2008, at 17:29, Dario Laera wrote:


Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:


How about calling the next version 2.009 (to be released in early
2009).



You may choose to compose a strange number like Knuth is doing with $ 
\pi$ for \TeX versioning. What about $\sqrt{2}$? :P




Now there's an idea... Doing something with Euler's famous formula,  
perhaps:

\$-(e^(i*pi))\$  (=1.0) :-)

Just sticking to an 'ordinary' version number seems to dull anyway. I  
don't mind if anyone is confused, quite on the contrary.



Cheers

Andreas

Re: Updating the FOP release plan

[Luis Ferro]

Sorry to mingle into this, but even if releasing a 1.0 is important (and
IMHO it should be done with current crop as it is recognized as stable for
it), a more important thing would be to update the empty space that appears
on the "future"...

I do believe that most current users and prospective users would like to see
what is in the road ahead... [i would hehehe]

;)

[no vote due to, well... i'm more a user then a dev of FOP hehehe]


On Thu, Nov 20, 2008 at 4:29 PM, Dario Laera <[EMAIL PROTECTED]> wrote:

> Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
>
>  How about calling the next version 2.009 (to be released in early
>> 2009).
>>
>
> 
> You may choose to compose a strange number like Knuth is doing with $\pi$
> for \TeX versioning. What about $\sqrt{2}$? :P
> 
>

Re: Updating the FOP release plan

[Dario Laera]

Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:


How about calling the next version 2.009 (to be released in early
2009).



You may choose to compose a strange number like Knuth is doing with $ 
\pi$ for \TeX versioning. What about $\sqrt{2}$? :P

Re: Updating the FOP release plan

[Adrian Cumiskey]

1.0 sounds fine to me, 2.009 seems like a bit of a jump from 0.95 :).

Adrian.

The Web Maestro wrote:

On Thu, Nov 20, 2008 at 5:11 AM, Vincent Hennebert <[EMAIL PROTECTED]> wrote:


Moreover, it can only puzzle users I think. We've used <1.0 version
numbers for all those years, we've started a whole series of 0.9x
releases, and all of a sudden we jump to >2.0?! With no significant
changes from 0.95, moreover. They will wonder what is that revolution
that they missed and that justifies such a jump.


I agree with Vincent here. I'd like to finally see a 1.0 release...
Perhaps we'll be in the minority of having a stable 1.0 release (or at
least that's the hope!)? ;-)


The 'least worse' way to stop the <1.0 curse, IMO, is to actually call
the next release 1.0, with the following message: the re-design branch
has been worked on for quite some time now, it brings many new features
and improvements compared to the old 0.20.5; it's considered stable
enough to be used in production and 1.0 is used to acknowledge that.

The work on changing IPD is likely to bring major changes to the layout
engine, which will justify a 1.5 or 2.0 version. Once serious work has
been done on optimization, a 2.5 or 3.0 can be released. Once
significant features from XSL-FO 1.1 have been added, 3.5 or 4.0. And so
on.

After all, there are many open-source projects that have been around for
years, and whose version numbers are still in 1.x or 2.x.x.


IMHO, we should finally get out of the crib, and call it fop-1.0.

Regards,

The Web Maestro

Re: Updating the FOP release plan

[The Web Maestro]

On Thu, Nov 20, 2008 at 5:11 AM, Vincent Hennebert <[EMAIL PROTECTED]> wrote:

> Moreover, it can only puzzle users I think. We've used <1.0 version
> numbers for all those years, we've started a whole series of 0.9x
> releases, and all of a sudden we jump to >2.0?! With no significant
> changes from 0.95, moreover. They will wonder what is that revolution
> that they missed and that justifies such a jump.

I agree with Vincent here. I'd like to finally see a 1.0 release...
Perhaps we'll be in the minority of having a stable 1.0 release (or at
least that's the hope!)? ;-)

> The 'least worse' way to stop the <1.0 curse, IMO, is to actually call
> the next release 1.0, with the following message: the re-design branch
> has been worked on for quite some time now, it brings many new features
> and improvements compared to the old 0.20.5; it's considered stable
> enough to be used in production and 1.0 is used to acknowledge that.
>
> The work on changing IPD is likely to bring major changes to the layout
> engine, which will justify a 1.5 or 2.0 version. Once serious work has
> been done on optimization, a 2.5 or 3.0 can be released. Once
> significant features from XSL-FO 1.1 have been added, 3.5 or 4.0. And so
> on.
>
> After all, there are many open-source projects that have been around for
> years, and whose version numbers are still in 1.x or 2.x.x.

IMHO, we should finally get out of the crib, and call it fop-1.0.

Regards,

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

Re: Updating the FOP release plan

[Vincent Hennebert]

Hi,

My actual opinion is not politically correct, so I’ll try to stick to
constructive comments.

Jeremias Maerki wrote:

On a serious note (as opposed to my outburst on fop-users), I think we
should really discuss the FOP release plan which we haven't updated in a
while. I would hate to see FOP in 0.x mode after 10 years of existence.
Let's assume 0.20.5 was actually FOP 1.0, and FOP 0.95 was actually FOP
2.0.


Seen from today’s point of view, I very much agree with that.
Actually the first release from the re-design branch (0.90 alpha 1)
should have been called 1.0alpha, 0.91beta should have been called
1.0beta, 0.92beta 1.0RC and 0.93 1.0, or something like that.



How about calling the next version 2.009 (to be released in early
2009).


Hmmm... no. Too many digits after the dot IMO, and not meaningful
enough. If we were to release another version in, say, September, how
would we call it? When the year is used in the versioning scheme, it’s
usually in the form of year.month (Ubuntu, AMD Catalyst drivers, etc.).

Moreover, it can only puzzle users I think. We’ve used <1.0 version
numbers for all those years, we’ve started a whole series of 0.9x
releases, and all of a sudden we jump to >2.0?! With no significant
changes from 0.95, moreover. They will wonder what is that revolution
that they missed and that justifies such a jump.

The ‘least worse’ way to stop the <1.0 curse, IMO, is to actually call
the next release 1.0, with the following message: the re-design branch
has been worked on for quite some time now, it brings many new features
and improvements compared to the old 0.20.5; it’s considered stable
enough to be used in production and 1.0 is used to acknowledge that.

The work on changing IPD is likely to bring major changes to the layout
engine, which will justify a 1.5 or 2.0 version. Once serious work has
been done on optimization, a 2.5 or 3.0 can be released. Once
significant features from XSL-FO 1.1 have been added, 3.5 or 4.0. And so
on.

After all, there are many open-source projects that have been around for
years, and whose version numbers are still in 1.x or 2.x.x.



Skip 1.0 entirely since that would only let the expectations rise
into the sky. FOP had a major redesign which warrants at least a version
jump of one major version. Not calling it 2.0 means it's not a first
release from a fresh development branch. That will carry the message
along that FOP is stable and usable in a productive environment. Hell,
it's used in production by so many people for so many years.
OhpointXitis is really bad.

I know we still have about one item left on our pre-1.0 list:
http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
But that's still going to take a while. I want to revisit this list and
see what today's view is.

Flame away.

Jeremias Maerki



Vincent

Re: Updating the FOP release plan

[Andreas Delmelle]

On 19 Nov 2008, at 09:37, Jeremias Maerki wrote:



How about calling the next version 2.009 (to be released in early
2009).


I like this idea. Something different that shows a clear break with  
the past, and at the same time not too seriously...


+1



OhpointXitis is really bad.


Agreed. We should finally move away from that.

Cheers

Andreas

Updating the FOP release plan

[Jeremias Maerki]

On a serious note (as opposed to my outburst on fop-users), I think we
should really discuss the FOP release plan which we haven't updated in a
while. I would hate to see FOP in 0.x mode after 10 years of existence.
Let's assume 0.20.5 was actually FOP 1.0, and FOP 0.95 was actually FOP
2.0. How about calling the next version 2.009 (to be released in early
2009). Skip 1.0 entirely since that would only let the expectations rise
into the sky. FOP had a major redesign which warrants at least a version
jump of one major version. Not calling it 2.0 means it's not a first
release from a fresh development branch. That will carry the message
along that FOP is stable and usable in a productive environment. Hell,
it's used in production by so many people for so many years.
OhpointXitis is really bad.

I know we still have about one item left on our pre-1.0 list:
http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
But that's still going to take a while. I want to revisit this list and
see what today's view is.

Flame away.

Jeremias Maerki

Suport For Saxon in future FOP release

[Philip V]

Hi,

I noticed that during the ant build of the trunk, Saxon is used. Since Saxon
is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as
the default processor with future releases of FOP?

Thanks,

Phil

-- 
View this message in context: 
http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html
Sent from the FOP - Dev mailing list archive at Nabble.com.

Re: Suport For Saxon in future FOP release

[Jess Holle]

One could potentially have a code path using the latest JAXP XPath 
facilities to avoid requiring Saxon...


Of course XPath is a bit funny.  Saxon's XPath does not return live 
nodes from the original DOM you hand to it.  Xalan's does -- but ever 
since 2.1.0 has assumed that you're going to do a lot of XPath against 
each DOM without any changes.  Thus ever since 2.1.0 Xalan has been 
incapable of any reasonable performance on a frequently changing, 
infrequently XPath'ed DOM (e.g. where you're using XPath to select DOM 
nodes and then modify them).  Jaxen and JXPath were flakey as could be 
for "real world" XPaths (giving incorrect results in many critical 
cases) and didn't have JAXP compliant XPath APIs last I investigated.


XSLT is simpler -- Saxon currently rules.  XSLT 1.0 is too limiting to 
justify continued use of Xalan.


--
Jess Holle

Jeremias Maerki wrote:

No. At runtime, FOP doesn't care what XSLT processor is used as long as
it's JAXP compatible. Inside the test code there's a hard reference to
Xalan for XPath processing. But that's unrelated to XSLT in general. The
runtime code doesn't have a dependency on Xalan.

On 05.09.2008 13:53:16 Philip V wrote:
  

Hi,

I noticed that during the ant build of the trunk, Saxon is used. Since Saxon
is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as
the default processor with future releases of FOP?

Thanks,

Phil

--
View this message in context: 
http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html
Sent from the FOP - Dev mailing list archive at Nabble.com.






Jeremias Maerki


  

Re: Suport For Saxon in future FOP release

[Jeremias Maerki]

No. At runtime, FOP doesn't care what XSLT processor is used as long as
it's JAXP compatible. Inside the test code there's a hard reference to
Xalan for XPath processing. But that's unrelated to XSLT in general. The
runtime code doesn't have a dependency on Xalan.

On 05.09.2008 13:53:16 Philip V wrote:
> 
> Hi,
> 
> I noticed that during the ant build of the trunk, Saxon is used. Since Saxon
> is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as
> the default processor with future releases of FOP?
> 
> Thanks,
> 
> Phil
> 
> -- 
> View this message in context: 
> http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html
> Sent from the FOP - Dev mailing list archive at Nabble.com.




Jeremias Maerki

Re: New FOP release: FOP 0.93

[Vincent Hennebert]

Simon Pepping a écrit :
> On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote:
>> As discussed recently, I will prepare a release of FOP, to be named
>> 0.93.
> 
> I have committed fixes for the reported issues with the dist files. I
> have also fixed a few other issues I discovered. I have added a few
> important changes to the release note, and I have reset the target
> release date to 9 January 2007.
> 
> I have tested the generated source and bin dist files. I could rebuild
> the dist target from the source dist. I have run the junit tests on
> the bin dist, after some fiddling with the targets in the Ant build
> file. I got one failure: 
> 
> [junit] Testcase: 
> color_1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1):   
> Caused an ERROR
> [junit] Expected XPath expression to evaluate to 
> 'fop-rgb-icc(1.0,0.5,0.0,sRGB,"../../../src/java/org/apache/fop/pdf/sRGB 
> Color Space Profile.icm",1.0,0.5,0.0)', but got '#ff8000' (XPath: 
> //block[4]//text/@color)
> 
> which may be due to its dependence on a file in the src directory,
> which is not included in the bin dist.
> 
> Please, test the current state of the branch
> xmlgraphics/fop/branches/fop-0_93 as a release candidate. See the
> commit message for the exact changes w.r.t. the rejected release. For
> your convenience I have uploaded one source dist file and one bin dist
> file, see http://people.apache.org/~spepping/.

Hmmm, I was planning to work a bit on Fop during holidays, but obviously
I haven't found the time... I'll get back to work on the release from
next Tuesday on.
Too bad, that fop.bat problem. But well, such problems always appear in
computer science. Thanks for your great work for the release, anyway.


Vincent

Re: New FOP release: FOP 0.93

[Simon Pepping]

On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote:
> As discussed recently, I will prepare a release of FOP, to be named
> 0.93.

I have committed fixes for the reported issues with the dist files. I
have also fixed a few other issues I discovered. I have added a few
important changes to the release note, and I have reset the target
release date to 9 January 2007.

I have tested the generated source and bin dist files. I could rebuild
the dist target from the source dist. I have run the junit tests on
the bin dist, after some fiddling with the targets in the Ant build
file. I got one failure: 

[junit] Testcase: 
color_1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an 
ERROR
[junit] Expected XPath expression to evaluate to 
'fop-rgb-icc(1.0,0.5,0.0,sRGB,"../../../src/java/org/apache/fop/pdf/sRGB Color 
Space Profile.icm",1.0,0.5,0.0)', but got '#ff8000' (XPath: 
//block[4]//text/@color)

which may be due to its dependence on a file in the src directory,
which is not included in the bin dist.

Please, test the current state of the branch
xmlgraphics/fop/branches/fop-0_93 as a release candidate. See the
commit message for the exact changes w.r.t. the rejected release. For
your convenience I have uploaded one source dist file and one bin dist
file, see http://people.apache.org/~spepping/.

I intend to generate the dist files and start a vote on the release
somewhere mid next week.

Regards, Simon

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

Re: New FOP release: FOP 0.93

[Simon Pepping]

On Sun, Dec 24, 2006 at 10:09:14AM -0600, Jess Holle wrote:
> Is there any sort of time table for a non-alpha/beta 0.9x or 1.0 release?

That is what I am preparing: FOP 0.93 (without beta), to be released
on 2 January 2007.

Regards, Simon

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

Re: New FOP release: FOP 0.93

[Jess Holle]

Is there any sort of time table for a non-alpha/beta 0.9x or 1.0 release?

--
Jess Holle

Re: New FOP release: FOP 0.93

[Jeremias Maerki]

I've just updated my view of the status of the subsystems. Some
additional tweaking might be required.

About the graphic: I might design a new one after a xmas break. If
someone beats me to it, all the better.

On 22.12.2006 20:28:21 Simon Pepping wrote:
> I want to do some rewriting of the file status.html of the web
> site.
> 
> Can you give some feedback on the items in the status overview table
> at the bottom?
> 
> It would be nice to have a few changes to the image as well: display
> release 0.93 and the future release 1.0 (without DR1). I cannot do
> that.


Jeremias Maerki

Re: New FOP release: FOP 0.93

[Simon Pepping]

I want to do some rewriting of the file status.html of the web
site.

Can you give some feedback on the items in the status overview table
at the bottom?

It would be nice to have a few changes to the image as well: display
release 0.93 and the future release 1.0 (without DR1). I cannot do
that.

Regards, Simon

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

Re: New FOP release: FOP 0.93

[Andreas L Delmelle]

On Dec 22, 2006, at 13:29, Simon Pepping wrote:

Hi Simon,



Uncertain status. The linked bug is resolved, but the description does
not match the description of the bug:

  Omitting fo:table-column or having fo:table-column without a  
column-width

  and attempting to create columns implicitly from the first
  table row is not implemented, yet (Bugzilla #35656a>).




As far as I can see, the testcases that I enabled with the patch  
solving the bug indicate that the described issue basically has been  
resolved:


table_table-layout_fixed_2.xml shows that FOP correctly handles  
columns in case none were specified


table-column_first-row-width does the same for the column-widths

OTOH, these testcases are *very* basic, namely: only test behaviour  
in case there is no spanning going on... I'll see if I can add some  
checks for creating columns off of cells spanning multiple columns,  
although I'm not entirely sure what the behaviour should be:



  

...

Should we create two implicit columns, and distribute the width evenly?

Currently in the code (TableBody.java), two implicit columns are  
created, but the cell's width is not yet automatically distributed.  
The latter happens only if the cell spans only one column (no  
distribution, but simple one-on-one transfer).



Cheers,

Andreas

Re: New FOP release: FOP 0.93

[Jeremias Maerki]

On 22.12.2006 13:29:19 Simon Pepping wrote:
> I edited the release notes, made some changes to the upgrading and
> changes documents.
> 
> I position this new release as the stable release. Version 0.20.5 is
> now advertised the previous release. This is apparent in various
> texts, esp. in the release notes and in 0.93/index.html, and in the
> redirects in .htaccess.
> 
> Specifically, I made the following changes:
> 
> Added to the changes:
>   
> Added support for the use of Open Type fonts
>   
>   
> Enabled Copy/Paste from PDF content in Acrobat Reader for text using 
> embedded TrueType fonts.
>   

Wasn't me. I've corrected the entry.

> Removed from the known issues in release notes:
> 
>   Copy/Paste from PDF content in Acrobat Reader is not supported for
>   text using embedded TrueType fonts.
> 
> 
>   Block-level content in fo:inlines may produce unwelcome results.
> 
> 
>   White space on direct inline-level children of a marker is not 
>   handled correctly.
> 
> compare with the change entry:
>   
> Deferred property resolution for markers until they are actually 
> retrieved,
> which leads to percentages and relative font-sizes now getting the 
> correct
> values. Also deferred white-space-handling for markers.
>   
> 
> Uncertain status. The linked bug is resolved, but the description does
> not match the description of the bug:
> 
>   Omitting fo:table-column or having fo:table-column without a 
> column-width 
>   and attempting to create columns implicitly from the first
>   table row is not implemented, yet ( href="http://issues.apache.org/bugzilla/show_bug.cgi?id=35656";>Bugzilla 
> #35656).
> 

All the combinations here seem to work.

> The possibility to do without font metrics files is only mentioned in
> the changes file.
> 
> Please, review. 
> 
> When I execute Ant's docs target, forrest insists on building a
> linkmap.html file with 0.92 and trunk. I cannot find out where that is
> derived from.

Doesn't happen here. Try a clean build.

> The only thing that remains is copying changes in the 0.93 directory
> of the documentation to the trunk directory. And respond to your
> remarks and edits, of course. Then this branch is ready for tagging
> and release. I target the release to 2 January 2007. That means that
> the vote will take place next week.

Wonderful! Thanks so much.

> Regards, Simon
> 
> On Wed, Dec 20, 2006 at 01:13:02PM +0100, Simon Pepping wrote:
> > I created the documentation for version 0.93 (see
> > src/documentation/content/xdocs/0.93) and edited it for the new
> > release version. Please, check it. Especial attention is needed for
> > the new release notes, src/documentation/content/xdocs/relnotes.xml,
> > most of which still have to be written, the FAQ,
> > src/documentation/content/xdocs/faq.xml, the main page of this
> > release, src/documentation/content/xdocs/0.93/index.xml, and the
> > upgrading page, src/documentation/content/xdocs/0.93/upgrading.xml.
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.eu



Jeremias Maerki

Re: New FOP release: FOP 0.93

[Simon Pepping]

I edited the release notes, made some changes to the upgrading and
changes documents.

I position this new release as the stable release. Version 0.20.5 is
now advertised the previous release. This is apparent in various
texts, esp. in the release notes and in 0.93/index.html, and in the
redirects in .htaccess.

Specifically, I made the following changes:

Added to the changes:
  
Added support for the use of Open Type fonts
  
  
Enabled Copy/Paste from PDF content in Acrobat Reader for text using 
embedded TrueType fonts.
  

Removed from the known issues in release notes:

  Copy/Paste from PDF content in Acrobat Reader is not supported for
  text using embedded TrueType fonts.


  Block-level content in fo:inlines may produce unwelcome results.


  White space on direct inline-level children of a marker is not 
  handled correctly.

compare with the change entry:
  
Deferred property resolution for markers until they are actually 
retrieved,
which leads to percentages and relative font-sizes now getting the 
correct
values. Also deferred white-space-handling for markers.
  

Uncertain status. The linked bug is resolved, but the description does
not match the description of the bug:

  Omitting fo:table-column or having fo:table-column without a column-width 
  and attempting to create columns implicitly from the first
  table row is not implemented, yet (http://issues.apache.org/bugzilla/show_bug.cgi?id=35656";>Bugzilla 
#35656).


The possibility to do without font metrics files is only mentioned in
the changes file.

Please, review. 

When I execute Ant's docs target, forrest insists on building a
linkmap.html file with 0.92 and trunk. I cannot find out where that is
derived from.

The only thing that remains is copying changes in the 0.93 directory
of the documentation to the trunk directory. And respond to your
remarks and edits, of course. Then this branch is ready for tagging
and release. I target the release to 2 January 2007. That means that
the vote will take place next week.

Regards, Simon

On Wed, Dec 20, 2006 at 01:13:02PM +0100, Simon Pepping wrote:
> I created the documentation for version 0.93 (see
> src/documentation/content/xdocs/0.93) and edited it for the new
> release version. Please, check it. Especial attention is needed for
> the new release notes, src/documentation/content/xdocs/relnotes.xml,
> most of which still have to be written, the FAQ,
> src/documentation/content/xdocs/faq.xml, the main page of this
> release, src/documentation/content/xdocs/0.93/index.xml, and the
> upgrading page, src/documentation/content/xdocs/0.93/upgrading.xml.

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

Re: New FOP release: FOP 0.93

[Jeremias Maerki]

On 19.12.2006 21:02:06 Simon Pepping wrote:
> As discussed recently, I will prepare a release of FOP, to be named
> 0.93.
> 
> Two issues need to be addressed:
> 
> 1. I will apply two patches by Richard Wheeldon, to improve memory
>usage:
> 
> Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with
> patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177
> 
> en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with
> patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155.
> 
> I will have to study the first patch, as I have not looked at it, and
> the bugzilla page contains nobody's comments. I will only apply the
> patch if it seems certain that it breaks nothing.
> 
> I have studied and commented the second patch, as has Andreas, and I
> believe it can be safely applied before the release.
> 
> Applying these patches allows us to present a production version whose
> memory usage has been trimmed somewhat.

Thanks for taking care of this.

> 2. With this release it is possible to use the original font metrics,
>without generating a special metrics file for FOP.
> 
> See
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL
>  PROTECTED]
> There is no entry for this in the changes file, and there is no
> documentation on the website. It is important enough to clarify with
> the release. I will try to add some text to the changes file and
> perhaps something to the documentation. As I am not familiar with this
> material, if someone else can do a better job, please do.

Well, this is still sort of experimental. The old functionality is
unchanged and stable. I'm not so sure about the part without the font
metrics. There wasn't much feedback. If this is to be documented, I'd
prefer if it is marked as experimental.

> After these changes I will create a branch.
> 
> Manuel, can you hold your changes until the branch has been created?
> 
> Please, let me know if you have different ideas.
> 
> Regards, Simon
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.eu



Jeremias Maerki

Re: New FOP release: FOP 0.93

[Simon Pepping]

I created the documentation for version 0.93 (see
src/documentation/content/xdocs/0.93) and edited it for the new
release version. Please, check it. Especial attention is needed for
the new release notes, src/documentation/content/xdocs/relnotes.xml,
most of which still have to be written, the FAQ,
src/documentation/content/xdocs/faq.xml, the main page of this
release, src/documentation/content/xdocs/0.93/index.xml, and the
upgrading page, src/documentation/content/xdocs/0.93/upgrading.xml.

On Wed, Dec 20, 2006 at 10:24:25AM +0100, Simon Pepping wrote:
> Done, and branch xmlgraphics/fop/branches/fop-0_93 created.
 
Regards, Simon

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

Re: New FOP release: FOP 0.93

[Simon Pepping]

Done, and branch xmlgraphics/fop/branches/fop-0_93 created.

On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote:
> As discussed recently, I will prepare a release of FOP, to be named
> 0.93.
> 
> Two issues need to be addressed:
> 
> 1. I will apply two patches by Richard Wheeldon, to improve memory
>usage:
> 
> Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with
> patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177
> 
> en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with
> patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155.
> 
> I will have to study the first patch, as I have not looked at it, and
> the bugzilla page contains nobody's comments. I will only apply the
> patch if it seems certain that it breaks nothing.
> 
> I have studied and commented the second patch, as has Andreas, and I
> believe it can be safely applied before the release.
> 
> Applying these patches allows us to present a production version whose
> memory usage has been trimmed somewhat.

Applied both.

> 2. With this release it is possible to use the original font metrics,
>without generating a special metrics file for FOP.
> 
> See
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL
>  PROTECTED]
> There is no entry for this in the changes file, and there is no
> documentation on the website. It is important enough to clarify with
> the release. I will try to add some text to the changes file and
> perhaps something to the documentation. As I am not familiar with this
> material, if someone else can do a better job, please do.

Change was already in the status file (but not on the web site).

Simon

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

Re: New FOP release: FOP 0.93

[Manuel Mall]

On Wednesday 20 December 2006 05:02, Simon Pepping wrote:

> Manuel, can you hold your changes until the branch has been created?
>

No problems, will wait until the branch is there.

>
> Regards, Simon

Manuel

New FOP release: FOP 0.93

[Simon Pepping]

As discussed recently, I will prepare a release of FOP, to be named
0.93.

Two issues need to be addressed:

1. I will apply two patches by Richard Wheeldon, to improve memory
   usage:

Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with
patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177

en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with
patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155.

I will have to study the first patch, as I have not looked at it, and
the bugzilla page contains nobody's comments. I will only apply the
patch if it seems certain that it breaks nothing.

I have studied and commented the second patch, as has Andreas, and I
believe it can be safely applied before the release.

Applying these patches allows us to present a production version whose
memory usage has been trimmed somewhat.

2. With this release it is possible to use the original font metrics,
   without generating a special metrics file for FOP.

See
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL 
PROTECTED]
There is no entry for this in the changes file, and there is no
documentation on the website. It is important enough to clarify with
the release. I will try to add some text to the changes file and
perhaps something to the documentation. As I am not familiar with this
material, if someone else can do a better job, please do.

After these changes I will create a branch.

Manuel, can you hold your changes until the branch has been created?

Please, let me know if you have different ideas.

Regards, Simon

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