bugzilla | 1 Sep 08:08 2008
Picon

Bug report for Fop [2008/08/31]

+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
|     |   |           MIN=Minor   NOR=Normal    ENH=Enhancement TRV=Trivial |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
| 1063|New|Nor|2001-03-21|fop does not handle large fo files                |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work                         |
| 3824|New|Blk|2001-09-25|MIF option with tables                            |
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG               |
| 5010|New|Enh|2001-11-21|Better error reporting needed                     |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem            |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images      |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
| 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes |
| 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code         |
|10379|New|Enh|2002-07-01|Improvement to FOP Classloader                    |
|12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses|
(Continue reading)

bugzilla | 1 Sep 10:10 2008
Picon

DO NOT REPLY [Bug 45702] Forced break-after and/or space-after causes unresolved page-number-citations

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

--- Comment #10 from Patrice ROSNET <patrice.rosnet <at> free.fr>  2008-09-01 01:10:36 PST ---
(In reply to comment #3)
> Even stranger, in my local sandbox, there is one set of IDs correctly resolved:
> those of the page-sequences. All the others still remain unresolved. If that
> doesn't happen in your case, I guess I'll also have to look to add that change
> for page-sequences to FOP Trunk.
> 

No problem with ID of page-sequences, IDs are correctly resolved

--

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Philip V | 1 Sep 23:10 2008
Picon
Picon

[trunk] - Build Fail


Hi, I just updated my version of trunk and was unable to do a build...

BUILD FAILED
java.lang.UnsupportedOperationException: Saxon cannot write a DOMResult
unless s
axon9-dom.jar is on the classpath
        at
net.sf.saxon.event.SerializerFactory.getReceiver(SerializerFactory.ja
va:200)
        at
net.sf.saxon.expr.XPathContextMinor.changeOutputDestination(XPathCont
extMinor.java:402)
        at net.sf.saxon.Controller.transformDocument(Controller.java:1720)
        at net.sf.saxon.Controller.transform(Controller.java:1559)
        at
org.apache.fop.tools.EventProducerCollectorTask.updateTranslationFile
(EventProducerCollectorTask.java:113)
        at
org.apache.fop.tools.EventProducerCollectorTask.execute(EventProducer
CollectorTask.java:79)
        at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
(Continue reading)

Andreas Delmelle | 1 Sep 23:20 2008
Picon

Re: I need fo:retrieve-table-marker example or how to implement continued label in FOP-95?

On Sep 1, 2008, at 23:02, Andreas Delmelle wrote:

(Moving this to fop-dev <at> )

> On Sep 1, 2008, at 22:42, Jean-François El Fouly wrote:
>> Hhmm... I've been quickly through the code and my first impression  
>> is that it IS implemented.
>
> Not really, I'm afraid. I have prepared the implementation a while  
> ago. That much is true. FOP simply does nothing with a retrieve- 
> table-marker node, but the node is created and the properties  
> parsed. Only in layoutmgr.LayoutManagerMapping, you will notice  
> that the RetrieveTableMarker generates no LayoutManager yet.
>
>> I've set up a simple test case and, going through the stack trace,  
>> I guess it could be a simple bug fix, something like a bad or  
>> insufficient test in TablePart.java
>
> Oh, rest assured, it's going to take a bit more thought and  
> effort... ;-)

To spare some time looking, I see one issue that may turn out to be  
quite a challenge.
One significant benefit is that it operates on the same fo:markers,  
so little work there, and it may even give you some ideas on how to  
solve it for the table-case, however...

If you follow what happens during regular marker-retrieval, you'll  
notice that the resolution depends on the markers having been added  
to the page-viewport.
(Continue reading)

Andreas Delmelle | 1 Sep 23:28 2008
Picon

Re: [trunk] - Build Fail

On Sep 1, 2008, at 23:10, Philip V wrote:

>
> Hi, I just updated my version of trunk and was unable to do a build...
>
> BUILD FAILED
> java.lang.UnsupportedOperationException: Saxon cannot write a  
> DOMResult
> unless saxon9-dom.jar is on the classpath

This is due to the new event-handling framework that has been added  
after 0.95.
The step in the build process that generates the resource files for  
the various messages, seems to require a writable DOM implementation.

As the message indicates, Saxon offers such an implementation in a  
separate JAR, which needs to be added to the classpath when building  
FOP Trunk.

Andreas

Philip V | 1 Sep 23:59 2008
Picon
Picon

Re: [trunk] - Build Fail


Thank Andreas,

Wasn't sure if the class was supposed to be referenced in the ant build
file. I am all set now.

Thanks,

Phil

Andreas Delmelle-2 wrote:
> 
> On Sep 1, 2008, at 23:10, Philip V wrote:
> 
>>
>> Hi, I just updated my version of trunk and was unable to do a build...
>>
>> BUILD FAILED
>> java.lang.UnsupportedOperationException: Saxon cannot write a  
>> DOMResult
>> unless saxon9-dom.jar is on the classpath
> 
> This is due to the new event-handling framework that has been added  
> after 0.95.
> The step in the build process that generates the resource files for  
> the various messages, seems to require a writable DOM implementation.
> 
> As the message indicates, Saxon offers such an implementation in a  
> separate JAR, which needs to be added to the classpath when building  
> FOP Trunk.
(Continue reading)

Jeremias Maerki | 2 Sep 09:37 2008
Picon

Re: I need fo:retrieve-table-marker example or how to implement continued label in FOP-95?

On 01.09.2008 23:20:29 Andreas Delmelle wrote:
> On Sep 1, 2008, at 23:02, Andreas Delmelle wrote:
> 
> (Moving this to fop-dev <at> )
> 
> > On Sep 1, 2008, at 22:42, Jean-François El Fouly wrote:
> >> Hhmm... I've been quickly through the code and my first impression  
> >> is that it IS implemented.
> >
> > Not really, I'm afraid. I have prepared the implementation a while  
> > ago. That much is true. FOP simply does nothing with a retrieve- 
> > table-marker node, but the node is created and the properties  
> > parsed. Only in layoutmgr.LayoutManagerMapping, you will notice  
> > that the RetrieveTableMarker generates no LayoutManager yet.
> >
> >> I've set up a simple test case and, going through the stack trace,  
> >> I guess it could be a simple bug fix, something like a bad or  
> >> insufficient test in TablePart.java
> >
> > Oh, rest assured, it's going to take a bit more thought and  
> > effort... ;-)
> 
> To spare some time looking, I see one issue that may turn out to be  
> quite a challenge.
> One significant benefit is that it operates on the same fo:markers,  
> so little work there, and it may even give you some ideas on how to  
> solve it for the table-case, however...
> 
> If you follow what happens during regular marker-retrieval, you'll  
> notice that the resolution depends on the markers having been added  
(Continue reading)

Jean-François El Fouly | 2 Sep 11:21 2008
Picon

A (long) question on implementing fo:retrieve-table-marker

I take as reference: http://www.w3.org/TR/xsl/

To begin with, I've built a simple example / test case related to my 
customer's needs but fairly based on the one in 6.13.1.1.2: 
http://www.w3.org/TR/xsl/#d0e14681
This example looks good and though not trivial to understand at first 
sight, it is a common-sense use of fo:retrieve-table-marker.
It has a sort of "conditional row" that is displayed (or not) in the 
table footer and is defined just after table-body:

*        <fo:marker marker-class-name="continued">
          <fo:table-row>
            <fo:table-cell>
              <fo:block>Table continued...</fo:block>
            </fo:table-cell>
          </fo:table-row>
        </fo:marker>
*

Now if I run my test case against the trunk of FOP I get this error message:

*GRAVE: Exception
javax.xml.transform.TransformerException: 
org.apache.fop.fo.ValidationException:
 file:/D:/Java/fop-0.95beta/test-rtm.fo:533:112: Error(533/112): 
fo:retrieve-tab
le-marker is not a valid child element of fo:table-header.
*
For the sake of clarity only let's call this a "bug" since 
*fo-retrieve-table-marker* /is/ a valid child element of 
(Continue reading)

Vincent Hennebert | 2 Sep 11:55 2008
Picon

Re: I need fo:retrieve-table-marker example or how to implement continued label in FOP-95?

For the sake of completeness, see this message and the following ones in
the same thread:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200805.mbox/<483197F2.2050204 <at> anyware-tech.com>

Some non-trivial changes are indeed necessary in the table layout
code... and might be further invalidated by the new page layout
approach.

Vincent

Jeremias Maerki wrote:
> On 01.09.2008 23:20:29 Andreas Delmelle wrote:
>> On Sep 1, 2008, at 23:02, Andreas Delmelle wrote:
>>
>> (Moving this to fop-dev <at> )
>>
>>> On Sep 1, 2008, at 22:42, Jean-François El Fouly wrote:
>>>> Hhmm... I've been quickly through the code and my first impression  
>>>> is that it IS implemented.
>>> Not really, I'm afraid. I have prepared the implementation a while  
>>> ago. That much is true. FOP simply does nothing with a retrieve- 
>>> table-marker node, but the node is created and the properties  
>>> parsed. Only in layoutmgr.LayoutManagerMapping, you will notice  
>>> that the RetrieveTableMarker generates no LayoutManager yet.
>>>
>>>> I've set up a simple test case and, going through the stack trace,  
>>>> I guess it could be a simple bug fix, something like a bad or  
>>>> insufficient test in TablePart.java
>>> Oh, rest assured, it's going to take a bit more thought and  
>>> effort... ;-)
(Continue reading)

Vincent Hennebert | 2 Sep 12:21 2008
Picon

Re: A (long) question on implementing fo:retrieve-table-marker

Hi Jean-François,

Jean-François El Fouly wrote:
> I take as reference: http://www.w3.org/TR/xsl/

<snip/>

> *GRAVE: Exception
> javax.xml.transform.TransformerException:
> org.apache.fop.fo.ValidationException:
> file:/D:/Java/fop-0.95beta/test-rtm.fo:533:112: Error(533/112):
> fo:retrieve-tab
> le-marker is not a valid child element of fo:table-header.
> *
> For the sake of clarity only let's call this a "bug" since
> *fo-retrieve-table-marker* /is/ a valid child element of
> *fo:table-header:* http://www.w3.org/TR/xsl/#fo_retrieve-table-marker

That’s right.

> So let's read the full stack trace and "fix" this by adding one more
> condition in *org.apache.fop.fo.flow.table.TablePart.validateChildNode()*.
> The next step is where I'm puzzled and don't know how to proceed since
> the W3C recommendation and the example they give seem inconsistent with
> each other, while the error message FOP returns seems consistent with
> the recommendation:
> 
> *GRAVE: Exception
> javax.xml.transform.TransformerException:
> org.apache.fop.fo.ValidationException:
(Continue reading)


Gmane