OASIS Open Document Format for Office Applications (OpenDocument) TC

robert_weir@us.ibm.com wrote:
> 
> Once we go down the road of defining runtime print behavior of 
> applications, we need to deal with more than just the data in the 
> document.  It gets messy very quickly.

I agree. Actually, I have no objection to defining in the specification 
how the default print range is calculated if that appears to be possible 
and reasonable, but it is also fine for me if we leave this up to the 
implementations.

In both cases, we need to adapt the wording of section 8.1.1. Assuming 
that we do not define how the print range is calculated, we may say 
something like:

If the table is printed, the table range that actually is printed may be 
specified by table:printrange attribute (see following section). If this 
attribute is not existing, the printing application may calculate the 
range to print.

> 
> -Rob

Michael
-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

My point is also that even if a print
range is defined, an application does not always follow it.  If the
user makes an explicit selection in the spreadsheet UI, then that is the
range printed, regardless of what is stored in the document that was loaded.

So we should say what table:printrange
actually is in practice, which is a hint or preference.  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.  Maybe
even new rows have been inserted into the spreadsheet, changing the effective
print range?

So all we can really say is "table:printrange
stores the last specified print range for this sheet. "

Applications that want to do something
with the last specified print range are free to use this value for that
purpose.  It probably would use it, along with the current state of
UI selection, to derive the actual range to print.  But we don't need
to get into that.  I don't think we need to say anything about what
happens if it is lacking either.

-Rob


Michael.Brauer@Sun.COM wrote on 07/01/2008 10:27:58
AM:


> robert_weir@us.ibm.com wrote:

> >

> > Once we go down the road of defining runtime print behavior of

> > applications, we need to deal with more than just the data in
the

> > document.  It gets messy very quickly.

>

> I agree. Actually, I have no objection to defining in the specification

> how the default print range is calculated if that appears to be possible

> and reasonable, but it is also fine for me if we leave this up to
the

> implementations.

>

> In both cases, we need to adapt the wording of section 8.1.1. Assuming

> that we do not define how the print range is calculated, we may say

> something like:

>

> If the table is printed, the table range that actually is printed
may be

> specified by table:printrange attribute (see following section). If
this

> attribute is not existing, the printing application may calculate
the

> range to print.

>

> >

> > -Rob

>

> Michael

> --

> Michael Brauer, Technical Architect Software Engineering

> StarOffice/OpenOffice.org

> Sun Microsystems GmbH             Nagelsweg
55

> D-20097 Hamburg, Germany          michael.brauer@sun.com

> http://sun.com/staroffice
        +49 40 23646 500

> http://blogs.sun.com/GullFOSS

>

> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,

>       D-85551 Kirchheim-Heimstetten

> Amtsgericht Muenchen: HRB 161028

> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer

> Vorsitzender des Aufsichtsrates: Martin Haering

2008/7/1  

"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%.

-Rob

2008/7/1  

>

> So reflect on what happens, not how.

>

> 1. No default in the spec.

> 2. User selection overrides stored values for a print

> 3. User selection stored over existing stored values .

> 4. No value, request one.

> 5. No more. Apps have run out of options. Hence non-compliant if they

> get this far

>

> Job done.

>


I don't believe #4 is what happens today.  I
believe that some implementations synthesize a default print range based
on their best guess of what parts of the document look like they have content
in them.  This derivation of a default range is done differently in
different applications.  Some may derive this by prompting the user.

So we bump of your #4.

Since #2 and #3 have nothing to do with the ODF document,
I don't think we should say anything about them.

That leaves #1, which has no defined behavior, which
we could explicitly state as implementation-defined.

You are really left with either having #1 be implementation
defined, or having #4 be implementation-defined.  I'd rather have
it be #1 and not go down the road of specifying user actions that lead
no where certain.

-Rob

2008/7/1  

Dave Pawson wrote:
> 2008/7/1  

On Tue, 2008-07-01 at 12:17 -0400, robert_weir@us.ibm.com wrote:
>   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. 

I would be rather astonished if an application would choose only to
print the range I happened to have selected in my document because I
edited it last.

>  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. 

I would agree with this as long as we don't in anyway imply that an
application ought to print a (accidentally or not) previously selected
range.

Andreas
> 

-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

On Tue, 2008-07-01 at 11:17 -0400, robert_weir@us.ibm.com wrote:
> 
> My point is also that even if a print range is defined, an application
> does not always follow it.  If the user makes an explicit selection in
> the spreadsheet UI, then that is the range printed, regardless of what
> is stored in the document that was loaded. 

Interesting. I am not aware of a spreadsheet in which there isn't always
a selection. So what do you mean with "explicit selection"? For example
in Openoffice.org, how do I make usre I have no explicit selection if I
have already clicked on a cell in this session?

Andreas

-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

Andreas J Guelzow <aguelzow@math.concordia.ab.ca>
wrote on 07/01/2008 02:02:41 PM:


> On Tue, 2008-07-01 at 11:17 -0400, robert_weir@us.ibm.com wrote:

> >

> > My point is also that even if a print range is defined, an application

> > does not always follow it.  If the user makes an explicit
selection in

> > the spreadsheet UI, then that is the range printed, regardless
of what

> > is stored in the document that was loaded.

>

> Interesting. I am not aware of a spreadsheet in which there isn't
always

> a selection. So what do you mean with "explicit selection"?
For example

> in Openoffice.org, how do I make usre I have no explicit selection
if I

> have already clicked on a cell in this session?

>


I mean an explicit print selection.  So, in Excel,
File\Print Area\Set Print Area.  OpenOffice has similar functionality
at Format\Print Ranges.

The point is that if a user makes such a selection,
they have not changed the value of printrange in their document.  In
fact, it may be a read-only document and the value of printrange cannot
change. 

In practice, printrange is the last printrange that
was set before the document was last saved.  Whether that range is
used again when the document is reloaded will depend on many things.  We
can't even assume that the range is still valid.  The sheet may have
been edited on the server, programmatically, and the printrange refers
to cells or sheets that no longer exist.

-Rob

On Tue, 2008-07-01 at 14:20 -0400, robert_weir@us.ibm.com wrote:
> The point is that if a user makes such a selection, they have not
> changed the value of printrange in their document.  In fact, it may be
> a read-only document and the value of printrange cannot change. 

I have never thought of considering only the "saved" version of the
document. In fact I think that is quite dangerous since "printing the
document" should clearly refer to the version as currently edited
whether saved or not or would you expect that printing only prints the
document as last saved?
> 
> In practice, printrange is the last printrange that was set before the
> document was last saved.

In practice for which application? I am pretty sure that in Excel, File
\Print Area\Show Print Area shows the print area as last set not
necessarily the last printrange that was set before the document was
last saved.

>   Whether that range is used again when the document is reloaded will
> depend on many things.  We can't even assume that the range is still
> valid.  The sheet may have been edited on the server,
> programmatically, and the printrange refers to cells or sheets that no
> longer exist. 

Are you telling me that the printrange contains sheet information? I
know that Gnumeric and I believe that also Excel and OpenOffice.org have
printareas that are sheet specific.

Andreas

-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

Andreas J Guelzow <aguelzow@math.concordia.ab.ca>
wrote on 07/01/2008 02:52:24 PM:


> On Tue, 2008-07-01 at 14:20 -0400, robert_weir@us.ibm.com wrote:

> > The point is that if a user makes such a selection, they have
not

> > changed the value of printrange in their document.  In fact,
it may be

> > a read-only document and the value of printrange cannot change.

>

> I have never thought of considering only the "saved" version
of the

> document. In fact I think that is quite dangerous since "printing
the

> document" should clearly refer to the version as currently edited

> whether saved or not or would you expect that printing only prints
the

> document as last saved?

> >

> > In practice, printrange is the last printrange that was set before
the

> > document was last saved.

>

> In practice for which application? I am pretty sure that in Excel,
File

> \Print Area\Show Print Area shows the print area as last set not

> necessarily the last printrange that was set before the document was

> last saved.

> 

table:print-ranges is the list of print ranges that
were last set before the document was last saved.  What prints at
runtime, given other user interactions, etc., could be different.  That's
my point.  

I don't disagree with anything you've said, but you
seem to disagree with what I'm saying.  I take that as a sign that
we're not speaking the same lingo yet.


-Rob