Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


wrong column/cell width when using subtables #612

hbrandl opened this Issue · 5 comments

3 participants


There is an issue with the calculation of the column/cell width when using subtables.

I discovered it while taking a closer look at the test case for bug report #502 during a reopening of bug report #407 with my pull request #579.

When adding a subtable the column width of the enclosing cell will be increased. I do think, that this is a bug, however it may be a feature that I'm not aware of.

The following test case (adapted from bug report #502) illustrates the problem:

it "illustrates wrong width with subtables" do 
      pdf =
      first = {:content=>"Foooo fo foooooo",:width=>50,:align=>:center}
      second = {:content=>"Foooo",:colspan=>2,:width=>70,:align=>:center}
      third = {:content=>"fooooooooooo, fooooooooooooo, fooo, foooooo fooooo",:width=>50,:align=>:center}
      fourth = {:content=>"Bar",:width=>20,:align=>:center}
      table_content = [[
      table = table_content, pdf
      table.column_widths.should == [50.0, 70.0]

In the current master branch it fails with

     Failure/Error: table.column_widths.should == [50.0, 70.0]
       expected: [50.0, 70.0]
            got: [50.0, 85.0] (using ==)

Screenshot of pdf when generated:

With my fix from pull request #579 it still fails with

     Failure/Error: table.column_widths.should == [50.0, 70.0]
       expected: [50.0, 70.0]
            got: [50.0, 75.0] (using ==)

Screenshot of pdf when generated with fix from pull request #579

As you can see with the fix the subtables dimensions are correct, but the enclosing cells dimensions are wrong. Without the fix, both are wrong.

So wheter pull request #579 will be merged or not, the dimensions are unexpected.


@bradediger Can you confirm whether or not adding a subtable should expand the with of the enclosing column? What @hbrandl said sounds right, but I'm unsure of what the original intent was.


@sandal Yes, @hbrandl's test case looks correct.

I have a hunch that in full generality, this problem may require a constraint solver to completely fix. I know that there is a variant of the table layout problem that someone has proven NP-complete. Our approach is currently heuristic, possibly necessarily so.


Closing this ticket as stale, but I'll keep the unresolved issue in the test suite. To get this ticket reopened, all anyone needs to do is move the research a little bit further along. Even some additional notes about the problem will do!

@practicingruby practicingruby removed the stale label

Reopening temporarily as part of an effort to get more of Prawn's unresolved issues looked at!


I am closing all issues for Prawn::Table, because it is being extracted into its own gem with its own repository (

As I close tickets, I'm marking them with a "table" tag, so that @hbrandl can easily find them and optionally move them over to the prawn-table issue tracker. Anything that has the table tag can be assumed to have been unresolved at the time I closed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.