Thanks for these; I've applied it as http://dev.plutext.org/trac/docx4j/changeset/1579
(except the pom.xml change - see my post in parent forum about that)
I think we should put this in 2.7.0; not sure whether another rc is necessary though .. we can wait a bit to see whether anything else crops up.
tinne wrote:In result of the removal, formatting applied to the SDT as a whole is lost, as I found no easy way to replicate the content of the sdtEndPr into the sdtContent nodes. Simply copying to each rPr/pPr/tcPr etc. would not do, as overrides applying to those required might require partial omission.
I looked at its description at http://msdn.microsoft.com/en-us/library ... rties.aspx
and played around with it in Word 2007. I don't think we need to worry about it at all, since this tag doesn't seem to affect the formatting of the contents of the sdt. The most I could get it to do in Word 2007: when I positioned my cursor immediately before the magic sdtendchar and typed something, the first thing I typed caused the final paragraph character to appear in that format (the letter i typed appeared *after* the sdt); following keystrokes appeared in the format, but again, outside the sdt. This testing was on a rich text para level sdt.
tinne wrote: I added a global option to support optionally removing entire cells based on a condition.
I can image a user wanting this to be set differently document to document, or even table to table within a document.
So I'm wondering how we could best change the convention to allow this.
One option would be to have it as an optional setting in <w:tag value="od:condition=..."/>
Perhaps <w:tag value="od:condition=...&removeIfEmpty=true"/>
Calling it "removeIfEmpty" might open the way to similar semantics for other empty objects (rows? text boxes?).
If you wanted to use this approach to get rid of a column, it might be a bit of a pain putting this property on each tc.
So alternatively, we could put the whole table in an sdt, and use that sdt to provide a table-wide setting for this property. I don't think I'd do this unless there were other table level properties we wanted to be able to alter. (Maybe we could provide a way of doing column oriented processing at this level??)
If we can work something out here, I'd like to do this for 2.7.0.
Finally, I will try to find time to write a couple of unit tests for these changes (unless you have some already?).
thanks again .. Jason