[scribus-dev] Question about effect of borders on cell content rectangle

Elvis Stansvik elvstone at gmail.com
Sun Aug 7 10:15:12 UTC 2011


Hi again,

Consider a cell spanning multiple rows and/or column where the
neighboring cells have different border widths. How do we want the
cell content rectangle (the rectangle where the cell text frame will
be placed) to be calculated?

Some investigation shows:

InDesign:
Uses the half of the maximum border width found among the collapsed
borders along the side of the cell, plus the cell padding.

OpenOffice/LibreOffice:
Completely disregards any borders during content rectangle
calculations, and only uses cell padding.

Chromium:
Just picks half the width of the collapsed border between the cell and
the _first_ neighboring cell along the side of the cell, plus the cell
padding.

Firefox:
Uses the same behavior as InDesign.

I believe the InDesign/Firefox way to be the correct, but it makes for
some more complicated code when doing the cell content rectangle
calculations.

If we want this behavior, then:

The code would essentially have to do the same kind of
looping/collapsing along the cell edges that is done in
collapsedtablepainter.cpp, so ideally this code should be refactored
so that it can be shared.

I did know about this when writing the painting code, and initially my
idea was to give TableCell some kind of iterator interface for
iterating across collapsed border segments along its four sides. This
code could then be used both by the table painter and by the cell
content rectangle calculation in PageItem_Table. However, it got
overly complex and I ended up with simpler loops in
CollapsedTablePainter instead..

So, either I start a refactor to make the code reusable, or there will
be some code duplication for a while, and I could leave some comments
about this needing a refactor. I'm thinking that with the amount of
time I have left on the project, it's better to go with the latter
approach.

This is all assuming that we want the same behavior as
InDesign/Firefox. If we're fine with e.g. doing it the way Chromium
does, the code gets simpler.

See the attached screenshots and example HTML.

Cheers,
Elvis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110807/8b77204d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: indesign.png
Type: image/png
Size: 34029 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110807/8b77204d/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libreoffice.png
Type: image/png
Size: 30963 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110807/8b77204d/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firefox.png
Type: image/png
Size: 16898 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110807/8b77204d/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chromium.png
Type: image/png
Size: 17196 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110807/8b77204d/attachment-0007.png>


More information about the scribus-dev mailing list