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


On Wed, Apr 23, 2008 at 5:24 AM, Ming Fei Jia <jiamingf@cn.ibm.com> wrote:
>  On Tue, Apr 22, 2008 at 12:06 AM, Ming Fei Jia <jiamingf@cn.ibm.com> wrote:
>  > Re: [office] auto-play presentation file format like PPS
>  >  <jmf>
>  >  I understand the "auto" you mean is different from mine. My "auto"
>  > emphasizes the launching application by a shortcut way. Your "auto" means
>  > play the slides automatically upon open. But you should know the behavior
> of
>  > MS PPS file, when open the PPS file via a shortcut way, it just enters
>  > "play" status, you need to play the slides by press the enter or some
> other
>  > triggered ways, not "automatically" as you described.
>
>  >What are the differences between this "triggered" play mode and the
>  >readonly mode?
>  Readonly mode is like those ODF viewer,PDF viewer showing,and users can not
> modify contents. Play mode is a kind of screen show, in which user can
> present slides(for meta file,might be each drawing segment) according to
> some triggered event. I think "play" itself already contains the meaning of
> "automatically" you described.

In my view, the only thing that the play/auto-play/whatever name value
would indicate is that the presentation would start upon opening the
document instead of waiting to be run by the user. Maybe
"presentation-auto-start" would be a better name.

>  > What we want is the
>  > "play" status like PPS. As to how the slide is played, "automatically" or
>  > "manually" should not be what we are talking about. We want to define a
>  > preferred view mode.
>
>  >If I am interpreting this statement correctly. You are asking for
>  >details about how a slide is presented during play. For instance, you
>  >want the ability to express something like "goto slide 1, play some
>  >sound, wait 30 sec, goto slide 2, wait 30 sec, etc." Is that correct?
>  >If that is what you are wanting, the preferred view mode shouldn't
>  >have anything to do with that problem.
>  You interpretation is correct. I also think "the preferred view mode" has
> nothing to do with how a slide is presented. See "should not be" in my
> prevous comments. So we should have no disagreement for this point.

Since my interpretation is correct, I think it is important to note
that OO.o already implements the timings for slides and effects in the
presentation. I also just confirmed that the support is in the
standard. This indicates that this proposal should have nothing to do
with slide or effect timings.

>  > Right...and a
>  > Also something like "presentation-auto-play" was
>  > already defined as one attribute of presentation in the original
> proposal,
>  > but you know, after discussion, we all agreed to move that out of
>  > presentation layer to more generic layer.

Actually, I never understood our discussion to say that we should
introduce the play view functionality to other types of documents. The
only things I got from the discussion were:
1) There is a need for "preferred-view-mode"s at the manifest level
2) Certain types of documents may use  "preferred-view-mode"s that
don't exist in other types of documents
3) A "readonly" mode makes sense for something like an ebook reader.
4) We could use MIME type args to make the "preferred-view-mode"
easily accessible.

Everyone, if I missed something, please let me know.

>  > In this generic layer, it is
> not
>  > reasonable to mark "presentation" tag on the view mode name although we
> know
>  > it might be only meaningful for presentation now.

The value namespace of "preferred-view-modes" should not be polluted
with global looking modes when they only apply to one document type.
There is not reason that we couldn't define a "auto-play" in a future
revision if we find that it makes sense for more than presentations.

>  >I don't remember agreeing that the auto-play mode would be defined for
>  >anything but presentations. There has clearly been a breakdown in
>  >communications (possibly only on my side), and I think we might need
>  >to address that before we can productively move on.
>  History is past:) What we are mattering is to get consensus for current
> point. We say "play" might be only meaningful for presentation, not say
> definitely it is. Maybe "play" a meta file,or "play" something other
> documents that are generated by other than presentation applications. "play"
> here is kind of screen show, in which user can present contents step by step
> according to some triggered events. It should not be limited to
> presentation.

I will not consent to adding slide timings (and other presentation
specific) info at the manifest level. Again the standard already
includes the information for slide and effect timings.

I will also not consent to adding poorly defined "play" mode.

>  > Cannot we say "play" a
>  > meta file? What's more, if we think "readonly" might be only for word
>  > processor, can we say the attribute name as "word-processor-readonly"?
>  >  </jmf>
>
>  >I never claimed that readonly was only for the word processor. I think
>  >it is sufficiently generic to apply to all document types. So far only
>  >"readonly" and "edit" are the only preferred-view-modes that are
>  >sufficiently generic to apply to all docs..
>  I did not say you claimed "readonly was only for the word processor", I
> said "if" that, just a metaphor. Anyway, that's not the point. I of course
> agree "readonly" and "edit" are sufficiently generic to apply to all
> docs,

I didn't realize that your were making a hypothetical. However, if it
could be said that some mode applied _only_ to word processing docs,
then it should be identified as such in the mode name. I don't think
that's unreasonable.

> here I want to say "play" should also be enough generic although now we
> can see limited user scenarios, e.g play presentation doc.

I am totally confused by this bit of your message.

>  >  <jmf>
>  >  As my understanding of "auto", it is relevant to interpreting the
> author's
>  > preference. As your understanding, it is irrelevant.
>
>  >I think its pretty clear that the OS launcher can use the information
>  >to launch the doc in some special way. I don't think we need to
>  >describe that in the standard at all. That's why it's not relevant. We
>  >aren't defining UI.
>  I agree we do not need to describe something like OS launcher in the
> standard. In previous comments, I already accepted your suggestion to remove
> that description in the proposal. I think there is no disagreement for this
> point. My previous comment is just an explanation for different
> understanding of "auto", which maybe bring you some misunderstanding. Sorry
> for that.

>  > But it does not matter,
>  > it is OK since we know what the actual is.
>  >  </jmf>
>
>  >I don't know what you are trying to say here. Please clarify.
>  It is the successive of previous explanation for different understanding of
> "auto", no disagreement here. "what the actual is" just means your "auto" is
> ..., and my "auto" is ... Sorry again if this still bring some
> misunderstanding.
>
>  >  <jmf>
>  >  This surely is a problem. Maybe any specification will meet such
> problem,
>  > generally we can not have bias to prefer specific products. But we have
> to
>  > prefer the existed users and the existed documents. This may be why ISO
>  > approved OOXML as a standard although many people opposed. BTW, Okular
>  > should be a viewer that mainly supports PDF.
>  >  </jmf>
>
>  >I wasn't attempting to start a discussion of which formats Okular
>  >prefers, which really doesn't matter. The point is to show that there
>  >is no reasonable default for a preferred-view-mode. I don't think
>  >there's anything wrong with the spec saying that the lack of a
>  >preferred-view-mode should be interpreted in an application specific
>  >manner. For an OS launcher, this probably means falling back to a
>  >default for the mimetype or extension, which is just fine. You just
>  >have to remember the following: if there is no preferred-view-mode in
>  >a document, we cannot just make up whatever we want for that value.
>  >It's simply data we don't have. Further, it's ok not to have that
>  >data.
>  Seems reasonable, you convince me. If there is no preferred view mode in a
> document, different applications can have their own interpretations, that
> should be OK since we can not cover so many applications. I also agree to
> add some words in the spec saying the lack of a preferred-view-mode should
> be interpreted in an application specific. Could you add the wording in the
> next comments? Thanks.

Sure.

What do you think of this wording?

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 define the intents of the defined views.

>  >  I think we need to figure this out because we really should have a
>  >  schema that someone could use to validate an ODF document. If the
>  >  schema doesn't represent an actual document spec, then what is the
>  >  point?
>  >  <jmf>
>  >  How about we just put "view" value there as a placeholder besides the
>  > definite view mode,"edit","play" and "readonly"?
>  >  </jmf>
>
>  >I don't think this does anything to address my concern.
>  Can you explain what your concern really is? If we have no appropriate
> schema to represent "any" view mode, currently we can choose: (1)do not
> define it at all, just add some words to explain that;(2) put "view" value
> there as a placeholder. Can you give a better solution? If not, why does
> neither of the above 2 options work for you? Thanks.

I will see if I can figure out the right schema to use.

BTW, 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 value of "preferred-view-mode" should be able to be defined by the app
5) the "preferred-view-mode" will have no default

Unresolved issues:
1) other standard defined values of the "preferred-view-mode" tag
2) how applications represent custom values for "preferred-view-mode"

Everyone again, if I have forgotten something, please chime in.

I have made a suggestion in the wording above for the representation
of custom views (item #2).

I have also suggested "presentation-auto-start" in the above text as a
replacement for "presentation-auto-play" or "play" (part of item #1).

Also, I still think that "readonly" mode really should be "read-only",
but I am willing to concede on that point.

wt


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