Bug 1084860 - RFE: Moar magic for table layouts
Summary: RFE: Moar magic for table layouts
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: future
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 4.2
Assignee: Jeff Fearn 🐞
QA Contact: Bruce Reeler
URL:
Whiteboard:
Depends On:
Blocks: 1128935
TreeView+ depends on / blocked
 
Reported: 2014-04-07 05:00 UTC by Joshua Wulf
Modified: 2014-10-19 23:02 UTC (History)
5 users (show)

Fixed In Version: 4.2.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1128935 (view as bug list)
Environment:
Last Closed: 2014-09-01 03:40:33 UTC
Embargoed:


Attachments (Terms of Use)

Description Joshua Wulf 2014-04-07 05:00:42 UTC
Currently humans need to specify the column width for tables to make them look good in output whenever they put data into a Docbook table.

These humans should be replaced by robots.

It would be great if code could compute the width needed to set the table columns to the right size. 

table-layout: auto in css does it; but it allows tables bigger than the page width to overflow the page. Also, it requires column width specification to be absent (currently table column widths are inserted by Publican).

So an algorithm that computes the right column width, or some magical css that does it would be nice - and more reliable than human intervention.

Comment 1 Jeff Fearn 🐞 2014-05-16 04:38:12 UTC
According to the Internet there is no way to use CSS on tables to force a max-width and allow columns to choose better sizes.

Since we can not allow tables to break the page width, this rules out CSS magic.

Calculating the smartest width for columns would require post processing the HTML, as the docbook is not tightly coupled to the output sizing. This is a PHD endeavour and not achievable in release time frames. (patches accepted!)

What I have done is stop publican from adding any widths when no widths are set in the source, this may aid layout for some content.

To ssh://git.fedorahosted.org/git/publican.git
   7b464d2..725d2e6  devel -> devel

Comment 2 Bruce Reeler 2014-08-25 23:56:03 UTC
Needinfo Jeff
Hi Jeff, how would one test this?

I created a table without any <col width="foo%"/> specified, and publican then creates a table with columns sized to fit the table proportionately, e.g. in halves with 2 cols, in thirds with 3 cols.

Is that sufficient to test what you changed here?
Thanks

Comment 3 Jeff Fearn 🐞 2014-08-26 00:00:23 UTC
(In reply to Bruce Reeler from comment #2)
> Needinfo Jeff
> Hi Jeff, how would one test this?
> 
> I created a table without any <col width="foo%"/> specified, and publican
> then creates a table with columns sized to fit the table proportionately,
> e.g. in halves with 2 cols, in thirds with 3 cols.
> 
> Is that sufficient to test what you changed here?
> Thanks

You need to check the HTML source to make sure there is no colwidth setting in the generated table.

Comment 4 Don Domingo 2014-08-26 00:44:47 UTC
Verified that not including a 'width' attribute to <col>s will result in no <col width=X%/> tags in the resulting HTML.

Including <col width=X%> in the XML source will still result in those same settings applied in the HTML as expected.

Tested on common-db5 brand.

Comment 5 Jeff Fearn 🐞 2014-09-01 03:40:33 UTC
A fix for this shipped in Publican 4.2.0.


Note You need to log in before you can comment on or make changes to this bug.