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] auto-play presentation file format like PPS



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):
  1. When in a presentation is in editing mode, the editing UI is show and page and object transition do not play.  
  2. 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.
  3. 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.


Inactive hide details for Re: [office] auto-play presentation file format like PPSRe: [office] auto-play presentation file format like PPS



Re: [office] auto-play presentation file format like PPS


Warren Turkal

to:

Bob Jolliffe

2008-04-26 00:33



Cc:

office, Ming Fei Jia







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]