date:20040105

Andreas L. Delmelle wrote:

Hi Andreas,

i hope you dont mind a little feedback on this.

snip/

Well, this is as far as I got (--actually, now I think at least column-span
is solved fully. Then again, so I did the first time ;)
In ascending order of importance:

1. In a number of methods in fop.layoutmgr.Row, I encountered the following
declaration:
  int size = columns.size();
I would make this an instance variable in this case, so it gets declared
only once for every row LM, instead of with each call to the LM's
getNextBreakPoss() or addAreas() (--and inside a while-loop: there would
have to be a *very* good reason for this. I see none in particular.)
(Also, but this I'm absolutely not sure about, is it *really* necessary to
be able to access the columns as objects at row level? For now, only their
widths seem to be used/referenced, so we might be able to use an array of
ints containing just these... Not that it's totally unimaginable that we
need to access other props, but we could always provide accessor methods for
them in the Row's parentLM. After all, they *are* in fact direct descendants
of the fo:table in XSL-FO...)
I would hold off on removing the column objects from the row LM until 
after a design for auto table layouts and border collapsing has been at 
least considered.

2. Add colspan and rowspan instance variables to the cell LM, to store the
column/row-spanning properties of the corresponding fop.fo.flow.TableCell.
Also add accessor methods for these, so they can be referenced from within
the row LM. (see further)
3. Add a cspanPrev instance variable to the cell LM, to store the number of
columns spanned by the previous cells in the same row (-- or previous rows,
in case of rowspan). 
what about when a cell spans both rows and columns? perhaps two 
variables cspanPrev and rspanPrev would be a better approach here?

For this variable, a setter would also have to be
provided to allow the row LMs to alter it. When a given cell with index i in
the current row spans m multiple rows, the values of the proposed variable
can then be increased for the cells with index = i for the next m - 1 rows,
increased by the value colspan - 1 of the current cell.
4. (This as a result of my altering the code in fop.layoutmgr.Row; found
myself typing up the same loop and needing it another time, so) Add a
convenience method to the row LM, say :
private int computeCellRefIPD( int cellidx ) {...}

which roughly contains the loop in the invalid (excuse for a) patch I
submitted a few days ago, with the necessary corrections.
This function would calculate the reference IPD of a given cell. In
combination with the above suggestions, the result will take into account:
- the column-spanning of the cell itself
- the row-spanning of cells in previous rows (and their column-spanning), so
effectively using the right base column for every cell
The things I'm still looking for are
- the correct adjustment for the cell LM's height in case of rowspan
- the adjustment for the x-coordinate of the cells affected by a rowspan
- some vague problems wrt breaks/keeps I can't seem to describe yet (a
gut-feeling, as they say)
Can't be that hard... Naively tried (rowHeight * rowspan) for the first, but
this obviously doesn't work in case one of the related rows is higher than
the current :)
Expect a new patch proposal soon!

The rest of what you propose sounds good.

Chris

Re: More on row and column span (was: RE: (Changing Vote) etc.)

Andreas L. Delmelle wrote:

Another detail overlooked is the column-number property, ...


Which is, for the moment quite ... unimplemented (--should've checked this
sooner :) ), so that explains why the spec isn't being followed when setting
the default value to 0.
This makes me think that much of colspan and rowspan could already be
managed at FO Tree level, so the LM's already get supplied the correct value
at least for colnr from interrogating their FObj. I would judge this
approach to be much cleaner... Any thoughts on this?
it would be easy to determine col number in Table.addChild. This number 
could then be replaced in TableColumn.doSetup only if Column Number has 
actually been specified in the FO. I'm not sure I would be keen on 
working out any spanning related stuff in the FO Tree classes as it 
seems the wrong place for such computations. But that is just an opinion.

With the current modifications I have made to the cell  row LM's (--more on
these soon), it should work... when support for the column-number property
would be available. That is: for the moment, I have column-span working
correctly apart from the fact that the column-number is always 0. If this is
not the case, as I could see when hacking this support into the row LM in
setupCells(), the cellIPD and xoffset for the following cells are being
calculated correctly, based upon the correct table-column. (This was done in
such a way that we can easily pick up the column-number from the
corresponding TableCell afterwards, if and when we figure out how to
correctly set the defaults for this.)
Understood.

The RowSpanMgr in maintenance *is* indeed very interesting... still no luck
here, though
I dont follow, could you elaborate?

Chris

Re: More on row and column span (was: RE: (Changing Vote) etc.)

Andreas L. Delmelle wrote:

-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
I guess the riddle I'm still trying to solve is:
How do I access the LM's for the subsequent rows at this point?


AFAICT, I have overlooked (at least) the following note in the spec (6.7.1
Table Formatting Objects - Introduction):
- a cell that is spanned may have a different background in each of the grid
units it occupies
Ahh... I can see why this would complicate things somewhat. Perhaps you 
could still just have a single Cell occupying each grid unit but allow 
each LM to render multiple backgrounds.

Reading this, I'm totally unsure of the solution I have proposed... As it
is, I think it would 'expand' the background props in the first grid unit,
and use them as background for the whole spanned cell. In order to achieve
this effect, it may be necessary to have the body LM add dummy cells to the
following rows.
So the child areas of a spanned cell need to be laid out to fill the full
range the cell spans, while the specified background may only be used on the
first grid unit... Quite a bit harder than I initially thought, but we'll
keep looking.
Another detail overlooked is the column-number property, which would
perfectly fulfill the role of my proposed cspanPrev variable. It is defined
in TableCell, but not according to the default defined in the spec.
(It's set to 0, but should be set to:
q the first column to be spanned by the table-cell. The initial value is
the current column-number. For the first table-cell in a table-row, the
current column is 1. For other table-cells, the current column-number is the
column-number of the previous table-cell in the row plus the number of
columns spanned by that previous cell. /q)
I didnt read your posts in the correct order, so my earlier reply on 
column-number is meaningless, sorry. I was thinking of TableColumn not 
the TableCell. But you could still work out column number in the FO Tree 
classes as you proposed. You may want to override the FObj.addChild 
method on TableRow in a similar manner to the Table class.

In the meantime, if anyone can provide me with any pointers, be sure to post
them!
(C'mon, ya layout-geeks, where are you? :) )
Chris

PropertySets

Glen,

Ive just noticed that the PropertySets class uses methods on 
java.util.bitset that only exist since JDK 1.4. Namely:

cardinality
nextBitSet
So you can no longer build with 1.3

Chris

DO NOT REPLY [Bug 25900] New: - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer

   Summary: [PATCH] dotted/dashed borders in PDF Renderer
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Ive changed the PDF Renderer to get style=dotted and style=dashed working 
for borders.

Instead of using the PDF command re I have used lines with m and l commands, 
and set the width and line style prior to issuing the commands.

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 13:58 ---
Created an attachment (id=9810)
Resulting PDF before patch applied

Regression caused by the string-int conversion

2004-01-05 Thread Finn Bock

  --- PropertyList.java 5 Jan 2004 00:44:59 -   1.19
  +++ PropertyList.java 5 Jan 2004 01:31:09 -   1.20
  @@ -184,20 +184,11 @@
*/
   public Property getExplicitOrShorthand(int propId) {
   /* Handle request for one part of a compound property */
  -String propertyName = FOPropertyMapping.getPropertyName(propId);
  -
  -int sepchar = propertyName.indexOf('.');
  -String baseName;
  -if (sepchar  -1) {
  -baseName = propertyName.substring(0, sepchar);
  -} else {
  -baseName = propertyName;
  -}
  -Property p = getExplicitBaseProp(baseName);
  +Property p = getExplicitBaseProp(propId  Constants.PROPERTY_MASK);
   if (p == null) {
   p = getShorthand(propId  Constants.PROPERTY_MASK);
   }
  -if (p != null  sepchar  -1) {
  +if (p != null  (propId  Constants.PROPERTY_MASK) != 0) {
   return getSubpropValue(p, propId);
   }
Glen, I think that the last 3 statements should read:

   +if (p != null  (propId  Constants.COMPOUND_MASK) != 0) {
return getSubpropValue(p, propId);
}
after all, the subprop should only be retrived when the propId also
includes a subproperty.
Also, there is a bit of a mixup wrt. the signature of the
Maker.setSubprop() method. The generated makers (eg. GenericSpace)
overrides
   setSubprop(Property, int, Property)
while the base method in Property.Maker defines and calls:
   setSubprop(Propertu, String, Property)
Something along these lines will fix the setSubprop issue:

--- src/java/org/apache/fop/fo/Property.java5 Jan 2004 00:44:59 -   1.9
+++ src/java/org/apache/fop/fo/Property.java5 Jan 2004 13:33:43 -
@@ -192,7 +192,8 @@
 if (spMaker != null) {
 Property p = spMaker.make(propertyList, value, fo);
 if (p != null) {
-return setSubprop(baseProp, partName, p);
+int partId = FOPropertyMapping.getSubPropertyId(partName);
+return setSubprop(baseProp, partId, p);
 }
 } else {
 //getLogger().error(compound property component 
@@ -215,7 +216,7 @@
  * component to be set.
  * @return The modified compound property object.
  */
-protected Property setSubprop(Property baseProp, String partName,
+protected Property setSubprop(Property baseProp, int parId,
   Property subProp) {
 return baseProp;
 }

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 13:58 ---
Created an attachment (id=9811)
resulting PDF after patch applied

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 13:59 ---
Created an attachment (id=9812)
not forgetting the test fo

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 14:16 ---
I'm unable to apply the patch. There seems to be, I dunno, an extra linefeed at 
the end of each of the lines that you have added?

When I look at the first chunck, there are 3 lines above your addition and
4 below. My version of 'patch' doesn't like that at all.

@@ -92,6 +92,7 @@
 import org.apache.fop.datatypes.ColorType;
 import org.apache.fop.fo.properties.BackgroundRepeat;
 import org.apache.fop.fo.properties.RuleStyle;
+import org.apache.fop.fo.Constants;

 import org.apache.fop.fonts.Typeface;
 import org.apache.fop.fonts.Font;
 import org.apache.fop.fonts.FontSetup;
@@ -578,7 +579,6 @@

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 14:22 ---
Created an attachment (id=9813)
cleaned up patch

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 14:24 ---
Hi Finn,

thanks for spotting that. Not sure what caused it. Weve been forced to upgrade 
to JBuilder 9 at work and I'm having all sorts of trouble with it. Anyway, I 
manually editted the patch removing the erroroneous LFs. Hopefully this will 
fix the issue.

RE: Draft discussion of Federation proposal

2004-01-05 Thread Thomas DeWeese

Hi Andreas, Jeremias,

Jeremias Maerki [mailto:[EMAIL PROTECTED]:

Concerning the proposed TLPs I'm wondering if FOP and Batik shouldn't go
together somehow. Both projects deal with XML to graphics conversions.
FOP currently has 2 Batik Transcoder implementations (additional output
formats for Batik: PDF, PS/EPS). So there is some kind of overlap which
needs to be dealt with sooner or later. One possibility is to move the
transcoders over to Batik but parts of them are FOP-specific so both
projects should somehow be able to work on the common code. Moving these
out of FOP still means a dependency on FOP's PDF, PostScript and font
support code. These might need to be separated into Commons projects
to be accessible to both projects and to ensure compatibility and
cooperation.
Andreas L. Delmelle [EMAIL PROTECTED] wrote:

I agree, and don't want to come across as greedy here, but when it comes to
use-cases, fact remains that you can have XSL-FO w/ embedded SVG, but not
the other way around. 
   True, but SVG was designed to be embedded in another document.
How are you going to deal with master pages etc if you try and
embed XSL-FO in SVG?  I'm not saying it couldn't be done but it would
involve inventing stuff that is in neither of the two specifications
(this is something that I find is generally a bad idea unless you are
an active participant in the standards groups and are in a position to
advance the standard[s]).
   XSL-FO is designed as a container language so I don't think it
makes sense, in general, to talk about embedding XSL-FO in SVG.  That
said the Batik architecture is extremely extensible, there would be
no problem with registering bridges for XSL-FO tags and building
a FOP rendering tree within the SVG tree - assuming you could make
sense of what that XSL-FO subtree should look like.
(and for that matter: AFAICT XSL-FO can be rendered to
SVG, but not the other way around... this could, of course, change if the
two projects in question were merged somehow) 
   Short of just generating a small XSL-FO wrapper around the SVG
content, how are you going to rendering SVG into XSL-FO?  AFAIK there
is no way to draw a poly-bezier or gradient in XSL-FO - you have to
use SVG or some other image format to do this.  Conversely,
SVG has quite advanced text rendering capabilities.  In other words
the _rendering_ model of SVG is AFAIK a strict super-set of XSL-FO,
with respect to layout SVG is much poorer than XSL-FO.
   To put this another way SVG is a 'lower level' tool than XSL-FO.
In many ways SVG is just a XML based rendering API, XSL-FO is a
document format, so I consider it quite natural that the relationship
is asymmetrical.
On top of that, judging solely from user-list traffic, [...] I definitely
see this as a pointer to the wideness of usage.
   I fail to see how this has any bearing on the decision to merge or
not (other than if we merge Batik users will be swamped by all this 
FOP traffic - a 33% increase is very different from a 400% increase in
mail volume - people will drop the ML I am certain)

I certainly support the idea of integrating the two projects one way or
another. 
   As do I, but I don't think it is a good idea to totally merge two
completely independent standards implementations.  If we could come up
with a good name for a merged TLP with Batik and FOP under it that
would probably be fine with me ( graphics? rendering? display?).  This
may be what you had in mind but your mention of the merged users list
makes me think otherwise.
   Another huge issue here is that for all intents and purposes
static content rendering is done for Batik.  All the work needed in
Batik is for supporting dynamic documents.  This is something FOP
doesn't begin to think about - and FOP developers essentially
don't benefit from and hence are not likely to contribute to.
   I agree that the current situation with the transcoders is
very problematic, I've even put together some ideas on what to do
about it in the past.  The correct solution I think is to separate
out all the Graphics2D implementations (SVG, PDF, PS) into a separate
common project and let both projects draw on that.
   Right now the biggest issue is that the PDF/PS stuff is deeply
ingrained in FOP due to Font stuff.  IMHO this means that the
Font stuff should either be made pluggable (so FOP can extend the
base PDF font stuff) or totally separated from FOP so anyone who
want's to use the PDF graphics can do so without FOP.  The SVG
Graphics2D is already essentially independent of the rest of Batik
(there are some dependencies on utility/constant classes).
As I understand, there's a bunch of talented developers at
batik-dev, so I would certainly welcome a closer cooperation between the two
teams. 
   Right now I am the only active committer for Batik, and in 2004
I currently have no 'work time' allocated for it.  As a result I don't
want to make a huge fuss as it is unclear how much I will be able to
contribute to implementing what ever the

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 16:42 ---
Created an attachment (id=9815)
Testcase .fo which shows the regressions.

RE: Draft discussion of Federation proposal

 -Original Message-
 From: Thomas DeWeese [mailto:[EMAIL PROTECTED]
 
snip /
 
 I think a combined user-list would be a disaster.  In general I
 think the people who need to know about SVG get told about Batik and
 the people who need to know about XSL-FO get told about FOP if they
 wander into the wrong group.
 
 

Bummer! But I guess I'm the worse judge here, so never mind my fb...


Cheers,

Andreas

RE: Row and Colspan

 -Original Message-
 From: Chris Bowditch [mailto:[EMAIL PROTECTED]

 Hi Andreas,

 i hope you dont mind a little feedback on this.


Hi Chris,

Not at all! Thanx for the fine input. I'll definitely get a lot closer to
what I'm (and FOP is) after. (Support for the number-columns-spanned,
number-columns-repeated and column-number is indeed *very* easily added to
Table.addChild(), for columns, but that gets us more than halfway there).

Another, property-related question (not specifically for you, Chris, but
*if* you have an idea...):
Is it the intention that the 'Table Properties' are in someway moulded into
a class (like now the Common*Properties are), or is the way I see them
defined/used now in the relevant classes in fop.fo.flow the intended
end-result?


Later,

Andreas

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 17:23 ---
Created an attachment (id=9818)
rev3 of patch

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 17:26 ---
Finn,

Ive got to bottom of what JBuilder was doing so there shouldnt be any problems 
with LFs in this patch.

1) Ive fixed the problem with color. the color was being changed for fill but 
the change requires the use of stroking. So now the color changes for stroking 
ops.
2) I knew this wasnt quite right, but then I didnt think it was quite right 
before. Ive had a play with the positions so that they do not overlay the 
inner text. If you want me to change it again I'm happy to, just provide the 
specifics of what you want.

Re: Row and Colspan

Andreas L. Delmelle wrote:

snip/
Another, property-related question (not specifically for you, Chris, but
*if* you have an idea...):
Is it the intention that the 'Table Properties' are in someway moulded into
a class (like now the Common*Properties are), or is the way I see them
defined/used now in the relevant classes in fop.fo.flow the intended
end-result?
The LayoutMgr classes makes use of the Common*Properties for Table 
objects. They are created by the FO Tree classes (see Table.setup for 
example) Are you asking if they should be created at the same time the 
FO tree is built?

A quick look at fo.flow.Block makes me believe they probably all work 
like this. I'm not sure what the pros/cons of changing it would be, but 
if it aint broke, why fix it?

Chris

RE: More on row and column span (was: RE: (Changing Vote) etc.)

 -Original Message-
 From: Chris Bowditch [mailto:[EMAIL PROTECTED]

snip /
 it would be easy to determine col number in Table.addChild. This number
 could then be replaced in TableColumn.doSetup only if Column Number has
 actually been specified in the FO. I'm not sure I would be keen on
 working out any spanning related stuff in the FO Tree classes as it
 seems the wrong place for such computations. But that is just an opinion.


No, I guess you're right that the computations themselves should be left to
Layout, although *that* seems a bit silly if the respective property values
are already given in their absolute form at parse time.

To explain what I do see handled at FOTree level: in case of rowspan (r),
the cells with index = the current cell in the subsequent (r-1) rows should
have their column-number increased by a value of colspan. I think this could
definitely be tracked when the FOTree is built...

Then further on in the Layout process, the xoffsets for all cells in the row
can be very quickly derived from the column-number ( sum of all
column-widths  cell-column-number )

snip /

 
  The RowSpanMgr in maintenance *is* indeed very interesting...
 still no luck
  here, though


Maintenance has a class (lemme see, ...) in fop.fo.flow called RowSpanMgr,
which I don't see reappearing in HEAD (unless someone has put it in a less
obvious location... Glen? You been moving some stuff around again??? ;) Jus'
kidding, of course...)
This class seems to be used to keep track of all rowspans. Haven't studied
in detail yet, but I guess one of these gets created for every table
(body/header/footer?), and it looks like the kind of thing I had in mind to
handle rowspans, so lucky me :)

Does anyone recall a thread where such was discussed? Or were tables
something 'to be figured out at an indefinite point in the future'? Well
then: No time like the present!


Cheers,

Andreas

RE: Row and Colspan

 -Original Message-
 From: Chris Bowditch [mailto:[EMAIL PROTECTED]
snip /
 Are you asking if they should be created at the same time the
 FO tree is built?


Not exactly. I'm referring to the grouping into CommonBorderAndPadding /
CommonMargin etc.

There is also a group of TableProperties in the spec, but the properties
seem to be treated rather loosely instead of being handled together in a
group, like the others.

 A quick look at fo.flow.Block makes me believe they probably all work
 like this. I'm not sure what the pros/cons of changing it would be, but
 if it aint broke, why fix it?

Nothing broke, but just checking to see if there's unfinished business in
there.


Cheers,

Andreas

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

[PATCH] dotted/dashed borders in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 19:02 ---
Regarding the positioning of the border, there is a number of missing pieces in 
both the rendere and layout. And I believe that the problem can't be fixed only 
in PDFRendere.
I've assumed that the rectangle given to drawBackAndBorder() was (or should be) 
the border rectangle of a block area.

  http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#area-geo

If that assumption holds, and I think it does, then the original placement of 
the border was correct.

I've tried to fix some of the remaining issues regarding position of borders in 
this patch:
   http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25802

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

2004-01-05 Thread Simon Pepping

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

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

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

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

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

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

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

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

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

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

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

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

Regards, Simon

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

cvs commit: xml-fop/src/java/org/apache/fop/fo PropertyList.java

2004-01-05 Thread gmazza

gmazza  2004/01/05 14:02:47

  Modified:src/java/org/apache/fop/fo PropertyList.java
  Log:
  COMPOUND_MASK/PROPERTY_MASK bug fixed in PropertyList.java (patch by Finn Bock).
  
  Revision  ChangesPath
  1.21  +1 -1  xml-fop/src/java/org/apache/fop/fo/PropertyList.java
  
  Index: PropertyList.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/PropertyList.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- PropertyList.java 5 Jan 2004 01:31:09 -   1.20
  +++ PropertyList.java 5 Jan 2004 22:02:47 -   1.21
  @@ -188,7 +188,7 @@
   if (p == null) {
   p = getShorthand(propId  Constants.PROPERTY_MASK);
   }
  -if (p != null  (propId  Constants.PROPERTY_MASK) != 0) {
  +if (p != null  (propId  Constants.COMPOUND_MASK) != 0) {
   return getSubpropValue(p, propId);
   }
   return p;
  
  
  

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

cvs commit: xml-fop/src/java/org/apache/fop/fo Property.java

2004-01-05 Thread gmazza

gmazza  2004/01/05 14:13:19

  Modified:src/java/org/apache/fop/fo Property.java
  Log:
  Switch from strings-ints in Property.setSubprop()  (from Finn Bock).
  
  Revision  ChangesPath
  1.10  +4 -3  xml-fop/src/java/org/apache/fop/fo/Property.java
  
  Index: Property.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Property.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- Property.java 5 Jan 2004 00:44:59 -   1.9
  +++ Property.java 5 Jan 2004 22:13:19 -   1.10
  @@ -192,7 +192,8 @@
   if (spMaker != null) {
   Property p = spMaker.make(propertyList, value, fo);
   if (p != null) {
  -return setSubprop(baseProp, partName, p);
  +int partId = FOPropertyMapping.getSubPropertyId(partName);
  +return setSubprop(baseProp, partId, p);
   }
   } else {
   //getLogger().error(compound property component 
  @@ -210,12 +211,12 @@
* compound properties.
* @param baseProp The Property object representing the compound property,
* such as SpaceProperty.
  - * @param partName The name of the component whose value is specified.
  + * @param partId The ID of the component whose value is specified.
* @param subProp A Property object holding the specified value of the
* component to be set.
* @return The modified compound property object.
*/
  -protected Property setSubprop(Property baseProp, String partName,
  +protected Property setSubprop(Property baseProp, int partId,
 Property subProp) {
   return baseProp;
   }
  
  
  

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

Re: Regression caused by the string-int conversion

2004-01-05 Thread Glen Mazza

Fixed.  Thanks.

Glen

--- Finn Bock [EMAIL PROTECTED] wrote:


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: PropertySets

2004-01-05 Thread Peter B. West

Chris Bowditch wrote:
Glen,

Ive just noticed that the PropertySets class uses methods on 
java.util.bitset that only exist since JDK 1.4. Namely:

cardinality
nextBitSet
So you can no longer build with 1.3

Chris
Chris,

Thanks for pointing this out.  I had not noticed when I was using the 
functionality (and very useful functionality it is.)

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html

DO NOT REPLY [Bug 25900] - [PATCH] dotted/dashed borders in PDF Renderer