bugzilla | 1 Dec 2002 13:02
Picon
Favicon

DO NOT REPLY [Bug 7449] - Large table row with keep-together=always runs FOP infinitely

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7449>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7449

Large table row with keep-together=always runs FOP infinitely

klease <at> club-internet.fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
bugzilla | 1 Dec 2002 13:33
Picon
Favicon

DO NOT REPLY [Bug 14979] New: - Make links availble for examples on website

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14979>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14979

Make links availble for examples on website

           Summary: Make links availble for examples on website
           Product: Fop
           Version: 0.20.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: documentation
        AssignedTo: fop-dev <at> xml.apache.org
        ReportedBy: alex_blewitt <at> yahoo.com

The examples on the website list what examples are packaged with the FOP distro,
but it would be useful if someone could click on the links to see what the FO 
actually looked like (especially in the case of simple.fo) so that they can
immediately see the source. It would also be beneficial, therefore, to show
the pre-generated outputs (PDF, image) from the source as well so that users
could get an idea of what fop is capable of prior to downloading it.
bugzilla | 1 Dec 2002 16:50
Picon
Favicon

DO NOT REPLY [Bug 14478] - Hyphenation for the first time works not correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14478>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14478

Hyphenation for the first time works not correctly

j3322ptm <at> yahoo.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From j3322ptm <at> yahoo.de  2002-12-01 15:50 -------
Fixed in CVS maintenance branch
bugzilla | 1 Dec 2002 17:43
Picon
Favicon

DO NOT REPLY [Bug 14963] - Fix for #8878 causes problems

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14963>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14963

Fix for #8878 causes problems

------- Additional Comments From klease <at> club-internet.fr  2002-12-01 16:43 -------
I also noticed this. I think it is happens because the blocks in the static
flows are composed on each page. Could perhaps also happen if you have a very
long table with headers or footers. I committed a change which makes this
problem go away, but I suspect that the looping behavior will now not be
detected either in all cases. It does still fix the bug #8878 however.

Please retest your document with latest CVS and close this bug if it is now
fixed. Thanks!
J.Pietschmann | 1 Dec 2002 19:33
Picon
Favicon

Re: Extension to write continued label in table headers

Karen Lease wrote:
> A while back, if I remember correctly, someone was looking for and 
> perhaps going to write an extension to write continued labels in table 
> headers. Ie, when the table continues, to add text like "(continued)" or 
> whatever in the header (and/or footer).
> 
> Apparently this never made it into the common pool, but I have recently 
> cooked up something fairly simple (and limited) to handle this. Is there 
> interest in putting it in for the next maintenance release ? It has very 
> minor impact on the table layout code and probably would be useful to a 
> number of people.

Well, the functionality can be nearly emulated with standard
XSLFO, even though it is somewhat messy, and perhaps some unwanted
space appears. Therefore it can be discussed whether this should
go into the FOP code pool.

A more generalized functionality would be FO which are conditionally
rendered before/after page breaks in the FO which they are attached
to:
   <fo:block>
     <fox:before-page-break>
        <fo:block>Continued on next page<fo:block>
     </fox:before-page-break>
     <fox:after-page-break>
        <fo:block>Continued from previouss page<fo:block>
     </fox:after-page-break>
     bla bla bla...

Because there is now an EXSLFO initiative, I think we should supply
(Continue reading)

J.Pietschmann | 1 Dec 2002 19:34
Picon
Favicon

Re: [VOTE] Victor as committer

Keiron Liddle wrote:
> I propose we have a vote for Victor to become a committer.

+1

J.Pietschmann
J.Pietschmann | 1 Dec 2002 20:11
Picon
Favicon

Re: Opinion poll: Additional utility jars

Jeremias Maerki wrote:
> I'm stumbling over code blocks every now and then that could/should be
> reused or even used from a common library.

Extensions to the original proposal:
- Modularize FOP a bit better: build separate jars for the core, CLI,
   AWTViewer and the servlet (and move the servlet from contrib to the
   main src tree)
- Check what can be shared with Batik. Some parts of font handling comes
   to mind. BIDI handling too. Unify approaches in the API perhaps.

> 2. Provide the same fop.jar as before but we'll have some more jars in
> out lib directory over time. This obviously means that the classpath
> will get some longer.
> 
> IMO both has to be done, especially to service those who don't like a
> lot of jars in their classpath.

Batik has a batik-all.jar and a huge bunch of smaller jars for people
who want only a part of the functionality.

While I like the idea of factoring out utilities and commonly used
funktionality to projects like xml-commons, this increases the potential
for version clashes. An example is the trouble in Cocoon because the
Batik version needed by FOP was not the same as the one used by the
Cocoon serializers. Auxilary libraries need a very stable API and a
very careful design. If this is met, I'm +1, otherwise -0.

J.Pietschmann
(Continue reading)

J.Pietschmann | 1 Dec 2002 20:23
Picon
Favicon

Re: Style guide (2nd update)

Rhett Aultman wrote:
 > It's my understanding that, for certain object types, the compiler can use
 > "final" designation as a flag for further optimizations and so it actually
 > might be a wise idea to do.  If nothing else, I remember reading an interview
 > with James Gosling on "object mutability", a compiler optimization whereby a
 > final object can be decomposed into certain constituents (since it will never
 > be altered).
 >
 > Personally, I just don't use final designations in the way it's shown because
 > it doesn't occur to me that it's important. ;)

Cocoon is full of "final", basically the same as the C++ use of "const", partly
because it allows *all* compilers to do important optimisations, and partly
because this let the compiler detect quite a few thinkos and some design flaws.
For example, declaring method parameters as final disallows assignments to them,
which may force the use of more localized variables, thereby often enhancing
maintainability, helping dumb compilers to compile better code and decreasing
the compile time for the cleveer compilers which can do proper flow analysis
by itself. Another aspect is that it helps in detecting traps like if the
parameter is named the same as an instance variable and someone thought he's
assigning the instance variable instead of the parameter.

There is a lot of literature about when and why using C++ const is an advantage
and when not, a large part of this is probably applicable to Java final. I think
we should leverage "final" more often in FOP.

J.Pietschmann
J.Pietschmann | 1 Dec 2002 20:30
Picon
Favicon

Re: [maintenance branch] FOP servlet doubled

Oleg Tkachenko wrote:
> Hmmm, looks like Joerg sees it differently - 
> http://marc.theaimsgroup.com/?l=fop-dev&m=103196215022751&w=2

This was a statement of the status quo, which I don't
like particularly well.
I think the servlet should be moved to src/org/apache/fop/servlet
and get a target in the main build.xml file.

BTW what about splitting the apps directory into an api and
a cli directory, perhaps with new API implementations? In
the latter case, the apps directory can be kept for compatibility
for a while.

J.Pietschmann
J.Pietschmann | 1 Dec 2002 20:32
Picon
Favicon

Re: DO NOT REPLY [Bug 11902] - fopDriver.getResults().getPageCount() returns wrong page count

bugzilla <at> apache.org wrote:
> fopDriver.getResults().getPageCount() returns wrong page count
> ------- Additional Comments From oleg <at> tkachenko.com  2002-11-21 20:27 -------
> Fixed already in cvs.

Oleg, have you tested this with multiple page sequences? Forced
page counts? I have some doubts I got everything correct there.

J.Pietschmann

Gmane