The geometricBounds of a table cell - what's the best approach / practice?

Report · May 19, 2009

To get the coordinates of a cell in a table, do you have to calculate that using the widths and heights of the cells to the left and over the cell, or is there a simpler way? (Since there's no geometricBounds property for a cell.)

-- Andreas

Report · May 19, 2009

If you know that there is text in the cell in question, you can use the baseline and horizontal offset of the first character of the cell as the basis for calculating the cell's geometric bounds. It's a messy process though.

Dave

Report · May 20, 2009

Thanks for the alternate solution, Dave! Yes, there will (most probably) only be need for the coordinates of cells with textual contents. Would using the offsets of the first character be a faster or more reliable solution than adding the heights and widths of previous cells in the table?

And on the other hand is the adding of heights and widths as simple as that... or can there be circumstances when using the widths and heights of the cells do not always add up to a sum equalling the width and height of the whole table?

-- Andreas

Report · May 20, 2009

The advantage of working with the text is that you don't have to worry (much) about tables that span pages. You can use the parent text frame of the text in the cell to easily work out which page the cell is on.

Dave

Report · Jul 09, 2009

I implemented a solution based on the baseline approach, using a character on the last visible line, to get the bottom bound.

var lastVisibleChar = myCell.characters[myCell.contents.length-1]; // get the last not overflowing character (contents only returns the visible portion)
var bottom = lastVisibleChar.baseline + myCell.bottomInset; // Bottom value is now based on the last character of the cell.
var top = bottom - myCell.height;

This works fine as long as the row height is not changed, to be higher than needed. Then there will be an unwanted offset of the whole bounds, based on the bottom character, and not the cell bottom, which I try to illustrate with the image attached (sorry for my poor drawing).

The red rectangle in my attached image is the bounds that I get back using my present code. The blue stipes indicates the area not taken into account by the calculation of the "bottom" variable.

Any ideas how to find the real bottom of the cell?

Best regards,

Andreas Jansson

Report · Jul 09, 2009

I see now that I could probably temporarily set the verticalJustification = VerticalJustification.BOTTOM_ALIGN before reading out the baseline, and doing the calculations, but since I'm doing this for all cells in all tables in the document, I'd rather find a better way.

Report · May 04, 2010

I'm back to this old one again...

"If you know that there is text in the cell in question, you can use the baseline and horizontal offset of the first character"

Yes... but even if I'm only interested in cells with contents, there is this special case (isn't there always?) when a user has entered a word that doesn't fit in the cell, so that all contents of the cell is overflowing.

Then I get no valid character to use with the baseline/bottomInset and horizontalOffset/leftInset.

Perhaps (fingers crossed) someone has discovered a smother way of extracting "cell coordinates", where you don't depent on the visibility of the cell contents?

-- Andreas

EDIT: I had to resort to the solution in my own (first) quiestion. For the left bound I check the id of the TextFrame container while adding the cell heights, and if the TextFrame is not the same as the one I want coordinates for, then I jump out (since I got to a previousTextFrame).

Message was edited by: Andreas Jansson