Re: Apache Fop debugging workflow

[Chris]

Hi Anton,

That's a pretty vague question. Can you describe the issue you are 
facing? It's also usual to share the XSL-Fo that causes the problem. We 
will then have some chance to advise on possible solutions

Thanks,

Chris

On 07/06/2019 14:01, Plotnikau, Anton wrote:
>
> HI Team,
>
> We faced with issue related to Apache FOP. We need to perform some 
> debugging in Apache Fop source code to investigate this issue.
>
> Could you please share any experience how debug Apache Fop?
>
> Best regards,
>
> *Anton Plotnikau*
>
> *PLUK 2nd Line Support Developer | EPAM*
>
> **
>
> Time Zone*:*(UTC +03:00) Minsk
>
> Mobile: +375 29 389 4514
>
> anton.plotni...@thomsonreuters.com 
> 
>

Re: Apache FOP XML to PDF problem with CJK Unified Ideographs Extension B character

[BRUCE Y L LEE]

Hi Glenn,

Thanks again your details explanation and help to create a bug report.

Thank you very much.

Regards,
Bruce


2011/9/19 Glenn Adams 

> I mean FOP itself needs to be modified to properly handle UTF-16 encoded
> (i.e., Java string encoded) surrogate pair encodings of non-BMP Unicode code
> points.
>
> I have been doing such modifications in part in my recent work to add
> complex script support (in which I did code for handling non-BMP
> codepoints), but I have not undertaken to perform all necessary
> modifications to support extra-BMP code points in pre-existing code.
>
> I have created a bug report for this at:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51843
>
> I am willing to accept the work of resolving this bug, but I can't give you
> a schedule at this time as to when I will work on it (as I have other work
> on complex scripts that will take priority). If anyone else wishes to
> actively work on it and develop a patch before I do, they are free to do so;
> in which case, I would appreciate hearing about such work ahead of time so I
> don't create a redundant patch.
>
> Regards,
> Glenn
>
>
> 2011/9/19 BRUCE Y L LEE 
>
>> Hi Glenn,
>>
>> Thanks your details explanation.
>>
>> May I know what is the meaning of "upgrade to the current code base" ? It
>> is related to OS or JDK? And how to upgrade to the current code base? I need
>> to know how to handle the CJK Unified Ideographs Extension B characters 
>> (characters
>> whose scalar value is greater than 65535 (decimal)) by my project
>> needs. Thank you very much.
>>
>> Regards,
>> Bruce
>>
>>
>> 2011/9/17 Glenn Adams 
>>
>>> In general, FOP does not support the use of characters outside the
>>> Unicode Base Multilingual Plane (BMP), i.e., characters whose scalar value
>>> is greater than 65535 (decimal).
>>>
>>> Support for extra-BMP Unicode codepoints will require an upgrade to the
>>> current code base. As you can see by the error messages below, it is
>>> attempting to treat individual UTF-16 surrogate pair codes as distinct code
>>> points, and not as a UTF-16 encoding of an extra-BMP code point.
>>>
>>> Regards,
>>> Glenn
>>>
>>> 2011/9/16 BRUCE Y L LEE 
>>>
 Hi

 I would like to transform XML to PDF using Apache FOP.
 CJK Unified Ideographs Extension B characters is included in the XML
 (e.g. 𠀀), I had add the font "Simsun (Founder Extended)" for Apache
 FOP but it cannot render the CJK Unified Ideographs Extension B characters,
 please help.

 CJK_ExtB.xml
 [code]
 𠀀
 [/code]

 CJK_ExtB_FO.xsl
 [code]
 
 http://www.w3.org/1999/XSL/Transform"; xmlns:fo="
 http://www.w3.org/1999/XSL/Format";>
  
 
 
  >>> page-width="21.0cm" margin="2cm">
 
  
 
 
  
 測試>>> select="CJK_ExtB"/>測試
  
 
 
  
 
 [/code]

 fop.xconf
 [code]
 
   
 flate
   
   
 >>> embed-url="file:///D:/fop-1.0/fonts/SURSONG.ttf">
  >>> weight="normal"/>
 >>> weight="bold"/>
  >>> weight="normal"/>
 >>> weight="bold"/>
  
   
 
 [/code]

 cmd
 [code]
 D:\fop-1.0>fop -c conf\fop.xconf -xml CJK_ExtB.xml -xsl CJK_ExtB_FO.xsl
 -pdf CJK_ExtB.pdf
 9月 15, 2011 2:32:20 下午 org.apache.fop.apps.FopFactoryConfigurator
 configure INFO: Default page-height set to: 11in
 9月 15, 2011 2:32:20 下午 org.apache.fop.apps.FopFactoryConfigurator
 configure INFO: Default page-width set to: 8.26in
 9月 15, 2011 2:32:23 下午 org.apache.fop.events.LoggingEventListener
 processEvent WARNING: Glyph "?" (0xd840) not available in font
 "FZSY--SURROGATE-0".
 9月 15, 2011 2:32:23 下午 org.apache.fop.events.LoggingEventListener
 processEvent WARNING: Glyph "?" (0xdc00) not available in font
 "FZSY--SURROGATE-0".
 [/code]


 Regards,
 Bruce
>>>
>>>
>>
>

Re: Apache FOP XML to PDF problem with CJK Unified Ideographs Extension B character

[Glenn Adams]

I mean FOP itself needs to be modified to properly handle UTF-16 encoded
(i.e., Java string encoded) surrogate pair encodings of non-BMP Unicode code
points.

I have been doing such modifications in part in my recent work to add
complex script support (in which I did code for handling non-BMP
codepoints), but I have not undertaken to perform all necessary
modifications to support extra-BMP code points in pre-existing code.

I have created a bug report for this at:

https://issues.apache.org/bugzilla/show_bug.cgi?id=51843

I am willing to accept the work of resolving this bug, but I can't give you
a schedule at this time as to when I will work on it (as I have other work
on complex scripts that will take priority). If anyone else wishes to
actively work on it and develop a patch before I do, they are free to do so;
in which case, I would appreciate hearing about such work ahead of time so I
don't create a redundant patch.

Regards,
Glenn

2011/9/19 BRUCE Y L LEE 

> Hi Glenn,
>
> Thanks your details explanation.
>
> May I know what is the meaning of "upgrade to the current code base" ? It
> is related to OS or JDK? And how to upgrade to the current code base? I need
> to know how to handle the CJK Unified Ideographs Extension B characters 
> (characters
> whose scalar value is greater than 65535 (decimal)) by my project
> needs. Thank you very much.
>
> Regards,
> Bruce
>
>
> 2011/9/17 Glenn Adams 
>
>> In general, FOP does not support the use of characters outside the Unicode
>> Base Multilingual Plane (BMP), i.e., characters whose scalar value is
>> greater than 65535 (decimal).
>>
>> Support for extra-BMP Unicode codepoints will require an upgrade to the
>> current code base. As you can see by the error messages below, it is
>> attempting to treat individual UTF-16 surrogate pair codes as distinct code
>> points, and not as a UTF-16 encoding of an extra-BMP code point.
>>
>> Regards,
>> Glenn
>>
>> 2011/9/16 BRUCE Y L LEE 
>>
>>> Hi
>>>
>>> I would like to transform XML to PDF using Apache FOP.
>>> CJK Unified Ideographs Extension B characters is included in the XML
>>> (e.g. 𠀀), I had add the font "Simsun (Founder Extended)" for Apache
>>> FOP but it cannot render the CJK Unified Ideographs Extension B characters,
>>> please help.
>>>
>>> CJK_ExtB.xml
>>> [code]
>>> 𠀀
>>> [/code]
>>>
>>> CJK_ExtB_FO.xsl
>>> [code]
>>> 
>>> http://www.w3.org/1999/XSL/Transform"; xmlns:fo="
>>> http://www.w3.org/1999/XSL/Format";>
>>>  
>>> 
>>> 
>>>  >> page-width="21.0cm" margin="2cm">
>>> 
>>>  
>>> 
>>> 
>>>  
>>> 測試>> select="CJK_ExtB"/>測試
>>>  
>>> 
>>> 
>>>  
>>> 
>>> [/code]
>>>
>>> fop.xconf
>>> [code]
>>> 
>>>   
>>> flate
>>>   
>>>   
>>> >> embed-url="file:///D:/fop-1.0/fonts/SURSONG.ttf">
>>>  >> weight="normal"/>
>>> >> weight="bold"/>
>>>  >> weight="normal"/>
>>> >> weight="bold"/>
>>>  
>>>   
>>> 
>>> [/code]
>>>
>>> cmd
>>> [code]
>>> D:\fop-1.0>fop -c conf\fop.xconf -xml CJK_ExtB.xml -xsl CJK_ExtB_FO.xsl
>>> -pdf CJK_ExtB.pdf
>>> 9月 15, 2011 2:32:20 下午 org.apache.fop.apps.FopFactoryConfigurator
>>> configure INFO: Default page-height set to: 11in
>>> 9月 15, 2011 2:32:20 下午 org.apache.fop.apps.FopFactoryConfigurator
>>> configure INFO: Default page-width set to: 8.26in
>>> 9月 15, 2011 2:32:23 下午 org.apache.fop.events.LoggingEventListener
>>> processEvent WARNING: Glyph "?" (0xd840) not available in font
>>> "FZSY--SURROGATE-0".
>>> 9月 15, 2011 2:32:23 下午 org.apache.fop.events.LoggingEventListener
>>> processEvent WARNING: Glyph "?" (0xdc00) not available in font
>>> "FZSY--SURROGATE-0".
>>> [/code]
>>>
>>>
>>> Regards,
>>> Bruce
>>
>>
>

Re: Apache Fop + Russian Language Support

[Chris Bowditch]

On 07/06/2011 09:49, Ankur wrote:

I am Ankur,need to generate Report in Russian Language.


Hi Ankur,


fop.xconf as:




XSL as:

Russian:


А Б В Г

but still the PostScript file is not showing these Russian characters.


That is because fop v1.0 and trunk do not support True Type Fonts (TTF) 
in Postscript. There is a branch in SVN where support for TTF in 
Postscript has been added. You will need to download the branch from SVN 
and compile it yourself if you can't find a Type 1 version of the Lucon 
font.



  Can someone
help me in this?
BTW: In future, please ask questions about FOP's usage on the fop-user 
mailing list. fop-dev is reserved for discussions about FOP's internals.


Chris

Re: Apache FOP 0.95 Patch

[Andreas Delmelle]

On 04 Jun 2009, at 14:53, Ben Wuest wrote:

Hi Ben


I agree that this should happen behind the scenes without the user
having to specify anything.  I had to perform this work-around the  
way I

did because of our current time constraints.  Hopefully, this can lead
to something else. Unfortunately, my knowledge of the Apache FOP  
Source
only extends to the last week of work getting this work-around in  
place.


All the more credit to you then, if you accomplished to understand  
enough to do it in one week! :-)


If you ever considered becoming a more steady contributor, you are  
very welcome to join us (as far as I'm concerned). Note that you will  
probably want to check our code-style guidelines in that case (minor  
details, but important for getting patches committed sooner rather  
than later).



I am pretty sure, however, that to implement memory management
effectively for FOP (behind the scenes) for RTF and PDF, the two
handlers (RTFHandler and AreaTreeHandler) will have to be modified.
Having said that, I think it will be much easier to modify the RTF
rendering because it does not use the Page Breaking Algorithm.


Definitely true. For the AreaTreeHandler, the code that is currently  
in endPageSequence() would have to be relocated to trigger the  
doLayout() loop sooner. I've considered starting this at some point,  
but quickly ran into some 'walls'. The whole layout loop is  
implemented so ... tightly (?) As you noticed, disentangling that web  
is really far from trivial.


Anyway, thanks again for this contribution!


Andreas

RE: Apache FOP 0.95 Patch

[Ben Wuest]

I agree that this should happen behind the scenes without the user
having to specify anything.  I had to perform this work-around the way I
did because of our current time constraints.  Hopefully, this can lead
to something else. Unfortunately, my knowledge of the Apache FOP Source
only extends to the last week of work getting this work-around in place.


I am pretty sure, however, that to implement memory management
effectively for FOP (behind the scenes) for RTF and PDF, the two
handlers (RTFHandler and AreaTreeHandler) will have to be modified.
Having said that, I think it will be much easier to modify the RTF
rendering because it does not use the Page Breaking Algorithm.  

Regards,

Ben.



-Original Message-
From: Andreas Delmelle [mailto:andreas.delme...@telenet.be] 
Sent: Thursday, June 04, 2009 9:35 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Apache FOP 0.95 Patch

On 04 Jun 2009, at 14:11, Simon Pepping wrote:

Hi Ben, Simon & Vincent,

>> 
>
> Indeed, it is a horrible hack with regard to the meaning of a
> page-sequence. But it is an interesting solution to the problem of
> influencing FOP's page breaking algorithm.

The very same thoughts over here. A really interesting showcase of  
what FOP can/should do, but I'd go about the implementation  
differently. Still a worthwhile overview of what needs to happen,  
albeit behind the scenes, without requiring the user to do anything  
special.

> 
> B.T.W., why does the algorithm not stop at hard page breaks?

IIC from recent debug-sessions, it does. Well, it's not really the  
algorithm that stops...
If the FlowLM signals a forced page-break, the current block-list is  
returned, page-breaks are computed and the areas are immediately added  
to the tree. After that, the PageBreaker resumes fetching the  
following block-lists. The breaks for the latter part are computed  
later by an entirely separate PageBreakingAlgorithm. In fact, this is  
one scenario where the line-breaking continues with a possibly  
different available i-p-d.

Span-changes are another example where FOP currently already processes  
part of the page-sequence with a different PageBreakingAlgorithm.

> I seem to recall that in the past this happened for hard line breaks.

This is indeed not so. Hard line-breaks just trigger the end of the  
current Paragraph and start a new one (an empty one, if it only  
contains a preserved linefeed, to produce a blank line), but the main  
getNextKnuthElements() loop is not interrupted. The forced breaks do,  
however, help the algorithm. I once ran a test with a document  
containing one single fo:block with the pre-formatted text of an  
entire book. Without 'linefeed-treatment="preserve"', FOP needed at  
least 768MB to avoid running out of memory, because it had to  
recompute all the line-breaks. Preserving the linefeeds, I needed only  
64MB (maybe even lower, but I don't think I tried that).



Regards

Andreas

Re: Apache FOP 0.95 Patch

[Andreas Delmelle]

On 04 Jun 2009, at 14:11, Simon Pepping wrote:

Hi Ben, Simon & Vincent,





Indeed, it is a horrible hack with regard to the meaning of a
page-sequence. But it is an interesting solution to the problem of
influencing FOP's page breaking algorithm.


The very same thoughts over here. A really interesting showcase of  
what FOP can/should do, but I'd go about the implementation  
differently. Still a worthwhile overview of what needs to happen,  
albeit behind the scenes, without requiring the user to do anything  
special.




B.T.W., why does the algorithm not stop at hard page breaks?


IIC from recent debug-sessions, it does. Well, it's not really the  
algorithm that stops...
If the FlowLM signals a forced page-break, the current block-list is  
returned, page-breaks are computed and the areas are immediately added  
to the tree. After that, the PageBreaker resumes fetching the  
following block-lists. The breaks for the latter part are computed  
later by an entirely separate PageBreakingAlgorithm. In fact, this is  
one scenario where the line-breaking continues with a possibly  
different available i-p-d.


Span-changes are another example where FOP currently already processes  
part of the page-sequence with a different PageBreakingAlgorithm.



I seem to recall that in the past this happened for hard line breaks.


This is indeed not so. Hard line-breaks just trigger the end of the  
current Paragraph and start a new one (an empty one, if it only  
contains a preserved linefeed, to produce a blank line), but the main  
getNextKnuthElements() loop is not interrupted. The forced breaks do,  
however, help the algorithm. I once ran a test with a document  
containing one single fo:block with the pre-formatted text of an  
entire book. Without 'linefeed-treatment="preserve"', FOP needed at  
least 768MB to avoid running out of memory, because it had to  
recompute all the line-breaks. Preserving the linefeeds, I needed only  
64MB (maybe even lower, but I don't think I tried that).




Regards

Andreas

Re: Apache FOP 0.95 Patch

[Simon Pepping]

On Thu, Jun 04, 2009 at 11:35:17AM +0100, Vincent Hennebert wrote:
> It is likely to interest other users who run into similar memory issues,
> and the good thing of having made it against the 0.95 release is that it
> won???t be made obsolete by further changes in the code.
> 
> We are not going to apply this patch to the Trunk, though. This is
> a workaround that, although quite clever, distorts too much the
> semantics of the fo:page-sequence element. A page sequence really is
> a self-contained set of typographical material, that should start and
> end on its own pages (the common analogy is the chapter of a book).

Indeed, it is a horrible hack with regard to the meaning of a
page-sequence. But it is an interesting solution to the problem of
influencing FOP's page breaking algorithm. Effectively, it inserts
points where it guides the algorithm to restrict its optimization to
the region up to that point. As long as we do not have a fundamental
solution to the problem, causing OOM situations for users, this is a
prototype for a nice interim solution: some hint that tells the
page-breaking algorithm to stop here, calculate and ship the pages,
and then resume.

B.T.W., why does the algorithm not stop at hard page breaks? I seem to
recall that in the past this happened for hard line breaks. It may
have been me who undid that, in my work on block elements in line
elements. I may have done that mostly because it seemed an unnecessary
complication at that time. In the context of the current problem it
may be good to revisit that. A hard page break is a much better hint
than a pseudo-page-sequence.

Regards, Simon

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

RE: Apache FOP 0.95 Patch

[Ben Wuest]

Vincent -

I agree this is a work-around and does distort the semantics of the 
fo:page-sequence element.  When I opened up the FOP 0.95 Source last week, it 
became apparent that trying to interject where FOP starts its layout would be 
time consuming. Currently the handlers are directly tied to the FO to only 
start rendering when a page-sequence is closed.  

I would like to point out that the patched code does not start rendering 
earlier than this.  It simply provides a method of continuing the rendering 
without a page break.  Again, this does not conform to the semantics of a 
page-sequence -- in that -- a page-sequence should be a set of pages that start 
and end on its own pages.  However, there was no other way (at least that I 
could see) within the confines of the time constraints I had to provide a 
work-around for FOP to manage the memory correctly.  

So, having said this, the patch allows RTF and PDF Rendering to work in 
original fashion or in the new modified approach.  The default behavior is to a 
page-sequence not trigger a page break at the end of its content.  To enable 
your document to render as it did pre-patch the page-sequence is specified as:


... Contents 


I understand why you are not going to blend this into Trunk.  Maybe some of the 
work provided in this patch can be used to provide a new mechanism for 
improving the memory management of FOP in which rendering is not tied to the 
end of page-sequences. 

Cheers.

Ben.



-Original Message-
From: Vincent Hennebert [mailto:vhenneb...@gmail.com] 
Sent: Thursday, June 04, 2009 7:35 AM
To: fop-dev@xmlgraphics.apache.org
Cc: Chris Fanjoy; Jody Brownell; Glen Campbell
Subject: Re: Apache FOP 0.95 Patch

Hi Ben,

Thank you very much for your interest in FOP and your contribution. I've
opened a Bugzilla issue containing your patch so that it can easily be
referred to:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47314

It is likely to interest other users who run into similar memory issues,
and the good thing of having made it against the 0.95 release is that it
won't be made obsolete by further changes in the code.

We are not going to apply this patch to the Trunk, though. This is
a workaround that, although quite clever, distorts too much the
semantics of the fo:page-sequence element. A page sequence really is
a self-contained set of typographical material, that should start and
end on its own pages (the common analogy is the chapter of a book).

Rather, at some point we will have to tackle that artificial limitation
of starting the layout only when the end of the page sequence has been
reached. It's possible to start earlier, like you have somehow proved
it. Also, we are planning to implement several layout options, providing
different trade-off between speed/memory consumption and typographical
quality. Eventually it should  no longer be necessary to split the
document into several page sequences to avoid memory issues.

Still, meanwhile your patch may save the lives of users who need a
quick solution to that problem.

I hope you understand.
Thanks again,
Vincent


Ben Wuest wrote:
> Hi -
> 
>  
> 
> We recently integrated Apache FOP 0.95 with our software to perform the 
> rendering of RTF and PDF reports.  This integration was very quick and 
> provided great results. However, due to the large amounts of data that our 
> software is required to handle, we began experiencing Out of Memory problems 
> with FOP.  We researched this and sent letters to the user community and 
> determined that what we were experiencing OOM issues because each of our 
> reports existed in one page-sequence.  We came to the conclusions from the 
> community response, Web Forums, and analysis of the Apache FOP code itself 
> that FOP reads to the end of a page sequence and then begins to render.   
> With the large amounts of data ( 40 Mb FO files ) we quickly ran into 
> scalability issues with one page-sequence per report.  At this point we 
> divided up our reports into multiple page-sequences only to find that FOP 
> starts a new page on every page sequence and this behavior can not be changed 
> (through the means of alterin
g the FO file).  Page breaking at unpredictable locations (sometimes leaving 
half or ¾ pages empty) made the report presentation visually unacceptable.
> 
>  
> 
> We have modified the Apache 0.95 code for PDF and RTF Rendering and would 
> like to offer this patch back to the community (the attached SVN diff is from 
> the 0.95 release baseline).   Listed below is an overview of the 
> modifications that have been made.  

> 
>  
> 
> 1.   Page Sequence Changes
> 
>  
> 
> The handling of the break-after attribute was added to the page-sequence.  
> This can only be set to auto (meaning that no page break will occur after t

Re: Apache FOP 0.95 Patch

[Vincent Hennebert]

Hi Ben,

Thank you very much for your interest in FOP and your contribution. I’ve
opened a Bugzilla issue containing your patch so that it can easily be
referred to:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47314

It is likely to interest other users who run into similar memory issues,
and the good thing of having made it against the 0.95 release is that it
won’t be made obsolete by further changes in the code.

We are not going to apply this patch to the Trunk, though. This is
a workaround that, although quite clever, distorts too much the
semantics of the fo:page-sequence element. A page sequence really is
a self-contained set of typographical material, that should start and
end on its own pages (the common analogy is the chapter of a book).

Rather, at some point we will have to tackle that artificial limitation
of starting the layout only when the end of the page sequence has been
reached. It’s possible to start earlier, like you have somehow proved
it. Also, we are planning to implement several layout options, providing
different trade-off between speed/memory consumption and typographical
quality. Eventually it should  no longer be necessary to split the
document into several page sequences to avoid memory issues.

Still, meanwhile your patch may save the lives of users who need a
quick solution to that problem.

I hope you understand.
Thanks again,
Vincent


Ben Wuest wrote:
> Hi -
> 
>  
> 
> We recently integrated Apache FOP 0.95 with our software to perform the 
> rendering of RTF and PDF reports.  This integration was very quick and 
> provided great results. However, due to the large amounts of data that our 
> software is required to handle, we began experiencing Out of Memory problems 
> with FOP.  We researched this and sent letters to the user community and 
> determined that what we were experiencing OOM issues because each of our 
> reports existed in one page-sequence.  We came to the conclusions from the 
> community response, Web Forums, and analysis of the Apache FOP code itself 
> that FOP reads to the end of a page sequence and then begins to render.   
> With the large amounts of data ( 40 Mb FO files ) we quickly ran into 
> scalability issues with one page-sequence per report.  At this point we 
> divided up our reports into multiple page-sequences only to find that FOP 
> starts a new page on every page sequence and this behavior can not be changed 
> (through the means of alterin
g the FO file).  Page breaking at unpredictable locations (sometimes leaving 
half or ¾ pages empty) made the report presentation visually unacceptable.
> 
>  
> 
> We have modified the Apache 0.95 code for PDF and RTF Rendering and would 
> like to offer this patch back to the community (the attached SVN diff is from 
> the 0.95 release baseline).   Listed below is an overview of the 
> modifications that have been made.  
> 
>  
> 
> 1.   Page Sequence Changes
> 
>  
> 
> The handling of the break-after attribute was added to the page-sequence.  
> This can only be set to auto (meaning that no page break will occur after the 
> page-sequence) or page (meaning that a page-break will occur after the 
> page-sequence).  There wasn't another suitable attribute to use (from the 
> xsl-fo standard) so break-after was employed.
> 
>  
> 
> 2.   PDF Rendering
> 
>  
> 
> In PDF rendering, the page-sequence handling was modified to consider the new 
> attribute on a page sequence (described in #1 above).  The rendering was 
> modified to save the last page of a page sequence for the next one and track 
> the available BPD.  In this fashion, when the next page sequence starts it 
> checks for an unfinished page on the previous page sequence and uses that to 
> begin its Page Breaking Algorithm.  This required some small changes in the 
> Page Break algorithm to read available BPD from carry over pages.
> 
>  
> 
> 3.   RTF Rendering
> 
>  
> 
> In RTF Rendering, the page-sequence handling was also modified to consider 
> the new attribute on a page sequence (described in #1 above). The RTFHandler 
> was modified to start a document Area for every page sequence and to release 
> the memory on page-sequence once it was complete (it is our impression from 
> JProfiler analysis that it currently does not do this).  We modified the 
> RTFElement class to allow for flags as to whether to write the prefix or 
> suffix.  This enables the rendering to actually write the RtfFile on every 
> page-sequence without closing the document.  In addition this means that 
> RtfFile is flushed (all memory) on every page-sequence (or RtfSection in the 
> context of the rendering).  
> 
>  
> 
>  
> 
> The result of this allows us to render 7000 page RTF and PDF reports that 
> contain continuous tables of over 20,000 records seamlessly (without page 
> breaks in the table that are not at an end of page)

Re: Apache FOP 0.93 Released

[Arnaud HERITIER]

Ok, I'll try to see if I can find a little time to help you.
I would like to upgrade FOP in the pdf plugin for maven.
Thanks

Arnaud


On 1/9/07, Simon Pepping <[EMAIL PROTECTED]> wrote:


Arnaud,

On Tue, Jan 09, 2007 at 01:31:13AM +0100, Arnaud HERITIER wrote:
> Hi Simon,
>
>  Can you deploy your jars on a maven repository please.
> For example :
> http://people.apache.org/repo/m1-ibiblio-rsync-repository/fop/jars/

Please ask on [EMAIL PROTECTED] There has been talk
about Maven. I know Jeremias and Vincent have looked at it. The build
script has a target for it. There is a POM file. But none of us have
much experience with it, and we have little time. Therefore your best
chance is a contribution by a user, such as yourself. Perhaps you can
patch the build script to create such a deployment.

Regards, Simon

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

Re: Apache FOP 0.93 Released

[Elliotte Harold]

Simon Pepping wrote:


* Support for the rgb-icc() function and for a proprietary cmyk()
  function (for device CMYK colors only through the PDF renderer so
  far).


The table at http://xmlgraphics.apache.org/fop/compliance.html still 
lists rgb-icc as a No. You should update this when you get a minute.




--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: Apache FOP 0.93 Released

[Simon Pepping]

Arnaud,

On Tue, Jan 09, 2007 at 01:31:13AM +0100, Arnaud HERITIER wrote:
> Hi Simon,
> 
>  Can you deploy your jars on a maven repository please.
> For example :
> http://people.apache.org/repo/m1-ibiblio-rsync-repository/fop/jars/

Please ask on [EMAIL PROTECTED] There has been talk
about Maven. I know Jeremias and Vincent have looked at it. The build
script has a target for it. There is a POM file. But none of us have
much experience with it, and we have little time. Therefore your best
chance is a contribution by a user, such as yourself. Perhaps you can
patch the build script to create such a deployment.

Regards, Simon

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

Re: Apache FOP on .NET

[Jeremias Maerki]

On 22.11.2005 15:39:24 Dalibor Topic wrote:
> On Tue, Nov 22, 2005 at 09:12:05AM +0100, Jeremias Maerki wrote:
> > Hi Dalibor
> > 
> > Good thing you're still lurking! :-)
> > 
> 
> Well, FOP is very interesting for me in terms of having a free DocBook
> toolchain on free runtimes that's well maintained. If you are around at
> FOSDEM, it'd be great to have a small talk about FOP, Batik, XML
> graphics and free runtimes, what works, what we still need, which areas
> would need more work, etc.

I currently don't have plans for that. But I'll look into it. In the
meantime, I'm always available here on the mailing list and via Skype.
I've also set up a Wiki page where we can track all the issues involved
here. Help is welcome.

http://wiki.apache.org/xmlgraphics/GnuClasspathCompatibility



> > > Yup. I was under the impression that the XML graphics project would help
> > > work around the most dire problems, though. Right?
> > 
> > As much as we can, anyway. I'm working on that. I don't think I'll be
> > able to help improving IKVM. GNU Classpath might be easier to help with,
> > but then I still don't have a clue how to work with GNU Classpath on
> > Windows (Cygwin only coming with GCC 3.x, not 4.0). I haven't had the
> > time to help myself to a true Unix environment, yet. I've got access to
> > two Unix systems, both of which don't have GCC/GCJ installed and I have
> > limited knowledge on unixish systems to simply know how to install
> > additional software (if I'm allowed at all). And then I hate C/C++ and
> > having to apply patches before I can compile some software. :-) So this
> > means that it takes a lot of nerves to go after this.
> 
> 
> Heh, I know, I know ... I can't build Kaffe on Cygwin without a patched
> up jikes, with Davanum's patches from CVS, etc... I need to pickup my
> conversation with Cygwin packagers to see if we can get Kaffe packaged
> in there. With the recent CVS head it's possible to use Kaffe with GNU
> Classpath like with JamVM, and other runtimes, but it's still some time
> to go until I release 1.1.7.
> 
> I'll play around a bit with gcjx on cygwin, to see if it works better
> than jikes.

Good luck! I'll keep trying myself.





Jeremias Maerki

Re: Apache FOP on .NET

[Dalibor Topic]

On Tue, Nov 22, 2005 at 09:12:05AM +0100, Jeremias Maerki wrote:
> Hi Dalibor
> 
> Good thing you're still lurking! :-)
> 

Well, FOP is very interesting for me in terms of having a free DocBook
toolchain on free runtimes that's well maintained. If you are around at
FOSDEM, it'd be great to have a small talk about FOP, Batik, XML
graphics and free runtimes, what works, what we still need, which areas
would need more work, etc.

> On 21.11.2005 23:48:37 Dalibor Topic wrote:
> > On Mon, Nov 21, 2005 at 10:29:18AM +0100, Jeremias Maerki wrote:
> > > Hi gang,
> > > 
> > > as you know we've have several inquiries in the past about compiling FOP
> > > with GNU Classpath for use in VMs such as Kaffe or natively on Unixes 
> > > (using GCC/GCJ) and about running Apache FOP under .NET. I've done some
> > > experiments last week in this direction and here's what I found out:
> > > 
> > > After removing Batik as a dependency for FOP allows FOP to run and
> > > compile under IKVM [1]. So far, I've managed to run FOP from the
> > > command-line as an EXE file on Windows to create PDF files. No fancy
> > > tests, yet. I'll try to see what needs to be done to call FOP from a C#
> > > application by compiling FOP and its dependency into DLLs.
> > 
> > 
> > Yay! Congrats all over!
> 
> :-)
> 
> > > Batik has the problem that it relies on com.sun.* classes which has been
> > > brought up on batik-dev. (Thomas, just so you know, I'm working on that
> > > one. I'll drop a note on batik-dev about that shortly.) Given this
> > > problem it's currently not possible to compile Batik for use in Kaffe or
> > > IKVM (both use GNU Classpath). Furthermore, it seems that the AWT
> > > implementation of IKVM is unfinished and results in runtime errors
> > > (which have nothing to do with the com.sun.* classes) when forcing IKVM
> > > to run a precompiled Batik JAR.
> > 
> > Yup. I was under the impression that the XML graphics project would help
> > work around the most dire problems, though. Right?
> 
> As much as we can, anyway. I'm working on that. I don't think I'll be
> able to help improving IKVM. GNU Classpath might be easier to help with,
> but then I still don't have a clue how to work with GNU Classpath on
> Windows (Cygwin only coming with GCC 3.x, not 4.0). I haven't had the
> time to help myself to a true Unix environment, yet. I've got access to
> two Unix systems, both of which don't have GCC/GCJ installed and I have
> limited knowledge on unixish systems to simply know how to install
> additional software (if I'm allowed at all). And then I hate C/C++ and
> having to apply patches before I can compile some software. :-) So this
> means that it takes a lot of nerves to go after this.


Heh, I know, I know ... I can't build Kaffe on Cygwin without a patched
up jikes, with Davanum's patches from CVS, etc... I need to pickup my
conversation with Cygwin packagers to see if we can get Kaffe packaged
in there. With the recent CVS head it's possible to use Kaffe with GNU
Classpath like with JamVM, and other runtimes, but it's still some time
to go until I release 1.1.7.

I'll play around a bit with gcjx on cygwin, to see if it works better
than jikes.

> > > Since we've also heard several voices who would like the
> > > Batik-dependency to be optional for FOP (to reduce JAR size), I'd like
> > > to propose making it so by extracting the SVG support from the main
> > > codebase. Some of this will be done anyway, as we're going to move stuff
> > > out to XML Graphics Commons. I'm not sure about the placement of the
> > > sources, yet. There are several possibilities:
> > > (1) Move optional FOP extensions (SVG and MathML) to
> > > src/extensions//java (where  is "svg" or "mathml").
> > > (2) Move optional FOP extensions to src/optional/java along with code
> > > for JAI, JIMI and similar things.
> > 
> > +1
> > 
> > > (3) Move FOP extensions under src/java/org/apache/fop/extensions/
> > > where all the various sources will be concentrated. ATM, the SVG support
> > > classes are scattered over the whole codebase which I don't like so much.
> > > 
> > > I'm open for additional suggestions. Generally, I don't like having all
> > > the code in one tree but in XML Graphics Commons this approach has won,
> > > too.
> > > 
> > > I think having the opportunity to provide a .NET version of FOP would
> > > widen the number of potential users considerably especially since
> > > to my knowledge there's no usable open source .NET FO implementation out
> > > there. Depending on the license situation (IKVM is BSD but GNU Classpath
> > > is LGPL) we could even think about distributing .NET binaries.
> > 
> > GNU Classpath is more liberally licensed than LGPL, actually ;) It's the
> > GPL with a big fat linking exception, that puts no restrictions on the 
> > license
> > of the linking code.
> 
> Oops, sorry, looks like I had the wrong idea in mind. There was so much
> talk within the ASF about LGPL that I assumed Harmony's problem was with
> the 

Re: Apache FOP on .NET

[Dalibor Topic]

On Tue, Nov 22, 2005 at 10:51:40AM +0100, Jeremias Maerki wrote:
> Hi Oleg,
> 
> I see you're still a lurker. :-)
> 
> J#: I don't know. It looks like you need a Visual Studio .NET license
> which I don't have. Was this what nfop was done with? I didn't look.
> C#: I don't have time to help with such an endeavour in the near future.
> That's a huge task. And the Java version takes effort enough at the
> moment.
> 
> I know people who would be very interested to run FOP on .NET but for
> the moment I'm only going to take the "easy road" via IKVM so see where
> I get. But I guess one could think about creating additional source code
> in C# or any other .NET language to provide additional features that
> might be difficult with IKVM. Since IKVM has problems with AWT it might
> make sense to write a renderer in C# to do direct printing, for example.
> But my priorities are with PDF and PS at the moment.

On a side note, an interesting way to get the AWT going on Win32 could
be to use the Qt4 peers in GNU Classpath with a Qt4 build on Win32. You
may want to see if Jeroen or someone on the IKVM list has looked that
way. I've got the Qt4 peers working with Kaffe on Linux and OS X, but
didn't have much time to play with Kaffe on Cygwin recently.

cheers,
dalibor topic

> 
> On 22.11.2005 10:27:09 Oleg Tkachenko wrote:
> > Jeremias Maerki wrote:
> > 
> > > I think having the opportunity to provide a .NET version of FOP would
> > > widen the number of potential users considerably especially since
> > > to my knowledge there's no usable open source .NET FO implementation out
> > > there. Depending on the license situation (IKVM is BSD but GNU Classpath
> > > is LGPL) we could even think about distributing .NET binaries.
> > 
> > I think that's a good move and definitely would be well accepted in the 
> > .NET community. I could help you on that.
> > And besides IKVM what do yo uthink about other options - using J# or 
> > even porting to C#?
> > -- 
> > Oleg
> 
> 
> 
> Jeremias Maerki
> 

Re: Apache FOP on .NET

[Oleg Tkachenko]

Jeremias Maerki wrote:


J#: I don't know. It looks like you need a Visual Studio .NET license
which I don't have. Was this what nfop was done with? I didn't look.


afair J# command line compiler is a part of .NET SDK. I'll check it out 
anyway. The main problem I think is that J# supports only Java 1.1.4 
subset...



C#: I don't have time to help with such an endeavour in the near future.
That's a huge task. And the Java version takes effort enough at the
moment.


Ok, forget it.
--
Oleg

Re: Apache FOP on .NET

[Jeremias Maerki]

Hi Oleg,

I see you're still a lurker. :-)

J#: I don't know. It looks like you need a Visual Studio .NET license
which I don't have. Was this what nfop was done with? I didn't look.
C#: I don't have time to help with such an endeavour in the near future.
That's a huge task. And the Java version takes effort enough at the
moment.

I know people who would be very interested to run FOP on .NET but for
the moment I'm only going to take the "easy road" via IKVM so see where
I get. But I guess one could think about creating additional source code
in C# or any other .NET language to provide additional features that
might be difficult with IKVM. Since IKVM has problems with AWT it might
make sense to write a renderer in C# to do direct printing, for example.
But my priorities are with PDF and PS at the moment.

On 22.11.2005 10:27:09 Oleg Tkachenko wrote:
> Jeremias Maerki wrote:
> 
> > I think having the opportunity to provide a .NET version of FOP would
> > widen the number of potential users considerably especially since
> > to my knowledge there's no usable open source .NET FO implementation out
> > there. Depending on the license situation (IKVM is BSD but GNU Classpath
> > is LGPL) we could even think about distributing .NET binaries.
> 
> I think that's a good move and definitely would be well accepted in the 
> .NET community. I could help you on that.
> And besides IKVM what do yo uthink about other options - using J# or 
> even porting to C#?
> -- 
> Oleg



Jeremias Maerki

Re: Apache FOP on .NET

[Oleg Tkachenko]

Jeremias Maerki wrote:


I think having the opportunity to provide a .NET version of FOP would
widen the number of potential users considerably especially since
to my knowledge there's no usable open source .NET FO implementation out
there. Depending on the license situation (IKVM is BSD but GNU Classpath
is LGPL) we could even think about distributing .NET binaries.


I think that's a good move and definitely would be well accepted in the 
.NET community. I could help you on that.
And besides IKVM what do yo uthink about other options - using J# or 
even porting to C#?

--
Oleg

Re: Apache FOP on .NET

[Jeremias Maerki]

Hi Dalibor

Good thing you're still lurking! :-)

On 21.11.2005 23:48:37 Dalibor Topic wrote:
> On Mon, Nov 21, 2005 at 10:29:18AM +0100, Jeremias Maerki wrote:
> > Hi gang,
> > 
> > as you know we've have several inquiries in the past about compiling FOP
> > with GNU Classpath for use in VMs such as Kaffe or natively on Unixes 
> > (using GCC/GCJ) and about running Apache FOP under .NET. I've done some
> > experiments last week in this direction and here's what I found out:
> > 
> > After removing Batik as a dependency for FOP allows FOP to run and
> > compile under IKVM [1]. So far, I've managed to run FOP from the
> > command-line as an EXE file on Windows to create PDF files. No fancy
> > tests, yet. I'll try to see what needs to be done to call FOP from a C#
> > application by compiling FOP and its dependency into DLLs.
> 
> 
> Yay! Congrats all over!

:-)

> > Batik has the problem that it relies on com.sun.* classes which has been
> > brought up on batik-dev. (Thomas, just so you know, I'm working on that
> > one. I'll drop a note on batik-dev about that shortly.) Given this
> > problem it's currently not possible to compile Batik for use in Kaffe or
> > IKVM (both use GNU Classpath). Furthermore, it seems that the AWT
> > implementation of IKVM is unfinished and results in runtime errors
> > (which have nothing to do with the com.sun.* classes) when forcing IKVM
> > to run a precompiled Batik JAR.
> 
> Yup. I was under the impression that the XML graphics project would help
> work around the most dire problems, though. Right?

As much as we can, anyway. I'm working on that. I don't think I'll be
able to help improving IKVM. GNU Classpath might be easier to help with,
but then I still don't have a clue how to work with GNU Classpath on
Windows (Cygwin only coming with GCC 3.x, not 4.0). I haven't had the
time to help myself to a true Unix environment, yet. I've got access to
two Unix systems, both of which don't have GCC/GCJ installed and I have
limited knowledge on unixish systems to simply know how to install
additional software (if I'm allowed at all). And then I hate C/C++ and
having to apply patches before I can compile some software. :-) So this
means that it takes a lot of nerves to go after this.

> > Since we've also heard several voices who would like the
> > Batik-dependency to be optional for FOP (to reduce JAR size), I'd like
> > to propose making it so by extracting the SVG support from the main
> > codebase. Some of this will be done anyway, as we're going to move stuff
> > out to XML Graphics Commons. I'm not sure about the placement of the
> > sources, yet. There are several possibilities:
> > (1) Move optional FOP extensions (SVG and MathML) to
> > src/extensions//java (where  is "svg" or "mathml").
> > (2) Move optional FOP extensions to src/optional/java along with code
> > for JAI, JIMI and similar things.
> 
> +1
> 
> > (3) Move FOP extensions under src/java/org/apache/fop/extensions/
> > where all the various sources will be concentrated. ATM, the SVG support
> > classes are scattered over the whole codebase which I don't like so much.
> > 
> > I'm open for additional suggestions. Generally, I don't like having all
> > the code in one tree but in XML Graphics Commons this approach has won,
> > too.
> > 
> > I think having the opportunity to provide a .NET version of FOP would
> > widen the number of potential users considerably especially since
> > to my knowledge there's no usable open source .NET FO implementation out
> > there. Depending on the license situation (IKVM is BSD but GNU Classpath
> > is LGPL) we could even think about distributing .NET binaries.
> 
> GNU Classpath is more liberally licensed than LGPL, actually ;) It's the
> GPL with a big fat linking exception, that puts no restrictions on the license
> of the linking code.

Oops, sorry, looks like I had the wrong idea in mind. There was so much
talk within the ASF about LGPL that I assumed Harmony's problem was with
the LGPL.

> cheers,
> dalibr topic
> 
> > WDYT?
> > 
> > [1] http://www.ikvm.net
> > 
> > Jeremias Maerki
> > 



Jeremias Maerki

Re: Apache FOP on .NET

[Dalibor Topic]

On Mon, Nov 21, 2005 at 10:29:18AM +0100, Jeremias Maerki wrote:
> Hi gang,
> 
> as you know we've have several inquiries in the past about compiling FOP
> with GNU Classpath for use in VMs such as Kaffe or natively on Unixes 
> (using GCC/GCJ) and about running Apache FOP under .NET. I've done some
> experiments last week in this direction and here's what I found out:
> 
> After removing Batik as a dependency for FOP allows FOP to run and
> compile under IKVM [1]. So far, I've managed to run FOP from the
> command-line as an EXE file on Windows to create PDF files. No fancy
> tests, yet. I'll try to see what needs to be done to call FOP from a C#
> application by compiling FOP and its dependency into DLLs.


Yay! Congrats all over!

> 
> Batik has the problem that it relies on com.sun.* classes which has been
> brought up on batik-dev. (Thomas, just so you know, I'm working on that
> one. I'll drop a note on batik-dev about that shortly.) Given this
> problem it's currently not possible to compile Batik for use in Kaffe or
> IKVM (both use GNU Classpath). Furthermore, it seems that the AWT
> implementation of IKVM is unfinished and results in runtime errors
> (which have nothing to do with the com.sun.* classes) when forcing IKVM
> to run a precompiled Batik JAR.

Yup. I was under the impression that the XML graphics project would help
work around the most dire problems, though. Right?

> Since we've also heard several voices who would like the
> Batik-dependency to be optional for FOP (to reduce JAR size), I'd like
> to propose making it so by extracting the SVG support from the main
> codebase. Some of this will be done anyway, as we're going to move stuff
> out to XML Graphics Commons. I'm not sure about the placement of the
> sources, yet. There are several possibilities:
> (1) Move optional FOP extensions (SVG and MathML) to
> src/extensions//java (where  is "svg" or "mathml").
> (2) Move optional FOP extensions to src/optional/java along with code
> for JAI, JIMI and similar things.

+1

> (3) Move FOP extensions under src/java/org/apache/fop/extensions/
> where all the various sources will be concentrated. ATM, the SVG support
> classes are scattered over the whole codebase which I don't like so much.
> 
> I'm open for additional suggestions. Generally, I don't like having all
> the code in one tree but in XML Graphics Commons this approach has won,
> too.
> 
> I think having the opportunity to provide a .NET version of FOP would
> widen the number of potential users considerably especially since
> to my knowledge there's no usable open source .NET FO implementation out
> there. Depending on the license situation (IKVM is BSD but GNU Classpath
> is LGPL) we could even think about distributing .NET binaries.

GNU Classpath is more liberally licensed than LGPL, actually ;) It's the
GPL with a big fat linking exception, that puts no restrictions on the license
of the linking code.

cheers,
dalibr topic

> WDYT?
> 
> [1] http://www.ikvm.net
> 
> Jeremias Maerki
> 

Re: Apache FOP

[Jeremias Maerki]

We appreciate your efforts! Thank you, Clay!

On 23.06.2005 16:41:44 The Web Maestro wrote:
> On Jun 23, 2005, at 12:10 AM, Christian Geisert wrote:
> > Just copy the files to /www/www.apache.org/dist/xml/fop/
> > (we should probably put them under SVN somewhere)
> >
> > Sorry no more time, going to for LinuxTag now ..
> >
> > Christian
> 
> heh... have fun?
> 
> I've uploaded the file. I don't see it anywhere yet, but I assume it'll 
> propagate in a few hours... I'll keep checking. Someone (probably me 
> ;-)) needs to add that to the DocMgt page...
> 
> Regards,
> 
> Web Maestro Clay
> -- 
> <[EMAIL PROTECTED]> - 
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet



Jeremias Maerki

Re: Apache FOP

[The Web Maestro]

On Jun 23, 2005, at 12:10 AM, Christian Geisert wrote:

Just copy the files to /www/www.apache.org/dist/xml/fop/
(we should probably put them under SVN somewhere)

Sorry no more time, going to for LinuxTag now ..

Christian


heh... have fun?

I've uploaded the file. I don't see it anywhere yet, but I assume it'll 
propagate in a few hours... I'll keep checking. Someone (probably me 
;-)) needs to add that to the DocMgt page...


Regards,

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