finally successful in ods with python, just one help needed.

John Machin sjmachin at lexicon.net
Sun Mar 15 09:07:34 CET 2009


On Mar 15, 4:46 am, David Bolen <db3l.... at gmail.com> wrote:

[snip]

> Note that it appears creating such a spreadsheet directly in Calc also
> adds covered table cells for those cells beneath the spanned cell, but
> Calc loads a file fine without those and still lets you later split
> the merge and edit the underlying cells.  So I'm not sure how required
> that is as opposed to just how Calc manages its own internal structure.

Don't feel lonely :-) OASIS and Calc aren't sure either. Here's what
the ODF 1.1 standard has to say [section 8.1.3]:
"""
Table Cell

The <table:table-cell> and <table:covered-table-cell> elements specify
the content of a table cells. They are contained in table row
elements. A table cell can contain paragraphs and other text content
as well as sub tables. Table cells may be empty.

The <table:table-cell> element is very similar to the table cell
elements of [XSL] and [HTML4], and the rules regarding cells that span
several columns or rows that exist in HTML and XSL apply to the
OpenDocument specification as well. This means that there are no
<table:table-cell> elements in the row/column grid for positions that
are covered by a merged cell, that is, that are covered by a cell that
spans several columns or rows. The <table:covered-table-cell> element
exists to be able to specify cells for such positions . It has to
appear wherever a position in the row/column grid is covered by a cell
that spans several rows or columns. Its position in the grid is
calculated by a assuming a column and row span of 1 for all cells
regardless whether they are specified by a <table:table-cell> or a
<table:covered-table-cell> element. The <table:covered-table-cell> is
especially used by spreadsheet applications, where it is a common use
case that a covered cell contains content.
"""

So I was under the impression that only a covered-table-cell could
appear under the cover, especially if the cell were to carry
meaningful content. Not so, evidently, ...

I have adapted your second script as follows, to specify:
row 1: 3-col 2-row spanning cell, then 1 ordinary (not "covered") cell
containing text "X"
row 2: 3 ordinary cells "P2" "Q2" "R2"
row 3: 3 ordinary cells "P3" "Q3" "R3"

odfpy does not automagically change the ordinary cells to covered.

According to the standard, the X cell and the P2-R2 cells are illegal;
they should be covered-table-cell elements.
However Calc neither complains nor bumps the cells out of the arena
(e.g. bumping the X cell from B1 to D1). X and the P2-R2 cells are
hidden ("covered"). If you unmerge the 3x2 A1, Calc displays X in B1,
P2 in A2, etc.

8<--- changed piece of script
    # Add first row with first cell spanning A1:C2
    tr = TableRow()
    table.addElement(tr)
    tc = TableCell(numbercolumnsspanned=3, numberrowsspanned=2,
stylename=centered)
    tc.addElement(P(text="ABC12"))
    tr.addElement(tc)

    # first row, second cell
    tc = TableCell()
    tc.addElement(P(text="X"))
    tr.addElement(tc)

    # Add two more rows with non-spanning non-covered cells
    for r in (2,3):
        tr = TableRow()
        table.addElement(tr)
        for c in "PQR":
            tc = TableCell()
            tc.addElement(P(text='%s%d' % (c, r)))
            tr.addElement(tc)
8<---

In practice, it seems that all cells in the spanned range must be
filled in somehow -- the minimum safest (in the sense of both
complying with the standard and working with Calc) filler being a
covered-table-cell with no attributes other than number-columns-
repeated.

Cheers,
John



More information about the Python-list mailing list