Rowspan and Colspan

[FTorrenegraG]

The problem with several rowspan and colspan, is fix ?

In my case, I have several rowspan and colspan in the same table, and this is fill using AngularJS, and when export, in xlsx, the table not appear in correct way.

(sorry for my english, not is very good)

[jmbkeyes]

I also came across this issue(table with rowspan and colspan), any feedback on it?

[clarketm]

This should have been fixed in v3.2.10. Please let me know as soon as possible if this is not the case.

[jmbkeyes]

It seems not fixed yet(rowspan didn't work as expected, and I doesn't test colspan), I used the stable version. and html table code as attached. table.txt

[clarketm]

I ran your example in a static browser environment and I do see one major bug related to the rowspan attribute. I will fix it for the next patch release (see attached image). Thank your help with this issue.

现金 and 1980 should be in column G and H, respectively.

[clarketm]

The new patch will likely come towards the tail-end of the week. I have a solution in the pipeline that warrants more testing before finalization or release.

[clarketm]

I am keeping this ticket open in case the fix @ d6ca877 is not the only issue. Please reference v3.3.7.

[basawyer]

FYI, we are still having this issue as of v3.3.9. We are happy to provide more information, not sure what would be useful. Thanks.

[basawyer]

We spent some more time today looking at this issue in hopes of putting together some sort of pull request.

Here's some example DOM structure that we are having issues with:

		Title	TitleOne	Totals
Title	Classification
TitleOne	ClassOne		1	1
	ClassTwo		1	1
Totals			2	2

It seems there are issues when building the 'rcMap' object. When encountering a rowspan, you account for the next row's column offset in the rcMap object:

if (val.hasAttribute('rowspan')) {
    for (var i = 1; i < val.getAttribute('rowspan'); i++) {
        rcMap[ir + i] = rcMap[ir + i] || {};
        rcMap[ir + i][ic] = 1
    }
}

But when calculating that next row, the first column might have a colspan, which has already been accounted for during the previous row calculations. We added some checking for this case and added the offset to the next column:

if (val.hasAttribute('colspan')) {
    rcMap[ir] = rcMap[ir] || {};
    if (!rcMap[ir][ic]) {
      rcMap[ir][ic + 1] = val.getAttribute('colspan') - 1
    } else {
      rcMap[ir][ic + 2] = val.getAttribute('colspan') - 1
    }
}

Which fixes our export from looking like this:

To looking more correct:

We are hoping to get a better understanding of how you are using the rcMap object, so we can move to a more generic solution. This patch does not work if we were to add another dimension to our data.

[nopace]

If you can merge the cell just fine

[clarketm]

@basawyer & @nopace – I would really like to get this patched and integrated into v4.

@basawyer – any luck on your end with a patch? I just started on a dual-pointer recursive approach that may do the trick. It's slated on the v4 channel, but as it's a bug in nature, it will also be applied to v3 as well.

[nopace]

Thanks again

[clarketm]

@basawyer / @nopace – these rowspan/colspan edge cases should now be fixed as of v5.0.0-rc.1.

If this is not the case, can you please send me a sample html structure where the algorithm fails?

NOTE: v5.0.0-rc.x will remain a release candidate (rc) until I can ascertain that the rowspan/colspan bug is resolved. Once verified and validated, v5.0.0 it will be published as a stable release.

[wo00421309]

Untitled1.txt

please help me! v5.0.0-rc.1.

[clarketm]

@wo00421309 – thanks for the html snippet. Let me take a look before working on a solution.

[wo00421309]

can i merge the cell as the question nopace mentioned

[clarketm]

@wo00421309 – cell merging is the next feature I'd like to introduce. In this case it looks like the rowspan ordering needs to be tracked correctly so the shift you are experiencing doesn't occur. Once this is fixed, I will have a much, much easier time adding cell merge functionality from SheetJS.

[clarketm]

@wo00421309 – v5.0.0-rc.3 applies the appropriate fixes to resolve the aforementioned rowspan/colspan issues such as the one you highlighted. As far as cell merge functionality goes, assuming that there aren't any lingering bugs with either rowspan or colspan, this is the logic next step as far as enhancements are concerned. I created an issue specifically for this feature #69.

[clarketm]

Multiple consecutive colspan is still broken. Thanks to @dulguun00 for pointing this out. Expect this to be fixed soon.

[clarketm]

v5.0.0-rc.6 presents dramatic improvements to this rowspan / colspan bug, effectively resolving this issue for most table constructs. There are a few exceptions where the RowColMap algorithm does break down.

Due to the complexity involved with emulating a native DOM parser, there are some cases where the browser rendered html table will not perfectly mimic the exported file's table structure, such as:

• when colspan or rowspan values introduce noncongruence with the row (<tr>) or column (<td> or <th>) length (e.g. nonsymmetric tables).

I will publish a few examples along with the v5 stable release.

[MikeAlhayek]

I am using v4.0.11 and I am seeing this issue as well. Is there a workaround or a fix for this bug?

[HarrySystems]

I've tested it with v5.0.0-rc.6 and I'm still facing this problem (as you can see in this pen)

[onlymaj]

Also this structure of html does not work for me too . I tested with version 5.2.0