OASIS Open Document Format for Office Applications (OpenDocument) TC

Re: [office] Proposal for table templates

  • 1.  Re: [office] Proposal for table templates

    Posted 10-06-2003 12:40
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    office message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: [office] Proposal for table templates


    Hi,
    
    David Faure wrote:
    > The idea here is to define "table templates". This is a set
    > of settings (frame borders, background color, and text properties)
    > that can be applied to a table when creating it (see attached screenshot).
    > 
    > That's not really a "style" since we don't really want existing
    > tables to point to a style defined that way (but to have one style
    > per actual cell instead).
    > If someone wants to change existing tables afterwards, he'll have
    > to change the cell styles (either the style properties or which
    > style is used in which cell). This is really only for new tables,
    > which also means it has little impact in cross-application
    > document exchange. However it's something that we need to store in
    > the files (and templates) nonetheless (*).
    > 
    > First, this relies on styles for table cells, defining the
    >  - the frame style ( borders, and background color )
    >  - the paragraph and text properties.
    > 
    > * Then we can define a "table template". Current model would look like:
    > <table:table-template>
    >    <table:first-row table:style-name="graystyle" table:topleftcorner="yes" table:toprightcorner="yes"/>
    >    <table:first-col table:style-name="lightgray" table:topleftcorner="no" table:bottomleftcorner="yes"/>
    >    <table:body      table:style-name="default"/>
    > </table:table-template>
    > 
    > (with similar tags for last-row and last-col)
    > 
    > Slightly redundant model: first-row and first-col could both claim
    > the topleftcorner.
    > 
    > <table:table-template table:topleftcorner="top" table:toprightcorner="top" table:bottomleftcorner="left">
    >    <table:first-row table:style-name="graystyle"/>
    >    <table:first-col table:style-name="lightgray"/>
    >    <table:body      table:style-name="default"/>
    > </table:table-template>
    
    The second model seems to be more reasonable to me, because it doesn't 
    allow to specify that for instance the top left corner should take its 
    style from the first row and the first column simultanously, what of 
    course is a conflict. Anyway, maybe "row" and "column" (or even 
    "first-row" and "first-column" would be more intuitive as names for the 
    attributes "table:topleftcorner" etc., because the attribute then reads 
    as something like "take the style for the top left corner from the row". 
    I'm also wondering whether we should rename the <table:first-row> to 
    <table:top-row> etc. to use the same terms within the template.
    
    In addition to this, we might consider to also allow different styles 
    for even and odd numbered rows or columns, since this is something that 
    is used very often as well.
    
    > 
    > topleftcorner be either "top" (which means it belongs to first-row)
    > or "left" (which means it belongs to first-col).
    > bottomleftcorner can be either "bottom" or "left", etc.
    > bottomrightcorner doesn't need to be specified in this example
    > since there's no specific settings for last-row or for last-col.
    > 
    > How does the OO model deal with corners? In the example at the end of 4.7,
    > if the "Col1" style defined a red background color, it's not clear to me
    > whether the top-left corner is going to be red, or blue (since the first
    > row is defined to be blue).
    
    OOo takes the precedence rules of XSL-FO/CSS2. That is, a cell 
    background overwrites a row background, that overwrites a column 
    background, that overwrites a table background. Maybe we should define 
    defaults values for "table:tableleftcorner" etc. that match these 
    precedence rules.
    
    > 
    > (*) a more general question. If an application adds its own stuff to the
    > XML - as could be a solution for the above issue - other apps should happily
    > ignore that. Currently, by simply adding an attribute when saving to the OOo format,
    > OOo refused to load the file (because it validated the file against a DTD...). Only
    > removing the office:version attribute fixed it - see 
    >  http://lists.kde.org/?l=koffice-devel&m=106201904703783&w=2 for details.
    > Hmm, I guess this is the wrong list for this, if it's just a OOo bug.
    
    Since OOo does not validate files, it seems to be a bug in OOo if a file 
    that contains an unknown attribute cannot be loaded any longer. But I 
    agree that that we should discuss this either in the 
    dev@xml.openoffice.org mailing list or by e-mail.
    
    > 
    > Anyway. I'm fine if the answer to this proposal is "this is too 
    > application-specific, and not needed to model actual document contents".
    > But I think it raises an interesting question about corner cells, which needs
    > to be solved anyway.
    
    Since many office applications support such table templates, it seems to 
    be reasonable to me to add them to the specification. The only reason 
    that they are not part of the OpenOffice.org XML specification is that 
    OpenOffice.org does not store the templates within the documents.
    
    A reasonable place for the table templates seems to be the 
    <office:master-styles> element. <office:styles> seems not be be a 
    reasonable place, because it is not possible to reference automatic 
    styles inside this element. This in fact might be useful, because 
    otherwise all cell styles that are referenced from the table have to be 
    real UI styles. The <office:automatc-styles> element seems not to be a 
    reasonable place, because styles within this element have no name that 
    is avialable in the user interface.
    
    Best regards
    
    Michael
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]