OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] Public comment #20 -- default print range in tables

"Dave Pawson" <dave.pawson@gmail.com> wrote on 07/01/2008 11:41:06 AM:

> >
> > So we should say what table:printrange actually is in practice, which is a
> > hint or preference.
> Or the default to be printed. Don't need to say any more.
>   It would not be incorrect for an application to
> > override or ignore this hint, since it may have more recent information,
> > such as a user selection.
> We're writing a standard Rob.
> If the default is ignored it's a simple non-compliance.

What you state is a fact.  But it is also irrelevant.

The question is not what a default value would mean for conformance.  The question is whether this value should be defined as a hint, and whether it should have a default.

I think it would be particularly bad practice to define a feature in ODF in a way which contradicts existing application practice as well as user expectations.  I believe that a user would be astonished if an application printed the range stored in the document rather than the range he/she has currently selected.  For that reason I would oppose any language in the ODF standard that made it a conformance requirement to print the range stored in the file.

This can all be solved if we define a runtime model, a runtime DOM, events, etc.  Then we just say that when you print, you print the current value of printrange in the DOM, and we define all of the things that can effect a change to that value.  So an onLoad event brings the value from the document into the DOM.  Inserting a row into the range intersecting the printrange will increase the height of the print range by one, etc.

But I don't sense any appetite for doing this in ODF 1.2.  We're a standard for a document format, not a standard for a word processor. That's where the focus it.  We cannot avoid touching on some runtime behaviors, but I think printing is 99% runtime and 1% printrange stored in the document.  We should hesitate to bite off that other 99%.


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