[xep-support] Re: Strange auto table layout column widths

Hi Kevin

It is understood that page oriented layout is more complicated, but that
doesn't help with my original question, which was why doesn't XEP pick
up that one column could be narrower and the other wider, in the
case of this table that happens to be only 20 or sow rows long?

E.g., how many rows does it "look ahead"?

And is this controllable by a parameter (or could it be) ?

In my case, for example, I don't really care how long it takes to
think about the problem (within reason), and would be happy to
tune the performance to get a better result.

Alternatively, if a table is smaller and less complicated, rather
than very complicated and very long, perhaps a different ('optimized")
alternative algorithm could be used perhaps (e.g., in those cases
where it was "acceptable" to make multiple passes).

David

On 2/25/14 4:11 PM, Kevin Brown wrote:
> Yes, the key in that specification is:
>
>> This algorithm may be inefficient since it requires the user agent to have
> access to all the content in the table before determining the final layout
> and may demand more than one pass.
>
> There are many things a "browser" doesn't do to make this even more complex
> for print formatting engines. Like worrying about table headers and footers
> and repeating them at break in columns or pages, worrying about keeps across
> those boundaries, line endings/tightness/squeezing to fit, font kerning...
> Keeps being also a huge influence, imagine that changing a column's width
> based on some algorithm also influences row height which could in turn (with
> keeps) cause entire rows to relocate to another page and leave huge empty
> spaces at page ends (maybe that row is 20 lines high). This is not anywhere
> in any "browser" solution as there are no "pages". And then I didn't even
> put footnotes in there, image the situation above where now that footnote
> moves across a page boundary and now the available page height changes for
> both pages ...
>
> Processing a whole table through multiple passes may be acceptably
> performing for some simple layouts and those that do not worry about
> keeps/splits where they can occur at page boundaries ... but a 4,000 page
> business to business phone bill that is 95% tabular would be a killer.
>
> There is a balance with performance and in many cases it would be
> unacceptable to process entire tables in multiple passes to determine
> "optimal" layout.
>
> Kevin Brown
> RenderX
>
>
>
> -----Original Message-----
> From: xep-support-bounces@renderx.com
> [mailto:xep-support-bounces@renderx.com] On Behalf Of David Clunie
> Sent: Tuesday, February 25, 2014 12:40 PM
> To: Bob Stayton; RenderX Community Support List
> Subject: [xep-support] Re: Strange auto table layout column widths
>
> Thanks Bob.
>
> It is instructive to compare how XEP lays it out automatically with how a
> browser using HTML generated output renders the same table, with arguably a
> "better" allocation of column widths for this case.
>
> XEP does not seem to be following the CSS algorithm that you referenced.
>
> David
>
> On 2/25/14 3:27 PM, Bob Stayton wrote:
>> Indeed, table-layout="auto" is the default, which is why the DocBook
>> stylesheet does not generate that property explicitly for XEP output.
>>
>> Here is a link to a relatively understandable explanation of how auto
>> table column widths are supposed to be computed (it is from the CSS
>> standard, which the XSL-FO standard refers to):
>>
>> http://www.w3.org/TR/CSS2/tables.html#width-layout
>>
>> Bob Stayton
>> Sagehill Enterprises
>> bobs@sagehill.net
>>
>> On 2/25/2014 11:31 AM, David Clunie wrote:
>>> Hi
>>>
>>> I am using DocBook that includes tables that do not specify explicit
>>> column widths, and that have xep.extensions set to '1', which I
>>> gather generates FO that leaves XEP to do the table formatting.
>>>
>>> This works very well most of the time, but sometimes the columns are
>>> wider than they need to be and others narrower than they could be
>>> with unnecessary line wrapping within cells.
>>>
>>> See attached screenshot, in which the "Tag" column could be narrower
>>> and the "Usage..." column wider without the break in the sentence
>>> about "aspect ratio".
>>>
>>> The FO fragment for the entire table is attached.
>>>
>>> I notice that the <fo:table/> element does not explicitly include the
>>> 'table-layout="auto"' attribute.
>>>
>>> Does it need to or is that the default?
>>>
>>> I assume it is the default, since if I mess with the DocBook
>>> stylesheets to add 'table-layout="auto"', e.g. by adding to my
> customization layer:
>>>
>>> <xsl:attribute-set name="table.table.properties">
>>> <xsl:attribute name="table-layout">auto</xsl:attribute>
>>> </xsl:attribute-set>
>>>
>>> then 'table-layout="auto"' does indeed get included in the FO, but
>>> the result looks exactly the same.
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> (*) To unsubscribe, please visit
>>> http://lists.renderx.com/mailman/options/xep-support
>>> (*) By using the Service, you expressly agree to these Terms of
>>> Service http://w ww.renderx.com/terms-of-service.html
>>>
>>
>>
>
>
>
>
>
>

!DSPAM:87,530d22089857204917684!

_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html
Received on Tue Feb 25 15:06:51 2014