>>>>> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii
Dekel> In 1.1.6, a tabular is stored as follows
[...]
Dekel> This is makes the lyx file very large: we use about 250 bytes
Dekel> per cell (not including the text of the cells), comparing to
Dekel> about 35 bytes per cell with old tabular code. This can be
Dekel> improved in the following ways:
I agree that table format is much too verbose.
Dekel> 1. The table/row/column/cell attributes should be written only
Dekel> if they differ from the default value (so instead of <Cell
Dekel> multicolumn="0" alignment="8" ...> we will, usually, have just
Dekel> <Cell> ).
This should be done later without problems, right? (not really breaks
the format).
Dekel> 2. The <Features> tag is redundant. The attributes stored there
Dekel> can be stored in <LyXTabular>.
This would not be a great saving anyway.
Dekel> 3. There are many redundant <Column> tags. Instead, we can use,
Dekel> for example,
Dekel> <LyXTabular (attributes)> <Column (1st column attributes)>
Dekel> <Column (2st column attributes)> ... <Row (attributes)> <Cell
Dekel> (attributes)> cell text </Cell> <Cell (attributes)> cell text
Dekel> </Cell> </Row> ...
Obviously, as is is used, Column and Cell could be merged (is there
only one cell per column?). Or maybe the current format is needed to
support multicolumn?
Other things to consider:
4. since xml tags are case dependent (am I right?), do we really want
to use this mixed case style?
5. the font settings of the text insets should be reduced against the
default font of the document, since this is what the default
tabular font is (am I right?).
Dekel> Although we want to release 1.1.6 soon, I think that the we
Dekel> should consider changing the tabular file format BEFORE 1.1.6.
Dekel> I've already made a patch that implements (1).
I guess that's Lars and Juergen decision.
JMarc
