On 12/18/2013 10:02 PM, Jeff Hooker wrote:
It makes sense to me that as soon as I resize one column using the dragging
feature, that all the columns are immediately assigned proportional widths; the
feature needs something to size against. It would be nice to be able to define
the total width of the table in some way and have the proportional values key
off of it, but I don't see that anywhere in the spec of either Docbook or DITA,
so I suppose that's off the table.
However, I would suggest that all adjustments following the first one (which
set the proportions of all the columns) would be strictly a transaction between
the columns to the left and the right of the line being dragged, and any
rounding needed to make the numbers balance be performed only on those two
colspecs.
You are right.
However, given the fact that resizing a table column assigns a
proportional or percentage width to *all* the columns of the table, we
don't see how what you suggest could be implemented in a simple and
straightforward manner.
Please remember that initially some columns of the table may have no
specified widths or may have widths specified using absolute units.
Perhaps I'm missing something significant about the use of proportional sizing
vs. percentage. Given that both divide the table into 100 units of negotiable
size and assign the colspec elements values that add up to an even total, I
don't really see how they'd be different in practice.
Once again, you are right. I didn't notice this.
I should add that my first message related to XMLmind 5.4.1. I just tested the
same scenario in 5.7 and the outcome is less severe, but still undesirable. The
two columns being adjusted always gave away a single point of their value to
the final column in the table, while the other columns remained stable.
We have already changed our implementation:
1) DocBook/DITA CALS tables and DITA simpletables are now given a total
width of 1000 units. Previously, it was 100 units. (FYI, the XSL
stylesheets do not care about this.)
2) DocBook/DITA/XHTML tables: it's the column which becomes wider after
dragging its separator which may get slightly more units due to
rounding. Previously, it was always the last column.
Our implementation is still simple and straightforward, but gives
noticeably better results than before.
======================================================================
Please note that with XMLmind XML Editor, very few features are
hardwired or undocumented. Therefore a third-party Java programmer
should have no problem replacing our resize table column commands by
her/his own, smarter, resize table column commands.
DITA example:
Excerpts from XXE_install_dir/addon/config/dita/topic.xxe
---
<!-- Interactively resize a table column by dragging its separator. -->
<binding>
<appEvent name="resize-table-column" />
<command name="dita.resizeTableColumn"
parameter="%{resizedColumn} %{columnCount}
%{oldColumnWidths} %{newColumnWidths}" />
</binding>
<command name="dita.resizeTableColumn">
<macro>
<choice>
<!-- tgroup is selected -->
<command name="dita.resizeCALSTableColumn" parameter="%*" />
<!-- simpletable is selected -->
<command name="dita.resizeSimpleTableColumn" parameter="%*" />
</choice>
</macro>
</command>
<command name="dita.resizeCALSTableColumn">
<class>com.xmlmind.xmleditext.docbook.table.ResizeTableColumn</class>
</command>
<command name="dita.resizeSimpleTableColumn">
<class>com.xmlmind.xmleditext.dita.ResizeSimpleTableColumn</class>
</command>
---
This means that a smarter "resize table column by dragging a column
separator" may be achieved by replacing:
com.xmlmind.xmleditext.docbook.table.ResizeTableColumn
and
com.xmlmind.xmleditext.dita.ResizeSimpleTableColumn
by other, smarter, commands.
Reference:
http://www.xmlmind.com/xmleditor/_distrib/doc/configure/binding.html#resize_table_column_app_event
======================================================================
--
XMLmind XML Editor Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
