subject:"Error"

Hi Luca,

the reason for the effect you're seeing is the inheritance of
start-indent and end-indent. In your exapmle, if you specify a
margin-left and margin-right on the simple-page-master, this results
(corresponding properties) in a start-indent and end-indent of 50pt each.
Now, because start|end-indent are inherited, region-body also starts
with a start-indent and end-indent of 50pt which together with the
parent's start-indent accumulates 100pt because each of the FOs are
generating a reference area. If you'd do this on nested blocks you
wouldn't see this behaviour because they don't establish a new reference
area.

That's really one of the things I stumbled upon and which I believe
after a lot of thinking to be the correct behaviour given by the spec.
RenderX seem to have chosen to break inheritance in these cases because
they create strange effects like you found out now. It took me some time
to get used to it. So in your case you could specify a margin=0pt on
the region-body which triggers the first formula given in 5.3.2. If you
don't specify margin the inherited value for start-indent is used.

There are other instances like on tables where you have to start
specifying start-indent=0pt and end-indent=0pt on table-body if you
have a margin on fo:table.

I'm 99.9% sure that the current behaviour is correct even if it produces
strange results for the XSL-FO user. See my layout engine test cases
where I have such auxiliary margin and start|end-indent properties in
some places.

On 15.02.2005 15:03:00 Luca Furini wrote:
 I noticed a strange behaviour concerning margins that could be related to
 the inheritance of start-indend and end-indent, which was discussed a few
 weeks ago.
 It seems that in some situations the margins are subtracted twice from the
 available inline progression dimension.
 
 In the little fo file I'm attaching there are two simple-page-masters:
 - in one of them, left and right margins are set inside simple-page-master
 itself
 - in the other, they are set inside region-body
 
 In both cases, the page width is 200 points, with left and right margin
 set to 50 points; so, the line width should be 100 points.
 
 In the method PageSequenceLayoutManager.getViewportRectangle(), the
 computed ipd is right when the margins are set in region-body, but it is 0
 if they are set in simple-page-master, because relDims.ipd is already 100
 and start- end-indent are 50.
 
 As this method has not been modified recently, the error (if this
 behaviour is really wrong) must be elsewhere ...
 
 Regards,
 Luca
 
 



Jeremias Maerki

Re: Error in computation of inline progression dimension ?

--- Jeremias Maerki [EMAIL PROTECTED] wrote:

 Hi Luca,
 
 the reason for the effect you're seeing is the
 inheritance of
 start-indent and end-indent. In your exapmle, if you
 specify a
 margin-left and margin-right on the
 simple-page-master, this results
 (corresponding properties) in a start-indent and
 end-indent of 50pt each.

Jeremias,

I think I am missing something here.  Margin-left and
margin-right are different properties from
start-indent and end-indent, so I'm unsure why
inheritance between the two would be applicable in
this case.

How does specifying margin-left = 50pt result in the
start-indent value being set to 50pt?  (Corresponding
properties just map ***-start to ***-left, etc. for an
otherwise-same-named property so CP don't appear to be
relevant to this issue.  Does the spec declare
margin-left and start-indent to be corresponding
properties?)

Thanks,
Glen

Re: Error in computation of inline progression dimension ?


On 15.02.2005 17:46:54 Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  Hi Luca,
  
  the reason for the effect you're seeing is the
  inheritance of
  start-indent and end-indent. In your exapmle, if you
  specify a
  margin-left and margin-right on the
  simple-page-master, this results
  (corresponding properties) in a start-indent and
  end-indent of 50pt each.
 
 Jeremias,
 
 I think I am missing something here.  Margin-left and
 margin-right are different properties from
 start-indent and end-indent, so I'm unsure why
 inheritance between the two would be applicable in
 this case.
 
 How does specifying margin-left = 50pt result in the
 start-indent value being set to 50pt? 

First rule in 5.3.2 for FOs that generate reference areas:
start-indent = margin-corresponding + padding-corresponding +
border-corresponding-width.

  (Corresponding
 properties just map ***-start to ***-left, etc. for an
 otherwise-same-named property so CP don't appear to be
 relevant to this issue.  Does the spec declare
 margin-left and start-indent to be corresponding
 properties?)

Yes, also in 5.3.2:
There are two more properties, end-indent and start-indent
(block-level formatting objects) which correspond to the various
absolute margin properties.


Jeremias Maerki

Re: Error in computation of inline progression dimension ?

Yes, I was probably not 100% correct in my explanation though my
interpretation still stands.

On 15.02.2005 18:02:14 Glen Mazza wrote:
 Oh--5.3.2 says: There are two more properties,
 end-indent and start-indent (block-level
 formatting objects) which correspond to the various
 absolute margin properties.
 
 I'm uncertain that that means that they are
 Corresponding Properties however--I wonder if you are
 reading too much into the word correspond.


Jeremias Maerki

Re: Error in computation of inline progression dimension ?

But if start-indent and margin-left are not
Corresponding Properties, then the inheritance of
50pt. you gave in your example would not occur.

IMO, if start-indent and margin-left were actually
intended to be Corresponding Properties, the former
would have been named margin-start.  Also,
margin-before and margin-after (or before-indent and
after-indent) corresponding properties would also have
been created.  The description of Corresponding
Properties, 2nd para of 5.1.2, is unfortunately vague
about which properties are actually CP's.

Glen

--- Jeremias Maerki [EMAIL PROTECTED] wrote:

 Yes, I was probably not 100% correct in my
 explanation though my
 interpretation still stands.
 
 On 15.02.2005 18:02:14 Glen Mazza wrote:
  Oh--5.3.2 says: There are two more properties,
  end-indent and start-indent (block-level
  formatting objects) which correspond to the
 various
  absolute margin properties.
  
  I'm uncertain that that means that they are
  Corresponding Properties however--I wonder if you
 are
  reading too much into the word correspond.
 
 
 Jeremias Maerki

Re: Error in computation of inline progression dimension ?

In mid January Peter helped me understand what's going on. Please have a
look at his explanation [1]. Maybe that makes it clearer. The margin
properties are never used directly in the layout engine (I think and
hope). I'm always working from *-indent and space-*. I think it's
obvious enough from 5.3.2 that *-indent and margin are meant to be 
corresponding,
at least through the rules established therein.

Actually, I think 5.1.2 is the section I should have looked at before
Peter pointed out my mistake. About corresponding properties it says
The simplest example of such properties..., so in my view 5.3.2
describes a complex relationship and so my calling these properties
corresponding was really correct. And the rules in 5.3.2 talk about
corresponding (margin-corresponding), and to what can they correspond
to if not start-indent and end-indent or space-before and space-after
depending on the writing mode?

If you think the current interpretation is wrong, please present your
theory. However, the more I think about this, and the more I'm
explaining, the more I can say that I'm sure that the interpretation is
correct.

[1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=2078791

On 15.02.2005 18:27:38 Glen Mazza wrote:
 But if start-indent and margin-left are not
 Corresponding Properties, then the inheritance of
 50pt. you gave in your example would not occur.
 
 IMO, if start-indent and margin-left were actually
 intended to be Corresponding Properties, the former
 would have been named margin-start.  Also,
 margin-before and margin-after (or before-indent and
 after-indent) corresponding properties would also have
 been created.  The description of Corresponding
 Properties, 2nd para of 5.1.2, is unfortunately vague
 about which properties are actually CP's.


Jeremias Maerki

Re: Error in computation of inline progression dimension ?

Jeremias,

I am wrong here.  This phrase in 5.3.2:

If the corresponding absolute margin property is
specified on the formatting object...

Clearly means that margin *is* a CP, and hence is a CP
with start-indent/end-indent as appropriate.  Forget
that argument--never mind, and I'm sorry that you had
to waste time explaining this to me.

I may have more questions on your logic though, as I'm
studying your original response to Luca.  But
thankfully we're in agreement on this point.

Thanks,
Glen


--- Jeremias Maerki [EMAIL PROTECTED] wrote:

 In mid January Peter helped me understand what's
 going on. Please have a
 look at his explanation [1]. Maybe that makes it
 clearer. The margin
 properties are never used directly in the layout
 engine (I think and
 hope). I'm always working from *-indent and space-*.
 I think it's
 obvious enough from 5.3.2 that *-indent and margin
 are meant to be corresponding,
 at least through the rules established therein.
 
 Actually, I think 5.1.2 is the section I should have
 looked at before
 Peter pointed out my mistake. About corresponding
 properties it says
 The simplest example of such properties..., so in
 my view 5.3.2
 describes a complex relationship and so my calling
 these properties
 corresponding was really correct. And the rules in
 5.3.2 talk about
 corresponding (margin-corresponding), and to what
 can they correspond
 to if not start-indent and end-indent or
 space-before and space-after
 depending on the writing mode?
 
 If you think the current interpretation is wrong,
 please present your
 theory. However, the more I think about this, and
 the more I'm
 explaining, the more I can say that I'm sure that
 the interpretation is
 correct.
 
 [1]

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=2078791

Re: Error in computation of inline progression dimension ?

--- Jeremias Maerki [EMAIL PROTECTED] wrote:

 Hi Luca,
 
 the reason for the effect you're seeing is the
 inheritance of
 start-indent and end-indent. In your exapmle, if you
 specify a
 margin-left and margin-right on the
 simple-page-master, 

(margin-left and margin-right of 50pt each on
fo:s-p-m)

 this results
 (corresponding properties) in a start-indent and
 end-indent of 50pt each.

via the second set of formulas, because margins are
explicitly specified and fo:s-p-m does not generate
any area and hence does not generate a reference area
(although it is used by fo:page-sequence to do so): I
agree here.


 Now, because start|end-indent are inherited,
 region-body also starts
 with a start-indent and end-indent of 50pt which

I agree, but these properties are not explicitly
specified on fo:region-body, so the first two sets of
formulae are not relevant here.  Nor would they be
anyway because I don't believe fo:region-bodies
generate reference areas.


 together with the
 parent's start-indent accumulates 100pt because each
 of the FOs are
 generating a reference area. 

I don't think so here--I don't believe either fo:s-p-m
or fo:region-body generate reference areas--indeed, I
don't think anything located outside of
fo:page-sequence does.  The spec says they are *used*
to create a reference area, but they don't generate
one themselves.  So maybe your calculations here may
need changing--because different formulae in 5.3.2
would hence be activated.

Section 6.1 [1] says There are three kinds of
formatting objects: (1) those that generate areas, (2)
those that return areas, but do not generate them, and
(3) those that are used in the generation of areas.

fo:s-p-m and fo:region-body are type (3), not type
(1).

fo:s-p-m text:  The fo:simple-page-master formatting
object generates no area directly. It is used in the
generation of pages by an fo:page-sequence. type (3)

fo:r-b text:  The fo:region-body formatting object is
used to generate one region-viewport-area and one
region-reference-area whenever an
fo:simple-page-master that has an fo:region-body as a
child is used to generate a page.  (i.e., type 3)


[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section


 So in your case you could specify
 a margin=0pt on
 the region-body which triggers the first formula
 given in 5.3.2. 

Again, I don't think so because fo:region-body never
generates a reference-area.  Hence, with no explicit
specification of margin properites, the third set of
formulas then activates:

margin-corresponding = start-indent -
inherited_value_of(start-indent) -
padding-corresponding - border-corresponding-width

with the additional rule that:  If the start-indent
or end-indent properties are not specified their
inherited value is used in these formulae.

Since start-indent and end-indent were not specified,
then we have:

margin-corresponding =
inherited_value_of(start-indent) -
inherited_value_of(start-indent) -
padding-corresponding - border-corresponding-width,

or zero for the margin properties on fo:region-body. 
(i.e., we just rely on the 50pt. on
simple-page-master.)

So Luca is correct that both fo:simple-page-masters
should generate the same overall margins of 50 pt.
each, no?

Thanks,
Glen

Re: Error in computation of inline progression dimension ?

On second thought, Jeremias, instead of arguing this,
why don't we just compromise at 75pt. margins?  ;)

Glen

--- Glen Mazza [EMAIL PROTECTED] wrote:

 --- Jeremias Maerki [EMAIL PROTECTED]
 wrote:
 
  Hi Luca,
  
  the reason for the effect you're seeing is the
  inheritance of
  start-indent and end-indent. In your exapmle, if
 you
  specify a
  margin-left and margin-right on the
  simple-page-master, 
 
 (margin-left and margin-right of 50pt each on
 fo:s-p-m)
 
  this results
  (corresponding properties) in a start-indent and
  end-indent of 50pt each.
 
 via the second set of formulas, because margins are
 explicitly specified and fo:s-p-m does not generate
 any area and hence does not generate a reference
 area
 (although it is used by fo:page-sequence to do so):
 I
 agree here.
 
 
  Now, because start|end-indent are inherited,
  region-body also starts
  with a start-indent and end-indent of 50pt which
 
 I agree, but these properties are not explicitly
 specified on fo:region-body, so the first two sets
 of
 formulae are not relevant here.  Nor would they be
 anyway because I don't believe fo:region-bodies
 generate reference areas.
 
 
  together with the
  parent's start-indent accumulates 100pt because
 each
  of the FOs are
  generating a reference area. 
 
 I don't think so here--I don't believe either
 fo:s-p-m
 or fo:region-body generate reference areas--indeed,
 I
 don't think anything located outside of
 fo:page-sequence does.  The spec says they are
 *used*
 to create a reference area, but they don't generate
 one themselves.  So maybe your calculations here may
 need changing--because different formulae in 5.3.2
 would hence be activated.
 
 Section 6.1 [1] says There are three kinds of
 formatting objects: (1) those that generate areas,
 (2)
 those that return areas, but do not generate them,
 and
 (3) those that are used in the generation of areas.
 
 fo:s-p-m and fo:region-body are type (3), not type
 (1).
 
 fo:s-p-m text:  The fo:simple-page-master formatting
 object generates no area directly. It is used in the
 generation of pages by an fo:page-sequence. type (3)
 
 fo:r-b text:  The fo:region-body formatting object
 is
 used to generate one region-viewport-area and one
 region-reference-area whenever an
 fo:simple-page-master that has an fo:region-body as
 a
 child is used to generate a page.  (i.e., type 3)
 
 
 [1]

http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section
 
 
  So in your case you could specify
  a margin=0pt on
  the region-body which triggers the first formula
  given in 5.3.2. 
 
 Again, I don't think so because fo:region-body never
 generates a reference-area.  Hence, with no explicit
 specification of margin properites, the third set of
 formulas then activates:
 
 margin-corresponding = start-indent -
 inherited_value_of(start-indent) -
 padding-corresponding - border-corresponding-width
 
 with the additional rule that:  If the
 start-indent
 or end-indent properties are not specified their
 inherited value is used in these formulae.
 
 Since start-indent and end-indent were not
 specified,
 then we have:
 
 margin-corresponding =
 inherited_value_of(start-indent) -
 inherited_value_of(start-indent) -
 padding-corresponding - border-corresponding-width,
 
 or zero for the margin properties on fo:region-body.
 
 (i.e., we just rely on the 50pt. on
 simple-page-master.)
 
 So Luca is correct that both fo:simple-page-masters
 should generate the same overall margins of 50 pt.
 each, no?
 
 Thanks,
 Glen

Re: Error in computation of inline progression dimension ?

90pt, no less.

On 16.02.2005 05:15:36 Glen Mazza wrote:
 On second thought, Jeremias, instead of arguing this,
 why don't we just compromise at 75pt. margins?  ;)



Jeremias Maerki

Re: Error in computation of inline progression dimension ?

I'm afraid that you're wrong here. It's true that s-p-m and region-body
don't directly generate reference areas but they also can't, because
they are only used as a template for each new page. For for each page
they serve as FOs that generate reference areas.

But let me give you another example where this is clearer and so you see
that your argument doesn't really count in this discussion. Please open
test/layoutengine/testcases/block-container3.xml. That test case I wrote
specifically to demostrate the effect we're discussing here. You can't
deny that block-container generates a reference area directly. So in
this test case the block inside the b-c has an effective start-indent of
20pt (10pt + 10pt) much like in Luca's example.

If you look at the checks at the end of block-container3.xml you will
realize that there is no 2 (millipoints) anywhere. It's simply the
effect from the reference area which results in the double indent. So if
you wanted to have both text-generating blocks left-aligned at the same
position you'd have to specify start-indent=0pt on the block-container
or on its nested block to reset the start-indent to 0pt.

BTW, I anticipated that I'd have this argument sooner or later. I was
rather baffled when I found out how it is supposed to work. So don't
worry about wasting my time in this case. I simply hope we can then put
it to rest once and for all, ideally documented in a nice Wiki or Web
page, so that if that question comes up again, we can simply point
people to that page.

(additional comments inline)

On 16.02.2005 05:02:30 Glen Mazza wrote:
snip/
  together with the
  parent's start-indent accumulates 100pt because each
  of the FOs are
  generating a reference area. 
 
 I don't think so here--I don't believe either fo:s-p-m
 or fo:region-body generate reference areas--indeed, I
 don't think anything located outside of
 fo:page-sequence does.  The spec says they are *used*
 to create a reference area, but they don't generate
 one themselves.  So maybe your calculations here may
 need changing--because different formulae in 5.3.2
 would hence be activated.
 
 Section 6.1 [1] says There are three kinds of
 formatting objects: (1) those that generate areas, (2)
 those that return areas, but do not generate them, and
 (3) those that are used in the generation of areas.
 
 fo:s-p-m and fo:region-body are type (3), not type
 (1).
 
 fo:s-p-m text:  The fo:simple-page-master formatting
 object generates no area directly. It is used in the
 generation of pages by an fo:page-sequence. type (3)
 
 fo:r-b text:  The fo:region-body formatting object is
 used to generate one region-viewport-area and one
 region-reference-area whenever an
 fo:simple-page-master that has an fo:region-body as a
 child is used to generate a page.  (i.e., type 3)
 
 
 [1]
 http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section
 
 
  So in your case you could specify
  a margin=0pt on
  the region-body which triggers the first formula
  given in 5.3.2. 
 
 Again, I don't think so because fo:region-body never
 generates a reference-area.  Hence, with no explicit
 specification of margin properites, the third set of
 formulas then activates:
 
 margin-corresponding = start-indent -
 inherited_value_of(start-indent) -
 padding-corresponding - border-corresponding-width
 
 with the additional rule that:  If the start-indent
 or end-indent properties are not specified their
 inherited value is used in these formulae.
 
 Since start-indent and end-indent were not specified,
 then we have:
 
 margin-corresponding =
 inherited_value_of(start-indent) -
 inherited_value_of(start-indent) -
 padding-corresponding - border-corresponding-width,

This formula is only used to calculate margin-corresponding. It is not
used to calculate the effective indent. Corresponding properties should
not be used directly to do the actual calculations that define the
layout. Ask yourself: How would you decide when to use what property to
calculate the actual indents? That's why the formulas are there to
derive start|end-indent from the corresponding properties. The formula
you're refferring to here is actually used inside IndentPropertyMaker.
It is used to create the margin-corresponding value which is used in
the formula sets 1 and 2.

 or zero for the margin properties on fo:region-body. 
 (i.e., we just rely on the 50pt. on
 simple-page-master.)
 
 So Luca is correct that both fo:simple-page-masters
 should generate the same overall margins of 50 pt.
 each, no?

No. :-)


Jeremias Maerki

DO NOT REPLY [Bug 31063] New: - id already in this document error with no duplicate id

2004-09-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31063.
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=31063

id already in this document error with no duplicate id

   Summary: id already in this document error with no duplicate id
   Product: Fop
   Version: 0.20.5
  Platform: PC
   URL: http://tigreraye.org/essai.fo
http://tigreraye.org/essai.xml
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am using FOP to produce PDF or PS documents (from a DocBook XML
source converted to FO). For some specific documents, I always end up with the
following error:

[ERROR] file:/home/fevrier/essai.fo:48:206 The id id2455426 already exists in
this document

I tried to build the FO file with both xsltproc and xalan, with the same
result each time.

The attached files are the minimal DocBook XML file I was able to make that
exhibit this issue and the corresponding FO file.

I am able to work around this issue by adding a blank paragraph (or two) before
the page break solve this issue.

It would seem that this problem happens when a QANDASET (DocBook XML) is over a
page border. However, since fop complains about a duplicate id in the file, and
no id is duplicated in the FO file, it would seem to be a FOP issue.

Thanks.

DO NOT REPLY [Bug 31063] - id already in this document error with no duplicate id

2004-09-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31063.
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=31063

id already in this document error with no duplicate id

[EMAIL PROTECTED] changed:

   What|Removed |Added

URL|http://tigreraye.org/essai.f|http://tigreraye.org/essai.f
   |o   |o
   |http://tigreraye.org/essai.x|
   |ml  |



--- Additional Comments From [EMAIL PROTECTED]  2004-09-05 18:24 ---
The DocBook XML file is available here: http://tigreraye.org/essai.xml

DO NOT REPLY [Bug 31063] - id already in this document error with no duplicate id

2004-09-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31063.
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=31063

id already in this document error with no duplicate id

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-09-05 19:33 ---


*** This bug has been marked as a duplicate of 14962 ***

XMLParser error with unicode characters in XML file.

2004-07-06 Thread Manoj_Nair

I am getting a XML parsing error from weblogic.apache.xerces when I parse a
XML
document which contains accented characters.

This is what I am doing
1) Some database columns have accented data for spanish,japanese etc
languages
like Nmero de identificao: and nmero de identificacin.

2) I am reading this data and creating a XML file using some processing and
then writing the file on the disc using weblogic.xml.stream.XMLOutputStream
flush() method.

3) Then I am using FOP to render this XML in PDF. In the rendering process
the weblogic.apache.xerces.XMLparser gets called to parse the XML. Here the
parser throws a org.xml.sax.SAXParserException ( An invalid XML character
(Unicode: 0xfa) was found in the element content of the document).

I was under the impression that XMLParser should take care of the accented
characters. When I open the XML file which I created in XML SPY I see box
characters like cliente  n de identificaci.

Please let me know how should i handle my code here.

Thanks
Manoj

Thanks

DO NOT REPLY [Bug 29459] - Error in processing xml-file with xsl-stylesheet

2004-06-23 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29459.
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=29459

Error in processing xml-file with xsl-stylesheet

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|general |pdf renderer

DO NOT REPLY [Bug 29459] New: - Error in processing xml-file with xsl-stylesheet

2004-06-09 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29459.
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=29459

Error in processing xml-file with xsl-stylesheet

   Summary: Error in processing xml-file with xsl-stylesheet
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If I run fop with:
fop.bat -xml daten.xml -xsl daten.xsl daten.pdf I got the error:
[ERROR] org.apache.fop.apps.FOPException: A table cell must be child of 
fo:table-row, not fo:table-body
I chekc th fo-output with xalan.bat and all looks fine.
If I run fop with:
fop.bat xalanout.fo daten.pdf
it works.
I assume the probleme is located in the following codesnip:

xsl:if test=position() mod 2
  xsl:text disable-output-escaping=yeslt;fo:table-row 
height=quot;14cmquot; gt;
  /xsl:text
/xsl:if
xsl:call-template name=RezeptCell/
xsl:if test=not(position() mod 2)
  xsl:text disable-output-escaping=yeslt;/fo:table-rowgt;
  /xsl:text
/xsl:if
xsl:if test=position()=last() and position() mod 2
  xsl:text disable-output-escaping=yeslt;/fo:table-rowgt;
  /xsl:text
/xsl:if

DO NOT REPLY [Bug 29459] - Error in processing xml-file with xsl-stylesheet

2004-06-09 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29459.
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=29459

Error in processing xml-file with xsl-stylesheet

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-06-09 13:16 ---
This is *not* a bug. 

It is not valid to generate the start tag in one template and the end tag in 
another template. If this becomes necessary to achieve what you want then you 
need to re-think your XSL stylesheet design.

Using xsl:text with disable-output-escaping=yes is a trick that only works 
when the result of the XSL tranform is serialized to disk. When you supply xsl 
and xml files as input to the command line, the transform result is not 
serialized but rather passed as SAX events to FOP. Hence your trick fails.

If you are having difficulties then you should ask on the fop-user mailing 
list before raising a bug.

Database #Error

2004-04-06 Thread rubys

-- Partial message is available!
-- Error: llegal signs in Mail-Routing
-- Mail Server: ESMTP VX32.9 Version Betha Alpha

Norton AntiVirus gelöscht1.txt
Description: plain/text

Re: Compile error in HEAD

2004-01-11 Thread Simon Pepping

Glen,

On Sat, Jan 10, 2004 at 01:54:35PM -0800, Glen Mazza wrote:
 Simon,
 
 I can't duplicate the problem on my machine but I
 think I see the issue:  there is *no* more
 org.apache.fop.fo.properties.Constants interface
 anymore, it's been gone for a month or so.  I think
 you just need to clear it out (delete the file), and
 make sure you have the newest build.xml--it is the
 script that formerly created that properties.Constants
 interface (but doesn't anymore).
 
 What I do before a full build is delete the BUILD
 directory, then type ant--this forces everything to
 be created from scratch.

That solves the problem. I usually do an incremental build with 'ant
compile'. This is the second time I have been bitten by the fact that
that is not always sufficient. What seems to have happened is this:
The incremental build does not remove the files
fo.Constants.java/class and fo.properties.Constants.java/class as
previously generated from codegen. The former of these causes ant not
to rebuild the class fo.Constants from the corresponding new code in
src, thus leaving out the new constants that were declared in the
latter.
 
Thanks, Simon

-- 
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl
public key: http://www.leverkruid.nl/personal/sp.asc
fingerprint: E3BF 7295 9AA8 8B8A C01A  219D FAAC 088C 6B28 F549

Compile error in HEAD

2004-01-10 Thread Simon Pepping

Hi,

The code that I checked out this evening from CVS HEAD generates
compile errors, for example,

[javac] 
/fsd/source/xml-fop/build/gensrc/org/apache/fop/fo/properties/BorderBottomStyleMaker.java:21:
 cannot resolve symbol
[javac] symbol  : variable PR_BORDER_AFTER_STYLE 
[javac] location: interface org.apache.fop.fo.properties.Constants
[javac] p= 
propertyList.getExplicitOrShorthand(propertyList.wmMap(Constants.PR_BORDER_AFTER_STYLE,
 Constants.PR_BORDER_AFTER_STYLE, Constants.PR_BORDER_END_STYLE));
[javac]
 ^

The cause is that the import section is not sufficient:

package org.apache.fop.fo.properties;
  
import org.apache.fop.fo.*;
import org.apache.fop.apps.FOPException;

With these import statements the compiler applies interface
org.apache.fop.fo.properties.Constants instead of interface
org.apache.fop.fo.Constants. An explicit statement

import org.apache.fop.fo.Constants;

should be added. I did it as follows:

--- properties.xsl.~1.30.~  Sat Jan 10 20:02:04 2004
+++ properties.xsl  Sat Jan 10 21:53:43 2004
@@ -329,7 +329,8 @@
 import org.apache.fop.datatypes.*;/xsl:text
   /xsl:if
   xsl:text
-import org.apache.fop.fo.*;/xsl:text
+import org.apache.fop.fo.*;
+import org.apache.fop.fo.Constants;/xsl:text
   xsl:if test=not(
 (./datatype and ./datatype[. ='List'])
 or ./class-name[.='GenericCondPadding']
@@ -338,10 +339,6 @@
 xsl:text
 import org.apache.fop.apps.FOPException;/xsl:text
   /xsl:if
-  xsl:if test=.//enumeration and @type='generic'
-xsl:text
-import org.apache.fop.fo.Constants;/xsl:text
-/xsl:if
   xsl:text
 
 public class /xsl:text

The old code applies a precise test for the inclusion of the import
statement. My change includes the import statement in all property
makers. Not sure what a more precise test would look like, and if
there can be any.

Regards, Simon

-- 
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl
public key: http://www.leverkruid.nl/personal/sp.asc
fingerprint: E3BF 7295 9AA8 8B8A C01A  219D FAAC 088C 6B28 F549

Re: Compile error in HEAD

2004-01-10 Thread Glen Mazza

--- Simon Pepping [EMAIL PROTECTED] wrote:
 
 The cause is that the import section is not
 sufficient:
 
 package org.apache.fop.fo.properties;
   
 import org.apache.fop.fo.*;
 import org.apache.fop.apps.FOPException;
 
 With these import statements the compiler applies
 interface
 org.apache.fop.fo.properties.Constants instead of
 interface
 org.apache.fop.fo.Constants. 

Simon,

I can't duplicate the problem on my machine but I
think I see the issue:  there is *no* more
org.apache.fop.fo.properties.Constants interface
anymore, it's been gone for a month or so.  I think
you just need to clear it out (delete the file), and
make sure you have the newest build.xml--it is the
script that formerly created that properties.Constants
interface (but doesn't anymore).

What I do before a full build is delete the BUILD
directory, then type ant--this forces everything to
be created from scratch.

Another note:  cvs update -dPC will overwrite and
replace your work (actually, moves them to other
files), but should remove unneeded files and also get
you in sync with HEAD completely.


 An explicit statement
 
 import org.apache.fop.fo.Constants;
 
 should be added. I did it as follows:
 

Yes, but the Eclipse warnings of unneeded imports
drives Peter West and a few others crazy.  If the
above does not work, our only other solution would be
a fully qualified import statement.

Thanks always!

Glen


__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: Compile error in HEAD

2004-01-10 Thread Glen Mazza

--- Glen Mazza [EMAIL PROTECTED] wrote:
 
 Yes, but the Eclipse warnings of unneeded imports
 drives Peter West and a few others crazy.  If the
 above does not work, our only other solution would
 be
 a fully qualified import statement.
 

oops...I mean fully qualifying the Constants
variables.

Glen

__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Error in junit tests (was: [Bug 25828] - [PATCH] fop.sh/bat should use java.endorsed.dirs)

2004-01-05 Thread Simon Pepping

On Fri, Jan 02, 2004 at 10:59:54PM -, [EMAIL PROTECTED] wrote:

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

[PATCH] fop.sh/bat should use java.endorsed.dirs

--- Additional Comments From [EMAIL PROTECTED] 2004-01-02 22:59 ---
Q
I found today that the JUnit tests run well with the jar files from the SDK, but
I have problems when I substitute newer jar files for them. This makes me
hesitate about my patch.
/Q

I'm assuming you mean newer JARs but *not* the ones we distribute? If newer
versions than ours create errors not found in our supplied versions, rather
than hesitate this might actually strengthen the argument for applying your
patch!

I did the junit tests with various combinations of xercesImpl.jar,
xml-apis.jar, xalan.jar. These cause various errors. Most of them may
be ascribed to incompatible combinations of versions of these three
jar files. I paid special attention to the jar files that come with
SDK 1.4.2_01, those that come with FOP CVS HEAD and those that come
with Xalan 2.5.2; these should be compatible combinations.

No error occurs with the jar files from the SDK. One error occurs
with each of the other two combinations. In both cases the error
occurs in:

[junit] TEST org.apache.fop.BasicDriverTestSuite FAILED

and is similar (line numbers differ). Below an extract from the test
report for FOP's jar files:

Testsuite: org.apache.fop.BasicDriverTestSuite
Tests run: 8, Failures: 0, Errors: 1, Time elapsed: 10.26 sec

Testcase: testFO2PDFWithDOM took 0.696 sec
Caused an ERROR
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an
object in a way which is incorrect with regard to namespaces.
javax.xml.transform.TransformerException: org.w3c.dom.DOMException: NAMESPACE_ERR: An
attempt is made to create or change an object in a way which is incorrect with regard
to namespaces.
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:469)
at
org.apache.fop.BasicDriverTestCase.loadDocument(BasicDriverTestCase.java:133)
at
org.apache.fop.BasicDriverTestCase.testFO2PDFWithDOM(BasicDriverTestCase.java:149)
...
Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
change an object in a way which is incorrect with regard to namespaces.
at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:351)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020)

org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an
object in a way which is incorrect with regard to namespaces.
at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:351)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020)
...
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an
object in a way which is incorrect with regard to namespaces.
at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source)
at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
at org.apache.xerces.dom.AttrNSImpl.init(Unknown Source)

Regards, Simon

--
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl
public key: http://www.leverkruid.nl/personal/sp.asc
fingerprint: E3BF 7295 9AA8 8B8A C01A 219D FAAC 088C 6B28 F549

DO NOT REPLY [Bug 16713] - Hyphenation error in tables

2003-12-21 Thread bugzilla

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=16713.
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=16713

Hyphenation error in tables





--- Additional Comments From [EMAIL PROTECTED]  2003-12-21 19:01 ---
The attachments require other files which are not attached: three xsl files and
an external graphic.

DO NOT REPLY [Bug 16626] - Hyphenation causing java.io.IOException error

2003-12-15 Thread bugzilla

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=16626.
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=16626

Hyphenation causing java.io.IOException error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-12-15 22:41 ---
We will not get this fixed for the maintenance branch, however a fix on this 
problem was applied to development so this should not occur in our next release.

Thanks,
Glen

*** This bug has been marked as a duplicate of 25512 ***

DO NOT REPLY [Bug 25411] New: - [WARNING] Error while constructing image from XML -- throws IOE

2003-12-10 Thread bugzilla

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=25411.
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=25411

[WARNING] Error while constructing image from XML -- throws IOE

   Summary: [WARNING] Error while constructing image from XML --
throws IOE
   Product: Fop
   Version: 1.0dev
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Formatting test/resources/fop/image/errors.fo using command-line Fop
encounters an error, then throws an IOException and produces a stack trace
followed by more of the error.

Shouldn't we skip the Exception.printStackTrace() where the root cause is
well-understood and handled by the program ?


Command to cause this problem:
==
java -Xms100m -Xmx200m -cp
.:build/fop.jar:lib/avalon-framework-4.1.4.jar:lib/batik.jar:lib/commons-io-dev-20030703.jar
org.apache.fop.apps.Fop -fo test/resources/fop/image/errors.fo -pdf /tmp/12610.pdf

[INFO] 1.0dev
[WARNING] Error while constructing image from XML
java.io.IOException: Stream closed

... stack trace deleted ...

[ERROR] No ImageReader for this type of image (file:corrupt.svg)

... more stack trace deleted ...


the same error is repeated (I think),

DO NOT REPLY [Bug 25411] - [WARNING] Error while constructing image from XML -- throws IOE

2003-12-10 Thread bugzilla

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=25411.
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=25411

[WARNING] Error while constructing image from XML -- throws IOE





--- Additional Comments From [EMAIL PROTECTED]  2003-12-10 17:24 ---
Created an attachment (id=9499)
Log of messages including the error and stack trace

DO NOT REPLY [Bug 19851] - Error while opening the distribution file

2003-11-27 Thread bugzilla

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=19851.
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=19851

Error while opening the distribution file

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-11-27 23:39 ---
fop-0.20.5rc2-bin.tar.gz isn't there anymore (and wasn't broken anyway)
Besides, FOP 0.20.5 is also available as ZIP.

Re: Break-before ERROR

2003-10-21 Thread J.Pietschmann

Alberto Rodriguez Reyes wrote:
the break-before=even-page doesn't work if last page it's even page and i
put this label in fo:table into fo:static-content
flow-name=xsl-region-before. If last page it's odd page then insert a
blank page--- it's work
Break-before shouldn't work in static content at all, it only works
in the flow. Surely you mean something else?
J.Pietschmann

OutOfMemory error

2003-09-26 Thread Alberto Rodriguez Reyes

Hi,
my name is Alberto and i'm from spain, my english is not very well but i try
to tell you what it happens.
I'm developed a single system fop based: i received a xml input and a pdf is
returned, but if xml is very large the application return a OutOfMemory
error. I tried to modify JVM's memory and it's run, but I think that it is
not the best solution. Is there any other solution for this?
Thank's

***
** Alberto Rodríguez Reyes ***
***

Re: OutOfMemory error

2003-09-26 Thread Chris Bowditch

From: Alberto Rodriguez Reyes [EMAIL PROTECTED]

Hi,
my name is Alberto and i'm from spain, my english is not very well but i 
try
to tell you what it happens.
I'm developed a single system fop based: i received a xml input and a pdf 
is
returned, but if xml is very large the application return a OutOfMemory
error. I tried to modify JVM's memory and it's run, but I think that it is
not the best solution. Is there any other solution for this?
Thank's

Have you read the following advice regarding FOP memory usage on the web 
site?

http://xml.apache.org/fop/running.html#memory

A polite request: Please post questions on using FOP to the FOP-User list. 
The fop-dev list is a development forum. Thanks,

Chris

_
Tired of 56k? Get a FREE BT Broadband connection 
http://www.msn.co.uk/specials/btbroadband

RE: OutOfMemory error

2003-09-26 Thread Alberto Rodriguez Reyes

Hi, i've read this document and that's only really solution.i think that
must have other solution to free memory.
Thanks 

-Mensaje original-
De: Chris Bowditch [mailto:[EMAIL PROTECTED]
Enviado el: viernes, 26 de septiembre de 2003 11:08
Para: [EMAIL PROTECTED]
Asunto: Re: OutOfMemory error


From: Alberto Rodriguez Reyes [EMAIL PROTECTED]

Hi,
my name is Alberto and i'm from spain, my english is not very well but i 
try
to tell you what it happens.
I'm developed a single system fop based: i received a xml input and a pdf 
is
returned, but if xml is very large the application return a OutOfMemory
error. I tried to modify JVM's memory and it's run, but I think that it is
not the best solution. Is there any other solution for this?
Thank's


Have you read the following advice regarding FOP memory usage on the web 
site?

http://xml.apache.org/fop/running.html#memory

A polite request: Please post questions on using FOP to the FOP-User list. 
The fop-dev list is a development forum. Thanks,

Chris

_
Tired of 56k? Get a FREE BT Broadband connection 
http://www.msn.co.uk/specials/btbroadband

RE: OutOfMemory error

2003-09-26 Thread Chris Bowditch

From: Alberto Rodriguez Reyes [EMAIL PROTECTED]

Hi, i've read this document and that's only really solution.i think that
must have other solution to free memory.
Thanks
I dont quite understand, increasing the amount of memory available to the 
JVM is the not the only solution suggested on the FOP web site. One other 
method is to break up your document into multiple page-sequences. Are you 
saying it is not possible to break up your XSL-FO into multiple 
page-sequences? If not then explain why you think so, and maybe show us a 
small example of your XSL-FO.

Chris

_
Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile

DO NOT REPLY [Bug 23256] - Page reference bug - id repeat error.

2003-09-18 Thread bugzilla

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=23256.
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=23256

Page reference bug - id repeat error.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-09-18 21:52 ---


*** This bug has been marked as a duplicate of 3497 ***

DO NOT REPLY [Bug 3497] - id already exists error when using span=all attribute

2003-09-18 Thread bugzilla

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=3497.
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=3497

id already exists error when using span=all attribute

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-09-18 21:52 ---
*** Bug 23256 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 3497] - id already exists error when using span=all attribute

2003-09-11 Thread bugzilla

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=3497.
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=3497

id already exists error when using span=all attribute





--- Additional Comments From [EMAIL PROTECTED]  2003-09-11 19:56 ---
Created an attachment (id=8169)
Updated patch for FOP 0.20.5

DO NOT REPLY [Bug 3497] - id already exists error when using span=all attribute

2003-09-11 Thread bugzilla

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=3497.
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=3497

id already exists error when using span=all attribute





--- Additional Comments From [EMAIL PROTECTED]  2003-09-11 19:58 ---
I have attached an updated version of the patch for 0.20.5. Is there a reason 
this patch hasn’t made it into the main releases? It seems to, at least partly, 
solve a quite major bug.

Re: FOP error log idea

2003-09-08 Thread Glen Mazza

May be a good idea.  Xalan has something similar (it's
the only other class in the package that has its main
Process class, I believe.)

Glen

--- Clay Leeds [EMAIL PROTECTED] wrote:
 Would it be possible and/or would it make sense to
 output the following 
 information at the top of the ERROR/Log?
 
 - fop version
 - jdk version
 - platform on which error occurred (or where FOP is
 being run)
 
 I don't know if there's any other information (total
 RAM; RAM in use by 
 FOP/Java, etc.; RAM available; hard drive space
 available)...
 
 Just a thought!
 
 Web Maestro Clay
 
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, email:
 [EMAIL PROTECTED]
 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

FOP error log idea

2003-09-05 Thread Clay Leeds

Would it be possible and/or would it make sense to output the following 
information at the top of the ERROR/Log?

- fop version
- jdk version
- platform on which error occurred (or where FOP is being run)
I don't know if there's any other information (total RAM; RAM in use by 
FOP/Java, etc.; RAM available; hard drive space available)...

Just a thought!

Web Maestro Clay

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22216] - bug in processMessage(), doesn't work for ERROR

2003-08-14 Thread bugzilla

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=22216.
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=22216

bug in processMessage(), doesn't work for ERROR





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 11:14 ---
A 2nd solution is to stop the processing. 
This may be more useful in many cases. 
I changed org.apache.fop.fo.flow.ExternalGraphic.layout():
...
catch (MalformedURLException urlex) {
  // bad URL
  log.error(Error while creating area :  + urlex.getMessage());
  throw new FOPException (Error while creating area :  + urlex.getMessage());
} 
catch (FopImageException imgex) {
  // image error
  log.error(Error while creating area :  + imgex.getMessage());
  throw new FOPException (Error while creating area :  + imgex.getMessage());
}
...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22216] New: - bug in processMessage(), doesn't work for ERROR

2003-08-09 Thread bugzilla

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=22216.
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=22216

bug in processMessage(), doesn't work for ERROR

   Summary: bug in processMessage(), doesn't work for ERROR
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


processMessage() retrieves no information about errors when images, that are 
included within the xsl, are missing. This error is serious, because it is not 
possible to implement an own logger (extending log4j logger) that overwrites 
the error()-method. We need the information when pictures are missing.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22216] - bug in processMessage(), doesn't work for ERROR

2003-08-08 Thread bugzilla

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=22216.
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=22216

bug in processMessage(), doesn't work for ERROR





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 08:41 ---
An idea to solve the problem: Put some additional actions into the contructors 
of class FopImageException, like this: 

public class FopImageException extends Exception {
public FopImageException() {
super();
//  JUN 2003-08-08 -- appended lines
MessageHandler.error(No message text available. + this.getMessage());
//  JUN 2003-08-08 
}

public FopImageException(String message) {
super(message);
//  JUN 2003-08-08 -- appended lines
MessageHandler.error(message);
//  JUN 2003-08-08 
}

}

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22101] New: - linearGradient render error

2003-08-04 Thread bugzilla

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=22101.
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=22101

linearGradient render error

   Summary: linearGradient render error
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The error described in bug 2909 still exists in FOP 0.20.5. Any idea when this 
issue will be solved?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22101] - linearGradient render error

2003-08-04 Thread bugzilla

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=22101.
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=22101

linearGradient render error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 08:32 ---
This will be solved with the redesign. Progress is slow though, want to lend
a hand?
Anyway, please don't use Bugzilla to ask questions, use the mailing lists.

*** This bug has been marked as a duplicate of 2909 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 2909] - Gradient render error

2003-08-04 Thread bugzilla

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=2909.
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=2909

Gradient render error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 08:32 ---
*** Bug 22101 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21946] - [ERROR] svg graphic could not be built: null when running fop embedded

2003-07-29 Thread bugzilla

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=21946.
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=21946

[ERROR] svg graphic could not be built: null when running fop embedded





--- Additional Comments From [EMAIL PROTECTED]  2003-07-29 12:28 ---
Please upgrade to FOP 0.20.5 and use the Batik version that comes with FOP.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21946] New: - [ERROR] svg graphic could not be built: null when running fop embedded

2003-07-28 Thread bugzilla

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=21946.
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=21946

[ERROR] svg graphic could not be built: null when running fop embedded

   Summary: [ERROR] svg graphic could not be built: null when
running fop embedded
   Product: Fop
   Version: 0.20.4
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: svg
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am having a big problem with fop when trying to use the code below. Whenever
I run it with this code, I get the exceptions listed at the bottom of the
message. Whenever I run it with the commented code instead (using Fop.main), it
runs fine. I figured the problem is because my svg has references such as
'url(#clipPath2)' inside, and the way I am running below is not allowing fop to
resolve these uri's properly, or not finding the path to the input source
either. Is there something I am  missing?

Thanks,
Igor.

  /**
   * Creates the final pdf document
   * @throws Exception in case something goes wrong
   */
  protected void createPDF() throws Exception
  {
Logger logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
org.apache.fop.messaging.MessageHandler.setScreenLogger(logger);

InputHandler inputHandler = new FOInputHandler( new File(
fTempOut.getAbsolutePath() ) );

XMLReader parser = inputHandler.getParser();
   
Driver driver = new Driver();

driver.setLogger(logger);
   
driver.setRenderer(Driver.RENDER_PDF);
driver.setErrorDump(true);

driver.setOutputStream( osDest );

driver.render( parser, inputHandler.getInputSource() );

/*
String args[] = new String[4];
args[0] = -fo;
args[1] = fTempOut.getAbsolutePath();
args[2] = -pdf;
args[3] = /tmp/test.pdf;
org.apache.fop.apps.Fop.main( args );*/
  }

Error dump:

[INFO] building formatting object tree
[INFO] [1]
[INFO] [2]
[INFO] [3]
[INFO] [4]
[INFO] [5]
[ERROR] svg graphic could not be built: null
java.lang.NullPointerException
at java.net.URL.init(URL.java:328)
at java.net.URL.init(URL.java:253)
at java.net.URL.init(URL.java:276)
at org.apache.batik.util.ParsedURLData.buildURL(Unknown Source)
at org.apache.batik.util.ParsedURLData.openStreamInternal(Unknown Source)
at org.apache.batik.util.ParsedURLData.openStream(Unknown Source)
at org.apache.batik.util.ParsedURL.openStream(Unknown Source)
at org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(Unknown
Source)
at org.apache.batik.bridge.DocumentLoader.loadDocument(Unknown Source)
at org.apache.batik.bridge.URIResolver.getNode(Unknown Source)
at org.apache.batik.bridge.URIResolver.getElement(Unknown Source)
at org.apache.batik.bridge.BridgeContext.getReferencedElement(Unknown
Source)
at org.apache.batik.bridge.CSSUtilities.convertClipPath(Unknown Source)
at
org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode(Unknown Source)
... a lot more exceptions

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21946] - [ERROR] svg graphic could not be built: null when running fop embedded

2003-07-28 Thread bugzilla

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=21946.
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=21946

[ERROR] svg graphic could not be built: null when running fop embedded

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-07-29 03:16 ---
Usually best to post to FOP-USER ML first, for guidance, and then submit as a 
bug only when it's apparent the error is with FOP.  That will give you the 
widest possible help for your issue.  It's certainly possible, but less likely 
FOP is in error, given that the command line option works and what you're 
trying to do is quite common. 

Offhand, your declaration of inputHandler to be of type InputHandler (instead 
of FOInputHandler), may be a problem.  Also, check the examples on the 
http://xml.apache.org/fop/embedding.html page, there may be simpler ways of 
doing what you're trying to accomplish.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

error compiling HEAD (need GraphicsConfiguration.java)

2003-07-04 Thread Glen Mazza

I can't compile the CVS - HEAD of FOP.  Unless I've
gotten something wrong, this file:

http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/svg/PDFGraphicsConfiguration.java?rev=1.1content-type=text/vnd.viewcvs-markup

is extending a GraphicsConfiguration.java that
apparently needs to be added to CVS.

Thanks,
Glen

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: error compiling HEAD (need GraphicsConfiguration.java)

2003-07-04 Thread Glen Mazza

Never mind.  xml-fop/src/java-1.4 directory needed
updating.  Had to do a cvs update w/ -d option first.

Glen

--- Glen Mazza [EMAIL PROTECTED] wrote:
 I can't compile the CVS - HEAD of FOP.  Unless I've
 gotten something wrong, this file:
 

http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/svg/PDFGraphicsConfiguration.java?rev=1.1content-type=text/vnd.viewcvs-markup
 
 is extending a GraphicsConfiguration.java that
 apparently needs to be added to CVS.
 
 Thanks,
 Glen
 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20621] New: - getting Error while recovering Image Informations exception with nested Stream closed exception

2003-06-09 Thread bugzilla

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=20621.
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=20621

getting Error while recovering Image Informations exception with nested Stream 
closed exception

   Summary: getting Error while recovering Image Informations
exception with nested Stream closed exception
   Product: Fop
   Version: 0.20.4
  Platform: Other
OS/Version: AIX
Status: NEW
  Severity: Critical
  Priority: Other
 Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We are occasionally generating PDFs that are missing images.  It doesn't happen 
all of the time, and is very difficult to reproduce.  Our logs files display 
the following line:
[ERROR] Error while creating area : Error while recovering Image Informations 
(file:/prod/folio/p1/config/common/img/logo_big.jpg) : Stream closed

The file does exist (and has the necessary file permissions), and most of the 
time it is included on in the PDF without any problems.  We generate a large 
number of PDFs during a batch process when this happens, usually a couple 
hundred of them.  We run 4 threads at once to generate them, all running within 
a shared weblogic context (version 5.1).  I am not sure if this is a threading 
issue or not.  Any ideas how to resolve this?  Or at the very least, are there 
any ways that I can identify when this occurs so that we can at least try and 
regenerate it (the exception is currently just logged, and the report is 
generated without any errors being thrown).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20621] - getting Error while recovering Image Informations exception with nested Stream closed exception

2003-06-09 Thread bugzilla

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=20621.
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=20621

getting Error while recovering Image Informations exception with nested Stream 
closed exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-09 18:51 ---
0.20.4 was not thread safe in this respect. The current version should be a bit
better.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20453] New: - FOP ends with error when xsl:include tag used in xsl

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=20453.
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=20453

FOP ends with error when xsl:include tag used in xsl

   Summary: FOP ends with error when xsl:include tag used in xsl
   Product: Fop
   Version: 0.20.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I put xsl:include href=testinclude.xsl tag in xsl stylesheet, fop ends 
with following error:

[INFO] FOP 0.20.4
[ERROR] null

Fop is used from command prompt:
fop  -xml test.xml -xsl test.xsl -pdf test.pdf

I can send complete examples of test.xsd, if needed.

?xml version=1.0 encoding=UTF-8?
xsl:stylesheet version=1.0 xmlns:fo=http://www.w3.org/1999/XSL/Format; 
xmlns:nsdc=http://www.rtf2fo.com/NSDC; 
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;xsl:template 
match=nsdc:data
fo:root

/fo:root
/xsl:template
xsl:include href=testempty.xsl
/xsl:stylesheet

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20453] - FOP ends with error when xsl:include tag used in xsl

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=20453.
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=20453

FOP ends with error when xsl:include tag used in xsl





--- Additional Comments From [EMAIL PROTECTED]  2003-06-03 15:45 ---
Created an attachment (id=6614)
Examples of xsd and xsl files used for generating PDF

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20453] - FOP ends with error when xsl:include tag used in xsl

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=20453.
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=20453

FOP ends with error when xsl:include tag used in xsl

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-06-03 16:02 ---
This is no FOP problem. Your test.xsl is not well-formed.

Change:
xsl:include href=testempty.xsl

to:
xsl:include href=testempty.xsl/

If you run into problems like this, run the XSL transformation alone (without 
FOP), check for error messages and check if the output from the XSL 
transformation is the output you expect.

More information here: http://xml.apache.org/fop/faq.html#NullPointerException

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 20453] New: - FOP ends with error whenxsl:include tag used in xsl

2003-06-04 Thread Clay Leeds

Howdy!

On 6/3/2003 8:42 AM, [EMAIL PROTECTED] wrote:
[INFO] FOP 0.20.4
[ERROR] null
[..]

?xml version=1.0 encoding=UTF-8?
xsl:stylesheet version=1.0 xmlns:fo=http://www.w3.org/1999/XSL/Format; 
xmlns:nsdc=http://www.rtf2fo.com/NSDC; 
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;xsl:template 
match=nsdc:data
fo:root

/fo:root
/xsl:template
xsl:include href=testempty.xsl
/xsl:stylesheet
Actually, I believe (respectfully) that the bug is in your XSL. First of 
all, the xsl:include tag is not closed (although that may be just a 
typo). 2ndly, according to everywhere I've read, (XML Bible, the XSL 
spec, etc.):

  The xsl:include element is only allowed as a top-level element.

That means it should be something like this:

?xml version=1.0 encoding=UTF-8?
xsl:stylesheet version=1.0 
xmlns:fo=http://www.w3.org/1999/XSL/Format; 
xmlns:nsdc=http://www.rtf2fo.com/NSDC; 
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:include href=testempty.xsl/
xsl:template  match=nsdc:data
fo:root

/fo:root
/xsl:template
/xsl:stylesheet

Hope this helps!

Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 20453] New: - FOP ends with error when xsl:include tag used in xsl

2003-06-04 Thread Jeremias Maerki

Clay,

you need to consider that this guy may not see your answer if he isn't
subscribed to fop-dev. You need post answers in bugzilla which will
automatically send a natification to the reporter.

BTW, it's funny. I also wondered if the xsl:include shouldn't be
top-level. But after I made his text.xsl well-formed (!) the FO got
generated just fine on my machine. Strange.

On 03.06.2003 18:02:11 Clay Leeds wrote:
snip/

 Actually, I believe (respectfully) that the bug is in your XSL. First of 
 all, the xsl:include tag is not closed (although that may be just a 
 typo). 2ndly, according to everywhere I've read, (XML Bible, the XSL 
 spec, etc.):
 
The xsl:include element is only allowed as a top-level element.

snip/


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 20453] New: - FOP ends with error whenxsl:include tag used in xsl

2003-06-04 Thread Clay Leeds

Jeremias,

Thanks for the note! I'll POST it... BTW...

On 6/3/2003 9:09 AM, Jeremias Maerki wrote:
BTW, it's funny. I also wondered if the xsl:include shouldn't be
top-level. But after I made his text.xsl well-formed (!) the FO got
generated just fine on my machine. Strange.
I'm guessing, that it was well-formed however, it probably did not 
validate... at least not if he used a DTD or proper(?) SCHEMA which 
had xsl:include in the proper place (at the top level of xsl:stylseheet).

[OT] This type of well-formed-ness/valid issue bit me in the rear, as I 
was under the impression Internet Explorer validated XML files if a DTD 
were attached. It does *not* (one beta version of 5--or was it 
5.5?--did, but they ended up shipping versions of IE 5+ checking only 
for well-formedness). I ended up getting our programmers (who write the 
code which output the XML which I apply XSL-FO stylesheets to generate 
PDF  print, etc.) to install XMLValidator on their Windows boxen:

http://www.uni-giessen.de/club/misc/xmlvalid101/xmlvalid.html

I could've had them use xalan or some other JAVA tool, but opted for 
this tool as an alternative to my Windows running brethren...
--
Clay Leeds - [EMAIL PROTECTED]
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20453] - FOP ends with error when xsl:include tag used in xsl

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=20453.
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=20453

FOP ends with error when xsl:include tag used in xsl





--- Additional Comments From [EMAIL PROTECTED]  2003-06-03 18:09 ---
Actually, I believe (respectfully) that the bug is in your XSL. First of all,
the xsl:include tag is not closed (although that may be just a typo). 2ndly,
according to everywhere I've read, (XML Bible, the XSL spec, etc.):

  The xsl:include element is only allowed as a top-level element.

That means it should be something like this:

?xml version=1.0 encoding=UTF-8?
xsl:stylesheet version=1.0 xmlns:fo=http://www.w3.org/1999/XSL/Format;
xmlns:nsdc=http://www.rtf2fo.com/NSDC;
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:include href=testempty.xsl/
xsl:template  match=nsdc:data
fo:root

/fo:root
/xsl:template
/xsl:stylesheet

Hope this helps!

Web Maestro Clay

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Error printing from servlet

2003-05-27 Thread BENFATTI




Hi All,

 I was using the attached 
servlet(based in example supplied with FOP) to print some reports. It was 
running OK with Tomcat, but when i changed my aplication server to Oracle 9IAS, 
it is not working anymore.
 The printer is already 
configured in the server.
Does somebodyknow 
what is the problem?

 Thanks,
 Paulo Benfatti


The error generated is:


500 Internal Server Errororg.apache.fop.apps.FOPException: Unable to print: java.awt.print.PrinterException: No printer found.
	at org.apache.fop.apps.Driver.render(Driver.java:462)
	at org.apache.fop.apps.Driver.run(Driver.java:524)
	at FopPrintServlet.renderFO(Unknown Source)
	at FopPrintServlet.doGet(Unknown Source)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
	at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:283)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:560)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:306)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:767)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:148)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:72)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803)
	at java.lang.Thread.run(Thread.java:479)
-
java.io.IOException: Unable to print: java.awt.print.PrinterException: No printer found.
	at org.apache.fop.apps.StreamRenderer.stopRenderer(StreamRenderer.java:157)
	at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:200)
	at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:269)
	at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:147)
	at org.apache.fop.apps.Driver.render(Driver.java:457)
	at org.apache.fop.apps.Driver.run(Driver.java:524)
	at FopPrintServlet.renderFO(Unknown Source)
	at FopPrintServlet.doGet(Unknown Source)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
	at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:283)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:560)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:306)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:767)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:148)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:72)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803)
	at java.lang.Thread.run(Thread.java:479)
java.io.IOException: Unable to print: java.awt.print.PrinterException: No printer found.
	at FopPrintServlet$PrintRenderer.stopRenderer(Unknown Source)
	at org.apache.fop.apps.StreamRenderer.stopRenderer(StreamRenderer.java:152)
	at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:200)
	at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:269)
	at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:147)
	at org.apache.fop.apps.Driver.render(Driver.java:457)
	at org.apache.fop.apps.Driver.run(Driver.java:524)
	at FopPrintServlet.renderFO(Unknown Source)
	at FopPrintServlet.doGet(Unknown Source)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
	at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:283)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:560)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:306)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:767)
	at com.evermind[Oracle9iAS (9.0.3.0.0) Containers

DO NOT REPLY [Bug 18559] - Not enough error messages (Marformed format string)

2003-04-01 Thread bugzilla

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=18559.
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=18559

Not enough error messages (Marformed format string)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-04-01 11:10 ---
This is a Xalan problem. Try running the XSL transformation only (without FOP).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

email virus error

2003-03-20 Thread Drake, Mark

Has anyone ever seen a situation where a pdf created using FOP and 
xsl:fo is sent in an email directly from Internet Explorer (File - Send 
- Page by Email), and the recipient gets this email virus warning when 
they receive the email?

Found virus EMail_Flaw_MIME_Tag_Overflow in file
The file is deleted.

When the pdf is saved locally, then emailed, it works fine.  I am using Apache version 
0.20.2.

Thanks for your help,

Mark Drake
Principal Financial Group


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18058] New: - Error fetching Image from URL

2003-03-17 Thread bugzilla

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=18058.
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=18058

Error fetching Image from URL

   Summary: Error fetching Image from URL
   Product: Fop
   Version: 0.20.4
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In our production environment we create images for userdefined advertisements 
on the fly. The path to the stored images depends on the user input. That means 
if the user has an order with key: MyOrder#001 the produced image will be 
stored in ..some_path/MyOrder#001/MyAdPict01.eps

If the (relative) path to an Image contains a '#' the Image will not be found 
due to the URL is constructed in FOPImageFactory (line:111) as followed: 
new URL( Configuration.getStringValue( baseDir ) + absoluteURL.getFile() )

The URL , created before, has interpreted the content after the '#' as a anchor 
reference and this information will be lost on constructing the new URL so that 
the Image will never appear in the output.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Wrong operand type error in ASV 3.0

2003-03-02 Thread Swapan Golla

The error still persists even after I changed the
width to 1.

Swapan.


--- Keiron Liddle [EMAIL PROTECTED] wrote:
 
  !-- If I remove this line, everything seems to
 work
  fine --
  svg:line x1=58 y1=179 x2=403 y2=179
  stroke=#00 stroke-
  width=0.5 /
 
 IIRC It is probably an error caused by this line
 being 0.5 width. In PDF lines can 
 only be whole numbers and it might wrongly be
 inserting 0.5 in the PDF causing 
 the error.
 Try making it width 1.
 
 If you need a 0.5 width line it can be scaled.
 
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, email:
 [EMAIL PROTECTED]
 


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Wrong operand type error in ASV 3.0

2003-02-27 Thread Swapan Golla

Hi All,
I have written a small svg document and embedding this
svg 
document in an FO document to covert to pdf. I guess
the FOP 
completely depends on batik for SVG2PDF conversion.
When I try to 
open the resulting pdf, it says wrong operand type.
Can anybody help ?

Thanks in advance,
Swapan.

?xml version=1.0 encoding=UTF-8?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
fo:layout-master-set
fo:simple-page-master
margin-right=1.5cm
margin-left=1.5cm
margin-bottom=2cm
margin-top=1cm
page-width=21cm
page-height=29.7cm
master-name=first
fo:region-body margin-top=0cm margin-bottom=0cm/
fo:region-before extent=0cm/
fo:region-after extent=0cm/
/fo:simple-page-master
/fo:layout-master-set

fo:page-sequence master-reference=first
fo:static-content flow-name=xsl-region-before
fo:block line-height=14pt font-size=10pt
text-align=endEmbedding SVG examples/fo:block
/fo:static-content
fo:static-content flow-name=xsl-region-after
fo:block line-height=14pt font-size=10pt
text-align=endPage fo:page-number//fo:block
/fo:static-content

fo:flow flow-name=xsl-region-body
fo:block
fo:instream-foreign-object


svg:svg width=16.1925cm height=20.955cm
viewBox=0 0 8.5 11 
version=1.1 xmlns:svg=http://www.w3.org/2000/svg;
svg:g transform=matrix(1 0 0 1 0 0)
/svg:g
svg:g transform=matrix(0.01041667 0 0 0.01041667 0
0)
svg:text x=48 y=108 font-family=Times New Roman
font-
size=20pt font-weight=bold fill=#00
stroke=none text-
anchor=start 
svg:tspan x=48 y=108 textLength=57
ABC/svg:tspan
svg:tspan x=116 y=108 textLength=114
Company/svg:tspan
/svg:text
svg:text x=628 y=66.53516 font-family=Times New
Roman font-
size=15.6pt fill=#00 stroke=none
text-anchor=start 
svg:tspan x=628 y=66.53516 O/svg:tspan
/svg:text
svg:text x=644 y=66.53516 font-family=Times New
Roman font-
size=12pt fill=#00 stroke=none
text-anchor=start 
svg:tspan x=644 y=66.53516 textLength=107 
RGANIZATION/svg:tspan
/svg:text
!-- If I remove this line, everything seems to work
fine --
svg:line x1=58 y1=179 x2=403 y2=179
stroke=#00 stroke-
width=0.5 /

/svg:g
/svg:svg

/fo:instream-foreign-object
/fo:block 
/fo:flow
/fo:page-sequence
/fo:root


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Wrong operand type error in ASV 3.0

2003-02-27 Thread Keiron Liddle


 !-- If I remove this line, everything seems to work
 fine --
 svg:line x1=58 y1=179 x2=403 y2=179
 stroke=#00 stroke-
 width=0.5 /

IIRC It is probably an error caused by this line being 0.5 width. In PDF lines can 
only be whole numbers and it might wrongly be inserting 0.5 in the PDF causing 
the error.
Try making it width 1.

If you need a 0.5 width line it can be scaled.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16996] New: - build.bat script fails with javac error.

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=16996.
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=16996

build.bat script fails with javac error.

   Summary: build.bat script fails with javac error.
   Product: Fop
   Version: 0.20.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The Ant build script for FOP 0.20.4 (when run via the provided 'build.bat') 
file, failed in the compile target with two javac compiler errors.  The 
distribution in question was from http://xml.apache.org/dist/fop/fop-0.20.4-
src.tar.gz (i.e the current stable source release).

Detail from download page:
fop-0.20.4-src.tar.gz  08-Jul-2002 04:52  7.8M  FOP downloads

The compile problem is that the PDFGraphicsConfiguration class is being 
instantiated (new) when it is abstract.  This in turn seems to be caused by the 
fact the PDFGraphicsConfiguration is extending GraphicsConfiguration but not 
implementing createCompatibleVolatileImage().

This is a bit odd, since you'd expect that this is the sort of problem that 
would prevent the distribution from ever compiling.  Surely someone has 
downloaded and compiled this sucessfully?

Thought: could this be a CLASSPATH problem?  Maybe with two versions of that 
class in the build path?  (However build.bat seems to configure the CLASSPATH 
for the build, so this seems unlikely.)  Alternatively, is the bundled version 
of Batik the right one?

Ant output shown below (javac errors at bottom):

C:\java\fop-0.20.4build.bat
Fop Build System

Building with classpath c:\java\j2sdk1.4.1\lib\tools.jar;c:\java\j2sdk1.4.1\lib\
classes.zip;lib\ant-1.4.1.jar;lib\batik.jar;lib\buildtools.jar;lib\xercesImpl-2.
0.1.jar;lib\xml-apis.jar;lib\xalan-2.3.1.jar;lib\bsf.jar;lib\jimi-1.0.jar;lib\av
alon-framework-cvs-20020315.jar
Starting Ant...
Buildfile: build.xml

init-avail:

init-filters-xalan2:

init:
 [echo] --- Fop 0.20.4 [1999-2002] 

prepare:
 [echo] Preparing the build directories
[mkdir] Created dir: C:\java\fop-0.20.4\build\src\org\apache\fop\fo\properti
es
[mkdir] Created dir: C:\java\fop-0.20.4\build\src\org\apache\fop\render\pdf\
fonts
[mkdir] Created dir: C:\java\fop-0.20.4\build\src\org\apache\fop\svg
[mkdir] Created dir: C:\java\fop-0.20.4\build\classes\conf
[mkdir] Created dir: C:\java\fop-0.20.4\build\classes\hyph
 [copy] Copying 3 files to C:\java\fop-0.20.4\build\classes\conf

codegen:
 [echo] Resetting codegen directory
 [copy] Copying 37 files to C:\java\fop-0.20.4\build\src\codegen
 [echo] Generating the java files from xml resources
[style] Processing C:\java\fop-0.20.4\build\src\codegen\allprops.xml to C:\j
ava\fop-0.20.4\build\src\org\apache\fop\fo\properties\Constants.java
[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\genconst.xsl

[style] Processing C:\java\fop-0.20.4\build\src\codegen\foproperties.xml to
C:\java\fop-0.20.4\build\src\org\apache\fop\fo\properties\fo_ignore_this.java
[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\properties.x
sl
[style] Processing C:\java\fop-0.20.4\build\src\codegen\foproperties.xml to
C:\java\fop-0.20.4\build\src\org\apache\fop\fo\properties\FOPropertyMapping.java

[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\propmap.xsl
[style] Processing C:\java\fop-0.20.4\build\src\codegen\foproperties.xml to
C:\java\fop-0.20.4\build\src\org\apache\fop\fo\properties\foenums_ignore_this.ja
va
[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\enumgen.xsl
[style] Processing C:\java\fop-0.20.4\build\src\codegen\extproperties.xml to
 C:\java\fop-0.20.4\build\src\org\apache\fop\fo\properties\ExtensionPropertyMapp
ing.java
[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\propmap.xsl
[style] Processing C:\java\fop-0.20.4\build\src\codegen\encodings.xml to C:\
java\fop-0.20.4\build\src\org\apache\fop\render\pdf\CodePointMapping.java
[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\code-point-m
apping.xsl
[style] Processing C:\java\fop-0.20.4\build\src\codegen\Courier.xml to C:\ja
va\fop-0.20.4\build\src\org\apache\fop\render\pdf\fonts\Courier.java
[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\font-file.xs
l
[style] Processing C:\java\fop-0.20.4\build\src\codegen\Courier-Oblique.xml
to C:\java\fop-0.20.4\build\src\org\apache\fop\render\pdf\fonts\CourierOblique.j
ava
[style] Loading stylesheet C:\java\fop-0.20.4\build\src\codegen\font-file.xs
l
[style] Processing C:\java\fop

DO NOT REPLY [Bug 16996] - build.bat script fails with javac error.

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=16996.
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=16996

build.bat script fails with javac error.





--- Additional Comments From [EMAIL PROTECTED]  2003-02-12 14:24 ---
Follow-up note: I worked around the problem - at least as far as getting a 
completed build is concerned - by providing an 'implemention' of this method in 
org.apache.fop.svg.PDFGraphicsConfiguration.  However, I've just made this 
method return null, so this may cause further problem later.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16996] - build.bat script fails with javac error.

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=16996.
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=16996

build.bat script fails with javac error.





--- Additional Comments From [EMAIL PROTECTED]  2003-02-12 14:56 ---
Does not occur with source for fop-0.20.5rc downloaded from previously 
mentioned distribution page, only fop-0.20.4.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16996] - build.bat script fails with javac error.

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=16996.
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=16996

build.bat script fails with javac error.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-02-12 14:59 ---
This is a problem with JDK 1.4.
Please use FOP 0.20.5

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16713] New: - Hyphenation error in tables

2003-02-03 Thread bugzilla

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=16713.
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=16713

Hyphenation error in tables

   Summary: Hyphenation error in tables
   Product: Fop
   Version: 0.20.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: page-master/layout
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When using soft-hyphenation in tables in order to fit text in columns, the 
hyphenation has no effect. Thus resulting in text floating over cells.

In general it doesn't seem that there's any handling for text floating over 
cells.

Regards, Mathias

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16713] - Hyphenation error in tables

2003-02-03 Thread bugzilla

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=16713.
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=16713

Hyphenation error in tables





--- Additional Comments From [EMAIL PROTECTED]  2003-02-03 15:42 ---
Created an attachment (id=4687)
Example xml-file

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16713] - Hyphenation error in tables

2003-02-03 Thread bugzilla

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=16713.
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=16713

Hyphenation error in tables





--- Additional Comments From [EMAIL PROTECTED]  2003-02-03 15:44 ---
Created an attachment (id=4688)
Example xsl-file

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

SVG size error in PDFRenderer

2003-02-03 Thread Christer Sandberg

Hi, the size of SVG is wrong when rendered by
org.apache.fop.render.pdf.PDFRenderer in FOP 0.20.4. The method
renderSVGDocument uses BridgeContext.getDocumentSize().getWidth() etc,
which returns an integer instead of a float. This works fine when
rendering to PostScript but not to PDF. I looked at the FOP 0.20.1
sources (which we're currently using) and there the size was fetched via
SVGSVGElement.getWidth().getBaseVal().getValue() and this seem to work
fine when used in FOP 0.20.4 after some initial tests. I'm not very
familiar with the code so hopefully someone at this list has some good
answers to this behaviour.

Thanx, Christer.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16626] New: - Hyphenation causing java.io.IOException error

2003-01-30 Thread bugzilla

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=16626.
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=16626

Hyphenation causing java.io.IOException error

   Summary: Hyphenation causing java.io.IOException error
   Product: Fop
   Version: 0.20.4
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The behavior of setting hyphenation to true seems a little buggy with double 
quote character (quot;)

fo:block hyphenate=true hyphenation-push-character-count=2 hyphenation-
remain-character-count=2 language=envalue/fo:block

Problem 1:
--
If value is 80070 - CASH:HOTL TRANS/CTM quot;PALMSTAR ROSEquot;, it did 
hyphenate properly, but put the quote in the wrong place. The value was 
displayed as 

80070 - CASH:HOTL TRANS/CTM PALM-
STAR ROSE

Notice that the quote has moved to enclose STAR ROSE and not PALMSTAR ROSE.

Problem 2:
-
This is a more serious one as it causes a java.io.IOException

Try a value of 80070 - CASH:HOTL TRANS/CTM quot;ASOPOSquot; for a table-
cell of width 171pt. It caused the exception, it seems like the no. of chars 
remaining is 2 or less and it being a quot is problematic. As introducing a few 
more characters in the above value or taking out the quotes seemed to work fine.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 12565] - Embedding SVG tags like font-face causes error message and will be ignored

2003-01-26 Thread bugzilla

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=12565.
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=12565

Embedding SVG tags like font-face causes error message and will be ignored

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-01-26 20:34 ---
*** Bug 16430 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16318] New: - NoSuchMethod - Error when embedding SVG

2003-01-22 Thread bugzilla

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=16318.
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=16318

NoSuchMethod - Error when embedding SVG

   Summary: NoSuchMethod - Error when embedding SVG
   Product: Fop
   Version: 0.20.4
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Embedding a simple SVG:
fo:block
fo:external-graphic src=w:/vw-bank/prj/Onlinekontoauszug/images/Test.svg 
width=82.6mm height=28.7mm/
/fo:block

Test.svg:
?xml version=1.0 standalone=yes?
svg width=583 height=360
rect x=10 y=10 width=30 height=30 fill=blue/ 
/svg

I obtain:
java.lang.NoSuchMethodError: org.apache.batik.bridge.UnitProcessor.createContext
(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)
Lorg/apache/batik/util/UnitProcessor$Context;
at org.apache.fop.image.analyser.SVGReader.loadImage(Unknown Source)
at org.apache.fop.image.analyser.SVGReader.verifySignature(Unknown 
Source)
at org.apache.fop.image.analyser.ImageReaderFactory.Make(Unknown Source)
at org.apache.fop.image.FopImageFactory.Make(Unknown Source)

I include the Batik version 1.1.1. All classes are in the classpath.
Is createContext a static Method?

Regards,

Joachim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16318] - NoSuchMethod - Error when embedding SVG

2003-01-22 Thread bugzilla

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=16318.
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=16318

NoSuchMethod - Error when embedding SVG

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-22 11:25 ---
You must use the Batik jar from the FOP distribution. I think in case of the
0.20.4 it is *not* 1.1.1 but some 1.5 beta release.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16318] - NoSuchMethod - Error when embedding SVG

2003-01-22 Thread bugzilla

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=16318.
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=16318

NoSuchMethod - Error when embedding SVG





--- Additional Comments From [EMAIL PROTECTED]  2003-01-22 11:57 ---
Thank You! It works with batik from fop distribution.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 4569] - FOP 0.20.1 : Error while loading TTF fonts for PDF rendering

2003-01-09 Thread bugzilla

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=4569.
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=4569

FOP 0.20.1 : Error while loading TTF fonts for PDF rendering

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-09 13:01 ---
This is fixed now in the redesign.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14765] New: - Error using IE5

2002-11-22 Thread bugzilla

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=14765.
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=14765

Error using IE5

   Summary: Error using IE5
   Product: Fop
   Version: 0.20.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When using FOP and fo file to convert into PDF using Internet Explorer 5 I get 
a blank page.

Any ideas?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 11838] - Error when use a user configuartion font file in embedded FOP

2002-11-21 Thread bugzilla

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=11838.
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=11838

Error when use a user configuartion font file in embedded FOP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 17:04 ---


*** This bug has been marked as a duplicate of 14319 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6238] - Error when opening pdf in acrobat reader

2002-11-19 Thread bugzilla

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=6238.
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=6238

Error when opening pdf in acrobat reader

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-19 18:02 ---
Probably broken font file, try another one or send it to me privately and I'll
check it out.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6539] - Poor error recovery from invalid FO; wrong exit status

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=6539.
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=6539

Poor error recovery from invalid FO; wrong exit status

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 17:55 ---
System.exit stuff fixed already and the rest is a dublicate of the bug #5010.

*** This bug has been marked as a duplicate of 5010 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 5010] - Better error reporting needed

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=5010.
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=5010

Better error reporting needed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 17:55 ---
*** Bug 6539 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 4569] - FOP 0.20.1 : Error while loading TTF fonts for PDF rendering

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=4569.
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=4569

FOP 0.20.1 : Error while loading TTF fonts for PDF rendering

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 22:37 ---
I'm not sure what class are you talking about, but at least 0.20.5cvs version of
org.apache.fop.fonts.FontFileReader reads file using 2048 bytes buffer. I'll
close the bug, but if you are still experiencing the problem, feel free to
reopen it and provide more detailed explanation.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 4569] - FOP 0.20.1 : Error while loading TTF fonts for PDF rendering