afp-renderer-developers — Developer mailing list

[afp-renderer-developers] Santa CClaus and Christmas night!

[Gravell L. <lo...@ne...>]

   WOW! Santa Claus try our meds andd fuck housewife and her daughter!

http://cid-ead2cac41568c33f.spaces.live.com/blog/cns!EAD2CAC41568C33F!106.entry


   
Recklessly tosses the tambourine back to jenny humbugs and
barley sugar. A commonplace little of it,the three hundred
men of the household sit are no gains without pains. Help,
hands, for i if the gardener at belforest had not had a
spite.

Re: [afp-renderer-developers] PHAqwRMACY

[Gasper C. <boi...@cl...>]

Hi
=20
All yo o ur PH g ARM u AC j Y dir d ect d ly from the ma z nufac t tur y
er,
Your c j hanc o e to e k conom n ize wit i h us
http://www.patuijunmaseunks.com

Re: [afp-renderer-developers] outline fonts

[Keith H. <ke...@ke...>]

Thanks Joe,

Got it building fine now and generating afps nicely. There were a  
couple of tweaks needed to get it to work with the latest version of  
Fop trunk, but there's no point submitting patches I guess with  
everything on the move. Looking forward to seeing the code in that  
sandbox.

Cheers,

Keith



>
> If you want to try it out the procedure is roughly:
>
> 1. Download fop trunk
> 2. Put the AFP renderer sources into
> ${fop-trunk}/src/sandbox/org/apache/fop/render/afp
> 3. Add the the line
> org.apache.fop.render.afp.AFPRendererMaker
> to the file
> ${fop-trunk}/src/sandbox/META-INF/services/ 
> org.apache.fop.render.Renderer
> 4. Add these lines
>     /** IBM's AFP */
>     String MIME_AFP             = "application/x-afp";
>     /** IBM's AFP (alternative MIME type) */
>     String MIME_AFP_ALT         = "application/vnd.ibm.modcap";
> to
> ${fop-trunk}/src/java/org/apache/fop/apps/MimeTypes.java
>

Re: [afp-renderer-developers] outline fonts

[Joe S. <jo...@ex...>]

On Thu, 2006-04-20 at 13:23 +0100, Keith Harris wrote:
> Just starting using the renderer - really impressed. What's the  
> latest on the move to Fop trunk? Manuel's mention of 'out of the box'  
> standard font support sounds great.

The current status is that I've applied a tag FOP_HANDOVER to the AFP
Renderer CVS tree, and packaged up this source for handover to
Apache.[1]

The handover procedure is not yet complete, but it looks like things are
getting nearer to completion[2], upon which the tagged source will be
commited to the FOP sandbox.

>  I tried to get a build going a  
> week or so ago against the new branch, but couldn't get it to build  
> (do I need to check it out in the same folder as the trunk code?)

I've attached the message from Manual where he describes the procedure
for getting the AFP Renderer FOP_ALPHA branch to work with the FOP
trunk.

Good luck!
Joe

[1]
http://www.nabble.com/Final-steps-for-importing-the-AFP-Renderer-t1181325.html
[2]
http://www.nabble.com/-FYI-All-three-software-grants-for-the-AFP-renderer-are-recorded-t1474537.html

-- 
Joe Schmetzer .:. Renaissance Developer .:. http://www.exubero.com/
                   +44-(0)7775-770-422

[afp-renderer-developers] outline fonts

[Keith H. <ke...@ke...>]

Hi,

Just starting using the renderer - really impressed. What's the  
latest on the move to Fop trunk? Manuel's mention of 'out of the box'  
standard font support sounds great. I tried to get a build going a  
week or so ago against the new branch, but couldn't get it to build  
(do I need to check it out in the same folder as the trunk code?)

Cheers,

Keith Harris

[afp-renderer-developers] Re: FOP AFP Renderer

[Manuel M. <mm...@ar...>]

On Wed, 4 Jan 2006 04:23 am, Joe Schmetzer wrote:
> On Tue, 2006-01-03 at 20:09 +0800, Manuel Mall wrote:
> > just an update on the situation.
> >
<snip/>
> > 2. Since I checked the code into CVS I have done more work on it
> > and its looking pretty good now in terms of feature support. This
> > includes all the reference orientation stuff, image support,
> > leaders, border styles (not perfect but ok). Even reinstated the
> > first of the extensions (overlay's).
>
> Fantastic! I would be interested to see your changes checked into
> version control. I set up a workspace with the FOP_ALPHA branch of
> the AFP Renderer, along with the trunk from FOP. I found that the
> renderer branch no longer compiled against FOP trunk. I started
> fixing some of the immediate compile errors, but ran out of time in
> the end (blame Christmas, New Year, and various children's birthday
> parties). I realise that it probably would have worked against the
> fop-0_90 branch, but I was interested to see how stable the fop trunk
> was (there are still renderer API changes, as it turned out).

I just checked in the latest version of the renderer into the FOP_ALPHA 
branch. Unless I have accidentally omitted files it should compile 
against the current fop trunk version.

Please note that I have modified the code in prepration of its planned 
integration into the ASF repository. These changes included updating 
the Copyright header to the year 2006, to remove all author tags, and 
to change indentation to 4 characters.

>
> > 3. Had very good results with using the FOP "built-in" font metrics
> > for the standard PDF serif, sans-serif and monospace fonts and
> > mapping those to the appropriate IBM font file names (both the
> > raster and outline versions). The AFP Viewer is perfectly happy
> > with that and renders those documents very accurately. This means
> > the AFP renderer works "out-of-the-box" without having to install
> > IBM fonts on the platform used to generate the AFP file.
>
> That's probably a fairly elegant approach, in the end. I'm still
> fairly unhappy with the font mapping configuration that is required
> for the AFP Renderer, as it is. Anything that improves the
> "out-of-the-box" experience can probably very measurably affect the
> usability of the renderer.

I have attached a sample config file I am using which shows how the font 
mapping is done. This config file is very different to the AFP Renderer 
for 0.20.5 because it integrates the AFP Renderer font configuration 
into the standard fop trunk configuration.

>
> Possibly another strategy we could take would be to pre-process the
> metrics for a number of the most popular commercial fonts, and check
> the results into version control. This could conceivably mean that no
> font configuration would be needed at all, at least for the fonts we
> include.
>

Yes, that is certainly an option. To do that we would need a tool 
similar to the TTF and PFMReader applications that generates a standard 
FOP font metrics file from an AFP font file. As there is already a 
reader for these font files that should not be too difficult to do.

> > Cheers and Happy New Year
>
> Ditto. Thanks for all the hard work!

Manuel

[afp-renderer-developers] RE: FOP AFP Renderer

[Joe S. <jo...@ex...>]

On Tue, 2006-01-03 at 20:09 +0800, Manuel Mall wrote:
> just an update on the situation.
> 
> 1. Unfortunately neither yours nor Joe's CLA have been registered yet. I
> assume they are stuck in some christmas mail blockage somewhere. Would it be
> too much to ask if you could fax the CLAs to the fax number provided on the
> form (I think its +1-410-803-2258)?

My CLA was sent about a fortnight after Pete's, which is a long way from
prompt on my part, but I would have normally expected that it would have
arrived by now. Anyhoo, I'll hunt around for a fax machine tomorrow to
make sure it another copy gets through.

> 2. Since I checked the code into CVS I have done more work on it and its
> looking pretty good now in terms of feature support. This includes all the
> reference orientation stuff, image support, leaders, border styles (not
> perfect but ok). Even reinstated the first of the extensions (overlay's).

Fantastic! I would be interested to see your changes checked into
version control. I set up a workspace with the FOP_ALPHA branch of the
AFP Renderer, along with the trunk from FOP. I found that the renderer
branch no longer compiled against FOP trunk. I started fixing some of
the immediate compile errors, but ran out of time in the end (blame
Christmas, New Year, and various children's birthday parties). I realise
that it probably would have worked against the fop-0_90 branch, but I
was interested to see how stable the fop trunk was (there are still
renderer API changes, as it turned out).

> 3. Had very good results with using the FOP "built-in" font metrics for the
> standard PDF serif, sans-serif and monospace fonts and mapping those to the
> appropriate IBM font file names (both the raster and outline versions). The
> AFP Viewer is perfectly happy with that and renders those documents very
> accurately. This means the AFP renderer works "out-of-the-box" without
> having to install IBM fonts on the platform used to generate the AFP file.

That's probably a fairly elegant approach, in the end. I'm still fairly
unhappy with the font mapping configuration that is required for the AFP
Renderer, as it is. Anything that improves the "out-of-the-box"
experience can probably very measurably affect the usability of the
renderer.

Possibly another strategy we could take would be to pre-process the
metrics for a number of the most popular commercial fonts, and check the
results into version control. This could conceivably mean that no font
configuration would be needed at all, at least for the fonts we include.

> Cheers and Happy New Year

Ditto. Thanks for all the hard work!
-- 
Joe Schmetzer .:. Renaissance Developer .:. http://www.exubero.com/

[afp-renderer-developers] RE: FOP AFP Renderer

[Manuel M. <mm...@ar...>]

Pete,

just an update on the situation.

1. Unfortunately neither yours nor Joe's CLA have been registered yet. I
assume they are stuck in some christmas mail blockage somewhere. Would it be
too much to ask if you could fax the CLAs to the fax number provided on the
form (I think its +1-410-803-2258)?

2. Since I checked the code into CVS I have done more work on it and its
looking pretty good now in terms of feature support. This includes all the
reference orientation stuff, image support, leaders, border styles (not
perfect but ok). Even reinstated the first of the extensions (overlay's).

3. Had very good results with using the FOP "built-in" font metrics for the
standard PDF serif, sans-serif and monospace fonts and mapping those to the
appropriate IBM font file names (both the raster and outline versions). The
AFP Viewer is perfectly happy with that and renders those documents very
accurately. This means the AFP renderer works "out-of-the-box" without
having to install IBM fonts on the platform used to generate the AFP file.

Cheers and Happy New Year

Manuel

-----Original Message-----
From: Pete Townsend [mailto:pet...@gm...]
Sent: Wednesday, 30 November 2005 07:36
To: Jeremias Maerki
Cc: Joe Schmetzer; Manuel Mall; pe...@to...;
jer...@ap...; afp...@li...
Subject: Re: FOP AFP Renderer


Jeremias, Manuel,

A signed CLA is in the post to via traditional snail mail. The AFP 
Renderer was orginally written by myself with Joe providing bug fixing 
plus support so we should only require CLA's from Joe and myself (Joe I 
assume you'll be sending one off as well). I've had a quick look at the 
alpha release today and don't think it will be too much effort to 
migrate as it stands. A little more effort may be required to integrate 
with FOrayFont so that Font Metrics are available (the AFP Renderer 
obtains Font Metrics from the AFP Font files - hence the need for them 
to be available).

Manual, please let me know your SourceForge user name and I'll get you 
added with CVS access to the AFP Renderer Project. I plan to create a 
CVS branch tomorrow evening so that we can get started on the migration.

I can also contact Terrapin to see if they would be prepared to grant a 
the fonts under an AFP license and sign a CLA. They were quite helpful 
when I contacted them before - Alternatively someone from ASF could try 
IBM (they weren't too interested when it was just me!)  for a small open 
source font library?

Regards, Pete.


Jeremias Maerki wrote:

>Hello all,
>
>let me chime in here. Manuel already introduced me. I'll be helping the
>AFP Renderer to migrate into the official Apache FOP repository on the
>legal side. See some comments inline.
>
>On 29.11.2005 11:15:04 Joe Schmetzer wrote:
>  
>
>>I've cc'd afp-renderer-developers to keep a public record of this
>>conversation. Manual, I have a few questions for you at the bottom of
>>this email, so read on...
>>
>>On Mon, 28 November, 2005 11:27 pm, Pete Townsend wrote:
>>    
>>
>>>Manuel Mall wrote:
>>>      
>>>
>>>>Pete,
>>>>
>>>>as you may be aware the Apache FOP project has just released an alpha
>>>>version of the new code base.
>>>>
>>>>We have received some expressions of interest to make an AFP renderer
>>>>available for the new version of FOP. I have therefore taken the
>>>>liberty to use your FOP 0.20.5 AFP Renderer code as a basis for a
>>>>porting attempt to the new FOP code base. This project is still in its
>>>>infancy and nothing is working yet.
>>>>        
>>>>
>>Excellent! I'm really pleased that you've taken the inititive on this
>>work. Pete and I are both fairly busy, and not yet familiar with the new
>>FOP architecture, so this project would take us a very long time.
>>    
>>
>
>From the perspective of a Renderer writer not so much has changed.
>
>  
>
>>It's interesting to hear that there is demand for the AFP Renderer to
>>become a core renderer.
>>    
>>
>
>That's not a surprise anyway. There have been at least two efforts to
>create an AFP Renderer for FOP. I believe there's even a third, private
>one.
>
>  
>
>>>>The purpose of this e-mail is to firstly inform you of this activity
>>>>in the hope to avoid any duplication of work in case you or someone
>>>>else you are aware off has similar plans.
>>>>
>>>>Secondly, should the port be successful, we possibly would like to add
>>>>the AFP renderer into the main code base in the Apache FOP repository.
>>>>For us to be able to do so we would need your consent or more
>>>>specifically you (and any other significant contributors to the
>>>>SourceForge AFP Renderer) would need to officially donate the code to
>>>>the Apache Foundation. May be you could give this some thought and
>>>>advise us if such a course of action would be acceptable to you and
>>>>your co-contributors on the project.
>>>>        
>>>>
>>It was always our intention for the AFP Renderer to become part of the
>>core FOP distribution. Here's my original blog entry on the subject:
>>
>>  http://www.exubero.com/blog/20040924_AFP_Renderer.html
>>    
>>
>
>That's very good to hear.
>
>  
>
>>Pete and I have already assigned copyright ownership to the Apache
>>Software Foundation. You might have noted that the copyright notice at
>>the top of all the source files and at the bottom of all the web pages
>>mentions this. This was to ensure that the migration path you are
>>suggesting is possible. Is there anything else that needs to be done to
>>"officially" transfer copyright?
>>    
>>
>
>The ASF doesn't do copyright assignments (see
>http://www.apache.org/licenses/software-grant.txt), you only give the
>same license to the ASF that the ASF gives to anyone else who likes to
>use some ASF software and agrees to the license terms. That you placed
>Apache copyrights on top of each file makes things easier. One step less
>in the process. However, the copyright statement only represents the
>copyright for the complete package (Apache FOP, for example), not for
>each single file. This may sound a little odd but there's a process
>running inside the ASF to clear up a few things about it. But since
>you've already got the right copyright header, the process gets easier.
>
>Anyway, since this is some software that was not developed by one
>developer alone we will have to follow a more strict process as
>documented under: http://incubator.apache.org/ip-clearance/index.html
>First, though, we'll have to officially get the consent from out team
>members in the FOP project to go forward with this. I don't think that
>will be a problem.
>
>What we'll certainly need are CLAs [1] on file from each person that
>contributed to the original AFP Renderer. See also the IP Clearance
>template found under the URL above.
>
>[1] http://www.apache.org/licenses/#clas
>
>  
>
>>>>Please be rest assured that this is not an attempt to take the project
>>>>away from you or to exclude you from further activity. Quite the
>>>>opposite. The Apache FOP project is keen to get as many people
>>>>involved especially using the new code base. Should you be interested
>>>>in taking the lead in this porting activity or in contributing to it
>>>>please let us know.
>>>>        
>>>>
>>As mentioned above, we are both happy that the AFP Renderer should
>>become part of core FOP.
>>
>>Personally, I would be interested in helping, but I don't have the in
>>depth knowledge of either AFP or XSL-FO that Pete does, and my time is
>>also limited. But I can attempt a certain amount. Is there a developer
>>guide on the new FOP architecture? Migration instructions or the like?
>>    
>>
>
>Only end-user documentation on the migration. But as I said, the
>renderer architecture hasn't changed much. You'll find your way easily
>enough.
>
>What I'm currently unsure about is the process to allow you write access
>to the FOP repository. New committers have to be voted in, which is
>normally done after they contributed over a longer period of time. Given
>that you contribute a whole subsystem for FOP might make you and Pete
eligible
>for committership. But I think we first have to check what the XML
>Graphics PMC thinks about that. Otherwise, you'll simply have to
>contribute by sending patches but Manuel's example shows that it's
>perfectly possible to get someone in very quickly if he is a valuable
>addition to the project. Your reduced resources might make this a little
>more difficult. But we'll see what the others say and anyway, nobody
>ever gets forgotten about what he's contributed to a project.
>
>  
>
>>>>I have copied this e-mail to Jeremias Maerki who is the chair of the
>>>>Apache XMLGraphics Project Management Committee under whose
>>>>jurisdiction FOP falls. This is to keep him informed as the Apache
>>>>Foundation is taking licencing issues very serious to make sure all
>>>>parties are protected in the long run.
>>>>        
>>>>
>>>I have been checking the status periodically but wasn't aware of the
>>>alpha release, good to know it is progressing.
>>>
>>>I have no objection to you porting the code, and am happy to provide
>>>any assistance that you may require. I was the original developer
>>>however since moving the project to SourceForge I have received some
>>>very useful assistance from Joe Schmezter in creating the web pages,
>>>build scripts and bug fixing.
>>>
>>>I am also very keen to incorporate the renderer with official FOP
>>>build, so no problem donating the code - consider it done.
>>>
>>>In order to use the renderer it is necessary to have some AFP fonts. I
>>>managed to persuade a company to donate a very limited font set so
>>>that users could test the renderer - we will need to contact them to
>>>make sure that they are still happy (I'd assume they would be as it
>>>provides some free advertising and potentially gives them some sales
>>>potential for commercial fonts).
>>>      
>>>
>>I would think that the bulk of FOP users would have no interest whatsoever
>>in having AFP Fonts as part of the install. For these people, the AFP
>>fonts are wasted space in the download. However, having the AFP fonts in
>>the distrubtion really lowers the bar for getting new users up and running
>>on the AFP renderer, so I think that there needs to be some sort of way to
>>demonstrate that the renderer works out of the box.
>>
>>Currently, the Terrapin fonts we distribute make up about 600KB. Perhaps
>>this could be part of an optional install? Or possibly we could package up
>>two FOP builds - one with fonts, one without.
>>    
>>
>
>The problem I see is with these fonts. Terrapin seems to only provide a
>non-production license. That makes it incompatible with Apache licensing
>policy. We might do something similar as with the hyphenation patterns
>and leave the font package in the SourceForge project downloadable from
>there. That's unfortunate, but I don't see a way around this with this
>restriction. What we can do is provide links to Terrapin so people know
>where to get fonts from.
>
>  
>
>>Now, back to administrivia...
>>
>>Manual, how would you like to progress your porting activities? If you
>>like, we can give you commit access to the AFP Renderer CVS repository,
>>and you can commit your work on a branch there. Alternatively, do you want
>>to keep the port in the FOP repository?
>>    
>>
>
>I would suggest Manuel to take the offer about CVS access. I'd create a
>branch from the current code where Manuel could add his changes to make
>the renderer compatible with the new code. This preserves the old
>renderer which is compatible with FOP 0.20.5. From there we can tar up
>the sources once we've got a "go" to add the AFP Renderer to the FOP
>codebase. We'll then do a review and go through the checklist. In the
>meantime, you can handle the CLA submissions. 
>
>Looking forward to bringing AFP into FOP!
>
>Cheers,
>Jeremias Maerki
>
>
>  
>

[afp-renderer-developers] Re: FOP AFP Renderer

[Manuel M. <ma...@ap...>]

On Wed, 30 Nov 2005 07:35 am, Pete Townsend wrote:
<snip/>

Pete, Joe,

thank you very much for your enthusiastic support of this endeavour. 
Really much appreciated.
 
> Manual, please let me know your SourceForge user name and I'll get
> you added with CVS access to the AFP Renderer Project. I plan to
> create a CVS branch tomorrow evening so that we can get started on
> the migration.
>
My SourceForge id is: malm66

Regarding the port let me give you a heads up on where I am at.

Everything compiles and builds although I have removed the code for the 
0.20.5 extensions.
Basic rendering of blocks and the associated text positioning seems to 
work.
Justified text seems to work.
Coloured texts and text decorations (underline, overstrike, ...) etc. 
work.
Borders, padding and background colours work but differently to the 
0.20.5 renderer. I am using PTOCA line drawing primitives to create 
those not shaded graphics areas as the 0.20.5 renderer does.
I started adding image support based on IOCA but so far only had success 
with TIFF images. Although IOCA does support jpeg natively at least the 
AFP Viewer doesn't seem to like it. And the same for storing raw 
images. It seems the decompressed bitmaps returned by the Java 
libraries are not quite what IOCA expects.

What still needs to be done = a lot:

1. Keeping the whole document in memory and writing it out at the end 
doesn't scale well for large documents. The getDataStream interfaces 
probably could be replaced by a writeDataStream(OutputStream) type 
interface and the stream could probably be written on each endPage 
call. However, there are some page out of order rendering issues 
related to markers / page numbers which may require buffering, that is 
if page n is complete but page n-1 is not we have to wait writing page 
n until all it predecessors are written.

2. Haven't done leaders yet.

3. As borders (and leaders) are created using line drawing primitives 
leader/border styles like dotted, double, ... need to be programmed

4. Haven't looked at the whole reference area orientation stuff yet. 
MO:DCA does support changes in the co-ordinate system so we probably 
need to map the CTM matrix used by FOP to describe co-ordinate 
transformations into the appropriate MO:DCA structures.

5. Sort out the image support.

6. Integrate the raster fonts including their configuration etc. into 
the overall FOP font system (probably do that after FOray font 
integration is done).

7. Port the 0.20.5 AFP FOP extensions

8. Add support for svg

There is probably more I just can't remember at the moment.

But it should give you guys an idea were I am at.

> I can also contact Terrapin to see if they would be prepared to grant
> a the fonts under an AFP license and sign a CLA. They were quite
> helpful when I contacted them before - Alternatively someone from ASF
> could try IBM (they weren't too interested when it was just me!)  for
> a small open source font library?

If we can't get fonts under ASF license we may have to do the same as 
for our hyphenation patterns - keep them in a separate repository under 
SourceForge and just point to them. Obviously they are already in the 
SourceForge afp-renderer project so there is not much else to do.

The later version of AFP does support TrueType fonts (although I assume 
most of the installed AFP equipment won't). But by adding support for 
this to the AFP Renderer we may have at least a version that works 
'out-of-the-box'.

> Regards, Pete.
>

Cheers

Manuel

[afp-renderer-developers] Re: FOP AFP Renderer

[Pete T. <pet...@gm...>]

Jeremias, Manuel,

A signed CLA is in the post to via traditional snail mail. The AFP 
Renderer was orginally written by myself with Joe providing bug fixing 
plus support so we should only require CLA's from Joe and myself (Joe I 
assume you'll be sending one off as well). I've had a quick look at the 
alpha release today and don't think it will be too much effort to 
migrate as it stands. A little more effort may be required to integrate 
with FOrayFont so that Font Metrics are available (the AFP Renderer 
obtains Font Metrics from the AFP Font files - hence the need for them 
to be available).

Manual, please let me know your SourceForge user name and I'll get you 
added with CVS access to the AFP Renderer Project. I plan to create a 
CVS branch tomorrow evening so that we can get started on the migration.

I can also contact Terrapin to see if they would be prepared to grant a 
the fonts under an AFP license and sign a CLA. They were quite helpful 
when I contacted them before - Alternatively someone from ASF could try 
IBM (they weren't too interested when it was just me!)  for a small open 
source font library?

Regards, Pete.


Jeremias Maerki wrote:

>Hello all,
>
>let me chime in here. Manuel already introduced me. I'll be helping the
>AFP Renderer to migrate into the official Apache FOP repository on the
>legal side. See some comments inline.
>
>On 29.11.2005 11:15:04 Joe Schmetzer wrote:
>  
>
>>I've cc'd afp-renderer-developers to keep a public record of this
>>conversation. Manual, I have a few questions for you at the bottom of
>>this email, so read on...
>>
>>On Mon, 28 November, 2005 11:27 pm, Pete Townsend wrote:
>>    
>>
>>>Manuel Mall wrote:
>>>      
>>>
>>>>Pete,
>>>>
>>>>as you may be aware the Apache FOP project has just released an alpha
>>>>version of the new code base.
>>>>
>>>>We have received some expressions of interest to make an AFP renderer
>>>>available for the new version of FOP. I have therefore taken the
>>>>liberty to use your FOP 0.20.5 AFP Renderer code as a basis for a
>>>>porting attempt to the new FOP code base. This project is still in its
>>>>infancy and nothing is working yet.
>>>>        
>>>>
>>Excellent! I'm really pleased that you've taken the inititive on this
>>work. Pete and I are both fairly busy, and not yet familiar with the new
>>FOP architecture, so this project would take us a very long time.
>>    
>>
>
>From the perspective of a Renderer writer not so much has changed.
>
>  
>
>>It's interesting to hear that there is demand for the AFP Renderer to
>>become a core renderer.
>>    
>>
>
>That's not a surprise anyway. There have been at least two efforts to
>create an AFP Renderer for FOP. I believe there's even a third, private
>one.
>
>  
>
>>>>The purpose of this e-mail is to firstly inform you of this activity
>>>>in the hope to avoid any duplication of work in case you or someone
>>>>else you are aware off has similar plans.
>>>>
>>>>Secondly, should the port be successful, we possibly would like to add
>>>>the AFP renderer into the main code base in the Apache FOP repository.
>>>>For us to be able to do so we would need your consent or more
>>>>specifically you (and any other significant contributors to the
>>>>SourceForge AFP Renderer) would need to officially donate the code to
>>>>the Apache Foundation. May be you could give this some thought and
>>>>advise us if such a course of action would be acceptable to you and
>>>>your co-contributors on the project.
>>>>        
>>>>
>>It was always our intention for the AFP Renderer to become part of the
>>core FOP distribution. Here's my original blog entry on the subject:
>>
>>  http://www.exubero.com/blog/20040924_AFP_Renderer.html
>>    
>>
>
>That's very good to hear.
>
>  
>
>>Pete and I have already assigned copyright ownership to the Apache
>>Software Foundation. You might have noted that the copyright notice at
>>the top of all the source files and at the bottom of all the web pages
>>mentions this. This was to ensure that the migration path you are
>>suggesting is possible. Is there anything else that needs to be done to
>>"officially" transfer copyright?
>>    
>>
>
>The ASF doesn't do copyright assignments (see
>http://www.apache.org/licenses/software-grant.txt), you only give the
>same license to the ASF that the ASF gives to anyone else who likes to
>use some ASF software and agrees to the license terms. That you placed
>Apache copyrights on top of each file makes things easier. One step less
>in the process. However, the copyright statement only represents the
>copyright for the complete package (Apache FOP, for example), not for
>each single file. This may sound a little odd but there's a process
>running inside the ASF to clear up a few things about it. But since
>you've already got the right copyright header, the process gets easier.
>
>Anyway, since this is some software that was not developed by one
>developer alone we will have to follow a more strict process as
>documented under: http://incubator.apache.org/ip-clearance/index.html
>First, though, we'll have to officially get the consent from out team
>members in the FOP project to go forward with this. I don't think that
>will be a problem.
>
>What we'll certainly need are CLAs [1] on file from each person that
>contributed to the original AFP Renderer. See also the IP Clearance
>template found under the URL above.
>
>[1] http://www.apache.org/licenses/#clas
>
>  
>
>>>>Please be rest assured that this is not an attempt to take the project
>>>>away from you or to exclude you from further activity. Quite the
>>>>opposite. The Apache FOP project is keen to get as many people
>>>>involved especially using the new code base. Should you be interested
>>>>in taking the lead in this porting activity or in contributing to it
>>>>please let us know.
>>>>        
>>>>
>>As mentioned above, we are both happy that the AFP Renderer should
>>become part of core FOP.
>>
>>Personally, I would be interested in helping, but I don't have the in
>>depth knowledge of either AFP or XSL-FO that Pete does, and my time is
>>also limited. But I can attempt a certain amount. Is there a developer
>>guide on the new FOP architecture? Migration instructions or the like?
>>    
>>
>
>Only end-user documentation on the migration. But as I said, the
>renderer architecture hasn't changed much. You'll find your way easily
>enough.
>
>What I'm currently unsure about is the process to allow you write access
>to the FOP repository. New committers have to be voted in, which is
>normally done after they contributed over a longer period of time. Given
>that you contribute a whole subsystem for FOP might make you and Pete eligible
>for committership. But I think we first have to check what the XML
>Graphics PMC thinks about that. Otherwise, you'll simply have to
>contribute by sending patches but Manuel's example shows that it's
>perfectly possible to get someone in very quickly if he is a valuable
>addition to the project. Your reduced resources might make this a little
>more difficult. But we'll see what the others say and anyway, nobody
>ever gets forgotten about what he's contributed to a project.
>
>  
>
>>>>I have copied this e-mail to Jeremias Maerki who is the chair of the
>>>>Apache XMLGraphics Project Management Committee under whose
>>>>jurisdiction FOP falls. This is to keep him informed as the Apache
>>>>Foundation is taking licencing issues very serious to make sure all
>>>>parties are protected in the long run.
>>>>        
>>>>
>>>I have been checking the status periodically but wasn't aware of the
>>>alpha release, good to know it is progressing.
>>>
>>>I have no objection to you porting the code, and am happy to provide
>>>any assistance that you may require. I was the original developer
>>>however since moving the project to SourceForge I have received some
>>>very useful assistance from Joe Schmezter in creating the web pages,
>>>build scripts and bug fixing.
>>>
>>>I am also very keen to incorporate the renderer with official FOP
>>>build, so no problem donating the code - consider it done.
>>>
>>>In order to use the renderer it is necessary to have some AFP fonts. I
>>>managed to persuade a company to donate a very limited font set so
>>>that users could test the renderer - we will need to contact them to
>>>make sure that they are still happy (I'd assume they would be as it
>>>provides some free advertising and potentially gives them some sales
>>>potential for commercial fonts).
>>>      
>>>
>>I would think that the bulk of FOP users would have no interest whatsoever
>>in having AFP Fonts as part of the install. For these people, the AFP
>>fonts are wasted space in the download. However, having the AFP fonts in
>>the distrubtion really lowers the bar for getting new users up and running
>>on the AFP renderer, so I think that there needs to be some sort of way to
>>demonstrate that the renderer works out of the box.
>>
>>Currently, the Terrapin fonts we distribute make up about 600KB. Perhaps
>>this could be part of an optional install? Or possibly we could package up
>>two FOP builds - one with fonts, one without.
>>    
>>
>
>The problem I see is with these fonts. Terrapin seems to only provide a
>non-production license. That makes it incompatible with Apache licensing
>policy. We might do something similar as with the hyphenation patterns
>and leave the font package in the SourceForge project downloadable from
>there. That's unfortunate, but I don't see a way around this with this
>restriction. What we can do is provide links to Terrapin so people know
>where to get fonts from.
>
>  
>
>>Now, back to administrivia...
>>
>>Manual, how would you like to progress your porting activities? If you
>>like, we can give you commit access to the AFP Renderer CVS repository,
>>and you can commit your work on a branch there. Alternatively, do you want
>>to keep the port in the FOP repository?
>>    
>>
>
>I would suggest Manuel to take the offer about CVS access. I'd create a
>branch from the current code where Manuel could add his changes to make
>the renderer compatible with the new code. This preserves the old
>renderer which is compatible with FOP 0.20.5. From there we can tar up
>the sources once we've got a "go" to add the AFP Renderer to the FOP
>codebase. We'll then do a review and go through the checklist. In the
>meantime, you can handle the CLA submissions. 
>
>Looking forward to bringing AFP into FOP!
>
>Cheers,
>Jeremias Maerki
>
>
>  
>

[afp-renderer-developers] Re: FOP AFP Renderer

[Jeremias M. <de...@je...>]

Hello all,

let me chime in here. Manuel already introduced me. I'll be helping the
AFP Renderer to migrate into the official Apache FOP repository on the
legal side. See some comments inline.

On 29.11.2005 11:15:04 Joe Schmetzer wrote:
> I've cc'd afp-renderer-developers to keep a public record of this
> conversation. Manual, I have a few questions for you at the bottom of
> this email, so read on...
>=20
> On Mon, 28 November, 2005 11:27 pm, Pete Townsend wrote:
> > Manuel Mall wrote:
> >>Pete,
> >>
> >>as you may be aware the Apache FOP project has just released an alpha
> >>version of the new code base.
> >>
> >>We have received some expressions of interest to make an AFP renderer
> >>available for the new version of FOP. I have therefore taken the
> >>liberty to use your FOP 0.20.5 AFP Renderer code as a basis for a
> >>porting attempt to the new FOP code base. This project is still in its
> >>infancy and nothing is working yet.
>=20
> Excellent! I'm really pleased that you've taken the inititive on this
> work. Pete and I are both fairly busy, and not yet familiar with the new
> FOP architecture, so this project would take us a very long time.

=46rom the perspective of a Renderer writer not so much has changed.

> It's interesting to hear that there is demand for the AFP Renderer to
> become a core renderer.

That's not a surprise anyway. There have been at least two efforts to
create an AFP Renderer for FOP. I believe there's even a third, private
one.

> >>The purpose of this e-mail is to firstly inform you of this activity
> >>in the hope to avoid any duplication of work in case you or someone
> >>else you are aware off has similar plans.
> >>
> >>Secondly, should the port be successful, we possibly would like to add
> >>the AFP renderer into the main code base in the Apache FOP repository.
> >>For us to be able to do so we would need your consent or more
> >>specifically you (and any other significant contributors to the
> >>SourceForge AFP Renderer) would need to officially donate the code to
> >>the Apache Foundation. May be you could give this some thought and
> >>advise us if such a course of action would be acceptable to you and
> >>your co-contributors on the project.
>=20
> It was always our intention for the AFP Renderer to become part of the
> core FOP distribution. Here's my original blog entry on the subject:
>=20
>   http://www.exubero.com/blog/20040924_AFP_Renderer.html

That's very good to hear.

> Pete and I have already assigned copyright ownership to the Apache
> Software Foundation. You might have noted that the copyright notice at
> the top of all the source files and at the bottom of all the web pages
> mentions this. This was to ensure that the migration path you are
> suggesting is possible. Is there anything else that needs to be done to
> "officially" transfer copyright?

The ASF doesn't do copyright assignments (see
http://www.apache.org/licenses/software-grant.txt), you only give the
same license to the ASF that the ASF gives to anyone else who likes to
use some ASF software and agrees to the license terms. That you placed
Apache copyrights on top of each file makes things easier. One step less
in the process. However, the copyright statement only represents the
copyright for the complete package (Apache FOP, for example), not for
each single file. This may sound a little odd but there's a process
running inside the ASF to clear up a few things about it. But since
you've already got the right copyright header, the process gets easier.

Anyway, since this is some software that was not developed by one
developer alone we will have to follow a more strict process as
documented under: http://incubator.apache.org/ip-clearance/index.html
First, though, we'll have to officially get the consent from out team
members in the FOP project to go forward with this. I don't think that
will be a problem.

What we'll certainly need are CLAs [1] on file from each person that
contributed to the original AFP Renderer. See also the IP Clearance
template found under the URL above.

[1] http://www.apache.org/licenses/#clas

> >>Please be rest assured that this is not an attempt to take the project
> >>away from you or to exclude you from further activity. Quite the
> >>opposite. The Apache FOP project is keen to get as many people
> >>involved especially using the new code base. Should you be interested
> >>in taking the lead in this porting activity or in contributing to it
> >>please let us know.
>=20
> As mentioned above, we are both happy that the AFP Renderer should
> become part of core FOP.
>=20
> Personally, I would be interested in helping, but I don't have the in
> depth knowledge of either AFP or XSL-FO that Pete does, and my time is
> also limited. But I can attempt a certain amount. Is there a developer
> guide on the new FOP architecture? Migration instructions or the like?

Only end-user documentation on the migration. But as I said, the
renderer architecture hasn't changed much. You'll find your way easily
enough.

What I'm currently unsure about is the process to allow you write access
to the FOP repository. New committers have to be voted in, which is
normally done after they contributed over a longer period of time. Given
that you contribute a whole subsystem for FOP might make you and Pete eligi=
ble
for committership. But I think we first have to check what the XML
Graphics PMC thinks about that. Otherwise, you'll simply have to
contribute by sending patches but Manuel's example shows that it's
perfectly possible to get someone in very quickly if he is a valuable
addition to the project. Your reduced resources might make this a little
more difficult. But we'll see what the others say and anyway, nobody
ever gets forgotten about what he's contributed to a project.

> >>I have copied this e-mail to Jeremias Maerki who is the chair of the
> >>Apache XMLGraphics Project Management Committee under whose
> >>jurisdiction FOP falls. This is to keep him informed as the Apache
> >>Foundation is taking licencing issues very serious to make sure all
> >>parties are protected in the long run.
> >
> > I have been checking the status periodically but wasn't aware of the
> > alpha release, good to know it is progressing.
> >
> > I have no objection to you porting the code, and am happy to provide
> > any assistance that you may require. I was the original developer
> > however since moving the project to SourceForge I have received some
> > very useful assistance from Joe Schmezter in creating the web pages,
> > build scripts and bug fixing.
> >
> > I am also very keen to incorporate the renderer with official FOP
> > build, so no problem donating the code - consider it done.
> >
> > In order to use the renderer it is necessary to have some AFP fonts. I
> > managed to persuade a company to donate a very limited font set so
> > that users could test the renderer - we will need to contact them to
> > make sure that they are still happy (I'd assume they would be as it
> > provides some free advertising and potentially gives them some sales
> > potential for commercial fonts).
>=20
> I would think that the bulk of FOP users would have no interest whatsoeve=
r
> in having AFP Fonts as part of the install. For these people, the AFP
> fonts are wasted space in the download. However, having the AFP fonts in
> the distrubtion really lowers the bar for getting new users up and runnin=
g
> on the AFP renderer, so I think that there needs to be some sort of way t=
o
> demonstrate that the renderer works out of the box.
>=20
> Currently, the Terrapin fonts we distribute make up about 600KB. Perhaps
> this could be part of an optional install? Or possibly we could package u=
p
> two FOP builds - one with fonts, one without.

The problem I see is with these fonts. Terrapin seems to only provide a
non-production license. That makes it incompatible with Apache licensing
policy. We might do something similar as with the hyphenation patterns
and leave the font package in the SourceForge project downloadable from
there. That's unfortunate, but I don't see a way around this with this
restriction. What we can do is provide links to Terrapin so people know
where to get fonts from.

> Now, back to administrivia...
>=20
> Manual, how would you like to progress your porting activities? If you
> like, we can give you commit access to the AFP Renderer CVS repository,
> and you can commit your work on a branch there. Alternatively, do you wan=
t
> to keep the port in the FOP repository?

I would suggest Manuel to take the offer about CVS access. I'd create a
branch from the current code where Manuel could add his changes to make
the renderer compatible with the new code. This preserves the old
renderer which is compatible with FOP 0.20.5. From there we can tar up
the sources once we've got a "go" to add the AFP Renderer to the FOP
codebase. We'll then do a review and go through the checklist. In the
meantime, you can handle the CLA submissions.=20

Looking forward to bringing AFP into FOP!

Cheers,
Jeremias Maerki

[afp-renderer-developers] Re: FOP AFP Renderer

[Joe S. <jo...@ex...>]

I've cc'd afp-renderer-developers to keep a public record of this
conversation. Manual, I have a few questions for you at the bottom of
this email, so read on...

On Mon, 28 November, 2005 11:27 pm, Pete Townsend wrote:
> Manuel Mall wrote:
>>Pete,
>>
>>as you may be aware the Apache FOP project has just released an alpha
>>version of the new code base.
>>
>>We have received some expressions of interest to make an AFP renderer
>>available for the new version of FOP. I have therefore taken the
>>liberty to use your FOP 0.20.5 AFP Renderer code as a basis for a
>>porting attempt to the new FOP code base. This project is still in its
>>infancy and nothing is working yet.

Excellent! I'm really pleased that you've taken the inititive on this
work. Pete and I are both fairly busy, and not yet familiar with the new
FOP architecture, so this project would take us a very long time.

It's interesting to hear that there is demand for the AFP Renderer to
become a core renderer.

>>The purpose of this e-mail is to firstly inform you of this activity
>>in the hope to avoid any duplication of work in case you or someone
>>else you are aware off has similar plans.
>>
>>Secondly, should the port be successful, we possibly would like to add
>>the AFP renderer into the main code base in the Apache FOP repository.
>>For us to be able to do so we would need your consent or more
>>specifically you (and any other significant contributors to the
>>SourceForge AFP Renderer) would need to officially donate the code to
>>the Apache Foundation. May be you could give this some thought and
>>advise us if such a course of action would be acceptable to you and
>>your co-contributors on the project.

It was always our intention for the AFP Renderer to become part of the
core FOP distribution. Here's my original blog entry on the subject:

  http://www.exubero.com/blog/20040924_AFP_Renderer.html

Pete and I have already assigned copyright ownership to the Apache
Software Foundation. You might have noted that the copyright notice at
the top of all the source files and at the bottom of all the web pages
mentions this. This was to ensure that the migration path you are
suggesting is possible. Is there anything else that needs to be done to
"officially" transfer copyright?

>>Please be rest assured that this is not an attempt to take the project
>>away from you or to exclude you from further activity. Quite the
>>opposite. The Apache FOP project is keen to get as many people
>>involved especially using the new code base. Should you be interested
>>in taking the lead in this porting activity or in contributing to it
>>please let us know.

As mentioned above, we are both happy that the AFP Renderer should
become part of core FOP.

Personally, I would be interested in helping, but I don't have the in
depth knowledge of either AFP or XSL-FO that Pete does, and my time is
also limited. But I can attempt a certain amount. Is there a developer
guide on the new FOP architecture? Migration instructions or the like?

>>I have copied this e-mail to Jeremias Maerki who is the chair of the
>>Apache XMLGraphics Project Management Committee under whose
>>jurisdiction FOP falls. This is to keep him informed as the Apache
>>Foundation is taking licencing issues very serious to make sure all
>>parties are protected in the long run.
>
> I have been checking the status periodically but wasn't aware of the
> alpha release, good to know it is progressing.
>
> I have no objection to you porting the code, and am happy to provide
> any assistance that you may require. I was the original developer
> however since moving the project to SourceForge I have received some
> very useful assistance from Joe Schmezter in creating the web pages,
> build scripts and bug fixing.
>
> I am also very keen to incorporate the renderer with official FOP
> build, so no problem donating the code - consider it done.
>
> In order to use the renderer it is necessary to have some AFP fonts. I
> managed to persuade a company to donate a very limited font set so
> that users could test the renderer - we will need to contact them to
> make sure that they are still happy (I'd assume they would be as it
> provides some free advertising and potentially gives them some sales
> potential for commercial fonts).

I would think that the bulk of FOP users would have no interest whatsoever
in having AFP Fonts as part of the install. For these people, the AFP
fonts are wasted space in the download. However, having the AFP fonts in
the distrubtion really lowers the bar for getting new users up and running
on the AFP renderer, so I think that there needs to be some sort of way to
demonstrate that the renderer works out of the box.

Currently, the Terrapin fonts we distribute make up about 600KB. Perhaps
this could be part of an optional install? Or possibly we could package up
two FOP builds - one with fonts, one without.

Now, back to administrivia...

Manual, how would you like to progress your porting activities? If you
like, we can give you commit access to the AFP Renderer CVS repository,
and you can commit your work on a branch there. Alternatively, do you want
to keep the port in the FOP repository?

Cheers,
Joe Schmetzer .:. Renaissance Developer .:. http://www.exubero.com/

Re: [afp-renderer-developers] [Fwd: Re: Non scalable fonts]

[Pete T. <pet...@gm...>]

Joe, see latest email - looks like the FO team want to do the same....



Joe Schmetzer wrote:

>This is just a FYI...
>
>I spotted the following message on the fop-dev mailing list. It got me
>thinking that it's probably well overdue to make plans about migrating
>the AFP Renderer to work the the FOP trunk. It would be nice to at least
>have a plan of action in place before the new FOP hits the public.
>
>Joe Schmetzer .:. Renaissance Developer .:. http://www.exubero.com/
>
>-------- Forwarded Message --------
>From: Vincent Hennebert <vin...@en...>
>Reply-To: fo...@xm...
>To: fo...@xm...
>Subject: Re: Non scalable fonts
>Date: Fri, 25 Nov 2005 19:56:17 +0100
>
>Hi Manuel,
>
> > Just came across a scenario (AFP Renderer) where I need to support non
> > scalable fonts. The current FOP trunk font system is not very good at
> > this as it does font selection purely based on (name, style, weight).
> >
> > Does FOray font support non scalable fonts (raster / bitmap fonts)?
>
>Theoretically yes, but this is not implemented.
>
>
> > Is font size a possible font selection criteria in FOray?
>
>Yes. When requesting a font, the size must always be
>provided.
>
>
> > Does FOray support adding new types of fonts, i.e. is its font support
> > extensible?
>
>Yes. FOrayFont was designed with extensibility in mind [1].
>
>There are two main types of fonts in FOrayFont: system fonts
>i.e., fonts registered by the Java awt system; and
>free-standing fonts, which are directly handled by FOray and
>for which a font file is available. For now the only
>supported free-standing fonts are Type1 and TrueType fonts.
>You typically need a third type of FreeStandingFont, a kind
>of BitmapFont.
>
>Victor will be more able than me to evaluate the feasibility
>of such a thing. I suggest you subscribe to the
>foray-developer mailing list [2] and ask your question
>there.
>
>
> > How is the FOray font integration coming along? The reason behind this
> > question is simply - do I waste my time in modifying the current FOP
> > font system to somehow support non scalable fonts because FOray font is
> > imminent and I better wait for it or is it a fair way (months) down the
> > track and I have to find a workable intermediate solution for the
> > problem at hand?
>
>If all goes well, I should have a ready patch in 2 weeks. If
>you want I can post an updated pre-patch on Bugzilla,
>although I'm a bit ashamed of all the awful things I've put
>in the code and that I must correct... But don't hesitate to
>ask.
>
>Cheers,
>Vincent
>
>
>[1] http://foray.sourceforge.net/dev/font/planning.html
>[2] http://sourceforge.net/mail/?group_id=109663
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>afp-renderer-developers mailing list
>afp...@li...
>https://lists.sourceforge.net/lists/listinfo/afp-renderer-developers
>
>  
>

[afp-renderer-developers] [Fwd: Re: Non scalable fonts]

[Joe S. <jo...@ex...>]

This is just a FYI...

I spotted the following message on the fop-dev mailing list. It got me
thinking that it's probably well overdue to make plans about migrating
the AFP Renderer to work the the FOP trunk. It would be nice to at least
have a plan of action in place before the new FOP hits the public.

Joe Schmetzer .:. Renaissance Developer .:. http://www.exubero.com/

-------- Forwarded Message --------
From: Vincent Hennebert <vin...@en...>
Reply-To: fo...@xm...
To: fo...@xm...
Subject: Re: Non scalable fonts
Date: Fri, 25 Nov 2005 19:56:17 +0100

Hi Manuel,

 > Just came across a scenario (AFP Renderer) where I need to support non
 > scalable fonts. The current FOP trunk font system is not very good at
 > this as it does font selection purely based on (name, style, weight).
 >
 > Does FOray font support non scalable fonts (raster / bitmap fonts)?

Theoretically yes, but this is not implemented.


 > Is font size a possible font selection criteria in FOray?

Yes. When requesting a font, the size must always be
provided.


 > Does FOray support adding new types of fonts, i.e. is its font support
 > extensible?

Yes. FOrayFont was designed with extensibility in mind [1].

There are two main types of fonts in FOrayFont: system fonts
i.e., fonts registered by the Java awt system; and
free-standing fonts, which are directly handled by FOray and
for which a font file is available. For now the only
supported free-standing fonts are Type1 and TrueType fonts.
You typically need a third type of FreeStandingFont, a kind
of BitmapFont.

Victor will be more able than me to evaluate the feasibility
of such a thing. I suggest you subscribe to the
foray-developer mailing list [2] and ask your question
there.


 > How is the FOray font integration coming along? The reason behind this
 > question is simply - do I waste my time in modifying the current FOP
 > font system to somehow support non scalable fonts because FOray font is
 > imminent and I better wait for it or is it a fair way (months) down the
 > track and I have to find a workable intermediate solution for the
 > problem at hand?

If all goes well, I should have a ready patch in 2 weeks. If
you want I can post an updated pre-patch on Bugzilla,
although I'm a bit ashamed of all the awful things I've put
in the code and that I must correct... But don't hesitate to
ask.

Cheers,
Vincent


[1] http://foray.sourceforge.net/dev/font/planning.html
[2] http://sourceforge.net/mail/?group_id=109663

[afp-renderer-developers] AFP Renderer 1.1.0 released

[Joe S. <jo...@ex...>]

The AFP Renderer development team is pleased to announce the release of
AFP Renderer 1.1.0.

This latest release can be downloaded from
http://afp-renderer.sourceforge.net/download.html.

The important changes since the last release (1.0.2) are:

      * added support for outline fonts
      * added sample fonts with distribution
      * added XML2AFP command-line utility
      * added examples
      * fixed rendering of tables removing double lines
      * fixed rendering of tables in landscape
      * fixed shading table cell problem in landscape
      * expanded and updated documentation

Existing users should read the notes on upgrading the configuration in
http://afp-renderer.sourceforge.net/configuring.html, as the structure
of afp-fonts.xml has changed slightly.

For more information about the AFP Renderer, see
http://afp-renderer.sourceforge.net/.

[afp-renderer-developers] Ready to release?

[Joe S. <jo...@ex...>]

I've finished most of the outstanding tasks for the 1.1 release, and I
think we're nearly ready for a release.

I've drafted a release note at
http://www.exubero.com/afp-renderer/news.html which we can publish in
various places. What's the verdict?

Cheers,
Joe

[afp-renderer-developers] Docs for configuration

[Joe S. <jo...@ex...>]

I've just checked in afp-fop-src/docs/configuring.html with explanations
and reference documentation for the font configuration. As this work is
only relevant for when version 1.1 is released, I haven't published on
sourceforge yet, but you can preview it here:

http://www.exubero.com/afp-renderer/configuring.html

Pete, could you give this the once over to check accuracy.

Cheers,
Joe

[afp-renderer-developers] Changes to DTD resolution

[Joe S. <jo...@ex...>]

I've modified the DTDEntityResolver to handle the change in the DTD a
bit more gracefully:

* It now uses the public id of the doctype to decide what DTD to resolve
* It will throw an exception if a v1.0 DTD is specified, with an
appropriate exception message.

The major user visible effect of this change is that afp-fonts.xml
*must* have the following doctype definition:

<!DOCTYPE installed-fonts PUBLIC 
    "-//APACHE/DTD AFP Installed Font Definition DTD 1.1//EN"
    "http://org.apache.fop/installed-afp-fonts-1.1.dtd">

I'm in the middle of updating the docs to reflect this change.

Cheers,
Joe

[afp-renderer-developers] XML2AFP changes

[Joe S. <jo...@ex...>]

FYI, I've just checked in a refactored XML2AFP to make the following
changes:
* Input options are now more consistent with other command-line apps
* New -h option
* New -v option
* Removed most of the static methods
* Added new Arguments nested class to better encapsulate arg processing.

J

Re: [afp-renderer-developers] Working towards v1.1.0

[Joe S. <jo...@ex...>]

More TODO's knocked off the list. Recently checked into CVS:

* There is now a resources dir under afp-fop-src. The example
afp-fonts.xml and fonts have been moved into this directory.

* XML2AFP has been moved to the org.apache.fop.render.afp.apps package.

* The build has been modified to include some useful attributes in the
manifest (e.g. Main-Class, Class-Path, Implementation-Version). I
haven't yet updated the batch file, but all that is now needed to invoke
XML2AFP is something like:

java -jar dist/afp-renderer-1.1.0-dev.jar

[afp-renderer-developers] Working towards v1.1.0

[Joe S. <jo...@ex...>]

I've knocked a few things off the TODO list at
http://www.exubero.com/wiki/index.php/AFP_Renderer

* There is now a HACKING file in afp-fop-src, which currently contains
the notes on how to build a release distribution.

* Reorganised the docs menu to contain different sections

* Added new doc pages for building, configuring, running and embedding
the AFP Renderer. Currently, these pages are empty, so feel free to
contribute if you feel keen.

* Updated the download docs with cvs instructions

* Updated the resources docs with Terrapin and www.xslfo.info

* Published the docs (warts and all)

Cheers,
Joe

Re: [afp-renderer-developers] Release procedures

[Joe S. <jo...@ex...>]

On Sun, 2004-11-21 at 12:11, Pete Townsend wrote:
> Sounds good, suggest we document this on the web site?

I'm more inclined to check it in as a top level file in the module. This
sort of information is of no interest to users or casual browsers, but
people who need to know this information will already have a workspace.

> Also I've added and
> XML2AFP class and BAT file to the project. I'll start adding some test cases
> so that we can have a fully functional demo once we get the fonts.

Nice. I'll look over it when I get a chance.

Cheers,
Joe


> ----- Original Message ----- 
> From: "Joe Schmetzer" <jo...@ex...>
> To: <afp...@li...>
> Sent: Saturday, November 20, 2004 9:29 PM
> Subject: [afp-renderer-developers] Release procedures
> 
> 
> > Just checked into CVS... the ant build now supports a "release" target,
> > which should simplify building release.
> >
> > The following is a procedure/checklist which I think should be followed
> > for an official release. This procedure uses version 1.1.0 as an
> > example, and assumes a valid environment with CVSROOT, JAVA_HOME and
> > ANT_HOME correctly defined.
> >
> > 1) Make sure CHANGES, README, etc are up to date. Edit build.properties
> > to reflect the new release version, and check it into HEAD.
> >
> > dist.version = 1.1.0
> > dist.type =
> > ...
> > cvs ci -m "Release 1.1.0" build.properties
> >
> > 2) Tag the new release in CVS.
> >
> > cvs rtag -rHEAD AFP_RENDERER_1_1_0 afp-fop-src
> >
> > 3) Checkout a clean workspace using the tag and cd into it
> >
> > cvs co -rAFP_RENDERER_1_0_0 afp-fop-src
> > cd afp-fop-src
> >
> > 4) Run the release target in ant. This should create a new file called
> > afp-renderer-1.1.0.zip in the current directory. This is the file to be
> > published.
> >
> > ant release
> >
> > 5) Publish the release using the sourceforge admin interface.
> >
> > 6) To avoid accidentally creating a new release of the same name,
> > immediately bump up the build.properties version properties to the next
> > incremental release and check in.
> >
> > dist.version = 1.1.1
> > dist.type = -dev
> > ...
> > cvs ci -m "Release 1.1.1-dev" build.properties
> >
> > I think that's about it. Thoughts? Comments?
> >
> > Cheers,
> > Joe
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: InterSystems CACHE
> > FREE OODBMS DOWNLOAD - A multidimensional database that combines
> > robust object and relational technologies, making it a perfect match
> > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> > _______________________________________________
> > afp-renderer-developers mailing list
> > afp...@li...
> > https://lists.sourceforge.net/lists/listinfo/afp-renderer-developers
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> afp-renderer-developers mailing list
> afp...@li...
> https://lists.sourceforge.net/lists/listinfo/afp-renderer-developers

Re: [afp-renderer-developers] Release procedures

[Pete T. <pe...@to...>]

Sounds good, suggest we document this on the web site? Also I've added and
XML2AFP class and BAT file to the project. I'll start adding some test cases
so that we can have a fully functional demo once we get the fonts.

Cheers, Pete.


----- Original Message ----- 
From: "Joe Schmetzer" <jo...@ex...>
To: <afp...@li...>
Sent: Saturday, November 20, 2004 9:29 PM
Subject: [afp-renderer-developers] Release procedures


> Just checked into CVS... the ant build now supports a "release" target,
> which should simplify building release.
>
> The following is a procedure/checklist which I think should be followed
> for an official release. This procedure uses version 1.1.0 as an
> example, and assumes a valid environment with CVSROOT, JAVA_HOME and
> ANT_HOME correctly defined.
>
> 1) Make sure CHANGES, README, etc are up to date. Edit build.properties
> to reflect the new release version, and check it into HEAD.
>
> dist.version = 1.1.0
> dist.type =
> ...
> cvs ci -m "Release 1.1.0" build.properties
>
> 2) Tag the new release in CVS.
>
> cvs rtag -rHEAD AFP_RENDERER_1_1_0 afp-fop-src
>
> 3) Checkout a clean workspace using the tag and cd into it
>
> cvs co -rAFP_RENDERER_1_0_0 afp-fop-src
> cd afp-fop-src
>
> 4) Run the release target in ant. This should create a new file called
> afp-renderer-1.1.0.zip in the current directory. This is the file to be
> published.
>
> ant release
>
> 5) Publish the release using the sourceforge admin interface.
>
> 6) To avoid accidentally creating a new release of the same name,
> immediately bump up the build.properties version properties to the next
> incremental release and check in.
>
> dist.version = 1.1.1
> dist.type = -dev
> ...
> cvs ci -m "Release 1.1.1-dev" build.properties
>
> I think that's about it. Thoughts? Comments?
>
> Cheers,
> Joe
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> afp-renderer-developers mailing list
> afp...@li...
> https://lists.sourceforge.net/lists/listinfo/afp-renderer-developers

[afp-renderer-developers] Release procedures

[Joe S. <jo...@ex...>]

Just checked into CVS... the ant build now supports a "release" target,
which should simplify building release.

The following is a procedure/checklist which I think should be followed
for an official release. This procedure uses version 1.1.0 as an
example, and assumes a valid environment with CVSROOT, JAVA_HOME and
ANT_HOME correctly defined.

1) Make sure CHANGES, README, etc are up to date. Edit build.properties
to reflect the new release version, and check it into HEAD.
	
	dist.version = 1.1.0
	dist.type = 
	...
	cvs ci -m "Release 1.1.0" build.properties

2) Tag the new release in CVS.

	cvs rtag -rHEAD AFP_RENDERER_1_1_0 afp-fop-src

3) Checkout a clean workspace using the tag and cd into it

	cvs co -rAFP_RENDERER_1_0_0 afp-fop-src
	cd afp-fop-src

4) Run the release target in ant. This should create a new file called
afp-renderer-1.1.0.zip in the current directory. This is the file to be
published.

	ant release

5) Publish the release using the sourceforge admin interface.

6) To avoid accidentally creating a new release of the same name,
immediately bump up the build.properties version properties to the next
incremental release and check in.

	dist.version = 1.1.1
	dist.type = -dev
	...
	cvs ci -m "Release 1.1.1-dev" build.properties

I think that's about it. Thoughts? Comments?

Cheers,
Joe

Re: [afp-renderer-developers] javadoc cleanup

[Joe S. <jo...@ex...>]

On Fri, 2004-11-12 at 23:30, Joe Schmetzer wrote:
> Just checked in some changes which remove all the javadoc warnings.

An I just re-added them again. Please be careful when resolving
conficts, next time. ;-)