table-row height attribute

[Mark Williams]

Hi,

I'm using the table-row height attribute to limit the height os specific
rows. However, if the text is greater than the height of the row, the row
height adjusts, so that it seems (at least in conjunction with table-rows)
that the height property specifies an "at least", not a fixed height. Is
this how height was intended. I'm using FOP to render, so this might be a
FOP problem.

Any info appreciated.

Regards,

Mark Williams


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[Andreas L. Delmelle]

-----Original Message-----
From: Mark Williams
I'm using the table-row height attribute to limit the height os specific
rows. However, if the text is greater than the height of the row, the row
height adjusts, so that it seems (at least in conjunction with table-rows)
that the height property specifies an "at least", not a fixed height. Is
this how height was intended. I'm using FOP to render, so this might be a
FOP problem.

Hi Mark,

Not sure if I understand the 'problem' correctly, but defining a row to be,
say, 10pt in height, and subsequently not making sure the entered text is
10pt max in font-size... (maybe even a bit smaller to make sure) it would
seem like 'asking for trouble' IYKWIM

I'm not really sure what the spec would say, but if it makes sense, this
should be considered an error, and so maybe the only problem would be that
FOP is ignoring it --*if* it turns out to be an error, that is. If the spec
says nothing in particular, then I guess how such situations are dealt with
is totally up to the implementors.

If the problem is something like the one I described above, I can only
suggest to avoid putting too large text inside the table-row..


Cheers,

Andreas


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[Mark Williams]

Hi Andreas,

Thanks for the response.

As you probably know, if the text in a cell is too long it wraps to the next
line and increases the row height. The spec says that specifying a height
fixes the height, by which I assumed it meant that any wrapping text would
be lost. Either I've misread the spec or FOP doesn't implement it correctly
for table rows. I appreciate what you say about keeping text within the row
size, but I don't have control over the size of the text inputted. What I
would like to be able to do, however, is control the row height so that it
will be fixed at say 0.6cm regardless of the text inputted. This would , of
course, has the unfortunate side effect of not rendering certain text, but I
still need to be able to do it.

If you have any thoughts, always appreciated.

Regards,

Mark Williams


----- Original Message -----
From: "Andreas L. Delmelle" <***@pandora.be>
To: <xsl-***@lists.mulberrytech.com>
Sent: Tuesday, March 09, 2004 7:58 PM
Subject: RE: [xsl] table-row height attribute

Post by Andreas L. Delmelle

-----Original Message-----
From: Mark Williams
I'm using the table-row height attribute to limit the height os specific
rows. However, if the text is greater than the height of the row, the row
height adjusts, so that it seems (at least in conjunction with table-rows)
that the height property specifies an "at least", not a fixed height.

Is

Post by Andreas L. Delmelle

this how height was intended. I'm using FOP to render, so this might be a
FOP problem.

Hi Mark,
Not sure if I understand the 'problem' correctly, but defining a row to be,
say, 10pt in height, and subsequently not making sure the entered text is
10pt max in font-size... (maybe even a bit smaller to make sure) it would
seem like 'asking for trouble' IYKWIM
I'm not really sure what the spec would say, but if it makes sense, this
should be considered an error, and so maybe the only problem would be that
FOP is ignoring it --*if* it turns out to be an error, that is. If the spec
says nothing in particular, then I guess how such situations are dealt with
is totally up to the implementors.
If the problem is something like the one I described above, I can only
suggest to avoid putting too large text inside the table-row..
Cheers,
Andreas
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[Andreas L. Delmelle]

-----Original Message-----
From: Mark Williams
As you probably know, if the text in a cell is too long it wraps
to the next line and increases the row height.
The spec says that specifying a height fixes the height, by which
I assumed it meant that any wrapping text would be lost.
Either I've misread the spec or FOP doesn't implement
it correctly for table rows.

Ah, in that case.. of course. I thought it did clip, but so it doesn't :(
(is why I was a bit puzzled by the problem)

I appreciate what you say about keeping text within the row size,
but I don't have control over the size of the text inputted.

Hmm. Indeed you don't, but do you have the possibility of extracting the
first n characters from the strings in question, where n is based on the
font metrics and the width of the cell (?)

Remote guess, but if you can 'normalize' the text in this fashion during the
XSL Transform, this might just be your way out.


Cheers,

Andreas


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[Mark Williams]

Andreas,

Thanks again for the reply. Ken has come up with a fairly hopeful sounding
solution, which I will try out.

Cheers,

Mark

----- Original Message -----
From: "Andreas L. Delmelle" <***@pandora.be>
To: <xsl-***@lists.mulberrytech.com>
Sent: Tuesday, March 09, 2004 9:20 PM
Subject: RE: [xsl] table-row height attribute

Post by Andreas L. Delmelle

-----Original Message-----
From: Mark Williams
As you probably know, if the text in a cell is too long it wraps
to the next line and increases the row height.
The spec says that specifying a height fixes the height, by which
I assumed it meant that any wrapping text would be lost.
Either I've misread the spec or FOP doesn't implement
it correctly for table rows.

Ah, in that case.. of course. I thought it did clip, but so it doesn't :(
(is why I was a bit puzzled by the problem)

I appreciate what you say about keeping text within the row size,
but I don't have control over the size of the text inputted.

Hmm. Indeed you don't, but do you have the possibility of extracting the
first n characters from the strings in question, where n is based on the
font metrics and the width of the cell (?)
Remote guess, but if you can 'normalize' the text in this fashion during the
XSL Transform, this might just be your way out.
Cheers,
Andreas
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[G. Ken Holman]

Post by Mark Williams
As you probably know, if the text in a cell is too long it wraps to the next
line and increases the row height. The spec says that specifying a height
fixes the height, by which I assumed it meant that any wrapping text would
be lost. Either I've misread the spec

I believe you have misread the spec, though I am having problems myself.

I think the height= doesn't apply to table-row, even though it is in the
spec, because the spec says table-row doesn't generate any areas, it only
returns areas, and the height= property states that it applies to boxes
generated by block-level elements.

So, I think height= is listed with table-row because table-row is a
block-level element, but since table-row doesn't generate any boxes, it
ends up not applying in the long run.

In my UBL stylesheets when I want to limit the height of a table-cell, I
put the lines of text into a block-container that has a height= property
and put that block-container into the table-cell. The definition for
block-container is that it does, indeed, generate boxes, so that is why
height= works.

But then, I'm not and wasn't on the committee itself, so this is conjecture
based on my read of the specification. Can someone from the committee
comment on this interpretation, please? I hate to mislead anyone, but the
explanation above fits the evidence.

And your work-around is to do what I do with my UBL stylesheets: use
block-containers with a fixed height and overflow="hidden".

I hope this helps.

........................ Ken

--
US XSL training: Washington,DC March 15; San Francisco,CA March 22
World-wide on-site corporate, government & user group XML training
G. Ken Holman mailto:***@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 [phone] (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[Mark Williams]

Ken,

Many thanks for the helpful reply and suggested solution. I did actually
try a block container, but I couldn't get this to work (it may be because I
was trying to specify an absolute position). I will try again.

As to the applicabilty of height to the table-rows, it does partially work.
It achieves an at least capability. That is, if you set a row-height of 10
cms the row will be at least that height, but it will also grow if it feels
it needs to.

Regards,

Mark

----- Original Message -----
From: "G. Ken Holman" <***@CraneSoftwrights.com>
To: <xsl-***@lists.mulberrytech.com>
Sent: Tuesday, March 09, 2004 9:35 PM
Subject: Re: [xsl] table-row height attribute

Post by G. Ken Holman

Post by Mark Williams
As you probably know, if the text in a cell is too long it wraps to the next
line and increases the row height. The spec says that specifying a height
fixes the height, by which I assumed it meant that any wrapping text would
be lost. Either I've misread the spec

I believe you have misread the spec, though I am having problems myself.
I think the height= doesn't apply to table-row, even though it is in the
spec, because the spec says table-row doesn't generate any areas, it only
returns areas, and the height= property states that it applies to boxes
generated by block-level elements.
So, I think height= is listed with table-row because table-row is a
block-level element, but since table-row doesn't generate any boxes, it
ends up not applying in the long run.
In my UBL stylesheets when I want to limit the height of a table-cell, I
put the lines of text into a block-container that has a height= property
and put that block-container into the table-cell. The definition for
block-container is that it does, indeed, generate boxes, so that is why
height= works.
But then, I'm not and wasn't on the committee itself, so this is conjecture
based on my read of the specification. Can someone from the committee
comment on this interpretation, please? I hate to mislead anyone, but the
explanation above fits the evidence.
And your work-around is to do what I do with my UBL stylesheets: use
block-containers with a fixed height and overflow="hidden".
I hope this helps.
....................... Ken
--
US XSL training: Washington,DC March 15; San Francisco,CA March 22
World-wide on-site corporate, government & user group XML training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 [phone] (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[G. Ken Holman]

Okay, so I was wrong. :{)}

Post by G. Ken Holman
But then, I'm not and wasn't on the committee itself, so this is
conjecture based on my read of the specification. Can someone from the
committee comment on this interpretation, please? I hate to mislead
anyone, but the explanation above fits the evidence.

Wellllll ... I've been directed to:

http://www.w3.org/TR/REC-CSS2/tables.htm

where in section 17.5.3 it explicitly states that height= is a *minimum*
value for the table row. So, "fixed" means the minimum is fixed, not that
the row's height is fixed. Hmmmmmmmmm.

I sit corrected.

So, I guess my work-around of block-container really is an appropriate way.

I hope this helps.

....................... Ken

--
US XSL training: Washington,DC March 15; San Francisco,CA March 22
World-wide on-site corporate, government & user group XML training
G. Ken Holman mailto:***@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 [phone] (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[Mark Williams]

Hi Ken,

Thanks for clearing that up.

Regards,

Mark

----- Original Message -----
From: "G. Ken Holman" <***@CraneSoftwrights.com>
To: <xsl-***@lists.mulberrytech.com>
Sent: Tuesday, March 09, 2004 10:42 PM
Subject: Re: [xsl] table-row height attribute

Post by G. Ken Holman
Okay, so I was wrong. :{)}

Post by G. Ken Holman
But then, I'm not and wasn't on the committee itself, so this is
conjecture based on my read of the specification. Can someone from the
committee comment on this interpretation, please? I hate to mislead
anyone, but the explanation above fits the evidence.

http://www.w3.org/TR/REC-CSS2/tables.htm
where in section 17.5.3 it explicitly states that height= is a *minimum*
value for the table row. So, "fixed" means the minimum is fixed, not that
the row's height is fixed. Hmmmmmmmmm.
I sit corrected.
So, I guess my work-around of block-container really is an appropriate way.
I hope this helps.
...................... Ken
--
US XSL training: Washington,DC March 15; San Francisco,CA March 22
World-wide on-site corporate, government & user group XML training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 [phone] (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[Eliot Kimber]

Post by Mark Williams
Hi Ken,
Thanks for clearing that up.

Post by G. Ken Holman
http://www.w3.org/TR/REC-CSS2/tables.htm
where in section 17.5.3 it explicitly states that height= is a *minimum*
value for the table row. So, "fixed" means the minimum is fixed, not that
the row's height is fixed. Hmmmmmmmmm.

I have to agree with Ken--it appears that the XSL-FO spec delegates to
the CSS2 spec to define the semantics of height on rows.

As Ken says, if you want to limit the height of the cell content, you
must put it in an fo:block-container with an explicit height= (or
block-progression-dimension= value).

Cheers,

Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9030 Research Blvd, #410
Austin, TX 78758
[phone]

***@innodata-isogen.com
www.innodata-isogen.com


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

[David Tolpin]

Post by Eliot Kimber
I have to agree with Ken--it appears that the XSL-FO spec delegates to
the CSS2 spec to define the semantics of height on rows.

Yes, it is true.

Post by Eliot Kimber
As Ken says, if you want to limit the height of the cell content, you
must put it in an fo:block-container with an explicit height= (or
block-progression-dimension= value).

No, it is not so. block-container with block-progression-dimension
is a workaround which may work in some cases, and will not in others
(when the cell is neihboring another one with row-span!=1). The
correct way to limit the height of a cell is to specify block-progression-dimension
on the table-cell itself. The specification allows to do so
by explicitely listing block-progression-dimension on fo:table-cell.

There is an error in the specification in that both height and
block-progression-dimension are listed for table-cell. This makes
no sense since height is mapped to block-progression-dimension in
XSL FO.

I admit that proper support of block-progression-dimension on table-cell
may not be available in FOP. But then it is a bug in FOP; XSL FO allows
it and it is the right way to specify cells with fixed height.

David Tolpin
http://davidashen.net/

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list