date:20090403

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

2009-04-03 Thread Vincent Hennebert

Hi,

 Author: jeremias
 Date: Fri Apr  3 07:44:09 2009
 New Revision: 761554
 
 URL: http://svn.apache.org/viewvc?rev=761554view=rev
 Log:
 Fixed a bug that left the PrintRenderer unconfigured even if a configuration 
 was specified for application/X-fop-print. 
 
snip/
 +/** {...@inheritdoc} */
 +public String getMimeType() {
 +return MimeConstants.MIME_FOP_PRINT;
 +}
 +

This method is defined in AbstractRenderer to return null. That makes me
wonder: is there a use case where you can expect a renderer to return
a null mime type?
The answer probably is no, in which case the definition of this method
should be removed from AbstractRenderer. That would force concrete
classes to implement a sensible getMimeType method and prevent this kind
of bug from occurring.
If I do it, the only class that no longer compiles is PageableRenderer.
Given that it is sub-classed by PrintRenderer and its constructor is not
called by external classes, I guess it can be made abstract.

Is that ok if I apply such changes?
Thanks,
Vincent

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

2009-04-03 Thread Adrian Cumiskey

Your suggestion sounds sensible enough to me (without having found time 
to take a look at the code), +1.


Adrian.

Vincent Hennebert wrote:

Hi,

  

Author: jeremias
Date: Fri Apr  3 07:44:09 2009
New Revision: 761554

URL: http://svn.apache.org/viewvc?rev=761554view=rev
Log:
Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for application/X-fop-print. 



snip/
  

+/** {...@inheritdoc} */
+public String getMimeType() {
+return MimeConstants.MIME_FOP_PRINT;
+}
+



This method is defined in AbstractRenderer to return null. That makes me
wonder: is there a use case where you can expect a renderer to return
a null mime type?
The answer probably is no, in which case the definition of this method
should be removed from AbstractRenderer. That would force concrete
classes to implement a sensible getMimeType method and prevent this kind
of bug from occurring.
If I do it, the only class that no longer compiles is PageableRenderer.
Given that it is sub-classed by PrintRenderer and its constructor is not
called by external classes, I guess it can be made abstract.

Is that ok if I apply such changes?
Thanks,
Vincent

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

2009-04-03 Thread Jeremias Maerki

Hi Vincent,

Removing getMimeType() on AbstractRenderer is ok although that could
break someone else's renderer (risk very slim). But I'd rather move the
getMimeType() implementation from PrintRenderer to PageableRenderer.
That alone doesn't solve Rey's problem but get one step closer. I'll do
that if you don't mind.

On 03.04.2009 11:40:20 Vincent Hennebert wrote:
 Hi,
 
  Author: jeremias
  Date: Fri Apr  3 07:44:09 2009
  New Revision: 761554
  
  URL: http://svn.apache.org/viewvc?rev=761554view=rev
  Log:
  Fixed a bug that left the PrintRenderer unconfigured even if a 
  configuration was specified for application/X-fop-print. 
  
 snip/
  +/** {...@inheritdoc} */
  +public String getMimeType() {
  +return MimeConstants.MIME_FOP_PRINT;
  +}
  +
 
 This method is defined in AbstractRenderer to return null. That makes me
 wonder: is there a use case where you can expect a renderer to return
 a null mime type?
 The answer probably is no, in which case the definition of this method
 should be removed from AbstractRenderer. That would force concrete
 classes to implement a sensible getMimeType method and prevent this kind
 of bug from occurring.
 If I do it, the only class that no longer compiles is PageableRenderer.
 Given that it is sub-classed by PrintRenderer and its constructor is not
 called by external classes, I guess it can be made abstract.
 
 Is that ok if I apply such changes?
 Thanks,
 Vincent




Jeremias Maerki

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

2009-04-03 Thread Jeremias Maerki

Hi,

I've been asked to do an estimate on implementing rounded borders in FOP.
I've put the technical part of my investigation on the Wiki for those
who are interested. There are not plans as of yet, I'm just trying to
get a feel for the amount of work necessary. Thoughts welcome.

On 03.04.2009 12:25:00 Apache Wiki wrote:
 Dear Wiki user,
 
 You have subscribed to a wiki page or wiki category on Xmlgraphics-fop Wiki 
 for change notification.
 
 The following page has been changed by JeremiasMaerki:
 http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
 
 The comment on the change is:
 Some thoughts on rounded borders (no concrete plans, yet)
 
 New page:
snip/


Jeremias Maerki

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

2009-04-03 Thread Vincent Hennebert

Hi Jeremias,

Jeremias Maerki wrote:
 Hi Vincent,
 
 Removing getMimeType() on AbstractRenderer is ok although that could
 break someone else's renderer (risk very slim). But I'd rather move the
 getMimeType() implementation from PrintRenderer to PageableRenderer.
 That alone doesn't solve Rey's problem but get one step closer. I'll do
 that if you don't mind.

Sounds good, thanks.
BTW, I’ve just noticed that the javadoc of Renderer.getMimeType()
explicitly states that the returned value may be null.
Does it still apply today? Can we reasonably expect a renderer not to
return any mime type?

Vincent


 On 03.04.2009 11:40:20 Vincent Hennebert wrote:
 Hi,

 Author: jeremias
 Date: Fri Apr  3 07:44:09 2009
 New Revision: 761554

 URL: http://svn.apache.org/viewvc?rev=761554view=rev
 Log:
 Fixed a bug that left the PrintRenderer unconfigured even if a 
 configuration was specified for application/X-fop-print. 

 snip/
 +/** {...@inheritdoc} */
 +public String getMimeType() {
 +return MimeConstants.MIME_FOP_PRINT;
 +}
 +
 This method is defined in AbstractRenderer to return null. That makes me
 wonder: is there a use case where you can expect a renderer to return
 a null mime type?
 The answer probably is no, in which case the definition of this method
 should be removed from AbstractRenderer. That would force concrete
 classes to implement a sensible getMimeType method and prevent this kind
 of bug from occurring.
 If I do it, the only class that no longer compiles is PageableRenderer.
 Given that it is sub-classed by PrintRenderer and its constructor is not
 called by external classes, I guess it can be made abstract.

 Is that ok if I apply such changes?
 Thanks,
 Vincent
 
 
 
 
 Jeremias Maerki

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

2009-04-03 Thread Jeremias Maerki

Hi Vincent,

well, the print renderer doesn't really have an official MIME type.
The result could be paper, PDF, PostScript or whatever. I've given it a
pseudo MIME type application/X-fop-print just so configuration works
for this renderer, too. So it really depends how you look at it.

But I've just noticed that there's another renderer that really doesn't
have a MIME type: Java2DRenderer. So, if anyone subclassed
Java2DRenderer to paint pages in their own Swing application they are
going to find themselves with a compile error next time they upgrade.
Actually a reason to put the getMimeType() back in AbstractRenderer.
However, they have to implement getMimeType() anyway if they want to
configure the renderer through the XML configuration so probably no harm
done.

On 03.04.2009 12:31:32 Vincent Hennebert wrote:
 Hi Jeremias,
 
 Jeremias Maerki wrote:
  Hi Vincent,
  
  Removing getMimeType() on AbstractRenderer is ok although that could
  break someone else's renderer (risk very slim). But I'd rather move the
  getMimeType() implementation from PrintRenderer to PageableRenderer.
  That alone doesn't solve Rey's problem but get one step closer. I'll do
  that if you don't mind.
 
 Sounds good, thanks.
 BTW, I’ve just noticed that the javadoc of Renderer.getMimeType()
 explicitly states that the returned value may be null.
 Does it still apply today? Can we reasonably expect a renderer not to
 return any mime type?
 
 Vincent
 
 
  On 03.04.2009 11:40:20 Vincent Hennebert wrote:
  Hi,
 
  Author: jeremias
  Date: Fri Apr  3 07:44:09 2009
  New Revision: 761554
 
  URL: http://svn.apache.org/viewvc?rev=761554view=rev
  Log:
  Fixed a bug that left the PrintRenderer unconfigured even if a 
  configuration was specified for application/X-fop-print. 
 
  snip/
  +/** {...@inheritdoc} */
  +public String getMimeType() {
  +return MimeConstants.MIME_FOP_PRINT;
  +}
  +
  This method is defined in AbstractRenderer to return null. That makes me
  wonder: is there a use case where you can expect a renderer to return
  a null mime type?
  The answer probably is no, in which case the definition of this method
  should be removed from AbstractRenderer. That would force concrete
  classes to implement a sensible getMimeType method and prevent this kind
  of bug from occurring.
  If I do it, the only class that no longer compiles is PageableRenderer.
  Given that it is sub-classed by PrintRenderer and its constructor is not
  called by external classes, I guess it can be made abstract.
 
  Is that ok if I apply such changes?
  Thanks,
  Vincent
  
  
  
  
  Jeremias Maerki




Jeremias Maerki

DO NOT REPLY [Bug 46960] New: Minor bug with fo:marker

2009-04-03 Thread bugzilla

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

   Summary: Minor bug with fo:marker
   Product: Fop
   Version: 1.0dev
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: minor
  Priority: P4
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: bowditch_ch...@hotmail.com


Created an attachment (id=23438)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23438)
Sample to demonstrate the bug

When a document sets and clears markers in order to display headers on some
pages and not others, an empty marker element fails to clear the marker. This
is more easily explained with an example. So I have attached the example FO. In
this example there are 3 pages, with the marker retrieved to the header. The
marker is cleared on the first page, set on page 2 and cleared on page 3. So I
only expect the Continued text to appear in the header of page but it also
appears on page 3 as well.

Changing fo:marker marker-class-name=Continued/ to

fo:marker marker-class-name=Continuedfo:block/fo:block/fo:marker

solves the problem, but this is a bug that ought to be fixed.

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

DO NOT REPLY [Bug 46960] Minor bug with fo:marker

2009-04-03 Thread bugzilla

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





--- Comment #1 from Chris Bowditch bowditch_ch...@hotmail.com  2009-04-03 
06:18:11 PST ---
Just noticed a mistake in the description the number 2 is missing from after
the word page when describing where the Continued text is expected to appear.

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

DO NOT REPLY [Bug 46962] New: Deadlock in PropertyCache class

2009-04-03 Thread bugzilla

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

   Summary: Deadlock in PropertyCache class
   Product: Fop
   Version: 0.95
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: ro...@devexperts.com


I have a multithreaded rendering application. Shortly after we had migrated to
some nice smooth and very fast hardware, we started getting Java deadlocks in
FOP code. Stack traces always looked like this one:

T4-CFD_MR accId=3065 prio=10 tid=0x2aab37aa1400 nid=0x6123 waiting for
monitor entry [0x4193e000..0x41941ac0]
   java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.fop.fo.properties.PropertyCache.get(PropertyCache.java:204)
- waiting to lock 0x2aaab388a3f8 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:283)
at
org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:301)
at
org.apache.fop.fo.properties.NumberProperty.getInstance(NumberProperty.java:120)
at
org.apache.fop.fo.expr.PropertyParser.parsePrimaryExpr(PropertyParser.java:262)
at
org.apache.fop.fo.expr.PropertyParser.parseUnaryExpr(PropertyParser.java:212)
at
org.apache.fop.fo.expr.PropertyParser.parseMultiplicativeExpr(PropertyParser.java:177)
at
org.apache.fop.fo.expr.PropertyParser.parseAdditiveExpr(PropertyParser.java:151)
at
org.apache.fop.fo.expr.PropertyParser.parseArgs(PropertyParser.java:378)
at
org.apache.fop.fo.expr.PropertyParser.parsePrimaryExpr(PropertyParser.java:343)
at
org.apache.fop.fo.expr.PropertyParser.parseUnaryExpr(PropertyParser.java:212)
at
org.apache.fop.fo.expr.PropertyParser.parseMultiplicativeExpr(PropertyParser.java:177)
at
org.apache.fop.fo.expr.PropertyParser.parseAdditiveExpr(PropertyParser.java:151)
at
org.apache.fop.fo.expr.PropertyParser.parseProperty(PropertyParser.java:125)



T3-CFD_MR accId=3031 prio=10 tid=0x2aab37a68800 nid=0x6122 waiting for
monitor entry [0x4183c000..0x41840c40]
   java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:226)
- waiting to lock 0x2aaab388a650 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:228)
- locked 0x2aaab388b200 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:228)
- locked 0x2aaab388b228 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:228)
- locked 0x2aaab388b250 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:228)
- locked 0x2aaab388b278 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:228)
- locked 0x2aaab388b2a0 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:228)
- locked 0x2aaab388b368 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.rehash(PropertyCache.java:228)



T2-CFD_MR accId=2823 prio=10 tid=0x2aab37a66c00 nid=0x6121 waiting for
monitor entry [0x4173c000..0x4173fbc0]
   java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.fop.fo.properties.PropertyCache.cleanSegment(PropertyCache.java:114)
- waiting to lock 0x2aaab38a33b8 (a [Z)
at
org.apache.fop.fo.properties.PropertyCache.put(PropertyCache.java:176)
- locked 0x2aaab388a650 (a
org.apache.fop.fo.properties.PropertyCache$CacheSegment)
at
org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:287)
at
org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:301)
at
org.apache.fop.fo.properties.NumberProperty.getInstance(NumberProperty.java:120)
at
org.apache.fop.fo.expr.PropertyParser.parsePrimaryExpr(PropertyParser.java:262)
at
org.apache.fop.fo.expr.PropertyParser.parseUnaryExpr(PropertyParser.java:212)
at
org.apache.fop.fo.expr.PropertyParser.parseMultiplicativeExpr(PropertyParser.java:177)
at
org.apache.fop.fo.expr.PropertyParser.parseAdditiveExpr(PropertyParser.java:151)
at
org.apache.fop.fo.expr.PropertyParser.parseArgs(PropertyParser.java:378)

DO NOT REPLY [Bug 46962] Deadlock in PropertyCache class

2009-04-03 Thread bugzilla

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





--- Comment #1 from Andreas L. Delmelle adelme...@apache.org  2009-04-03 
11:53:01 PST ---

Thanks for the report. We will investigate this closer ASAP. 
For now, the only immediate relief would be to switch to FOP Trunk, which
allows to disable the PropertyCache via a system property
org.apache.fop.fo.properties.use-cache. Set it to false to avoid caching.
The drawback is obviously that the processes will all use up more memory (the
difference can be quite significant if you have a lot of identical
property-specs on a lot of FOs).

For the rest, it would also be interesting to know more about the environment. 
Which Java VM (vendor + version) are you using? If it's GNU Classpath, I'd
first try if switching to a Sun VM  helps.

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

DO NOT REPLY [Bug 46962] Deadlock in PropertyCache class

2009-04-03 Thread bugzilla

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





--- Comment #2 from Andreas L. Delmelle adelme...@apache.org  2009-04-03 
12:20:07 PST ---
(In reply to comment #1)

Just to be complete:

 For now, the only immediate relief would be to switch to FOP Trunk, ...

The addition of the system property to disable caching of the properties
apparently never made it into 0.95, but the required modifications are pretty
straightforward:
- add a 'useCache' member to PropertyCache
- in the constructor, initialize it to reflect the value of the system property
- in the generic, private fetch() method, if useCache is true, bypass the
entire method body, and simply return the parameter instance

Apart from that, no easy solution I'm afraid. It comes down to choosing the
lesser of two 'evils': 
* either use the Trunk version, which means, strictly speaking, no guarantees
about stability, although there are people who do use it in production
environments
* or modify the sources in the 0.95 branch, which also leaves you with an
unofficial version.

Again, we'll be look into it closer soon, but these types of issues are almost
always very difficult to reproduce...

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

DO NOT REPLY [Bug 46486] page-position=last causes blocks with span=all to disappear

2009-04-03 Thread bugzilla

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


Andreas L. Delmelle adelme...@apache.org changed:

   What|Removed |Added

  Attachment #23090|0   |1
is obsolete||




--- Comment #8 from Andreas L. Delmelle adelme...@apache.org  2009-04-03 
14:41:35 PST ---
Created an attachment (id=23440)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23440)
Minimized sample file that demonstrates the issue

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

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

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

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml

DO NOT REPLY [Bug 46960] New: Minor bug with fo:marker

DO NOT REPLY [Bug 46960] Minor bug with fo:marker

DO NOT REPLY [Bug 46962] New: Deadlock in PropertyCache class

DO NOT REPLY [Bug 46962] Deadlock in PropertyCache class

DO NOT REPLY [Bug 46962] Deadlock in PropertyCache class

DO NOT REPLY [Bug 46486] page-position=last causes blocks with span=all to disappear

12 matches

Site Navigation

Mail list logo

Footer information