Bug 1084860

Summary:	RFE: Moar magic for table layouts
Product:	[Community] Publican	Reporter:	Joshua Wulf <jwulf>
Component:	publican	Assignee:	Jeff Fearn 🐞 <jfearn>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Bruce Reeler <breeler>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	future	CC:	aigao, ddomingo, jfearn, lcarlon, rlandman
Target Milestone:	4.2
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	4.2.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1128935 (view as bug list)		Environment:
Last Closed:	2014-09-01 03:40:33 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1128935

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.