office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] auto-play presentation file format like PPS
- From: robert_weir@us.ibm.com
- To: office@lists.oasis-open.org
- Date: Wed, 30 Apr 2008 16:52:46 -0400
Thanks for the summary.
I suggest we put aside the question
of what to name this setting and concentrate on a precise definition of
the behavior. Once we have a good definition, the name will be easier
to agree on.
My understanding of the problem as originally
stated, was that Microsoft PowerPoint had two different file extensions,
PPT files were opened up in the PowerPoint editor, while those with PPS
file extensions were opened by default in "screen show mode".
PowerPoint calls these "PowerPoint Show" files. There
was no difference in the files themselves. You can rename a PPS file
to a PPT file and edit it normally.
This is an orthogonal concept to read-only
versus editable, or from whether or not the slides advance automatically.
There are interactions, of course. Generally, it works like
this in PowerPoint and Impress and Freelance Graphics (which I worked on
many years ago):
- When in a presentation is in
editing mode, the editing UI is show and page and object transition do
not play.
- When in screen show mode, the
editing UI does not show. Instead you get a simplified viewing UI.
Also, page and object transitions (animations) play. Auto-advance
of a slide is just one example of a page transition.
- When in screen show mode, the
file cannot be edited. This is because there is no editing UI presented.
I think the difference between edit
mode and view mode applies to other document types as well. For example,
David Wheeler mentioned the example of a text document on the XO laptop,
which might be in a view mode for students in a class, who are using it
to read the document.
ODF already takes care of object and
page transitions, including the ability of presentation slides to auto-advance
according to a timer. We don't need to reinvent that part.
Do we need anything more than a simple
statement like:
"The foo attribute, when set to
true, indicates that the document should be loaded and displayed using
a presentation-oriented user experience mode rather than an authoring-oriented
user experience mode. The details of these two modes are implementation-dependent,
but typically a presentation-oriented mode will suppress an editing user
interface and will instead be optimized for viewing and navigating the
document."
Regards,
-Rob
Rob Weir
Software Architect
Workplace, Portal and Collaboration Software
IBM Software Group
email: robert_weir@us.ibm.com
phone: 1-978-399-7122
blog: http://www.robweir.com/blog/
Ming Fei Jia <jiamingf@cn.ibm.com>
04/29/2008 12:22 PM
|
To
| "Warren Turkal" <turkal@google.com>
|
cc
| office@lists.oasis-open.org
|
Subject
| Re: [office] auto-play presentation
file format like PPS |
|
Go through the previous long list of comments, also with
your explanation in this mail, I confirm the contents with consensus for
this topic include #1 and #2:
#1 consensus description part:
The manifest:preferred-view-mode attribute is meant to provide a preference
on how the author of the document would like the document to be presented.
There is no default. View modes are not necessarily generally applicable
to all MIME types. The way in
which an application responds when no "preferred-view-mode" attribute
is specified is undefined.
#2 consensus schema part:
<define name="file-entry-attlist" combine="interleave">
<optional>
<attribute name="manifest:preferred-view-mode">
<choice>
<value>edit</value>
<value>readonly</value>
</choice>
</attribute>
</optional>
</define>
The unresolved issues include #3,#4,#5:
#3 view mode name for auto-play
currently you prefer "presentation-auto-start", I still prefer
"play". I understand "presentation-auto-start" means
"start to play slides on opening the file" or "enter play
state on opening the file".
There are 2 sub issues to discuss:
(1) understanding of "auto-start".I think here "auto"
has the same meaning of "on opening the file", which is the user
scenario for the view mode. "auto-start" itself can not express
a kind of view mode. Like "edit" or "readonly", although
we mean "start to edit" or "start to view without allowing
modification" on opening the file, we still agree to call the view
mode as "edit" or "readonly" instead of "editor-auto-start"
or "viewer-auto-start" since the "auto" meaning already
is implict. If we want to express the "auto" explictly, I suggest
to add the words "upon the document is opened" to the #1 description,
i.e. the first sentence should be "The manifest:preferred-view-mode
attribute is meant to provide a preference on how the author of the document
would like the document to be presented upon the document is opened".
(2) whether the view mode name should contain the application name, like
"presentation-auto-start". I copy my previous comments here:"Let's
succeed the discussion with the hypothetical of "readonly mode only
apply to word processor now". If now we define the name as "wordProcessor-readonly",
and in the future when there are some other applications called "XXX1","XXX2",...,
which also make sense for "readonly", then at that time we shall
have to define the new view modes as "XXX1-readonly","XXX2-readonly",etc.
Do you think that will make sense for you? Why do not we just define "readonly"
there now? As the same situation, why do not we just define "play"
there now?". Adding application name
to the view mode name will bring trivial definitions.
#4 custom view mode definition
It makes sense for me to define a custom view mode, but depends an appropriate
schema expression. It does not make sense for me that the custom view name
contains the application name as the above reason.
Additionally, I copy my previous comments for the suggested 2 descriptions
in the parentheses:
The following modes are defined by this standard:(remove
"by this standard", extraneous)"edit",
"readonly",and presentation-auto-start".The "edit"
and "readonly" values can be applied to any MIME type. The presentation-auto-start"
value can be applied only to presentations. ("presentation-auto-start"
does not make sense for me, the reason is in the above. Also, I suggest
it is not necessary to state like "The "edit" and "readonly"
values can be applied to any MIME type. The "presentation-auto-start"
value can be applied only to presentations". Remove the sentence.)
Applications are also free to create their own custom views. Custom views
MUST start with "x-". It is RECOMMENDED that views that don't
applied to all MIME types identify the type of document they can be applied
to in their name (e.g. "presentation-auto-play").
(It does not make sense for me
to add application name in the mode name. The reason is in the above. I
think this paragraph is extraneous.)
#5.TODO: We will also need to define the intents of the defined views.
It will be a good thing if you want. But spec should keep concise, if something
is obvious, no need to state it detailedly.
Re:
[office] auto-play presentation file format like PPS
|
Re: [office] auto-play presentation file
format like PPS |
|
On Thu, Apr 24, 2008 at 9:53 PM, Bob Jolliffe <bobj@dst.gov.za> wrote:
> Warren I think you might be a little bit confused. The point
is not for the presentation to "play itself" in the automated
manner you suggest.
>
> When you present a presentation you open the file and by default
you are in an edit mode - as is the case with the file you provide. From
here you would normally have to press the button, or select the menu item
or press the shortcut key (all of these being application dependent) to
actually "play" or "present" the presentation. The
only thing automatic which is being suggested is to arrive at this point
(automatically) on opening the file.
I was trying to communicate this in my prior messages. Here's a
potential workflow when opening a file in OO.o or another office
suite. The "presentation-auto-play" mode would basically start
into
presentation mode when opening the file (something like opening the
file and choosing "Slide Show" -> "Slide Show" in
OO.o). Of course
you'd be able to press <ESC> and go back to edit mode.
The point of my immediately prior message was to clarify what Ming was
looking for. I am confused at this point as to (1) whether he is
looking for something like the presentation file I sent in the last
message or (2) whether he is looking for a way to start the
presentation mode upon opening the file.
(1) is already addressed in the ODF 1.2 draft 7 (and probably earlier
revisions of the standard).
(2) is what I thought we were discussing. I still think that
"presentation-auto-start" is better than "play". It
indicates that the
mode only applies to presentations and that it will start the
presentation automatically.
Here's my suggested text for the description of preferred-view-mode attribute:
The manifest:preferred-view-mode attribute (should this be "tag")
is
meant to provide a preference on how the author of the document would
like the document to be presented. There is no default. View modes are
not necessarily generally applicable to all MIME types. The way in
which an application responds when no "preferred-view-mode" attribute
is specified is undefined.
The following modes are defined by this standard: "edit", "readonly",
and "presentation-auto-start". The "edit" and "readonly"
values can be
applied to any MIME type. The "presentation-auto-start" value
can be
applied only to presentations.
Applications are also free to create their own custom views. Custom
views MUST start with "x-". It is RECOMMENDED that views that
don't
applied to all MIME types identify the type of document they can be
applied to in their name (e.g. "presentation-auto-play").
TODO: We will also need to add text define the intents of the standard
defined views.
Also, here is a summary of the situation, as I understand it.
Issues with consensus:
1) the tag should be called "preferred-view-mode"
2) "edit" is a possible value for the tag
3) "readonly" is a possible value of the tag
4) the "preferred-view-mode" will have no default
5) apps should be able to define custom values of
"preferred-view-mode" (changed text from my prior message
Unresolved issues:
1) other standard defined values of the "preferred-view-mode"
tag
2) how applications represent custom values for "preferred-view-mode"
Suggested schema:
<define name="file-entry-attlist" combine="interleave">
<optional>
<attribute name="manifest:preferred-view-mode">
<choice>
<value>edit</value>
<value>play</value>
<value>presentation-auto-start</value>
<text/>
<!-- is there anything we can do to limit the previous line to
"x-"<text/> so that extensions can only have "x-*"
names? Also, is the
previous line valid in RelaxNG? -->
</choice>
</attribute>
</optional>
</define>
> I don't think anyone is suggesting that the presentation should
actually "play" itself. Just that it should be possible
to open it in a mode where it is ready to be "played" or presented
rather than ready to be edited.
I thought this was the case. I may have misread some of Ming's
messages, but I got the idea that he was saying that he wasn't looking
for automatically starting the presentation upon opening the file,
which is what I originally thought we were discussing.
wt
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
pic30015.gif
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]