Re: tablePositions empty assertion error in version 1.0

2012-03-14 Thread Glenn Adams
A little experimentation quickly shows:

(1) removing all but one row doesn't change behavior; however
(2) removing the fo:inline parent that contains the table (and moving the
font size property to the parent fo:block) fixes the problem

Did you really intend to nest the table in an inline?

G.

On Wed, Mar 14, 2012 at 11:17 AM, Thomas Morrison <
thomas.morri...@microfocus.com> wrote:

> The attached fo document causes the tablePositions assertion, requesting
> that the fo be sent.
>
> The full output of the rendering is:
>
> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
> processEvent
> WARNING: Font "Symbol,normal,700" not found. Substituting with
> "Symbol,normal,400".
> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
> processEvent
> WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
> "ZapfDingbats,normal,400".
> Mar 14, 2012 11:40:07 AM
> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
> SEVERE: tablePositions empty. Please send your FO file to
> fop-users@xmlgraphics.apache.org
>
> The table-header is rendered at the end of the table.
>
> ---
>
> The PDF is renedered the same on 0.95, although the output is different,
> not mentioning the two WARNINGs:
> Mar 14, 2012 11:51:29 AM
> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
> SEVERE: tablePositions empty. Please send your FO file to
> fop-users@xmlgraphics.apache.org
>
> ---
>
> The table-header is rendered correctly in 0.20.5 with the following
> output:
> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
> [INFO] FOP 0.20.5
> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
> [INFO] building formatting object tree
> [INFO] setting up fonts
> [INFO] [1]
> [WARNING] Sum of fixed column widths 50 greater than maximum
> specified IPD 0
> [INFO] [2]
> [INFO] Parsing of document complete, stopping renderer
>
> I have searched for a possible cause, and would like a workaround if not
> a fix.  I have so far been unable to determine what aspect of the table
> header may be triggering this behavior.
>
> Tom Morrison
> This message has been scanned by MailController -
> portal1.mailcontroller.co.uk
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>


RE: tablePositions empty assertion error in version 1.0

2012-03-14 Thread Thomas Morrison
Thanks, Glenn, for the quick response.  I have been experimenting too, but am 
nowhere near an expert on FO.  (I have a customer wanting to use XML 
publishing.)

 

The document was created using Stylus Studio using the WYSIWYG editor.  I will 
retrace my steps to see where I created the fo:inline (which does seem rather 
useless).

 

It is interesting to note, though, that 0.20.5 and RenderX (as delivered in 
Stylus Studio) both render this in the ‘expected’ manner.

 

I will test your work around and get the information to the customer.  Maybe we 
will just have to add ‘remove fo:inline’ as part of the recipe.

 

Tom

 

From: Glenn Adams [mailto:gl...@skynav.com] 
Sent: Wednesday, March 14, 2012 2:12 PM
To: fop-users@xmlgraphics.apache.org
Cc: Thomas Morrison
Subject: Re: tablePositions empty assertion error in version 1.0

 

A little experimentation quickly shows:

 

(1) removing all but one row doesn't change behavior; however

(2) removing the fo:inline parent that contains the table (and moving the font 
size property to the parent fo:block) fixes the problem

 

Did you really intend to nest the table in an inline?

 

G.

 

On Wed, Mar 14, 2012 at 11:17 AM, Thomas Morrison 
 wrote:

The attached fo document causes the tablePositions assertion, requesting
that the fo be sent.

The full output of the rendering is:

Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
processEvent
WARNING: Font "Symbol,normal,700" not found. Substituting with
"Symbol,normal,400".
Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
processEvent
WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
"ZapfDingbats,normal,400".
Mar 14, 2012 11:40:07 AM
org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
SEVERE: tablePositions empty. Please send your FO file to
fop-users@xmlgraphics.apache.org

The table-header is rendered at the end of the table.

---

The PDF is renedered the same on 0.95, although the output is different,
not mentioning the two WARNINGs:
Mar 14, 2012 11:51:29 AM
org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
SEVERE: tablePositions empty. Please send your FO file to
fop-users@xmlgraphics.apache.org

---

The table-header is rendered correctly in 0.20.5 with the following
output:
[INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
[INFO] FOP 0.20.5
[INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
[INFO] building formatting object tree
[INFO] setting up fonts
[INFO] [1]
[WARNING] Sum of fixed column widths 50 greater than maximum
specified IPD 0
[INFO] [2]
[INFO] Parsing of document complete, stopping renderer

I have searched for a possible cause, and would like a workaround if not
a fix.  I have so far been unable to determine what aspect of the table
header may be triggering this behavior.

Tom Morrison
This message has been scanned by MailController - portal1.mailcontroller.co.uk

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

 

This message has been scanned by MailController 
<http://portal1.mailcontroller.co.uk/> .

 



Re: tablePositions empty assertion error in version 1.0

2012-03-14 Thread Glenn Adams
I believe it is a bug, and am getting ready to create one (if not already
there). However, in the mean time, you may be able to work around it by
eliminating the inline.

In the future, it is best to trim down the test file to the minimum
necessary to demonstrate the error. I have done this in the attached.

On Wed, Mar 14, 2012 at 1:20 PM, Thomas Morrison <
thomas.morri...@microfocus.com> wrote:

> Thanks, Glenn, for the quick response.  I have been experimenting too, but
> am nowhere near an expert on FO.  (I have a customer wanting to use XML
> publishing.)
>
> ** **
>
> The document was created using Stylus Studio using the WYSIWYG editor.  I
> will retrace my steps to see where I created the fo:inline (which does seem
> rather useless).
>
> ** **
>
> It is interesting to note, though, that 0.20.5 and RenderX (as delivered
> in Stylus Studio) both render this in the ‘expected’ manner.
>
> ** **
>
> I will test your work around and get the information to the customer.
> Maybe we will just have to add ‘remove fo:inline’ as part of the recipe.**
> **
>
> ** **
>
> Tom
>
> ** **
>
> *From:* Glenn Adams [mailto:gl...@skynav.com]
> *Sent:* Wednesday, March 14, 2012 2:12 PM
> *To:* fop-users@xmlgraphics.apache.org
> *Cc:* Thomas Morrison
> *Subject:* Re: tablePositions empty assertion error in version 1.0
>
> ** **
>
> A little experimentation quickly shows:
>
> ** **
>
> (1) removing all but one row doesn't change behavior; however
>
> (2) removing the fo:inline parent that contains the table (and moving the
> font size property to the parent fo:block) fixes the problem
>
> ** **
>
> Did you really intend to nest the table in an inline?
>
> ** **
>
> G.
>
> ** **
>
> On Wed, Mar 14, 2012 at 11:17 AM, Thomas Morrison <
> thomas.morri...@microfocus.com> wrote:
>
> The attached fo document causes the tablePositions assertion, requesting
> that the fo be sent.
>
> The full output of the rendering is:
>
> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
> processEvent
> WARNING: Font "Symbol,normal,700" not found. Substituting with
> "Symbol,normal,400".
> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
> processEvent
> WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
> "ZapfDingbats,normal,400".
> Mar 14, 2012 11:40:07 AM
> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
> SEVERE: tablePositions empty. Please send your FO file to
> fop-users@xmlgraphics.apache.org
>
> The table-header is rendered at the end of the table.
>
> ---
>
> The PDF is renedered the same on 0.95, although the output is different,
> not mentioning the two WARNINGs:
> Mar 14, 2012 11:51:29 AM
> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
> SEVERE: tablePositions empty. Please send your FO file to
> fop-users@xmlgraphics.apache.org
>
> ---
>
> The table-header is rendered correctly in 0.20.5 with the following
> output:
> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
> [INFO] FOP 0.20.5
> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
> [INFO] building formatting object tree
> [INFO] setting up fonts
> [INFO] [1]
> [WARNING] Sum of fixed column widths 50 greater than maximum
> specified IPD 0
> [INFO] [2]
> [INFO] Parsing of document complete, stopping renderer
>
> I have searched for a possible cause, and would like a workaround if not
> a fix.  I have so far been unable to determine what aspect of the table
> header may be triggering this behavior.
>
> Tom Morrison
> This message has been scanned by MailController -
> portal1.mailcontroller.co.uk
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
> ** **
>
> This message has been scanned by 
> MailController<http://portal1.mailcontroller.co.uk/>
> .
>
>  
>

http://www.w3.org/1999/XSL/Format";>














H






C










-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: tablePositions empty assertion error in version 1.0

2012-03-14 Thread Glenn Adams
It looks like this bug was already reported at

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

I added the trimmed down version of your FO file to this bug report as an
attachment.

2012/3/14 Glenn Adams 

> I believe it is a bug, and am getting ready to create one (if not already
> there). However, in the mean time, you may be able to work around it by
> eliminating the inline.
>
> In the future, it is best to trim down the test file to the minimum
> necessary to demonstrate the error. I have done this in the attached.
>
>
> On Wed, Mar 14, 2012 at 1:20 PM, Thomas Morrison <
> thomas.morri...@microfocus.com> wrote:
>
>> Thanks, Glenn, for the quick response.  I have been experimenting too,
>> but am nowhere near an expert on FO.  (I have a customer wanting to use XML
>> publishing.)
>>
>> ** **
>>
>> The document was created using Stylus Studio using the WYSIWYG editor.  I
>> will retrace my steps to see where I created the fo:inline (which does seem
>> rather useless).
>>
>> ** **
>>
>> It is interesting to note, though, that 0.20.5 and RenderX (as delivered
>> in Stylus Studio) both render this in the ‘expected’ manner.
>>
>> ** **
>>
>> I will test your work around and get the information to the customer.
>> Maybe we will just have to add ‘remove fo:inline’ as part of the recipe.*
>> ***
>>
>> ** **
>>
>> Tom
>>
>> ** **
>>
>> *From:* Glenn Adams [mailto:gl...@skynav.com]
>> *Sent:* Wednesday, March 14, 2012 2:12 PM
>> *To:* fop-users@xmlgraphics.apache.org
>> *Cc:* Thomas Morrison
>> *Subject:* Re: tablePositions empty assertion error in version 1.0
>>
>> ** **
>>
>> A little experimentation quickly shows:
>>
>> ** **
>>
>> (1) removing all but one row doesn't change behavior; however
>>
>> (2) removing the fo:inline parent that contains the table (and moving the
>> font size property to the parent fo:block) fixes the problem
>>
>> ** **
>>
>> Did you really intend to nest the table in an inline?
>>
>> ** **
>>
>> G.
>>
>> ** **
>>
>> On Wed, Mar 14, 2012 at 11:17 AM, Thomas Morrison <
>> thomas.morri...@microfocus.com> wrote:
>>
>> The attached fo document causes the tablePositions assertion, requesting
>> that the fo be sent.
>>
>> The full output of the rendering is:
>>
>> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
>> processEvent
>> WARNING: Font "Symbol,normal,700" not found. Substituting with
>> "Symbol,normal,400".
>> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
>> processEvent
>> WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
>> "ZapfDingbats,normal,400".
>> Mar 14, 2012 11:40:07 AM
>> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
>> SEVERE: tablePositions empty. Please send your FO file to
>> fop-users@xmlgraphics.apache.org
>>
>> The table-header is rendered at the end of the table.
>>
>> ---
>>
>> The PDF is renedered the same on 0.95, although the output is different,
>> not mentioning the two WARNINGs:
>> Mar 14, 2012 11:51:29 AM
>> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
>> SEVERE: tablePositions empty. Please send your FO file to
>> fop-users@xmlgraphics.apache.org
>>
>> ---
>>
>> The table-header is rendered correctly in 0.20.5 with the following
>> output:
>> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
>> [INFO] FOP 0.20.5
>> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
>> [INFO] building formatting object tree
>> [INFO] setting up fonts
>> [INFO] [1]
>> [WARNING] Sum of fixed column widths 50 greater than maximum
>> specified IPD 0
>> [INFO] [2]
>> [INFO] Parsing of document complete, stopping renderer
>>
>> I have searched for a possible cause, and would like a workaround if not
>> a fix.  I have so far been unable to determine what aspect of the table
>> header may be triggering this behavior.
>>
>> Tom Morrison
>> This message has been scanned by MailController -
>> portal1.mailcontroller.co.uk
>>
>> -
>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org***
>> *
>>
>> ** **
>>
>> This message has been scanned by 
>> MailController<http://portal1.mailcontroller.co.uk/>
>> .
>>
>>  
>>
>
>


Re: tablePositions empty assertion error in version 1.0

2012-03-14 Thread Glenn Adams
I also notice the following listed at [1]:

*inline_block_nested_3.xml* (NPE for table inside an inline):
Placing a table as a child of an fo:inline produces a NullPointerException.

[1] http://xmlgraphics.apache.org/fop/1.0/knownissues_overview.html


On Wed, Mar 14, 2012 at 1:45 PM, Glenn Adams  wrote:

> It looks like this bug was already reported at
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47192
>
> I added the trimmed down version of your FO file to this bug report as an
> attachment.
>
>
> 2012/3/14 Glenn Adams 
>
>> I believe it is a bug, and am getting ready to create one (if not already
>> there). However, in the mean time, you may be able to work around it by
>> eliminating the inline.
>>
>> In the future, it is best to trim down the test file to the minimum
>> necessary to demonstrate the error. I have done this in the attached.
>>
>>
>> On Wed, Mar 14, 2012 at 1:20 PM, Thomas Morrison <
>> thomas.morri...@microfocus.com> wrote:
>>
>>> Thanks, Glenn, for the quick response.  I have been experimenting too,
>>> but am nowhere near an expert on FO.  (I have a customer wanting to use XML
>>> publishing.)
>>>
>>> ** **
>>>
>>> The document was created using Stylus Studio using the WYSIWYG editor.
>>> I will retrace my steps to see where I created the fo:inline (which does
>>> seem rather useless).
>>>
>>> ** **
>>>
>>> It is interesting to note, though, that 0.20.5 and RenderX (as delivered
>>> in Stylus Studio) both render this in the ‘expected’ manner.
>>>
>>> ** **
>>>
>>> I will test your work around and get the information to the customer.
>>> Maybe we will just have to add ‘remove fo:inline’ as part of the recipe.
>>> ****
>>>
>>> ** **
>>>
>>> Tom
>>>
>>> ** **
>>>
>>> *From:* Glenn Adams [mailto:gl...@skynav.com]
>>> *Sent:* Wednesday, March 14, 2012 2:12 PM
>>> *To:* fop-users@xmlgraphics.apache.org
>>> *Cc:* Thomas Morrison
>>> *Subject:* Re: tablePositions empty assertion error in version 1.0
>>>
>>> ** **
>>>
>>> A little experimentation quickly shows:
>>>
>>> ** **
>>>
>>> (1) removing all but one row doesn't change behavior; however
>>>
>>> (2) removing the fo:inline parent that contains the table (and moving
>>> the font size property to the parent fo:block) fixes the problem
>>>
>>> ** **
>>>
>>> Did you really intend to nest the table in an inline?
>>>
>>> ** **
>>>
>>> G.
>>>
>>> ** **
>>>
>>> On Wed, Mar 14, 2012 at 11:17 AM, Thomas Morrison <
>>> thomas.morri...@microfocus.com> wrote:
>>>
>>> The attached fo document causes the tablePositions assertion, requesting
>>> that the fo be sent.
>>>
>>> The full output of the rendering is:
>>>
>>> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
>>> processEvent
>>> WARNING: Font "Symbol,normal,700" not found. Substituting with
>>> "Symbol,normal,400".
>>> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener
>>> processEvent
>>> WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
>>> "ZapfDingbats,normal,400".
>>> Mar 14, 2012 11:40:07 AM
>>> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
>>> SEVERE: tablePositions empty. Please send your FO file to
>>> fop-users@xmlgraphics.apache.org
>>>
>>> The table-header is rendered at the end of the table.
>>>
>>> ---
>>>
>>> The PDF is renedered the same on 0.95, although the output is different,
>>> not mentioning the two WARNINGs:
>>> Mar 14, 2012 11:51:29 AM
>>> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas
>>> SEVERE: tablePositions empty. Please send your FO file to
>>> fop-users@xmlgraphics.apache.org
>>>
>>> ---
>>>
>>> The table-header is rendered correctly in 0.20.5 with the following
>>> output:
>>> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
>>> [INFO] FOP 0.20.5
>>> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
>>> [INFO] building formatting object tree
>>> [INFO] setting up fonts
>>> [INFO] [1]
>>> [WARNING] Sum of fixed column widths 50 greater than maximum
>>> specified IPD 0
>>> [INFO] [2]
>>> [INFO] Parsing of document complete, stopping renderer
>>>
>>> I have searched for a possible cause, and would like a workaround if not
>>> a fix.  I have so far been unable to determine what aspect of the table
>>> header may be triggering this behavior.
>>>
>>> Tom Morrison
>>> This message has been scanned by MailController -
>>> portal1.mailcontroller.co.uk
>>>
>>> -
>>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org**
>>> **
>>>
>>> ** **
>>>
>>> This message has been scanned by 
>>> MailController<http://portal1.mailcontroller.co.uk/>
>>> .
>>>
>>>  
>>>
>>
>>
>