On Thu, Oct 14, 2010 at 09:49:37AM +0200, Johannes Hofmann wrote:
On Wed, Oct 13, 2010 at 03:13:16PM -0300, Jorge Arellano Cid wrote:
On Tue, Oct 12, 2010 at 09:54:13PM +0200, Johannes Hofmann wrote:
*snip*
As currently the cell border, padding and margin are drawn by the cell widget (textblock) inside a table, the general idea is to make textblock consider "collapse" mode when inside a table.
postprocessAttrs() does not take into account in which element we currently are (e.g. <table>, <td>, ...) You could check whether you currently are in a certain element by looking at doctree->top ()->element and do special things for certain elements. However looking at "The collapsing border model" I'm not sure whether you can get away with leaving the dw/* code as it is and just fiddling with the Style objects. For example if you have
<td>1</td><td>2</td>
There currently is no way to get the style of the first <td> when creating the style of the second <td> in StyleEngine - which you would need to compute the thickness of the border between the two.
Fully agreed.
Actually we can't play with the values of the Style object in postprocessAttrs() as we like. They must contain what the spec mentions as "computed value". And as I read the spec, the computed value of e.g. border-width does not depend on the value of border-collapse.
I didn't know this ("computed value" requirement). Well, it defines better what's to be done if ever.
What *might* work is to take the Style object that StyleEngine gives you and modify it in in case that border-collapse is set before passing it to the table cell in src/table.cc:293.
Do you mean as if it was a nonCssHint? I was afraid CSS would take precedence (i.e. if nonCssHint says margin is 0 and CSS says it's 20, I'd bet on the second one!).
No, not via nonCssHints. I meant to directly modify the style before giving it to the Textblock. Attached is a small patch to demonstrate what I mean. With some more work I think we could make it cover the most common cases of the collapsing border model.
At this point, if we can set margin to zero for the "separate" model, and half the value for "collapsing" it would be quite an advance (in rendering). OTOH, it must be commented as a workaround because it's not the correct way to implement it. An implementation would need major surgery.
Another approach is to make dw::table render its borders and margin, and only leave padding to the cell widget.
Yes, that's the other way to do it. You could still reuse the border drawing helper routines from style.cc. Nevertheless it might be pretty complex. Not sure if it is really worth it...
Fully agreed.
Most probably a full implementation is not worth ATM, given the small use cases out there. A partial workaround may help though.
Yes, I think it would be reasonable to just cover the common cases e.g a table with a 1px grid with a single color and style.
After some more testing, and some tricks, it looks like common cases could get away with a good workaround. I'll keep working on it. -- Cheers Jorge.-