DO NOT REPLY [Bug 38648] - NPE in PropertyTokenizer. with table-cell property border=inherit

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38648


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2006-02-15 08:53 ---
Hmm, surrounding the code in the PropertyTokenizer's constructor with an "if (s
!= null)" fixes the NPE, but "inherit" still doesn't work because only the
direct parent gets evaluated. The property value is not properly inherited.
Looks like this will need further inspection.

Work-around for now: Explicitely specify the border property on every
table-cell. Use attribute-sets in XSLT.

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

DO NOT REPLY [Bug 38648] - NPE in PropertyTokenizer. with table-cell property border=inherit

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38648





--- Additional Comments From [EMAIL PROTECTED]  2006-02-15 04:50 ---
Created an attachment (id=17700)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17700&action=view)
test input with simple table using border=inherit in cells


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

DO NOT REPLY [Bug 38648] New: - NPE in PropertyTokenizer. with table-cell property border=inherit

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38648

   Summary: NPE in PropertyTokenizer. with table-cell property
border=inherit
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: fo tree
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm running the attached simply xsl-fo (foo.xml) through the FOTreeBuilder -
with "border=inherit" this fails because of a NPE below.

Somehow org.apache.fop.fo.properties.PropertyMaker.make(PropertyMaker.java:391)
passes a defaultValue=null down the line which doesn't fare well.

Thanks
Nils



java.lang.NullPointerException
at 
org.apache.fop.fo.expr.PropertyTokenizer.(PropertyTokenizer.java:67)
at org.apache.fop.fo.expr.PropertyParser.(PropertyParser.java:103)
at org.apache.fop.fo.expr.PropertyParser.parse(PropertyParser.java:88)
at 
org.apache.fop.fo.properties.PropertyMaker.make(PropertyMaker.java:423)
at 
org.apache.fop.fo.properties.PropertyMaker.make(PropertyMaker.java:391)
at 
org.apache.fop.fo.properties.PropertyMaker.get(PropertyMaker.java:298)
at org.apache.fop.fo.PropertyList.get(PropertyList.java:171)
at org.apache.fop.fo.StaticPropertyList.get(StaticPropertyList.java:71)
at org.apache.fop.fo.PropertyList.get(PropertyList.java:152)
at org.apache.fop.fo.PropertyList.getFromParent(PropertyList.java:208)
at 
org.apache.fop.fo.properties.PropertyMaker.make(PropertyMaker.java:412)
at 
org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:344)
at 
org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:300)
at org.apache.fop.fo.FObj.processNode(FObj.java:118)
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:216)

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

Re: white-space-collapse not working in trunk?

[Manuel Mall]

> On Tue, Feb 14, 2006 at 10:26:52AM +0100, Luca Furini wrote:
>>
>> In order to preserve all spaces, we could use the elements that are now
>> generated for a nbsp:
>>box  w=0
>>penalty inf
>>glue (elastic or not, according to the alignment)
>>
>> They are not suppressed and they do not allow a break, so I think they
>> should fit quite well this situation too, when white-space-treatment =
>> "preserve" and wrap-option="no-wrap".
>
> If wrap-option="no-wrap", cannot we somehow avoid the whole linebreak
> calculation? Each line is a Knuth paragraph and creates a single line.
>
>> If wrap-option="wrap", however, we must add some penalties in order to
>> allow a break between spaces; we must be careful, as if there are 3
>> spaces
>> between two words, there are 4 possible breaks (ignoring, at the moment,
>> unicode breaking rules), so we just cannot add a penalty before or after
>> the other elements.
>
> Isn't it so that in the case of white-space-treatment="preserve" the
> line breaks are between the spaces instead of on them? Then for a___b,
> where an underscore indicates a space, I would construct
>
> box(a) p box(0) p(inf) glue p box(0) p(inf) glue p box(0) p(inf) glue p
> box(b)
>
> with possible line breaks at the p.
>

The above sequence only covers the simplest case. The moment we have
justification and/or border padding it gets more complicated. Some time
ago (mid Nov 2005) I started a WIKI page
http://wiki.apache.org/xmlgraphics-fop/LineBreaking where I attempted to
document the different scenarios with respect to line breaking and Knuth
element generation.

I identified the following different cases:

1. Non breaking / non elastic
2. Non breaking / elastic space
3. Break / non elastic
4. Break / non elastic / add character if break
5. Break / non elastic / remove if not break
6. Break / non elastic / removable
7. Break / elastic / non removable
8. Break / elastic / removable

Your case above is basically case 7.).

May be this is a trigger for those interested (Luca?, Simon?, ...) to
review this WIKI page and may be suggest clarifications, corrections,
restructuring,  I still think it would be valuable to
a) Capture all the different break scenarios (may be the cases 1. to 8.
above are not complete or can be simplified)
b) Document the relevant Knuth sequences applying to each identified break
scenario
Once we have that converting it into code should be fairly straightforward.

> Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.nl
>

Manuel

Re: differnece between fop and xep: which is right?

[Simon Pepping]

I read the two definitions in 7.28,3 and 7.28.4 as follows:

label-end() =
  width of the content-rectangle of the reference-area into
which the list-block is placed
   - (the value of the provisional-distance-between-starts
  + the value of the start-indent
  + start-intrusion-adjustment
  - the value of the provisional-label-separation)
 of the closest ancestor fo:list-block

(that is, as printed in the spec) and

body-start() =
  (the value of the start-indent
   + start-intrusion-adjustment
   + the value of the provisional-distance-between-starts)
  of the closest ancestor fo:list-block

(that is, I added parentheses around the expression so that all are
evaluated on fo:list-block).

Then you can do some math:

label-end() =
  width of the content-rectangle of the reference-area into
which the list-block is placed
   - (body-start()
  - the value of the provisional-label-separation)
 of the closest ancestor fo:list-block

which gives:

width of the content-rectangle - label-end()
  + provisional-label-separation = body-start()

label-end() is counted from the end of the content-rectangle, and
therefore width of the content-rectangle - label-end() is the distance
of the label end to the start of the content-rectangle. Then

from start of content-rectangle to end of label
  + provisional-label-separation = body-start()

  +-+
  | |
  |   +---+   +---+ |
  |   |   |   |   | |
  |   +---+   |   | |
  |   .   |   | |
  |   .   |   | |
  |   .   | |
  |   .<--->|
  .   |   label-end()   |
   <->|
 body-start() |
   <->.<->|
(1)   .(2)|

 (1) = width of the content-rectangle - label-end()
 (2) = provisional-label-separation
 (1) + (2) = body-start()

This is the relation you would expect, which supports my
interpretation.

Sorry for still being at the level of ascii art. Read it in Courier.

Simon

On Tue, Feb 14, 2006 at 09:36:06AM +0100, Jeremias Maerki wrote:
>
> On 14.02.2006 07:24:03 Manuel Mall wrote:
> > Jeremias,
> >
> > I did read those sections of the spec at the time and that's how the
> > question arose. I didn't check the code though. Any way the spec says in
> > 7.28.4:
> >
> > body-start() = the value of the start-indent + start-intrusion-adjustment
> > + the value of the provisional-distance-between-starts of the closest
> > ancestor fo:list-block.
> >
> > The questions arises what is meant by 'the value of the start-indent',
> > i.e. the start-indent of which fo is suppose to be used? Does the suffix
> > 'of the closest ancestor fo:list-block' apply to all three terms
> > 'start-indent', 'start-intrusion-adjustment' and
> > 'provisional-distance-between-starts' or only to
> > 'provisional-distance-between-starts'?.
>
> "start-indent" can't be the start-indent of the list-item-body, that
> much is clear. I always assumed it was inherited(start-indent). Anything
> else would make no sense (recursion). I guess the spec could be clearer.
> "of the closest anscestor fo:list-block" (at least for me) applies
> directly and only to "provisional-distance-between-starts". That
> property is inherited but only applies to fo:list-block. Furthermore,
> start-intrusion-adjustment is something that can't come from the
> list-block.
>
> > I assume now it means the further that is start-indent is to be taken from
> > the closest ancestor fo:list-block. Therefore my initial concern that we
> > have a recursive case here is probably not an issue.
>
> As I wrote above, I believe it's inherited(start-indent), i.e. comes
> from the parent fo:list-item, not the list-block. This is important
> because it allows you to indent individual list-items differently in the
> same list-block.

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

Re: white-space-collapse not working in trunk?

[Simon Pepping]

On Tue, Feb 14, 2006 at 10:26:52AM +0100, Luca Furini wrote:
> 
> In order to preserve all spaces, we could use the elements that are now 
> generated for a nbsp:
>box  w=0
>penalty inf
>glue (elastic or not, according to the alignment)
> 
> They are not suppressed and they do not allow a break, so I think they 
> should fit quite well this situation too, when white-space-treatment = 
> "preserve" and wrap-option="no-wrap".

If wrap-option="no-wrap", cannot we somehow avoid the whole linebreak
calculation? Each line is a Knuth paragraph and creates a single line.
 
> If wrap-option="wrap", however, we must add some penalties in order to 
> allow a break between spaces; we must be careful, as if there are 3 spaces 
> between two words, there are 4 possible breaks (ignoring, at the moment, 
> unicode breaking rules), so we just cannot add a penalty before or after 
> the other elements.

Isn't it so that in the case of white-space-treatment="preserve" the
line breaks are between the spaces instead of on them? Then for a___b,
where an underscore indicates a space, I would construct

box(a) p box(0) p(inf) glue p box(0) p(inf) glue p box(0) p(inf) glue p box(b)

with possible line breaks at the p.
 
Simon

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

Re: [Xmlgraphics-fop Wiki] Update of "ApiDesign" by JeremiasMaerki

[J.Pietschmann]

Sorry for the delay.

Jeremias Maerki wrote:

Do you mean something like setOutputProperty(name, value) in the JAXP
Transformer?


No, rather something like setParam(name,value), but on the renderer.


Note that PDF encryption parameters are specific to a rendering run
while the character encoding is probably more of a
environmental/factory-level config value.


After some thinking, I'd say I mean a mechanism for setting or
overwriting configuration values from the command line.
Something like
  fop -fo foo.fo -pdf foo.pdf -r noprint=yes -r filters=''
(oops, convoluted example), and the name/value pairs after the -r
switch would be passed to the renderer by whatever means, for example
by mangling the configuration or, as I tried to suggest, as a Properties
object.

I'm bothered with having a very renderer specific data class in the
UserAgent, and no obvious way to pass command line values to the
renderer.
BTW: encryption options like noprint should as well be configurable,
and there are arguments that even the user password for encryption
could benefit from being read from the XML configuration data.

J.Pietschmann

DO NOT REPLY [Bug 38639] - PDF not opening

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38639


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2006-02-14 12:09 ---
What version of FOP are using? What Operating System are you generating PDFs 
on? What version of Java are you using? Please provide the sample FO. What 
version of Acrobat is being used?

PS: Questions like this really ought to be asked on the fop-user Mailing list

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

Re: Finally finalizing the FOP API

[Jeremias Maerki]

Ok, the necessary changes except for the deprecations are done in the
branch.

On 13.02.2006 10:16:25 Jeremias Maerki wrote:

> I decided that I will implement my proposal in
> a new branch. There, everyone can have a look at the real thing and
> we'll adjust as necessary to make everyone happy. 



Jeremias Maerki

Re: white-space-collapse not working in trunk?

[Luca Furini]

(moved from fop-users as we are going into the implementation details)

Manuel Mall wrote:

the shorthand property white-space="pre" should be used or its expanded 
equivalents:

   linefeed-treatment="preserve"
   white-space-collapse="false"
   white-space-treatment="preserve"
   wrap-option="no-wrap"

If you do that the bug I was referring to would show because
white-space-treatment="preserve" is not correctly implemented.


In order to preserve all spaces, we could use the elements that are now 
generated for a nbsp:

   box  w=0
   penalty inf
   glue (elastic or not, according to the alignment)

They are not suppressed and they do not allow a break, so I think they 
should fit quite well this situation too, when white-space-treatment = 
"preserve" and wrap-option="no-wrap".


If wrap-option="wrap", however, we must add some penalties in order to 
allow a break between spaces; we must be careful, as if there are 3 spaces 
between two words, there are 4 possible breaks (ignoring, at the moment, 
unicode breaking rules), so we just cannot add a penalty before or after 
the other elements.


Is this ok, or am I missing some important detail?

Regards
Luca

DO NOT REPLY [Bug 38639] New: - PDF not opening

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38639

   Summary: PDF not opening
   Product: Fop
   Version: all
  Platform: Other
OS/Version: Solaris
Status: NEW
  Severity: major
  Priority: P2
 Component: pdf
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


We have used FOP for generation of PDF reports in our application.
PDF reports opens in IE browser.
The reports are working fine in our environment  but at our client site PDF 
does not open. Screen hangs and all system resources are used by AcroRd32.exe.
Please help. Is there any setting which is creating problem.

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

Re: differnece between fop and xep: which is right?

[Jeremias Maerki]

On 14.02.2006 07:24:03 Manuel Mall wrote:
> Jeremias,
> 
> I did read those sections of the spec at the time and that's how the
> question arose. I didn't check the code though. Any way the spec says in
> 7.28.4:
> 
> body-start() = the value of the start-indent + start-intrusion-adjustment
> + the value of the provisional-distance-between-starts of the closest
> ancestor fo:list-block.
> 
> The questions arises what is meant by 'the value of the start-indent',
> i.e. the start-indent of which fo is suppose to be used? Does the suffix
> 'of the closest ancestor fo:list-block' apply to all three terms
> 'start-indent', 'start-intrusion-adjustment' and
> 'provisional-distance-between-starts' or only to
> 'provisional-distance-between-starts'?.

"start-indent" can't be the start-indent of the list-item-body, that
much is clear. I always assumed it was inherited(start-indent). Anything
else would make no sense (recursion). I guess the spec could be clearer.
"of the closest anscestor fo:list-block" (at least for me) applies
directly and only to "provisional-distance-between-starts". That
property is inherited but only applies to fo:list-block. Furthermore,
start-intrusion-adjustment is something that can't come from the
list-block.

> I assume now it means the further that is start-indent is to be taken from
> the closest ancestor fo:list-block. Therefore my initial concern that we
> have a recursive case here is probably not an issue.

As I wrote above, I believe it's inherited(start-indent), i.e. comes
from the parent fo:list-item, not the list-block. This is important
because it allows you to indent individual list-items differently in the
same list-block.

> Now (finally) looking at the code it navigates up the fo tree until the
> nearest ancestor fo:list-item and not fo:list-block. If start-indent on a
> fo:list-item is always identical to the start-indent on the ancestor
> list-block thats fine. If its not then we may have a problem.

I don't think we have a problem. I believe the code is correct. What we
could do, however, is add additional test cases which exercise the
different start-indent scenarios. That would also allow comparisons with
other implementations.

> Manuel
> 
> PS: Moved the thread to fop-dev.
> 
> > Manuel,
> >
> > see 7.28.4. “provisional-distance-between-starts” and 5.10.4. "Property
> > Value
> > Functions"
> >
> > In the source code: org.apache.fop.fo.expr.BodyStartFunction
> >
> > On 13.02.2006 09:31:47 Manuel Mall wrote:
> >> Jeremias,
> >>
> >> just out of curiosity and not directly related to the posters question:
> >>
> >> The definition of block-start() refers to start-indent. Here we are
> >> actually setting start-indent. Which value of start-indent is used in
> >> calculating block-start()?
> >>
> >> Manuel
> >>
> >> > I think XEP is wrong if it reports an error. XSL-FO 1.0 says in "5.9
> >> > Expressions": "All property value specifications in attributes within
> >> an
> >> > XSL stylesheet can be expressions."
> >> >
> >> > IMO, your expression for start-indent is valid.
> >> >
> >> > On 13.02.2006 04:59:48 Paul Tremblay wrote:
> >> >> I have the following line in my of.xml file:
> >> >>
> >> >>
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >>  >> >> text-indent="-12pt">
> >> >>In late
> >> >> winter
> >> >>
> >> >> I want to create a hanging indents for long lines of poetry. When I
> >> >> run this document through xep's processor, I get the following error:
> >> >>
> >> >>  [warning] Bad attribute start-indent: Cannot add type Word to type
> >> >>  Length
> >> >>
> >> >> However, when I run it through fop .91 beta, it works exactly like I
> >> >> want it to.
> >> >>
> >> >> Is xep correct in reporting an error? Is fop cheating? Of course, I
> >> am
> >> >> glad that fop processes the document the way I want!


Jeremias Maerki