Apache OpenOffice (AOO) Bugzilla – Issue 53489
Column widths in Writer only calculated in percent values
Last modified: 2013-02-07 22:37:19 UTC
I've been using XSLT stylesheets to create the "content.xml" file in Open Document format in OO.o Writer 1.9.122. The source documents in DocBook XML format specify table column widths proportionally using the "n*" notation, where "n" is the proportion. These values are copied directly to the Open Document content because they are defined to mean the same thing and work the same way. In Open Document the content looks like this: <style:style style:family="table-column" style:name="col1"> <style:table-column-properties style:rel-column-width="40*"/> </style:style> <style:style style:family="table-column" style:name="col2"> <style:table-column-properties style:rel-column-width="60*"/> </style:style> <!-- .... --> <table:table table:style-name="YYY" table:table-name="t1"> <table:table-columns> <table:table-column table:style-name="col1"/> <table:table-column table:style-name="col2"/> </table:table-columns> <!-- ... --> </table:table> When I open this content in Writer, it looks fine. The column widths are split 40:60 as expected. However, if the proportions are specified as values that do not resemble percentages, it does not work. The same relative column widths can be specified using "2*" and "3*" instead of "40*" and "60*", but small numbers like that result in all columns appearing to be the same width. Because the "percentage-like" ratios work and the very same ratios specified using "non-percentage-like" values do not work, I suspect that the relative column widths are being interpreted as percentages instead of arbitrary ratios. This does not conform to the Open Document 1.0 specification (section 15.9.1 "Column Width") that shows how the widths should be calculated from the proportional values (the same way as DocBook does it, which it why the transformation should be so convenient and why I noticed that there was a problem). I tried to find the source code that does this calculation but got completely lost and couldn't find anything at all--I didn't even know which CVS repository might contain the code--so, I can't confirm that the reason for the problem is what I suspect it might be. Does anyone know where that code might be?
Currently relative column width in Writer tables are calculated in percent values. There should also be a possibility according to the OpenDocument spec. There, also a possibility is stated where absolute relations like 1:3:4 (for three cells) can be used.
Are you sure this should be treated as an "enhancement"? Treating the relative column widths as "percent values" is simply wrong and not just an incomplete implementation that can later be enhanced. The treatment only works when, by accident or design, the relative widths add up to approximately 100 (once the total is close to 100, any slight error will probably go unnoticed). The Open Document specification says: "A relative width is specified by the style:rel-column-width property that takes a number value, followed by a '*' character. If rc is the relative with [sic] of the column, rs the sum of all relative columns widths, and ws the absolute width that is available for these columns, then the absolute with wc of the column is wc=rc ws/rs." Nowhere is there any suggestion that these values should be assumed to be percentage values. As I cannot find the code in question, I would guess that the error is that "rs" (the sum of all relative column widths) is being assumed to be 100 instead of being calculated correctly by summing the relative width values for each column. This use of "n*" notation for relative width values is identical to the proportional width scheme defined in the DocBook specification and assuming the values to be percentages (despite the "*" character, not the "%" character) hinders what was probably a deliberate attempt to make the specifications compatible in this respect. In the meantime, I can work around this by converting the ratios to percentage values, but this is not easy to do in what was an otherwise simple XSLT stylesheet (I might post my solution later if I can get something working).
OpenOffice.org Issue Tracker - Feedback Request. The Issue you raised is currently assigned to 'Requirements' pending review, but has not been updated within the last 3 years. Please consider re-testing with one of the latest versions of OOo, as the problem(s) may have already been addressed. Either use the recent stable version: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ Please report back the outcome so this Issue may be Closed or Progressed as necessary - otherwise it may be Resolved as Invalid in the future. You may also wish to search for (and note) any duplicates of this Issue that may have advanced further by checking the Issue Tracker: http://www.openoffice.org/issues/query.cgi Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
In the intervening four years I have lost interest in this issue and do not intend to retest it. I fail to see the point of a bug tracking system where reporters put a lot of effort into reporting issues only to be told years later to retest because the bug may have been fixed by accident. You don't need a bug tracking system to manage a process like that--just redirect everything to /dev/null.