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

[Ming Fei Jia <jiamingf@cn.ibm.com>]

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

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

Warren Turkal

to:

Ming Fei Jia

2008-04-23 01:35

Cc:

office

---

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.

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

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

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

> 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,here I want to say "play" should also be enough generic although now we can see limited user scenarios, e.g play presentation doc. 
>  <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.

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

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