headers
Andreas L Delmelle | 1 Dec 2007 22:19
Picon

Re: Property Cache: Null Pointer Exception

On Nov 27, 2007, at 20:06, Andreas L Delmelle wrote:

Hi Chris (and other interested parties)

> On Nov 27, 2007, at 18:32, Chris Bowditch wrote:
>
>> Andreas L Delmelle wrote:
>>
>>> Cannot reproduce it here...
>>
>> Strange. The patch is definitely applied and I tried building it  
>> twice just to make sure. The second time it run and generated  
>> about 100 docs before failure.
>>
>>>>
>>>> java.lang.NullPointerException
>>>>         at  
>>>> org.apache.fop.fo.properties.PropertyCache.cleanSegment  
>>>> (PropertyCache.java:99)
>>> ... and this line can normally not cause an NPE.
>>> Which JVM did you test it on? Do you run multiple concurrent  
>>> threads,  or is it just a plain single-threaded iteration?
>>
>> Sun 1.5.0_12 on Windows XP SP 2.
>
> I tested on Apple JVM 1.4.2 and 1.5.0 on OS X 10.4. Both single-  
> and multi-threaded.
> Heap remains stable here over hundreds of runs.
> With multiple concurrent runs, my CPU usage easily reaches 180-190%  
> (2 CPUs)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Patrick Jaromin | 2 Dec 2007 22:45

RE: Custom Fonts in Java2DRenderer & Hardcoded ColorModel

Jeremias-

Alright. Between the kid's naps, I've managed to create a patch to allow
for user-configured fonts in Java2DRenderers. I've tested it with the
PNG and TIFF renderers.

A couple things...

1) I've renamed the original "FontMetricMapper" to
"SystemFontMetricMapper" and created a new interface
"org.apache.fop.fonts.FontMetricMapper". Then the new implementation is
called "CustomFontMetricMapper," which represents the fonts *not*
installed on the system but described in the fop config. I looked at
maintaining the original naming but just didn't like any of the names I
could think of. If this won't fly perhaps someone can suggest an
alternative naming strategy.

2) I changed the signature of the FontInfo.setup method (the java2d
version of that class). It actually now more closely resembles its
counterpart. Since the PCLRenderer uses this same class I changed the
call there as well. However, I don't know how to test that renderer
properly and am just guessing that it would be fine. If not, it would be
simple to overload the setup method with the former signature and revert
PCLRenderer.

3) I don't really know how to write tests for these changes and so,
consequently, I didn't. I used the fop script to output PNG and TIFF
images with various combinations of settings in my userconfig.xml and it
ultimately worked as expected. I'm a pretty big proponent of test-driven
development but it wasn't obvious to me how to add new tests -- I'm not
(Continue reading)

Permalink | Reply | 6 comments |
headers
Cameron McCormack | 3 Dec 2007 07:10
Picon
Gravatar

Re: Maven artifacts for Batik

Carlos Sanchez:
> > > groupId should probably be org.apache.xmlgraphics.batik

Cameron McCormack:
> > OK.  Does that mean the groupId for FOP and XML Graphics Commons is
> > wrong?  (It says <groupId>org.apache.xmlgraphics</groupId> in the POM
> > file for both.)
> 
Carlos Sanchez:
> it's up to xmlgraphics project to decide how to subdivide the space
> for the subprojects

OK.  (Jeremias and others, any opinion here?  Unless there’s any issue
with it, I’ll choose org.apache.xmlgraphics as the groupId, to keep it
consistent.)

> > [mutual dependency with fop and batik]

> do you mean that fop needs batik to compile and batik needs fop?
> chicken and egg problem? how do you do that?

Well, it’s not quite true.  Batik has an optional run-time dependency on
a pdf-transcoder.jar file that can be built from FOP.  That
pdf-transcoder has a compile-time dependency on Batik.  We deal with it
by having a copy of FOP’s pdf-transcoder.jar in Batik’s repository and a
copy of Batik’s jar in FOP’s repository.  At some point some
disentaglement will be done by moving some stuff to xmlgraphics commons…

> > What's the difference?  Artifacts in the m1-… directory can be used by
> > both Maven 1 and 2, but those in the m2-… directory can only be used by
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 3 Dec 2007 08:08
Picon
Favicon

Bug report for Fop [2007/12/02]

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

Permalink | Reply | 0 comments |
headers
Jeremias Maerki | 3 Dec 2007 08:54
Picon
Gravatar

Re: Maven artifacts for Batik

On 03.12.2007 07:10:34 Cameron McCormack wrote:
> Carlos Sanchez:
> > > > groupId should probably be org.apache.xmlgraphics.batik
> 
> Cameron McCormack:
> > > OK.  Does that mean the groupId for FOP and XML Graphics Commons is
> > > wrong?  (It says <groupId>org.apache.xmlgraphics</groupId> in the POM
> > > file for both.)
> > 
> Carlos Sanchez:
> > it's up to xmlgraphics project to decide how to subdivide the space
> > for the subprojects
> 
> OK.  (Jeremias and others, any opinion here?  Unless there’s any issue
> with it, I’ll choose org.apache.xmlgraphics as the groupId, to keep it
> consistent.)

IMO, it doesn't make much sense to further divide that.
group=project=all products released by one PMC.

<snip/>

Jeremias Maerki
Permalink | Reply | 0 comments |
headers
Jeremias Maerki | 3 Dec 2007 09:23
Picon
Gravatar

Re: Does Forced Height on Table Rows Include the Cells’ borders and border-separation?

On 30.11.2007 11:54:38 Vincent Hennebert wrote:
> Hi Jeremias,
> 
> Thanks again for your patience :-)
> 
> Jeremias Maerki wrote:
> > On 29.11.2007 18:12:35 Vincent Hennebert wrote:
> >> Hi,
> >>
> >> Ready for yet another one? Everyone’s welcome to join the game ;-)
> >>
> >> If a table-row element has a forced height, must that height include 
> >> border-separation and the cells’ borders, or only the cells’ bpd?
> > 
> > The property (!) b-p-d is defined to specify the extent of the
> > content-rectangle which means border (and border-separation) and padding
> > do not belong in here.
> 
> So? When a block-container has block children, its content rectangle 
> includes the childrens’ borders, paddings and contents. A bpd explicitly 
> set on the block-container is to be divided among the childrens’ 
> borders, paddings and bpds.

With bpd on a table for example, I mean the table's border and padding
are not included. I don't talk about its children.

> 
> > The row-height trait (including border, border
> > sep, padding) is calculated as described in the CSS spec. I think/hope
> > that's what I implemented. Your example seems to prove that.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vincent Hennebert | 3 Dec 2007 12:37
Favicon

Re: Does Forced Height on Table Rows Include the Cells’ borders and border-separation?

Hi,

Jeremias Maerki wrote:
> On 30.11.2007 11:54:38 Vincent Hennebert wrote:
>> Jeremias Maerki wrote:
>>> On 29.11.2007 18:12:35 Vincent Hennebert wrote:
>>>> If a table-row element has a forced height, must that height 
>>>> include border-separation and the cells’ borders, or only the 
>>>> cells’ bpd?
>>> The property (!) b-p-d is defined to specify the extent of the
>>> content-rectangle which means border (and border-separation) and padding
>>> do not belong in here.
>> So? When a block-container has block children, its content rectangle 
>> includes the childrens’ borders, paddings and contents. A bpd explicitly 
>> set on the block-container is to be divided among the childrens’ 
>> borders, paddings and bpds.
> 
> With bpd on a table for example, I mean the table's border and padding
> are not included. I don't talk about its children.

Yeah, but with bpd on table-row? I took block-container as an analogy:
    block-container <-> table-row
    children blocks <-> children table-cells
bpd set on the block-container is to be divided among the children 
blocks’ bpds, paddings and borders.

So, likewise IMO, bpd set on table-row would have to be divided among 
the cells’ bpd, paddings and borders.

<snip/>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cameron McCormack | 5 Dec 2007 03:31
Picon
Gravatar

Re: FOP and XML Graphics Commons Maven artifacts

Hi Max.

Max Berger:
> Jeremias,
> Jason,
> 
> it looks like the only way to properly deploy maven bundles is to  
> actually use maven. I have finally managed to install the bundles  
> into a local directory for JEuclid, but the same process should apply  
> for the apache rsync-repository [1].
> 
> The results can be seen at
> http://jeuclid.sourceforge.net/m2/
> 
> in particular
> http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/fop/
> and
> http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/xmlgraphics- 
> commons/
> 
> you may just be able to take the files from there and copy then to  
> the apache rsync-repository.
> 
> How this was done? If you use maven, you need to create setting for  
> the repository in your .m2/settings.xml and then you can deploy using  
> the maven-deploy-plugin. I have documented the whole process in [2].

It looks like you have taken the fop-0.94.jar from inside the
fop-0.94-bin-jdk1.4.zip distribution, and the
xmlgraphics-commons-1.2.jar from inside the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jeremias Maerki | 5 Dec 2007 08:06
Picon
Gravatar

Re: FOP and XML Graphics Commons Maven artifacts

As long as JARs are published that are part of an official release,
there's certainly no problem. One thing that happened, though, was that
publishing FOP over iBiblio got rejected because the maintainers thought
it should happen over ASF infrastructure. But I couldn't figure out how
to publish a Maven artifact over ASF infrastructure from a non-Maven
build so essentially I left it for anyone who actually uses Maven. I
wasted too much time on the topic.

On 05.12.2007 03:31:10 Cameron McCormack wrote:
> Hi Max.
> 
> Max Berger:
> > Jeremias,
> > Jason,
> > 
> > it looks like the only way to properly deploy maven bundles is to  
> > actually use maven. I have finally managed to install the bundles  
> > into a local directory for JEuclid, but the same process should apply  
> > for the apache rsync-repository [1].
> > 
> > The results can be seen at
> > http://jeuclid.sourceforge.net/m2/
> > 
> > in particular
> > http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/fop/
> > and
> > http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/xmlgraphics- 
> > commons/
> > 
> > you may just be able to take the files from there and copy then to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Max Berger | 5 Dec 2007 11:29
Gravatar

Re: FOP and XML Graphics Commons Maven artifacts

Dear Fop-Devs,

actually, this could be a very fun experiment to see if my new fop
account is working. It should (theoretically) give me access to the
people.apache.org server mentioned in the howto. So yes, I am
volunteering to do it. (And provide a how-to afterwards)

There is no particular reason why I mixed the two compiled versions
other than pure coincidence. Would it be reasonable to upload the 1.4
artifacts only? Or should the 1.3 jars should also be uploaded (probly
with something like -1.3 in the name)?

Max

Am Mittwoch, den 05.12.2007, 13:31 +1100 schrieb Cameron McCormack:
> Hi Max.
> 
> Max Berger:
> > Jeremias,
> > Jason,
> > 
> > it looks like the only way to properly deploy maven bundles is to  
> > actually use maven. I have finally managed to install the bundles  
> > into a local directory for JEuclid, but the same process should apply  
> > for the apache rsync-repository [1].
> > 
> > The results can be seen at
> > http://jeuclid.sourceforge.net/m2/
> > 
> > in particular
(Continue reading)

Permalink | Reply | 4 comments |

Gmane