You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Petr Andrs <pa...@artax.karlin.mff.cuni.cz> on 2001/08/02 14:24:25 UTC
problems with height of cells in tables
Please see attached file. There is table with three lines, which all
should have equal height. But they haven't, the last one has lower
height than the other two. (Or the fist two have greater height than
the las one) I would expect all three lines to look something like the
last one, the first two are too high for my eye.
Petr
Table Status (was Re: problems with height of cells in tables)
Posted by Karen Lease <kl...@club-internet.fr>.
Hi Arved (and other interested parties),
Lots of other bugs (like the inline-area height) show up well in tables
because the grid makes things visible. That's the case with the trailing
white-space bug I saw the other day, resulting in an empty table row.
Some of these can also be shown by using border, padding and background
on fo:block, which also needs more test cases.
I think base-level table functionality has gotten considerably better,
and we need to publicize that with the next release, since there have
been so many problems in the past releases. Of course, I know there are
still a number of bugs, but I think the row-spanning, vertical alignment
and general border-handling improvements should help lots of people.
Off the top of my head, here are major areas for work:
1. border-collapse=collapse. There is a partial bandaid for this now.
I've written a lot of pseudo-code for this, as the general case is quite
complex. It should take into account cell, row and column borders
(though I'd like to see the final word in the PR on this). As often, I
ran up against the problem of handling the break conditions, since that
can affect the borders. But unless someone else has done lots of work
here or has some easy improvements, I'd like to keep it on my plate
(after vacation).
2. Keeps and breaks. There are some cases where breaks cause problems;
as I recall the culprit is in table-body. I know the general problem of
keeps can't really be handled, but tables are a particularly sore point
for that. It's worth trying to do keep-together for table-row; actually
I think I did a first pass on this when I did spans.
3. Handling limit conditions, like table-row with keeps but which
doesn't fit on the page.
4. Indents. Just looked at Koen's bug, which involves the indents not
affecting the table itself, but rather the cell content. My reading of
the CR is that the areas created by fo:table are block areas and should
be positioned by indents. Lots of people also want to center their
tables; I can't figure out how this is supposed to happen, unless it's
in table-and-capation.
5. The table-and-caption fo.
6. Row-less tables using start-row and end-row properties on the cells.
I think this can be handled in addChild for the table-body by creating
"fake" TableRow objects as needed.
7. Automatic table layout style (this is a fairly big deal). Or at least
really implement the percentage stuff, which would be simpler and still
quite flexible. This needs some work in calculating the column widths
once the size of the containing reference area is known.
8. The relative-align style for vertical alignment. Needs
post-processing once all cells in the row are done. Might as well wait
until we get our line-stacking straightened out.
That should keep people thinking for a while...
There are also a few remarks below. I'll be away from my Internet access
for a while, so this is probably it for now. Overall the idea seems
good. Obviously if I've temporarily let go of bottom-up layout, it was
to try to reduce the volume of table-related complaints.
Regards and "a bientot"
Karen
Arved Sandstrom wrote:
>
> Hi, Karen (and other interested parties)
>
> A thought occurred to me just now. A high percentage of our bandwidth (and
> bug reports) are devoted to tables. There are so many table-related bug
> reports mainly because so many folks want to use tables, I believe, not
> because there are more bugs in tables than elsewhere.
>
> I'm thinking that perhaps we can use table support as the centrepiece for
> all of our FOP efforts. In order to have tables be fully supported, and work
> properly, a really big percentage of the XSL specification (and FOP
> mechanics) gets exercised. Redesign of layout is something of a fuzzy goal;
> making tables work isn't.
>
> You've currently got probably the best perspective on tables. What I am
> thinking would be useful would be a report concerning table FOs, with a
> property-by-property breakdown, that assesses what works, and what doesn't,
> and what needs to happen in order to make things work. This could drive a
> whole bunch of tasks that people could take on. It would be easier to gauge
> the progress of FOP, because table support would be a bellwether for FOP as
> a whole.
>
> This doesn't mean that everything else would be ignored. But the shift of
> emphasis would be as follows: if I want to work on markers, I make sure that
> they work inside fo:table-and-caption, fo:table, fo:table-caption,
> fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If
> someone wants to make sure FO X works, they make sure it works also as a
> descendant of fo:table-cell. Keiron has laid the groundwork for testing - a
> really suitable area for a first comprehensive set of test-cases could be
> (you guessed it) tables! :-)
KL: Agreed. I started to do some test cases, but then discovered I
needed to add more properties to the AreaTree concerning borders and
padding. I didn't get around to doing this, so we can put that on the
list.
> It would be really cool if you could generate such a report concerning table
> status - we could generate tasks from the description of unimplemented or
> work-in-progress features, and take it from there. My concern at the moment
> is that a lot of what we have is somewhat superficial - things that work on
> fo:block begin to break down when blocks are nested, or occur inside lists
> and tables. I'm as guilty of this as anyone, I figure. Having one central
> major area that we can concentrate on allows us to get to the point where
> things work everywhere they are supposed to.
KL: I think that if we correctly implement layout of FOs with respect to
their containing reference areas, layout of fo:xxx in a table shouldn't
be an issue. On the other hand, as you say, if it looks wierd in the
table, it probably means there is a bug in the layout of the fo:xxx
itself.
> This is an initial thought. I'm certainly not trying to pile more work on
> your shoulders, but I genuinely believe that this is a good route to follow,
> and you can be of great assistance here.
>
> Thanks,
> Arved
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: problems with height of cells in tables
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Hi, Karen (and other interested parties)
A thought occurred to me just now. A high percentage of our bandwidth (and
bug reports) are devoted to tables. There are so many table-related bug
reports mainly because so many folks want to use tables, I believe, not
because there are more bugs in tables than elsewhere.
I'm thinking that perhaps we can use table support as the centrepiece for
all of our FOP efforts. In order to have tables be fully supported, and work
properly, a really big percentage of the XSL specification (and FOP
mechanics) gets exercised. Redesign of layout is something of a fuzzy goal;
making tables work isn't.
You've currently got probably the best perspective on tables. What I am
thinking would be useful would be a report concerning table FOs, with a
property-by-property breakdown, that assesses what works, and what doesn't,
and what needs to happen in order to make things work. This could drive a
whole bunch of tasks that people could take on. It would be easier to gauge
the progress of FOP, because table support would be a bellwether for FOP as
a whole.
This doesn't mean that everything else would be ignored. But the shift of
emphasis would be as follows: if I want to work on markers, I make sure that
they work inside fo:table-and-caption, fo:table, fo:table-caption,
fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If
someone wants to make sure FO X works, they make sure it works also as a
descendant of fo:table-cell. Keiron has laid the groundwork for testing - a
really suitable area for a first comprehensive set of test-cases could be
(you guessed it) tables! :-)
It would be really cool if you could generate such a report concerning table
status - we could generate tasks from the description of unimplemented or
work-in-progress features, and take it from there. My concern at the moment
is that a lot of what we have is somewhat superficial - things that work on
fo:block begin to break down when blocks are nested, or occur inside lists
and tables. I'm as guilty of this as anyone, I figure. Having one central
major area that we can concentrate on allows us to get to the point where
things work everywhere they are supposed to.
This is an initial thought. I'm certainly not trying to pile more work on
your shoulders, but I genuinely believe that this is a good route to follow,
and you can be of great assistance here.
Thanks,
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: problems with height of cells in tables
Posted by Karen Lease <kl...@club-internet.fr>.
Arved Sandstrom wrote:
>
> At 12:22 AM 8/6/01 +0200, Karen Lease wrote:
> >So much for the explanations. Unfortunately, I'm not sure I'll try to
> >fix this right away, since I fear that it involves some rather major
> >changes. It really comes down to the fact that the fo:inline object
> >doesn't actually generate a nested inline area, but just adds characters
> >to the LineArea. So there's no place for it to actually store the
> >line-height information. Perhaps someone else will be be braver. In any
> >case, it's certainly on the list for the layout redesign...
>
> As soon as FOP 0.20.0 hits the streets, this is something that we may as
> well tackle and get over with. I ran into the same stumbling block a few
> weeks ago - I wanted to complete the set of FOs that can have markers, and
> fo:inline was one. Unfortunately, as you point out, fo:inline currently
> generates no area. If we are going to follow the conceptual model in the
> spec, which FOP currently does, then I figure we need to do so consistently,
> so fo:inline needs to create an area.
>
> I actually went down the initial design and coding road a bit. My conclusion
> was that if this is carefully done then it is not that bad. I also figured
> that for an initial cut it is better to duplicate and add classes to support
> this rather than to modify any existing classes, like FOText, because they
> are too central. But one could make the argument that FOText itself maybe
> needs work, so why _not_ modify it for the general case?
>
Yes, I pretty much agree. When I was doing the "redesign", I was working
on the concept of creating inline areas for all inline type objects
(except wrappers). I was going to just make one big "inline flow set"
with all the inline areas in a single sequence, and then do the breaking
from there. Once the line breaks were determined, then we can do the
line-height calculations according to the rules and the values of the
different properties. The biggest problem with having the actual text at
different levels in the tree is for doing things like white-space
handling, word-breaking hyphenation etc (assuming that at least some of
those should abstract from the actual inline tree).
Along those lines, and after trying to understand the white-space
handling in LineArea, I was wondering if it wouldn't be possible to do
that while building the FO tree. I was thinking of some kind of state
machine and using an iterator over the FO tree to abstract the level
problem. Sounds like I need to look into Peter's Tree work. (I'm sure
all that sounds quite obscure... oh well, just lettings people know
where I might be poking around.)
Regards,
Karen
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: problems with height of cells in tables
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 12:22 AM 8/6/01 +0200, Karen Lease wrote:
>So much for the explanations. Unfortunately, I'm not sure I'll try to
>fix this right away, since I fear that it involves some rather major
>changes. It really comes down to the fact that the fo:inline object
>doesn't actually generate a nested inline area, but just adds characters
>to the LineArea. So there's no place for it to actually store the
>line-height information. Perhaps someone else will be be braver. In any
>case, it's certainly on the list for the layout redesign...
As soon as FOP 0.20.0 hits the streets, this is something that we may as
well tackle and get over with. I ran into the same stumbling block a few
weeks ago - I wanted to complete the set of FOs that can have markers, and
fo:inline was one. Unfortunately, as you point out, fo:inline currently
generates no area. If we are going to follow the conceptual model in the
spec, which FOP currently does, then I figure we need to do so consistently,
so fo:inline needs to create an area.
I actually went down the initial design and coding road a bit. My conclusion
was that if this is carefully done then it is not that bad. I also figured
that for an initial cut it is better to duplicate and add classes to support
this rather than to modify any existing classes, like FOText, because they
are too central. But one could make the argument that FOText itself maybe
needs work, so why _not_ modify it for the general case?
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: problems with height of cells in tables
Posted by Karen Lease <kl...@club-internet.fr>.
Hi Peter,
Thanks for the test files. Yes, you are right that font metrics
influence the calculation. In fact, these examples point out a number of
problems with FOP's line sizing logic. The sizing is really determined
by the font-family and font-size specified or inherited on the fo:block
containing the text. The actual size of the text is ignored in
calculating the line height! So the last four lines of your table
correspond to this:
1. 18pt, Arial
2. 18pt, default font-family (sans-serif)
3. default font-size (12pt), Arial
4. default font-size (12pt), default font-family (sans-serif)
The font metrics for Arial obviously have a larger ascender value than
those for the default font.
So much for the explanations. Unfortunately, I'm not sure I'll try to
fix this right away, since I fear that it involves some rather major
changes. It really comes down to the fact that the fo:inline object
doesn't actually generate a nested inline area, but just adds characters
to the LineArea. So there's no place for it to actually store the
line-height information. Perhaps someone else will be be braver. In any
case, it's certainly on the list for the layout redesign...
Regards,
Karen
Petr Andrs wrote:
>
> Hi Karen,
>
> I have made some further investigation. I agree that this is probably
> not specific to tables, but it is better observable on tables. When
> using embedded TTF fonts, height of line is influenced also by font-
> family attribute. If font-family is specified on table-row or cell (I
> think it can be generalized to any block level object) height of line
> is different from case when font-family is specified on inline level
> object. So I made simple testing example. I made table with lines
> having all possible combinations of place of specificatin of font-size
> and font-family (at block level v. at inline level) resulting in four
> table lines. Then I made more combinations using two different font-
> sizes and two different font-families resulting in 16 line table.
> Results of this experiment are attached. You can notice than every line
> printed by Arial 18pt (the four bottom lines) has its own unique height
> of line. So it maybe has something to do with usage of font metrics.
>
> Petr
>
> On 5 Aug 2001, at 0:16 Karen Lease wrote about Re: problems with height of cells i :
>
> > Hi Petr,
> >
> > I've looked at this quickly and my first reaction is that it's probably
> > not specific to tables. I think it has to do with line-height (aka
> > leading in old typographic terms). Neither font-size nor line-height are
> > specified at a high level in your .fo. The default font-size is 12pt and
> > the default line-height 1.2 em (14.4pt). When you set font-size at the
> > block level as in the last row, that will also change the line-height,
> > since it's relative, so the total height is smaller. When you set
> > font-size at the inline or wrapper, it apparently isn't changing
> > line-height. I guess since line-height can be specified for both
> > fo:ineline and fo:character (via the fo:wrapper), that the line-height
> > should also be modified by setting font-size on those objects too.
> >
> > Good eye!
>
> on thousand lines the difference makes several pages so it is quite
> noticable
>
> > Regards,
> > Karen
> >
> > Petr Andrs wrote:
> > >
> > > Please see attached file. There is table with three lines, which all
> > > should have equal height. But they haven't, the last one has lower
> > > height than the other two. (Or the fist two have greater height than
> > > the las one) I would expect all three lines to look something like the
> > > last one, the first two are too high for my eye.
> > >
> > > Petr
>
> ------------------------------------------------------------------------
> Name: emptest.fo
> emptest.fo Type: unspecified type (Application/Octet-stream)
> Encoding: BASE64
>
> Name: emptest.pdf
> emptest.pdf Type: Portable Document Format (application/pdf)
> Encoding: BASE64
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: problems with height of cells in tables
Posted by Petr Andrs <pa...@artax.karlin.mff.cuni.cz>.
Hi Karen,
I have made some further investigation. I agree that this is probably
not specific to tables, but it is better observable on tables. When
using embedded TTF fonts, height of line is influenced also by font-
family attribute. If font-family is specified on table-row or cell (I
think it can be generalized to any block level object) height of line
is different from case when font-family is specified on inline level
object. So I made simple testing example. I made table with lines
having all possible combinations of place of specificatin of font-size
and font-family (at block level v. at inline level) resulting in four
table lines. Then I made more combinations using two different font-
sizes and two different font-families resulting in 16 line table.
Results of this experiment are attached. You can notice than every line
printed by Arial 18pt (the four bottom lines) has its own unique height
of line. So it maybe has something to do with usage of font metrics.
Petr
On 5 Aug 2001, at 0:16 Karen Lease wrote about Re: problems with height of cells i :
> Hi Petr,
>
> I've looked at this quickly and my first reaction is that it's probably
> not specific to tables. I think it has to do with line-height (aka
> leading in old typographic terms). Neither font-size nor line-height are
> specified at a high level in your .fo. The default font-size is 12pt and
> the default line-height 1.2 em (14.4pt). When you set font-size at the
> block level as in the last row, that will also change the line-height,
> since it's relative, so the total height is smaller. When you set
> font-size at the inline or wrapper, it apparently isn't changing
> line-height. I guess since line-height can be specified for both
> fo:ineline and fo:character (via the fo:wrapper), that the line-height
> should also be modified by setting font-size on those objects too.
>
> Good eye!
on thousand lines the difference makes several pages so it is quite
noticable
> Regards,
> Karen
>
> Petr Andrs wrote:
> >
> > Please see attached file. There is table with three lines, which all
> > should have equal height. But they haven't, the last one has lower
> > height than the other two. (Or the fist two have greater height than
> > the las one) I would expect all three lines to look something like the
> > last one, the first two are too high for my eye.
> >
> > Petr
Re: problems with height of cells in tables
Posted by Karen Lease <kl...@club-internet.fr>.
Hi Petr,
I've looked at this quickly and my first reaction is that it's probably
not specific to tables. I think it has to do with line-height (aka
leading in old typographic terms). Neither font-size nor line-height are
specified at a high level in your .fo. The default font-size is 12pt and
the default line-height 1.2 em (14.4pt). When you set font-size at the
block level as in the last row, that will also change the line-height,
since it's relative, so the total height is smaller. When you set
font-size at the inline or wrapper, it apparently isn't changing
line-height. I guess since line-height can be specified for both
fo:ineline and fo:character (via the fo:wrapper), that the line-height
should also be modified by setting font-size on those objects too.
Good eye!
Regards,
Karen
Petr Andrs wrote:
>
> Please see attached file. There is table with three lines, which all
> should have equal height. But they haven't, the last one has lower
> height than the other two. (Or the fist two have greater height than
> the las one) I would expect all three lines to look something like the
> last one, the first two are too high for my eye.
>
> Petr
>
> ------------------------------------------------------------------------
> Name: emptest.fo
> emptest.fo Type: unspecified type (Application/Octet-stream)
> Encoding: BASE64
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org