I don't think that Glenn's idea is that bad. FOP's open bugzilla issues are not 
only bugs, they also show what are the areas that FOP needs to be improved. If 
we start from the beginning, then 

| 1063|New|Nor|2001-03-21|fop does not handle large fo files   

is a real, very interesting issue and the solution is not to increase the Java 
heap size. There are workarounds such as caching objects but a good solution 
might be deeper in FOP's  layout engine. What about checking or implementing 
Donald Knuth's first-fit or best-fit algorithms ? In theory, it would allow to 
free FO tree and layout manager objects after the end of every page. 

There was a recent discussion about this, see
http://apache.markmail.org/message/3ejv4opwcceipfpl?q=list:org%2Eapache%2Exmlgraphics%2Efop-users+total+best+fit

Of course there will be drawbacks, FOP is complex (more complex than it should 
be in my opinion, cleanup / modularization would help) and this is not a simple 
task.


Alex Giotis


On Mar 5, 2012, at 4:49 PM, mehdi houshmand wrote:

> Haha, if only it were that simple... The projects have to be
> interesting and fulfilling and at least bordering on fun. They also
> have to be an opportunity to learn and encourage opensource
> development. There's little fun to be had fixing bugs hidden in the
> depths of FOPs fairly difficult to delve-in code base, also - probably
> more importantly - I can't imagine it would serve as encouragement.
> 
> Mehdi
> 
> On 5 March 2012 14:36, Glenn Adams <gl...@skynav.com> wrote:
>> I would suggest whittling down the fop bug list, starting from the
>> beginning.
>> 
>> 
>> On Mon, Mar 5, 2012 at 6:35 AM, mehdi houshmand <med1...@gmail.com> wrote:
>>> 
>>> Because of the overwhelming popularity of this idea, I've created a
>>> link on the Wiki
>>> (http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2012) for
>>> the GSoC proposals.
>>> 
>>> On a serious note, this is literally work for free. Google pays the
>>> bills and I'm happy to mentor any applicants and do the admin, all you
>>> have to do is provide ideas for projects. If you have a wish list or a
>>> list of TODOs that you think a newbie could do for a summer project (I
>>> do appreciate that's quite a big caveat), now's your opportunity.
>>> 
>>> Mehdi
>>> 
>>> On 1 March 2012 16:26, mehdi houshmand <med1...@gmail.com> wrote:
>>>> Hi Glenn,
>>>> 
>>>> The GSoC doesn't relate directly to the ASF or FOP directly, however,
>>>> putting a few FOP projects as proposals would be a good way to get
>>>> some new interest into the project. I think it would be good for us as
>>>> we benefit from any work done, and it helps whomever does the work
>>>> learn the various skills that we as a community can impart upon them.
>>>> 
>>>> I've included a link to the GSoC below, but if you do some research,
>>>> there's plenty of information out there.
>>>> 
>>>> http://code.google.com/soc/
>>>> 
>>>> Mehdi
>>>> 
>>>> On 1 March 2012 16:13, Glenn Adams <gl...@skynav.com> wrote:
>>>>> could you provide a link to the "Google Summer of Code Project"? how
>>>>> does it
>>>>> relate to ASF and FOP activities?
>>>>> 
>>>>> 
>>>>> On Thu, Mar 1, 2012 at 3:50 AM, mehdi houshmand <med1...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> We're thinking of submitting a proposal or two to the Google Summer of
>>>>>> Code project and wanted to get some input from the community on ideas.
>>>>>> Once we've got a few proposals I'll create a wiki page and put all the
>>>>>> ideas on there, but for now I just wanted to gauge interest.
>>>>>> 
>>>>>> In terms of mentoring, I'm happy to be a mentor and I've registered as
>>>>>> one and if any other committers fancy the job, do register, the more
>>>>>> the merrier. The deadline is 9th March, so that doesn't give us long
>>>>>> to bounce around ideas, but here are a few I was thinking:
>>>>>> 
>>>>>> - There have been recent discussions between Jeremias, myself and
>>>>>> others about extracting the Fonts packages into their own library. I
>>>>>> think this would be a great idea for a project because essentially it
>>>>>> only involves a few, well defined specifications (TTF, Type1 etc) and
>>>>>> doesn't expose the person to too much complexity. The way I'd suggest
>>>>>> this to be done, is by re-writing rather than porting, that way it
>>>>>> gives the person much more flexibility and also the current code would
>>>>>> give them good tips and tricks on how to deal with parsing fonts.
>>>>>> 
>>>>>> - TTF in AFP. I know we still have the TrueTypeInPostScript branch
>>>>>> flying around, and however much I'd like to fob that onto someone
>>>>>> else, I don't think it's fair to do so. I have no idea how long this
>>>>>> project would take, but I think FOP could really benefit from it.
>>>>>> Currently we're forcing users to use AFP fonts for AFP documents, a
>>>>>> lot of which are archaic and use EBCDIC, for those of you who haven't
>>>>>> been exposed to EBCDIC, count yourself lucky.
>>>>>> 
>>>>>> There may be something to do with PCL?? I'm not at all familiar with
>>>>>> the format, but I do remember discussions about upgrading to a newer
>>>>>> PCL standard? I'd be happy to acquaint myself with the format if
>>>>>> there's interest in the idea.
>>>>>> 
>>>>>> Hopefully we can get a proposal together in time.
>>>>>> 
>>>>>> Mehdi
>>>>> 
>>>>> 
>> 
>> 

Reply via email to