getPageCount and FOP 1.0dev
Jeremias, happy to do so - I just setup Fop under NetBeans 4.1. However, where do I start for something like this? Manuel PS: I moved this thread over to fop-dev as I assume its more appropriate here. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, 27 July 2005 14:08 To: fop-users@xmlgraphics.apache.org Subject: Re: getPageCount and FOP 1.0dev No, but you're welcome to help improve the situation. :-) On 27.07.2005 03:50:46 Manuel Mall wrote: Jeremias post on fop-dev suggesting to push for a release made me curious to check out if the new trunk code will work with our application. Downloading it with subversion and building it with ant was not a big problem (These things never seem to be 100% straightforward). Some of the interfaces have changed and what was ...apps.Driver is now sort of ...apps.Fop. Not such a big deal especially as examples exist, just a nuisance if you only want to see if the new trunk code works with what we have got as it means code changes to existing code. However I am stuck with how to replace the old driver.getResults().getPageCount(). Is there something equivalent in 1.0dev? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Building Fop 1.0dev with JDK 1.3 ??
The question seemed to fit in this list rather than fop-users: I've checked out the fop trunk and tried to build it with JDK 1.3, however that doesn't seem to work (getting a number of compile errors on among other things, java.awt.Color) Is the trunk known to require JDK1.4 or higher, if not, what do I need to think about ? The reason I need JDK 1.3 is that I'm trying to fit fop into an application where JRE1.3 is used, AND I need it to be able to render the (embedded) SVG in the XSL-FO which is what doesn't work for me in fop 0.20.5. TIA /Rob
Re: getPageCount and FOP 1.0dev
Manuel, thanks for grabbing this. I think the easiest thing will be to recreate what was in 0.20.5. It doesn't offer very much and I have a better overall mechanism in mind (as a long-term solution) but for the moment it is easiest to do that. Here's what I would do: - Copy over FormattingResults and PageSequenceResults over from 0.20.5 and replace the license header with the once you find all over FOP Trunk. - Go to org.apache.fop.area.AreaTreeHandler.endPageSequence() and build up the FormattingResults structure as it's done in 0.20.5 in StreamRenderer. AreaTreeHandler is more or less the old StreamRenderer. - When endPageSequence() is called you can probably derive the number of pages generated for a page-sequence by subtracting currentPageNumber from startPageNumber in layoutmgr.PageSequenceLayoutManager. - Find a way to access the FormattingResults structure in Fop.java like it was done in 0.20.5. As an alternative to doing this in AreaTreeHandler you might want to investigate fo.Root and fo.PageSequence but I'd prefer to have stuff like that in AreaTreeHandler. I hope that gives you some hints to do this. It shouldn't really be that hard. On 27.07.2005 08:13:58 Manuel Mall wrote: Jeremias, happy to do so - I just setup Fop under NetBeans 4.1. However, where do I start for something like this? Manuel PS: I moved this thread over to fop-dev as I assume its more appropriate here. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, 27 July 2005 14:08 To: fop-users@xmlgraphics.apache.org Subject: Re: getPageCount and FOP 1.0dev No, but you're welcome to help improve the situation. :-) On 27.07.2005 03:50:46 Manuel Mall wrote: Jeremias post on fop-dev suggesting to push for a release made me curious to check out if the new trunk code will work with our application. Downloading it with subversion and building it with ant was not a big problem (These things never seem to be 100% straightforward). Some of the interfaces have changed and what was ...apps.Driver is now sort of ...apps.Fop. Not such a big deal especially as examples exist, just a nuisance if you only want to see if the new trunk code works with what we have got as it means code changes to existing code. However I am stuck with how to replace the old driver.getResults().getPageCount(). Is there something equivalent in 1.0dev? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki
Re: Building Fop 1.0dev with JDK 1.3 ??
Until we decide otherwise, FOP is still targeted at JDK 1.3 but you're right it currently doesn't compile. Nobody took the time, yet, to make it compile under 1.3. It's on my list of things but there are so many little things still to do. If you could try to fix it and send a patch that would be absolutely awesome! Do you want to try? On 27.07.2005 08:14:14 Bielik, Robert wrote: The question seemed to fit in this list rather than fop-users: I've checked out the fop trunk and tried to build it with JDK 1.3, however that doesn't seem to work (getting a number of compile errors on among other things, java.awt.Color) Is the trunk known to require JDK1.4 or higher, if not, what do I need to think about ? The reason I need JDK 1.3 is that I'm trying to fit fop into an application where JRE1.3 is used, AND I need it to be able to render the (embedded) SVG in the XSL-FO which is what doesn't work for me in fop 0.20.5. TIA /Rob Jeremias Maerki
RE: Building Fop 1.0dev with JDK 1.3 ??
Phew... OK, I'll try. Though I have very limited insight into FOP to know what my changes would incur, and unfortunately _very_ limited time so I don't want you to count on me... ;) Btw, when you develop FOP, what environment are you using ? I'm thinking of cramming it into Eclipse which is sailing up to be my number 1 choice of IDE :) Regards /R -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 8:48 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Building Fop 1.0dev with JDK 1.3 ?? Until we decide otherwise, FOP is still targeted at JDK 1.3 but you're right it currently doesn't compile. Nobody took the time, yet, to make it compile under 1.3. It's on my list of things but there are so many little things still to do. If you could try to fix it and send a patch that would be absolutely awesome! Do you want to try? On 27.07.2005 08:14:14 Bielik, Robert wrote: The question seemed to fit in this list rather than fop-users: I've checked out the fop trunk and tried to build it with JDK 1.3, however that doesn't seem to work (getting a number of compile errors on among other things, java.awt.Color) Is the trunk known to require JDK1.4 or higher, if not, what do I need to think about ? The reason I need JDK 1.3 is that I'm trying to fit fop into an application where JRE1.3 is used, AND I need it to be able to render the (embedded) SVG in the XSL-FO which is what doesn't work for me in fop 0.20.5. TIA /Rob Jeremias Maerki
Re: getPageCount and FOP 1.0dev
Jeremias, Excellent, thanks for the pointers. I'll have a go at it over the coming weekend as I am going away for a few days now. Manuel On Wed, 27 Jul 2005 02:43 pm, Jeremias Maerki wrote: Manuel, thanks for grabbing this. I think the easiest thing will be to recreate what was in 0.20.5. ...
RE: Building Fop 1.0dev with JDK 1.3 ??
Ok, I've now managed to get everything to compile alright. It wasn't really any
large problems. However, there is one in Java2DRenderer.java regarding
ColorModel:
Original code (1001):
ColorModel cm = new ComponentColorModel(ColorSpace.
getInstance(ColorSpace.CS_LINEAR_RGB), false,
false,
ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);
which made javac complain about wrong number of arguments. It seems that an
int[] denoting the bitdepth of each color component was lacking, so I changed
it to:
ColorModel cm = new
ComponentColorModel(ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB),
new int[] {8, 8, 8},
false, false,
ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);
I guess thats OK? (since there seems to be no alpha component)
However, then ant crashes at build.xml (480) complaining about wrong timestamp
format:
-MM-dd'T'HH:mm:ssZ
so I changed that to the other jar creation tstamp formats:
MMdd-HHmmss-z
Then it all goes through. However, if it'll work, that's another matter... ;)
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 9:07 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
On 27.07.2005 08:54:27 Bielik, Robert wrote:
Phew... OK, I'll try. Though I have very limited insight
into FOP to know what my
changes would incur, and unfortunately _very_ limited time
so I don't want you to
count on me... ;)
If you have very limited time then it's probably too soon for
you to try
out FOP Trunk. It's still work in progress and we're only planning the
first preview (!) release. It's not like the whole thing is
already fit
for production work. It's a good time for interested people to try out
the code and provide some feedback (or even better, fixes).
Btw, when you develop FOP, what environment are you using ?
I'm thinking of
cramming it into Eclipse which is sailing up to be my
number 1 choice of IDE :)
You're free to choose. I personally use Eclipse as do a few
others. Just
make sure you run ant codegen to create the build/gensrc directory
which you have to add to the source path.
http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide
Regards
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 8:48 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
Until we decide otherwise, FOP is still targeted at JDK
1.3 but you're
right it currently doesn't compile. Nobody took the time,
yet, to make
it compile under 1.3. It's on my list of things but there
are so many
little things still to do. If you could try to fix it and
send a patch
that would be absolutely awesome! Do you want to try?
On 27.07.2005 08:14:14 Bielik, Robert wrote:
The question seemed to fit in this list rather than fop-users:
I've checked out the fop trunk and tried to build it with
JDK 1.3, however
that doesn't seem to work (getting a number of compile
errors on among other
things, java.awt.Color)
Is the trunk known to require JDK1.4 or higher, if not,
what do I need to
think about ?
The reason I need JDK 1.3 is that I'm trying to fit fop
into an application
where JRE1.3 is used, AND I need it to be able to render
the (embedded) SVG in the
XSL-FO which is what doesn't work for me in fop 0.20.5.
TIA
/Rob
Jeremias Maerki
Jeremias Maerki
Re: DO NOT REPLY [Bug 35534] - fo document output is placed in page margins
Jeremias Maerki wrote: The situation is now improved here. The missing glues are now produced but if there are shrink and stretch possibilities the spaces are currently not adjusted, i.e. differing .minimum/.optimum/.maximum values on space-before and space-after may produce undesirable results. If you agree, I could work to fix this: it would very similar (much easier, actually) to what is currently done in the justifyBoxes() method, without the need to get an updated element list. Regards Luca
Re: Building Fop 1.0dev with JDK 1.3 ??
Thanks for taking the time. Are you sure that these are all the changes
that were necessary? When I change what you indicated here, I still get
a few other errors. If you made more than just these modifications would
you please send us a patch so I can put the changes into the repository?
The thing that surprises me is the timestamp stuff but that should be no
problem since it is only informational. The fix in Java2DRenderer looks
fine. I'll verify that it still works when I add the changes to the repo.
On 27.07.2005 10:09:25 Bielik, Robert wrote:
Ok, I've now managed to get everything to compile alright. It wasn't really
any
large problems. However, there is one in Java2DRenderer.java regarding
ColorModel:
Original code (1001):
ColorModel cm = new ComponentColorModel(ColorSpace.
getInstance(ColorSpace.CS_LINEAR_RGB), false,
false,
ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);
which made javac complain about wrong number of arguments. It seems that an
int[] denoting the bitdepth of each color component was lacking, so I changed
it to:
ColorModel cm = new
ComponentColorModel(ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB),
new int[] {8, 8, 8},
false, false,
ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);
I guess thats OK? (since there seems to be no alpha component)
However, then ant crashes at build.xml (480) complaining about wrong
timestamp format:
-MM-dd'T'HH:mm:ssZ
so I changed that to the other jar creation tstamp formats:
MMdd-HHmmss-z
Then it all goes through. However, if it'll work, that's another matter... ;)
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 9:07 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
On 27.07.2005 08:54:27 Bielik, Robert wrote:
Phew... OK, I'll try. Though I have very limited insight
into FOP to know what my
changes would incur, and unfortunately _very_ limited time
so I don't want you to
count on me... ;)
If you have very limited time then it's probably too soon for
you to try
out FOP Trunk. It's still work in progress and we're only planning the
first preview (!) release. It's not like the whole thing is
already fit
for production work. It's a good time for interested people to try out
the code and provide some feedback (or even better, fixes).
Btw, when you develop FOP, what environment are you using ?
I'm thinking of
cramming it into Eclipse which is sailing up to be my
number 1 choice of IDE :)
You're free to choose. I personally use Eclipse as do a few
others. Just
make sure you run ant codegen to create the build/gensrc directory
which you have to add to the source path.
http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide
Regards
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 8:48 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
Until we decide otherwise, FOP is still targeted at JDK
1.3 but you're
right it currently doesn't compile. Nobody took the time,
yet, to make
it compile under 1.3. It's on my list of things but there
are so many
little things still to do. If you could try to fix it and
send a patch
that would be absolutely awesome! Do you want to try?
On 27.07.2005 08:14:14 Bielik, Robert wrote:
The question seemed to fit in this list rather than fop-users:
I've checked out the fop trunk and tried to build it with
JDK 1.3, however
that doesn't seem to work (getting a number of compile
errors on among other
things, java.awt.Color)
Is the trunk known to require JDK1.4 or higher, if not,
what do I need to
think about ?
The reason I need JDK 1.3 is that I'm trying to fit fop
into an application
where JRE1.3 is used, AND I need it to be able to render
the (embedded) SVG in the
XSL-FO which is what doesn't work for me in fop 0.20.5.
TIA
/Rob
Jeremias Maerki
Jeremias Maerki
Jeremias Maerki
RE: Building Fop 1.0dev with JDK 1.3 ??
No, there were a couple of other changes. They were as follows:
1) In PageSequenceLayoutManager.java inner class PageBreaker, all 'log.' were
changed to 'pslm.log.' so that the log instance in PageSeq...Manager.java is
called.
2) In org.apache.fop.render.bitmap.TIFFRenderer the getLogger() call in the
inner class LazyPageImagesIterator method next() was out-commented. I'm not
sure how to get to TIFFRenderer.getLogger() from here.
3) In org.apache.fop.render.java2d.Java2DRenderer all calls to Color constants
were changed to lower case. Here it was Color.WHITE - Color.white.
4) In org.apache.fop.render.pdf.PDFXMLHandler it was Color.BLACK - Color.black
.
If memory serves me right, that was it :)
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 10:34 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
Thanks for taking the time. Are you sure that these are all
the changes
that were necessary? When I change what you indicated here, I
still get
a few other errors. If you made more than just these
modifications would
you please send us a patch so I can put the changes into the
repository?
The thing that surprises me is the timestamp stuff but that
should be no
problem since it is only informational. The fix in
Java2DRenderer looks
fine. I'll verify that it still works when I add the changes
to the repo.
On 27.07.2005 10:09:25 Bielik, Robert wrote:
Ok, I've now managed to get everything to compile alright.
It wasn't really any
large problems. However, there is one in
Java2DRenderer.java regarding ColorModel:
Original code (1001):
ColorModel cm = new ComponentColorModel(ColorSpace.
getInstance(ColorSpace.CS_LINEAR_RGB), false, false,
ColorModel.OPAQUE,
DataBuffer.TYPE_BYTE);
which made javac complain about wrong number of arguments.
It seems that an int[] denoting the bitdepth of each color
component was lacking, so I changed it to:
ColorModel cm = new
ComponentColorModel(ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB),
new int[] {8, 8, 8},
false, false,
ColorModel.OPAQUE,
DataBuffer.TYPE_BYTE);
I guess thats OK? (since there seems to be no alpha component)
However, then ant crashes at build.xml (480) complaining
about wrong timestamp format:
-MM-dd'T'HH:mm:ssZ
so I changed that to the other jar creation tstamp formats:
MMdd-HHmmss-z
Then it all goes through. However, if it'll work, that's
another matter... ;)
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 9:07 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
On 27.07.2005 08:54:27 Bielik, Robert wrote:
Phew... OK, I'll try. Though I have very limited insight
into FOP to know what my
changes would incur, and unfortunately _very_ limited time
so I don't want you to
count on me... ;)
If you have very limited time then it's probably too soon for
you to try
out FOP Trunk. It's still work in progress and we're only
planning the
first preview (!) release. It's not like the whole thing is
already fit
for production work. It's a good time for interested
people to try out
the code and provide some feedback (or even better, fixes).
Btw, when you develop FOP, what environment are you using ?
I'm thinking of
cramming it into Eclipse which is sailing up to be my
number 1 choice of IDE :)
You're free to choose. I personally use Eclipse as do a few
others. Just
make sure you run ant codegen to create the
build/gensrc directory
which you have to add to the source path.
http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide
Regards
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 8:48 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
Until we decide otherwise, FOP is still targeted at JDK
1.3 but you're
right it currently doesn't compile. Nobody took the time,
yet, to make
it compile under 1.3. It's on my list of things but there
are so many
little things still to do. If you could try to fix it and
send a patch
that would be absolutely awesome! Do you want to try?
On 27.07.2005 08:14:14 Bielik, Robert wrote:
The question seemed to fit in this list rather than
fop-users:
I've checked out the fop trunk and tried to build it with
JDK 1.3, however
that doesn't seem to work (getting a number of compile
errors on among other
things, java.awt.Color)
Re: Building Fop 1.0dev with JDK 1.3 ??
I see. So, do you know how to create a patch? Just run svn diff
mydiff.txt and send us the file. That way I don't have to recreate all
your changes. Thanks in advance!
On 27.07.2005 10:44:54 Bielik, Robert wrote:
No, there were a couple of other changes. They were as follows:
1) In PageSequenceLayoutManager.java inner class PageBreaker, all 'log.' were
changed to 'pslm.log.' so that the log instance in PageSeq...Manager.java is
called.
2) In org.apache.fop.render.bitmap.TIFFRenderer the getLogger() call in the
inner class LazyPageImagesIterator method next() was out-commented. I'm not
sure how to get to TIFFRenderer.getLogger() from here.
3) In org.apache.fop.render.java2d.Java2DRenderer all calls to Color
constants were changed to lower case. Here it was Color.WHITE - Color.white.
4) In org.apache.fop.render.pdf.PDFXMLHandler it was Color.BLACK -
Color.black .
If memory serves me right, that was it :)
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 10:34 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
Thanks for taking the time. Are you sure that these are all
the changes
that were necessary? When I change what you indicated here, I
still get
a few other errors. If you made more than just these
modifications would
you please send us a patch so I can put the changes into the
repository?
The thing that surprises me is the timestamp stuff but that
should be no
problem since it is only informational. The fix in
Java2DRenderer looks
fine. I'll verify that it still works when I add the changes
to the repo.
On 27.07.2005 10:09:25 Bielik, Robert wrote:
Ok, I've now managed to get everything to compile alright.
It wasn't really any
large problems. However, there is one in
Java2DRenderer.java regarding ColorModel:
Original code (1001):
ColorModel cm = new ComponentColorModel(ColorSpace.
getInstance(ColorSpace.CS_LINEAR_RGB), false, false,
ColorModel.OPAQUE,
DataBuffer.TYPE_BYTE);
which made javac complain about wrong number of arguments.
It seems that an int[] denoting the bitdepth of each color
component was lacking, so I changed it to:
ColorModel cm = new
ComponentColorModel(ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB),
new int[] {8, 8, 8},
false, false,
ColorModel.OPAQUE,
DataBuffer.TYPE_BYTE);
I guess thats OK? (since there seems to be no alpha component)
However, then ant crashes at build.xml (480) complaining
about wrong timestamp format:
-MM-dd'T'HH:mm:ssZ
so I changed that to the other jar creation tstamp formats:
MMdd-HHmmss-z
Then it all goes through. However, if it'll work, that's
another matter... ;)
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 9:07 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
On 27.07.2005 08:54:27 Bielik, Robert wrote:
Phew... OK, I'll try. Though I have very limited insight
into FOP to know what my
changes would incur, and unfortunately _very_ limited time
so I don't want you to
count on me... ;)
If you have very limited time then it's probably too soon for
you to try
out FOP Trunk. It's still work in progress and we're only
planning the
first preview (!) release. It's not like the whole thing is
already fit
for production work. It's a good time for interested
people to try out
the code and provide some feedback (or even better, fixes).
Btw, when you develop FOP, what environment are you using ?
I'm thinking of
cramming it into Eclipse which is sailing up to be my
number 1 choice of IDE :)
You're free to choose. I personally use Eclipse as do a few
others. Just
make sure you run ant codegen to create the
build/gensrc directory
which you have to add to the source path.
http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide
Regards
/R
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 8:48 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
Until we decide otherwise, FOP is still targeted at JDK
1.3 but you're
right it currently doesn't compile. Nobody took the time,
yet, to make
it compile under 1.3. It's on my list of things but there
are so many
little things still to do. If you could try to fix it and
send a patch
that would be absolutely awesome! Do you want to
RE: Building Fop 1.0dev with JDK 1.3 ??
Ok, diff file is attached. build.properties and build.xml is included in it but
I guess you can scrap that part...
Regards,
/Robert
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 10:50 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
I see. So, do you know how to create a patch? Just run svn diff
mydiff.txt and send us the file. That way I don't have to
recreate all
your changes. Thanks in advance!
Index: src/java/org/apache/fop/render/java2d/Java2DRenderer.java
===
--- src/java/org/apache/fop/render/java2d/Java2DRenderer.java (revision
225262)
+++ src/java/org/apache/fop/render/java2d/Java2DRenderer.java (working copy)
@@ -883,7 +883,7 @@
state.getGraph().draw(line);
// lower Leader
line.setLine(startx, starty + thickness, endx, starty + thickness);
-state.getGraph().setColor(Color.WHITE);
+state.getGraph().setColor(Color.white);
state.getGraph().draw(line);
// TODO the implementation could be nicer, f.eg. with triangles at
@@ -904,7 +904,7 @@
state.getGraph().draw(line);
// upperLeader
line.setLine(startx, starty, endx, starty);
-state.getGraph().setColor(Color.WHITE);
+state.getGraph().setColor(Color.white);
state.getGraph().draw(line);
// TODO the implementation could be nicer, f.eg. with triangles at
@@ -998,9 +998,10 @@
byte[] raw = fopimage.getBitmaps();
// TODO Hardcoded color and sample models, FIX ME!
-ColorModel cm = new ComponentColorModel(ColorSpace
-.getInstance(ColorSpace.CS_LINEAR_RGB), false, false,
-ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);
+ColorModel cm = new
ComponentColorModel(ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB),
+ new int[] {8, 8, 8},
+ false, false,
+ ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);
SampleModel sampleModel = new PixelInterleavedSampleModel(
DataBuffer.TYPE_BYTE, w, h, 3, w * 3, new int[] { 0, 1, 2
});
DataBuffer dbuf = new DataBufferByte(raw, w * h * 3);
Index: src/java/org/apache/fop/render/pdf/PDFXMLHandler.java
===
--- src/java/org/apache/fop/render/pdf/PDFXMLHandler.java (revision
225262)
+++ src/java/org/apache/fop/render/pdf/PDFXMLHandler.java (working copy)
@@ -266,8 +266,8 @@
PDFRenderer renderer = (PDFRenderer)context.getRenderer();
renderer.saveGraphicsState();
//pdfInfo.currentStream.add(q\n);
-renderer.setColor(Color.BLACK, false, null);
-renderer.setColor(Color.BLACK, true, null);
+renderer.setColor(Color.black, false, null);
+renderer.setColor(Color.black, true, null);
// transform so that the coordinates (0,0) is from the top left
// and positive is down and to the right. (0,0) is where the
// viewBox puts it.
Index: src/java/org/apache/fop/render/bitmap/TIFFRenderer.java
===
--- src/java/org/apache/fop/render/bitmap/TIFFRenderer.java (revision
225262)
+++ src/java/org/apache/fop/render/bitmap/TIFFRenderer.java (working copy)
@@ -185,7 +185,7 @@
}
public Object next() {
-getLogger().debug([ + (current + 1) + ]);
+//getLogger().debug([ + (current + 1) + ]);
// Renders current page as image
BufferedImage pageImage = null;
Index: src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
===
--- src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
(revision 225262)
+++ src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
(working copy)
@@ -188,7 +188,7 @@
needColumnBalancing = (childLC.getNextSpan() ==
Constants.EN_ALL);
}
if (needColumnBalancing) {
-log.debug(Column balancing necessary for the next element
list!!!);
+pslm.log.debug(Column balancing necessary for the next
element list!!!);
}
return nextSequenceStartsOn;
}
@@ -302,8 +302,8 @@
protected void doPhase3(PageBreakingAlgorithm alg, int partCount,
BlockSequence originalList, BlockSequence effectiveList) {
if (needColumnBalancing) {
-log.debug(Column balancing now!!!);
-
log.debug(===);
+pslm.log.debug(Column balancing
AW: MathML and barcode support for FOP
Sorry to interrupt you all. But I have so concerns using JEuclid for MathML. I'm not sure if I have the permission to post here, but maybe you will excuse my post if so. I am not sure if using JEuclid is the right way to deal with MathML. As far as I understand JEuclid transforms a MathML expression into an image. If this is correct, than I would found this the wrong way in principle. Wouldn't it be nicer if the MathML expression is converted into XSL:FO it self? I am not very in this field, but as far as I understand MathML (pm) this should be the way to go. Or do I completely misinterpret something? Regards Norman Markgraf
Re: AW: MathML and barcode support for FOP
The MathML extension uses JEuclid to convert the MathML to SVG internally so we get quite good quality. I don't think it is possible to create XSL-FO code from MathML because you can't properly place all the elements. Doing that with SVG is a lot better. On 27.07.2005 10:54:45 Norman Markgraf wrote: Sorry to interrupt you all. But I have so concerns using JEuclid for MathML. I'm not sure if I have the permission to post here, but maybe you will excuse my post if so. I am not sure if using JEuclid is the right way to deal with MathML. As far as I understand JEuclid transforms a MathML expression into an image. If this is correct, than I would found this the wrong way in principle. Wouldn't it be nicer if the MathML expression is converted into XSL:FO it self? I am not very in this field, but as far as I understand MathML (pm) this should be the way to go. Or do I completely misinterpret something? Jeremias Maerki
Re: Building Fop 1.0dev with JDK 1.3 ??
Thanks a lot, Robert. This saved me a lot of time. I've committed your patch to the repository. http://svn.apache.org/viewcvs?rev=225486view=rev On 27.07.2005 10:56:19 Bielik, Robert wrote: Ok, diff file is attached. build.properties and build.xml is included in it but I guess you can scrap that part... Regards, /Robert -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 10:50 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Building Fop 1.0dev with JDK 1.3 ?? I see. So, do you know how to create a patch? Just run svn diff mydiff.txt and send us the file. That way I don't have to recreate all your changes. Thanks in advance! Jeremias Maerki
Re: MathML and barcode support for FOP
Sorry to interrupt you all. But I have so concerns using JEuclid for MathML. I'm not sure if I have the permission to post here, but maybe you will excuse my post if so. I am not sure if using JEuclid is the right way to deal with MathML. As far as I understand JEuclid transforms a MathML expression into an image. Not exactly. JEuclid renders MathML on Graphics2D object. Depending on the Graphics2D nature you can output MathML as image or svn graphics or something else. There is a custom PDFGraphics2D class in the FOP. We use especially this PDFGraphics2D to output MathML directly into PDF. The important moment here is that we insert MathML into PDF not as an image but we render MathML by means of font glyphs. Sure, with JEuclid MathML could be inserted into PDF as an image as well: MathML could be rendered as SVG image and then inserted into PDF. But such transformation is redundant. If this is correct, than I would found this the wrong way in principle. Wouldn't it be nicer if the MathML expression is converted into XSL:FO it self? It is impossible. XSL:FO does not support MathML spec. In other words, you can't render MathML by means of XSL:FO elements only. I am not very in this field, but as far as I understand MathML (pm) this should be the way to go. Or do I completely misinterpret something? Regards Norman Markgraf -- Cheers, Siarhei Baidun
Re: AW: MathML and barcode support for FOP
While we are speaking of that, If I may give my opinion: I agree with Norman that using images to render maths isn't a good solution in the long-term. The fact that it is SVG improves the situation a bit because fonts will be rendered fine, but there are other problems to address: for example it is difficult to align the baseline of an inline-rendered equation with the text's baseline. It also is not possible to break an equation into multiple lines. A native MathML renderer will be necessary to beat TeX in this area. I was thinking of writing one for Fop but I'm missing time and for now I'm in the font subsystem stuff. The work referred by Siarhei Baidun may definitely be interesting. Vincent Jeremias Maerki a écrit : The MathML extension uses JEuclid to convert the MathML to SVG internally so we get quite good quality. I don't think it is possible to create XSL-FO code from MathML because you can't properly place all the elements. Doing that with SVG is a lot better. On 27.07.2005 10:54:45 Norman Markgraf wrote: Sorry to interrupt you all. But I have so concerns using JEuclid for MathML. I'm not sure if I have the permission to post here, but maybe you will excuse my post if so. I am not sure if using JEuclid is the right way to deal with MathML. As far as I understand JEuclid transforms a MathML expression into an image. If this is correct, than I would found this the wrong way in principle. Wouldn't it be nicer if the MathML expression is converted into XSL:FO it self? I am not very in this field, but as far as I understand MathML (pm) this should be the way to go. Or do I completely misinterpret something? Jeremias Maerki
AW: MathML and barcode support for FOP
Thank you, Siarhei, for the explanation of the interrelationship between JEuclid and FOP. In fact that was roughly what I mean by image. As I explained, I am not in the details. The words by Jeremias, that you can not place all element properly, might be the point that sounds the most important to me. Does anybody know if there is an approach like that one Vincent wanted to try, but has not find the time for? You are most likely right, Jeremias, but ... I think the way to convert MathML to XSL:FO is more natural. Maybe here are some people who give this a try. If so, please contact me via private email. Regards, Norman Markgraf
Re: AW: MathML and barcode support for FOP
Please don't work on private channels. You can use the fop-dev mailing list to discuss stuff around MathML as long as there is some relation to FOP. I wasn't aware of the advanced requirements like baseline alignment and such. At any rate, the new FOP has the ideal infrastructure to handle cases like that. You also have to see that the MathML extension was probably never used in production since it was hidden for years inside the examples directory. If you guys have additional needs bring them here, band together. The FOP committers will certainly assist where they can. If bringing in JEuclid into the Apache Software Foundation helps this process I'm glad to help start talks with the original authors of JEuclid and to serve as sponsoring member when it has to go through the Incubator. Still, Norman, converting MathML to XSL-FO is almost certainly not doable but that's not even necessary because as Siarhei Baidun mentioned it is possible to paint the formulae directly to a Graphics2D interface (all inside FOP). The way through SVG is most probably not necessary for output formats like PDF, PostScript and Java2D. On 27.07.2005 13:07:59 Norman Markgraf wrote: Thank you, Siarhei, for the explanation of the interrelationship between JEuclid and FOP. In fact that was roughly what I mean by image. As I explained, I am not in the details. The words by Jeremias, that you can not place all element properly, might be the point that sounds the most important to me. Does anybody know if there is an approach like that one Vincent wanted to try, but has not find the time for? You are most likely right, Jeremias, but ... I think the way to convert MathML to XSL:FO is more natural. Maybe here are some people who give this a try. If so, please contact me via private email. Regards, Norman Markgraf Jeremias Maerki
Re: Building Fop 1.0dev with JDK 1.3 ??
That was to be expected. Run a svn revert -R .. This will revert all the files to the state in the repository. Note that you will lose any changes that you made since you sent the patch. HTH. On 27.07.2005 14:17:17 Bielik, Robert wrote: You're welcome :) However, I did a svn up and several .java files had conflict resolve markers in them ( = ). I'm not used to svn, is there something more I need to do? /Robert -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 12:02 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: Building Fop 1.0dev with JDK 1.3 ?? Thanks a lot, Robert. This saved me a lot of time. I've committed your patch to the repository. http://svn.apache.org/viewcvs?rev=225486view=rev On 27.07.2005 10:56:19 Bielik, Robert wrote: Ok, diff file is attached. build.properties and build.xml is included in it but I guess you can scrap that part... Regards, /Robert -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 10:50 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Building Fop 1.0dev with JDK 1.3 ?? I see. So, do you know how to create a patch? Just run svn diff mydiff.txt and send us the file. That way I don't have to recreate all your changes. Thanks in advance! Jeremias Maerki Jeremias Maerki
Re: fop contribution
Right. For example we could provide an additional extension element under fo:root which would involve extending its contents from: (layout-master-set,declarations?,page-sequence+) to: (layout-master-set,declarations?,(page-sequence|fox:external-document)+) This way it would be possible to freely mix content. fox:external-document could have the following attributes: - content-type (application/pdf in case of PDF files) - src (URL to the PDF to be included) have no objections. lets have it through fox: extension element. Any volunteers to start talking to the JEuclid guys? I can serve as sponsoring member. Well, think me or somebody from our company could do it. If you'd like to talk yourself - no problem. Please don't do it this way. Please create an implementation of an XMLHandler. Do it the same way SVG/Batik-support is implemented. Ok. Did not dig into the detaild of SVG support implementation. But ok, for the sake of consistency lets do in the same way as SVG done.
Re: fop contribution
I've just had a closer look into the JEuclid project. There seems absolutely no activity lately. That's true I'd recommend the following approach: Contact the original authors and tell them that there is interest to do some work on JEuclid, mainly to make it fit for use in FOP and to address the additional requirements you and Vincent have. Try to work with them to integrate the change you've already done within the JEuclid project in SourceForge. Like this we can gauge if this project is really good enough to be adopted into the ASF. If I can see that this is the case I'll gladly help to get it into the Incubator if the JEuclid people are willing to do that. Since I don't need MathML support myself and I'm deep in other things I can't take the lead here. I can help where FOP code is concerned but, at this stage, nothing more. Lets do so. We'll contact the authors and try to commit our code to source forge. -- Siarhei Baidun
Re: fop contribution
On 27.07.2005 15:49:02 Siarhei Baidun wrote: Jeremias, we consider the signing of the CCLA (corporate) , not ICLA (individual). The ICLA is mandatory for each person that intends to submit a contribution to an ASF project. The CCLA is only necessary if you work for a company and you want to make sure everything is 100% waterproof. At the ASF no company can be a contributor. It's always an individual that does the actual contribution. The CCLA is simply there to make certain that you are entitled as an employee of that company to make contributions to the ASF. Could you please advise if ICLAs have to be signed along with CCLA for those employees who would commit to Apache? I don't want to be a nitpicker but at first, you can only submit patches as a contributor. Commit rights have to be earned and are proposed to you by the existing committers. Just to avoid any false expectations. Jeremias Maerki
Element list generation for tables (special case)
I got a test case for tables which raises not a technical but rather a interesting conceptual question. Please have a look at the attached test case. It defines a table with two columns and two rows. In the given setup the second row creates an break decision with the current code that can be argued as being bad (see the PDF). Here's an excerpt from the element list: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=0 //-- this is where the second row starts 13) penalty p=0 w=9600 //this penalty is due to the possible break after B 14) box w=28800 15) penalty p=0 w=0 //this is the next break poss after three lines //due to the orphan setting 16) box w=28800 While working on element list generation for tables I came across this question and decided not to do anything about it, especially since removing some of these break possibilities might not be desirable in all cases. A rule that could be easily implemented would be that we allow the first break possibility only after every cell in a new row contributed at least one of its own boxes to the combined element list. An example: If you look at page 1 of [1], step 1 would over ignored. On page 3 of [1], the steps 1 and 2 would be ignored. [1] http://people.apache.org/~jeremias/fop/KnuthBoxesForTablesWithBorders.pdf With this rule the element list would look like this: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=28800 //-- this is where the second row starts 13) penalty p=0 w=0 14) box w=28800 I'm unsure ATM what this would mean for cases with row spanning, though. I can see that this new rule would make this better in most cases. What worries me is that there might be cases where we wouldn't want that behaviour, although ATM I can't see them. So I just want to check with you that I haven't forgotten about anything. Or maybe someone has a better rule to implement this. Thoughts welcome. Jeremias Maerki table-body4.xml Description: Binary data table-body4.xml.head.pdf Description: Binary data
Re: Element list generation for tables (special case)
One thing that IMHO is still lacking in the table breaking code is penalty values. ATM all penalties are 0. I believe the penalty value should depend on the extra vertical size that the break contributes, that is, on the penalty's width. I have no idea about the multiplication constant, nor if it should be linear or quadratic. I am not sure if it avoids the current case, but it is surely needed in order to favour better breaks over worse ones. Simon On Wed, Jul 27, 2005 at 08:45:48PM +0200, Jeremias Maerki wrote: I got a test case for tables which raises not a technical but rather a interesting conceptual question. Please have a look at the attached test case. It defines a table with two columns and two rows. In the given setup the second row creates an break decision with the current code that can be argued as being bad (see the PDF). Here's an excerpt from the element list: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=0 //-- this is where the second row starts 13) penalty p=0 w=9600 //this penalty is due to the possible break after B 14) box w=28800 15) penalty p=0 w=0 //this is the next break poss after three lines //due to the orphan setting 16) box w=28800 While working on element list generation for tables I came across this question and decided not to do anything about it, especially since removing some of these break possibilities might not be desirable in all cases. A rule that could be easily implemented would be that we allow the first break possibility only after every cell in a new row contributed at least one of its own boxes to the combined element list. An example: If you look at page 1 of [1], step 1 would over ignored. On page 3 of [1], the steps 1 and 2 would be ignored. [1] http://people.apache.org/~jeremias/fop/KnuthBoxesForTablesWithBorders.pdf With this rule the element list would look like this: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=28800 //-- this is where the second row starts 13) penalty p=0 w=0 14) box w=28800 I'm unsure ATM what this would mean for cases with row spanning, though. I can see that this new rule would make this better in most cases. What worries me is that there might be cases where we wouldn't want that behaviour, although ATM I can't see them. So I just want to check with you that I haven't forgotten about anything. Or maybe someone has a better rule to implement this. Thoughts welcome. Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: getPageCount and FOP 1.0dev
Don't AreaTreeModel.getPageSequenceCount() and AreaTreeModel.getPageCount(int seq) do this? AreaTreeHandler.model is the AreaTreeModel object. Simon On Wed, Jul 27, 2005 at 08:43:50AM +0200, Jeremias Maerki wrote: Manuel, thanks for grabbing this. I think the easiest thing will be to recreate what was in 0.20.5. It doesn't offer very much and I have a better overall mechanism in mind (as a long-term solution) but for the moment it is easiest to do that. Here's what I would do: - Copy over FormattingResults and PageSequenceResults over from 0.20.5 and replace the license header with the once you find all over FOP Trunk. - Go to org.apache.fop.area.AreaTreeHandler.endPageSequence() and build up the FormattingResults structure as it's done in 0.20.5 in StreamRenderer. AreaTreeHandler is more or less the old StreamRenderer. - When endPageSequence() is called you can probably derive the number of pages generated for a page-sequence by subtracting currentPageNumber from startPageNumber in layoutmgr.PageSequenceLayoutManager. - Find a way to access the FormattingResults structure in Fop.java like it was done in 0.20.5. As an alternative to doing this in AreaTreeHandler you might want to investigate fo.Root and fo.PageSequence but I'd prefer to have stuff like that in AreaTreeHandler. I hope that gives you some hints to do this. It shouldn't really be that hard. On 27.07.2005 08:13:58 Manuel Mall wrote: Jeremias, happy to do so - I just setup Fop under NetBeans 4.1. However, where do I start for something like this? Manuel PS: I moved this thread over to fop-dev as I assume its more appropriate here. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, 27 July 2005 14:08 To: fop-users@xmlgraphics.apache.org Subject: Re: getPageCount and FOP 1.0dev No, but you're welcome to help improve the situation. :-) On 27.07.2005 03:50:46 Manuel Mall wrote: Jeremias post on fop-dev suggesting to push for a release made me curious to check out if the new trunk code will work with our application. Downloading it with subversion and building it with ant was not a big problem (These things never seem to be 100% straightforward). Some of the interfaces have changed and what was ...apps.Driver is now sort of ...apps.Fop. Not such a big deal especially as examples exist, just a nuisance if you only want to see if the new trunk code works with what we have got as it means code changes to existing code. However I am stuck with how to replace the old driver.getResults().getPageCount(). Is there something equivalent in 1.0dev? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: getPageCount and FOP 1.0dev
Right. I forgot that the AreaTreeModel keeps track of the page sequences. On 27.07.2005 21:41:27 Simon Pepping wrote: Don't AreaTreeModel.getPageSequenceCount() and AreaTreeModel.getPageCount(int seq) do this? AreaTreeHandler.model is the AreaTreeModel object. Simon On Wed, Jul 27, 2005 at 08:43:50AM +0200, Jeremias Maerki wrote: Manuel, thanks for grabbing this. I think the easiest thing will be to recreate what was in 0.20.5. It doesn't offer very much and I have a better overall mechanism in mind (as a long-term solution) but for the moment it is easiest to do that. Here's what I would do: - Copy over FormattingResults and PageSequenceResults over from 0.20.5 and replace the license header with the once you find all over FOP Trunk. - Go to org.apache.fop.area.AreaTreeHandler.endPageSequence() and build up the FormattingResults structure as it's done in 0.20.5 in StreamRenderer. AreaTreeHandler is more or less the old StreamRenderer. - When endPageSequence() is called you can probably derive the number of pages generated for a page-sequence by subtracting currentPageNumber from startPageNumber in layoutmgr.PageSequenceLayoutManager. - Find a way to access the FormattingResults structure in Fop.java like it was done in 0.20.5. As an alternative to doing this in AreaTreeHandler you might want to investigate fo.Root and fo.PageSequence but I'd prefer to have stuff like that in AreaTreeHandler. I hope that gives you some hints to do this. It shouldn't really be that hard. On 27.07.2005 08:13:58 Manuel Mall wrote: Jeremias, happy to do so - I just setup Fop under NetBeans 4.1. However, where do I start for something like this? Manuel PS: I moved this thread over to fop-dev as I assume its more appropriate here. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, 27 July 2005 14:08 To: fop-users@xmlgraphics.apache.org Subject: Re: getPageCount and FOP 1.0dev No, but you're welcome to help improve the situation. :-) On 27.07.2005 03:50:46 Manuel Mall wrote: Jeremias post on fop-dev suggesting to push for a release made me curious to check out if the new trunk code will work with our application. Downloading it with subversion and building it with ant was not a big problem (These things never seem to be 100% straightforward). Some of the interfaces have changed and what was ...apps.Driver is now sort of ...apps.Fop. Not such a big deal especially as examples exist, just a nuisance if you only want to see if the new trunk code works with what we have got as it means code changes to existing code. However I am stuck with how to replace the old driver.getResults().getPageCount(). Is there something equivalent in 1.0dev? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
Re: Element list generation for tables (special case)
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote: Hi, I got a test case for tables which raises not a technical but rather a interesting conceptual question. Please have a look at the attached test case. It defines a table with two columns and two rows. In the given setup the second row creates an break decision with the current code that can be argued as being bad (see the PDF). Indeed, doesn't look right. Given the value for the orphans property, one still would reasonably expect the break to occur before the first cell of the second row. BTW: tried adding a third column mirroring the first, and this leads to ONLY the second column being moved to the next page... This as a further demonstration that the currently produced result still leaves a bit to be desired. (see attach) Here's an excerpt from the element list: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=0 //-- this is where the second row starts 13) penalty p=0 w=9600 //this penalty is due to the possible break after B 14) box w=28800 15) penalty p=0 w=0 //this is the next break poss after three lines //due to the orphan setting 16) box w=28800 While working on element list generation for tables I came across this question and decided not to do anything about it, especially since removing some of these break possibilities might not be desirable in all cases. A rule that could be easily implemented would be that we allow the first break possibility only after every cell in a new row contributed at least one of its own boxes to the combined element list. So IOW, if I get this correctly: all break possibilities are to be considered preliminary until the last cell occupying this row (= last grid-unit in the row) has been taken into account? An example: If you look at page 1 of [1], step 1 would over ignored. On page 3 of [1], the steps 1 and 2 would be ignored. [1] http://people.apache.org/~jeremias/fop/ KnuthBoxesForTablesWithBorders.pdf Hmm... Do you mean that the steps would be performed but their results discarded, or that the steps simply would not be performed at all? I'd think the first, but just want to make sure... Are the break possibilities currently considered only at the level of the table body --so the element list contains the elements for the cells' boxes, but no separate elements/indicators of row-boundaries? In that case --with the risk of underestimating the complexity of what I propose--, perhaps an alternative to the suggested rule would be to insert a step that combines the generated boxes/penalties only after the element list for the last grid unit in a logical row has been created (?) Anyway, instead of simply ignoring those steps, we could also increase the penalty value for the offending break possibility (currently: p=0 for all of them) So, IOW, for each row, store the element lists, and after all lists are available, review the calculated penalty values, increasing them when a given break possibility has undesirable consequences when the other element lists for the row are taken into account. Or the other way around: give them a default penalty value that is high enough, then afterwards decreasing them for the most favorable break possibilities. Or modify all boxes' widths (=heights) to be equal to the largest box. After this step is completed, add the combined element list to the body. IIC, the two separate element lists for the second row would be: First grid unit: 1) box w=9600 2) penalty p=0 w=0 Second grid unit: 1) box w=28800 2) penalty p=0 w=0 So, compare the first boxes' widths and, since the first box in the first list is smaller than that in the second list, either increase the penalty value for the second step in the first list, or change the width of the first box in the first list. Maybe the latter is more attractive, since the resulting combined list can then be created by concatenating the two separate lists... [Admitted: this particular case is rather simple, since both lists only have one box.] Then combine the lists to arrive at the result below: With this rule the element list would look like this: snip / 12) box w=28800 //-- this is where the second row starts 13) penalty p=0 w=0 14) box w=28800 I'm unsure ATM what this would mean for cases with row spanning, though. As long as the criterion is that every _grid unit_ for the (logical) row in question must have contributed at least one box, I wouldn't expect any particular problem. I can see that this new rule would make this better in most cases. What worries me is that there might be cases where we wouldn't want that behaviour, although ATM I can't see them. So I just want to check with you that I haven't forgotten about anything. Or maybe someone has a better rule to implement this. Thoughts welcome. Greetz, AD
Re: Element list generation for tables (special case)
Sorry, forgot the attachment... table-body4b.xml.head.pdf Description: Adobe PDF document On Jul 27, 2005, at 23:26, Andreas L Delmelle wrote: On Jul 27, 2005, at 20:45, Jeremias Maerki wrote: Hi, I got a test case for tables which raises not a technical but rather a interesting conceptual question. Please have a look at the attached test case. It defines a table with two columns and two rows. In the given setup the second row creates an break decision with the current code that can be argued as being bad (see the PDF). Indeed, doesn't look right. Given the value for the orphans property, one still would reasonably expect the break to occur before the first cell of the second row. BTW: tried adding a third column mirroring the first, and this leads to ONLY the second column being moved to the next page... This as a further demonstration that the currently produced result still leaves a bit to be desired. (see attach) Here's an excerpt from the element list: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=0 //-- this is where the second row starts 13) penalty p=0 w=9600 //this penalty is due to the possible break after B 14) box w=28800 15) penalty p=0 w=0 //this is the next break poss after three lines //due to the orphan setting 16) box w=28800 While working on element list generation for tables I came across this question and decided not to do anything about it, especially since removing some of these break possibilities might not be desirable in all cases. A rule that could be easily implemented would be that we allow the first break possibility only after every cell in a new row contributed at least one of its own boxes to the combined element list. So IOW, if I get this correctly: all break possibilities are to be considered preliminary until the last cell occupying this row (= last grid-unit in the row) has been taken into account? An example: If you look at page 1 of [1], step 1 would over ignored. On page 3 of [1], the steps 1 and 2 would be ignored. [1] http://people.apache.org/~jeremias/fop/ KnuthBoxesForTablesWithBorders.pdf Hmm... Do you mean that the steps would be performed but their results discarded, or that the steps simply would not be performed at all? I'd think the first, but just want to make sure... Are the break possibilities currently considered only at the level of the table body --so the element list contains the elements for the cells' boxes, but no separate elements/indicators of row-boundaries? In that case --with the risk of underestimating the complexity of what I propose--, perhaps an alternative to the suggested rule would be to insert a step that combines the generated boxes/penalties only after the element list for the last grid unit in a logical row has been created (?) Anyway, instead of simply ignoring those steps, we could also increase the penalty value for the offending break possibility (currently: p=0 for all of them) So, IOW, for each row, store the element lists, and after all lists are available, review the calculated penalty values, increasing them when a given break possibility has undesirable consequences when the other element lists for the row are taken into account. Or the other way around: give them a default penalty value that is high enough, then afterwards decreasing them for the most favorable break possibilities. Or modify all boxes' widths (=heights) to be equal to the largest box. After this step is completed, add the combined element list to the body. IIC, the two separate element lists for the second row would be: First grid unit: 1) box w=9600 2) penalty p=0 w=0 Second grid unit: 1) box w=28800 2) penalty p=0 w=0 So, compare the first boxes' widths and, since the first box in the first list is smaller than that in the second list, either increase the penalty value for the second step in the first list, or change the width of the first box in the first list. Maybe the latter is more attractive, since the resulting combined list can then be created by concatenating the two separate lists... [Admitted: this particular case is rather simple, since both lists only have one box.] Then combine the lists to arrive at the result below: With this rule the element list would look like this: snip / 12) box w=28800 //-- this is where the second row starts 13) penalty p=0 w=0 14) box w=28800 I'm unsure ATM what this would mean for cases with row spanning, though. As long as the criterion is that every _grid unit_ for the (logical) row in question must have contributed at least one box, I wouldn't expect any particular problem. I can see that this new rule would make this better in most cases. What worries me is that there might be cases where we wouldn't want that behaviour, although ATM I can't see them. So I just want to check with you
Re: Flame-fodder: Thinking about starting to release again....
J.Pietschmann schrieb: Jeremias Maerki wrote: I don't know of any such convention. I've seen various variants: rc, beta, previews etc. I think we're free to choose. I'd rather go for alpha. rc means release candidate, meaning Yes 0.90-alpha sounds like version number Christian
