- From: Futomi Hatano <futomi.hatano@newphoria.co.jp>
- Date: Sat, 25 May 2013 16:33:44 +0900
- To: public-websignage@w3.org
- Cc: franck.dupin@innes.fr
Hi all,
I updated the doc as a result of the discussion of SVG.
http://futomi.github.io/Web-based_Signage_Player_Core_Profile/
* Delete "SVG-based page" from "7 Scene content types"
You can see the changes in detail here.
https://github.com/futomi/Web-based_Signage_Player_Core_Profile/commit/f164576ac86dd80691426f38bec86682850273bd
This does not mean SVG is excluded.
SVG is still referred in the doc.
This implies that the support of SVG as a scene content type is
changed from "MUST" to "MAY" in the Core Profile.
Cheers,
Futomi
On Fri, 24 May 2013 21:36:23 +0200
"Franck Dupin" <franck.dupin@innes.fr> wrote:
> Hi all
>
> I share the point of view of Futomi.
> For example, in Playzilla (our player), the control data is a smil file (CSS3 + JS with more) .
> HTML5 and SVG are content type.
> Attention: We were taken to manage an AppCache file in addition to the control data file. This notion is not specified in the paper. I do not know if this should be the case. John, have you had the same need in your "offline" smil player?
>
> Concerning SVG in the core format, I understand the opinion of john in the case of a box or display with old ARM processor. But the evolution of processors today bring minimum of html5 with SVG, Canvas, etc ...
> For example new Samsung Smart Signage Large Display support a complete HTML5 stack (http://www.samsungdforum.com/Devtools/Spec). Spinetix too, maybe Brightsign ....
>
>
> Sincerly,
>
> Franck Dupin
> INNES
> ZAC Atalante champeaux
> 5A rue Pierre Joseph Colin
> 35000 RENNES - FRANCE
> Tel: +33 (0)2 23 20 01 62 / Fax: +33 (0)2 23 20 22 59 / http://www.innes.pro
>
>
>
>
>
>
> -----Message d'origine-----
> De : John C. Wang [mailto:John.Wang@IAdea.com]
> Envoyé : vendredi 24 mai 2013 06:01
> À : Futomi Hatano
> Cc : public-websignage@w3.org
> Objet : Re: Some comments
>
> Agreed.
>
> John C. Wang
> IAdea: Digital Signage Media Appliances
> http://www.IAdea.com
> Skype: jcwang_tw
>
> On 5/24/2013 11:59 AM, Futomi Hatano wrote:
> > Hi John,
> >
> > I think SMIL is a kind of the playlist formats rather than a content type of a scene.
> > In the doc, it is called "Control data".
> > See the section "3 Concept of control data".
> > http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#concept
> > _of_control_data I know SMIL is common in the signage industry, so I
> > intentionally didn't define the format of the control data in the doc.
> > We can use SMIL as the format of the control data.
> > (though someone has to develop a parser of SMIL as a JavaScript
> > library)
> >
> > Cheers,
> > Futomi
> >
> >
> > On Fri, 24 May 2013 11:38:05 +0800
> > "John C. Wang" <John.Wang@IAdea.com> wrote:
> >
> >> Hi Futomi:
> >>
> >> Thanks for the consideration. I don't think there is too many companies using SVG, but many may be using SMIL (see http://www.a-smil.org/index.php/SMIL_systems for commercial digital signage products), which shares a subset in the animation portion with SVG. However, I feel it would be highly controversial if we include either one as REQUIRED by the Core Profile.
> >>
> >> Personally I'd recommend listing SMIL as an "option" in light of the large number of supporting software options.
> >>
> >> John C. Wang
> >> IAdea: Digital Signage Media Appliances http://www.IAdea.com
> >> Skype: jcwang_tw
> >>
> >> On 5/24/2013 10:40 AM, Futomi Hatano wrote:
> >>> Hi John,
> >>>
> >>> Thanks for your comment.
> >>> It's a good question!
> >>> It's just what I want to discuss.
> >>> In fact, I don't have any logic to put SVG in the doc.
> >>> I heard many signage players support SVG documents.
> >>> So I put it in the doc. That's it for now.
> >>> But I don't know SVG is actually and commonly used in the signage
> >>> industry around the globe.
> >>> SVG is not common at least in Japan.
> >>> Personally, I think SVG may be put away from the Core Profile.
> >>> If needed, it can be put in an another profile, such as "Content
> >>> Type Profile".
> >>>
> >>> Your comment is very helpful.
> >>> I'll wait for other member's opininons for a while.
> >>> If no one disagrees with putting it away, I'll delete it from the
> >>> Core Profile.
> >>>
> >>> Cheers,
> >>> Futomi
> >>>
> >>> On Thu, 23 May 2013 12:35:37 +0800
> >>> "John C. Wang" <John.Wang@IAdea.com> wrote:
> >>>
> >>>> Dear Futomi:
> >>>>
> >>>> Thanks for the work and I have a quick question.
> >>>>
> >>>> Section 7, it seems you listed SVG-based page as a "requirement". Is there a practical reason for requiring so? I feel okay with SVG as an option ('MAY' instead of 'MUST') but a requirement I believe will add unnecessary complexity to players as SVG may be an overly complicated spec.
> >>>>
> >>>> Just wanted to understand the logic behind your thinking.
> >>>>
> >>>> John C. Wang
> >>>> IAdea: Digital Signage Media Appliances http://www.IAdea.com
> >>>> Skype: jcwang_tw
> >>>>
> >>>> On 5/23/2013 10:03 AM, Futomi Hatano wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I updated the doc as a result of the discussion in this thread.
> >>>>> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/
> >>>>>
> >>>>> * Delete the phrase mentioned abut PDF from "Single image"
> >>>>> * Replace the term "content viewport" with "application viewport"
> >>>>>
> >>>>> You can see the changes in detail here.
> >>>>> https://github.com/futomi/Web-based_Signage_Player_Core_Profile/co
> >>>>> mmit/fdf8e989068fdec4460da218de9d03684282d909
> >>>>>
> >>>>> Besides, I added "Scheduling Profile" as a planned profile on the wiki.
> >>>>> http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_for
> >>>>> _Web-based_Signage_Player
> >>>>>
> >>>>> Cheers,
> >>>>> Futomi
> >>>>>
> >>>>>
> >>>>> On Thu, 23 May 2013 09:50:11 +0900 Futomi Hatano
> >>>>> <futomi.hatano@newphoria.co.jp> wrote:
> >>>>>
> >>>>>> Hi Franck,
> >>>>>>
> >>>>>>> 7 Scene content types
> >>>>>>>
> >>>>>>>> I know PDF is *not" identical to an image file.
> >>>>>>>> But in terms of HTML, PDF is conceptually similar to an image
> >>>>>>>> file because the img element in a HTML document is allowed to
> >>>>>>>> embed an PDF file in itself.
> >>>>>>> I am not agree. PDF must be see like a document and not like an elementary media (image or video).
> >>>>>>> PDF can contain jpeg, font, signature, stamp, mp3, forms like a HTML page.
> >>>>>>> For example, our player (Playzilla) treat PDF like a HTML page with “PDF.JS” inside a iframe.
> >>>>>> Good point. It makes sense.
> >>>>>> Maybe, we see PDF in a different way.
> >>>>>> You see it in terms of its structure.
> >>>>>> I see it in terms of authoring.
> >>>>>> (Authors can treat the both in a same way using the img element)
> >>>>>> Anyway, it seems to be confusing if PDF is put in "Single image".
> >>>>>>
> >>>>>> The following phrase seems to be deleted from "Single image".
> >>>>>> [[
> >>>>>> Players may support more sophisticated formats, such as PDF.
> >>>>>> [PDF] ]]
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Futomi
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, 22 May 2013 22:32:32 +0200 "Franck Dupin"
> >>>>>> <franck.dupin@innes.fr> wrote:
> >>>>>>
> >>>>>>> Hi Futomi,
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> My comments about your comments :
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> 6 Regions
> >>>>>>>
> >>>>>>> …
> >>>>>>>
> >>>>>>> sorry, I did not read
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> 7 Scene content types
> >>>>>>>
> >>>>>>> >>>
> >>>>>>>> I know PDF is *not" identical to an image file.
> >>>>>>>> But in terms of HTML, PDF is conceptually similar to an image
> >>>>>>>> file because the img element in a HTML document is allowed to
> >>>>>>>> embed an PDF file in itself.
> >>>>>>> >>>
> >>>>>>> I am not agree. PDF must be see like a document and not like an elementary media (image or video).
> >>>>>>>
> >>>>>>> PDF can contain jpeg, font, signature, stamp, mp3, forms like a HTML page.
> >>>>>>>
> >>>>>>> For example, our player (Playzilla) treat PDF like a HTML page with “PDF.JS” inside a iframe.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>> As you mentioned, PDF have the slideshow mode. On the other
> >>>>>>>> hand, GIF can have similar capability using animations (i.e. animation GIF).
> >>>>>>>> I think that having the slideshow mode is not a matter in this context.
> >>>>>>> >>>
> >>>>>>> Why not, but GIF is an elementary media not a document.
> >>>>>>>
> >>>>>>> W3C describes very well the kinds compound documents CDF by
> >>>>>>> inclusion (pdf, epub, ms-powerpoint,..) and CDF by reference
> >>>>>>> (HTML, RSS feeds,…)
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>> The document is "Core Profile".
> >>>>>>>> As described in the section "Abstract", it defines just
> >>>>>>>> requisite minimum for web-based signage.
> >>>>>>>> Most of existing signs don't need all features.
> >>>>>>>> We can define other features as other profiles.
> >>>>>>>> Actually, this BG has listed some profiles in the wiki.
> >>>>>>>> <http://www.w3.org/community/websignage/wiki/Main_Page#Profiles
> >>>>>>>> _for_Web-based_Signage_Player>
> >>>>>>>> http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_
> >>>>>>>> for_Web-based_Signage_Player
> >>>>>>> >>>
> >>>>>>> Right.
> >>>>>>>
> >>>>>>> But my point of view is that it is questionable to support “PDF format” in the core profile.
> >>>>>>>
> >>>>>>> why not consider it in a more complete profile?
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>> 8 Playlist
> >>>>>>>> …But the "Core Profile" doesn't treat media files such as video, audio.
> >>>>>>>> Video and audio are planed to be defined in the "Basic Media Profile"
> >>>>>>> Right.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>>> 9 Scheduling
> >>>>>>>>> Why don’t advice full features of iso8601 (
> >>>>>>>>> <http://en.wikipedia.org/wiki/ISO_8601> http://en.wikipedia.org/wiki/ISO_8601) :
> >>>>>>> >>>
> >>>>>>>> Though the documents we are planning don't define the format,
> >>>>>>>> It seems to be really helplul. I didn't know it.
> >>>>>>> >>>
> >>>>>>>>> Repeated Date/Time Events with some examples :
> >>>>>>>>> On the top of every hour starting 9AM on January 1st, 2010
> >>>>>>>>> R/2010-01-01T09:00/PT1H On midnight of each of the first 6
> >>>>>>>>> Mondays in the year 2010 R6/2010-01-01+w1/P1W
> >>>>>>> >>>
> >>>>>>>> It seems to be useful.
> >>>>>>>> How about we plan to make "Scheduling Profile" or "Scheduling
> >>>>>>>> Extension"?
> >>>>>>> >>>
> >>>>>>> Scheduling Profile : Indeed it would be a good idea
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> Sincerely,
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> Franck Dupin
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> Description : logo-innes
> >>>>>>>
> >>>>>>> ZAC Atalante champeaux
> >>>>>>>
> >>>>>>> 5A rue Pierre Joseph Colin
> >>>>>>>
> >>>>>>> 35000 RENNES - FRANCE
> >>>>>>>
> >>>>>>> Tel: +33 (0)2 23 20 01 62 / Fax: +33 (0)2 23 20 22 59 /
> >>>>>>> http://www.innes.pro
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> -----Message d'origine-----
> >>>>>>> De : Futomi Hatano [mailto:futomi.hatano@newphoria.co.jp]
> >>>>>>> Envoyé : mercredi 22 mai 2013 03:22 À : franck.dupin@innes.fr Cc
> >>>>>>> : public-websignage@w3.org Objet : Re: Some comments
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> Hi Franck,
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> Thanks for your helpful comments.
> >>>>>>>
> >>>>>>> Responses inline below.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> On Tue, 21 May 2013 23:07:07 +0200
> >>>>>>>
> >>>>>>> "Franck Dupin" < <mailto:franck.dupin@innes.fr> franck.dupin@innes.fr> wrote:
> >>>>>>>
> >>>>>>> >>>
> >>>>>>>> Hi Futomi.
> >>>>>>>> Thanks a lot for your work about web signage player.
> >>>>>>>> I have some comments about your document proposal (
> >>>>>>>> <http://futomi.github.io/Web-based_Signage_Player_Core_Profile/> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/) :
> >>>>>>>> 4. Concept of viewport
> >>>>>>>> “The display viewport is the area in which the display can show something.
> >>>>>>>> The content viewport is the area in which an application shows
> >>>>>>>> web-based signage contents. The display viewport and the
> >>>>>>>> content viewport are not necessarily identical.”
> >>>>>>>>> I’m bored with your notion of “content viewport”. in fact, you
> >>>>>>>>> describe
> >>>>>>>> here an “application viewport”. “application viewport” being
> >>>>>>>> composed of a region(s), of a scene, of a content like your
> >>>>>>>> illustration
> >>>>>>> >>>
> >>>>>>> You are right.
> >>>>>>>
> >>>>>>> The term "content viewport" is likely to be confusing.
> >>>>>>>
> >>>>>>> The term "application viewport" seems to be better.
> >>>>>>>
> >>>>>>> I'll modify it soon.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>>> 6 Regions
> >>>>>>>> “Background color
> >>>>>>>> This color will be seen at areas where the contents do not
> >>>>>>>> exist or the contents are transparent. This color is specified in a CSS color.
> >>>>>>>> [CSSCOLOR]”
> >>>>>>>>> You talk about background color for regions but can we
> >>>>>>>>> consider background
> >>>>>>>> color for content viewport ( and display viewport) ?
> >>>>>>> >>>
> >>>>>>> Yes.
> >>>>>>>
> >>>>>>> This document has already included the background color for both of the content viewport (a.k.a. application viewport) and the display viewport.
> >>>>>>>
> >>>>>>> See the section "5 Viewport properties".
> >>>>>>>
> >>>>>>>
> >>>>>>> <http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#
> >>>>>>> viewport_properties>
> >>>>>>> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#v
> >>>>>>> iewport_properties
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>> 7 Scene content types
> >>>>>>>> “Conformant players of this profile must support 3 types of
> >>>>>>>> contents as a scene.
> >>>>>>>> Single image
> >>>>>>>> Players must render an image file as a scene. Players must
> >>>>>>>> support PNG, GIF (including animation gif), and JPEG as an
> >>>>>>>> image format at least. An image file is rendered using the img
> >>>>>>>> element or the object element specified in HTML5. [PNG] [GIF]
> >>>>>>>> [JPEG] [HTML5] Players must support DataURLs for images.
> >>>>>>>> [RFC2397] Players may support more sophisticated formats, such
> >>>>>>>> as PDF. [PDF] “
> >>>>>>>>> I think it is an error to consider pdf document like single
> >>>>>>>>> image. Pdf is a
> >>>>>>>> CDFi (Compount Document Format by Inclusion – see
> >>>>>>>> <http://www.w3.org/2004/CDF/> http://www.w3.org/2004/CDF/)
> >>>>>>>> and specifically “paged document” with slideshow mode
> >>>>>>> >>>
> >>>>>>> I know PDF is *not" identical to an image file.
> >>>>>>>
> >>>>>>> But in terms of HTML, PDF is conceptually similar to an image
> >>>>>>> file
> >>>>>>>
> >>>>>>> because the img element in a HTML document is allowed to
> >>>>>>>
> >>>>>>> embed an PDF file in itself.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> As you mentioned, PDF have the slideshow mode. On the other
> >>>>>>> hand,
> >>>>>>>
> >>>>>>> GIF can have similar capability using animations (i.e. animation GIF).
> >>>>>>>
> >>>>>>> I think that having the slideshow mode is not a matter
> >>>>>>>
> >>>>>>> in this context.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>>> A signage player should play :
> >>>>>>>>> Image raster (png, gif, jpeg)
> >>>>>>>>> Vector (svg, svg+smil, flash)
> >>>>>>>>> Video (mp4, webm)
> >>>>>>>>> HTML5 based page (iframe)
> >>>>>>>>> Paged document like pdf, e-pub, or ms-powerpoint / open
> >>>>>>>>> office documents
> >>>>>>>> ( <http://webodf.org> http://webodf.org )
> >>>>>>>>> RSS / Ticker / Why not Timed Text (
> >>>>>>>>> <http://www.w3.org/AudioVideo/TT/>
> >>>>>>>>> http://www.w3.org/AudioVideo/TT/ or
> >>>>>>>> <http://dev.w3.org/html5/webvtt/>
> >>>>>>>> http://dev.w3.org/html5/webvtt/ )
> >>>>>>> >>>
> >>>>>>> The document is "Core Profile".
> >>>>>>>
> >>>>>>> As described in the section "Abstract",
> >>>>>>>
> >>>>>>> it defines just requisite minimum for web-based signage.
> >>>>>>>
> >>>>>>> Most of existing signs don't need all features.
> >>>>>>>
> >>>>>>> We can define other features as other profiles.
> >>>>>>>
> >>>>>>> Actually, this BG has listed some profiles in the wiki.
> >>>>>>>
> >>>>>>>
> >>>>>>> <http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_
> >>>>>>> for_Web-based_Signage_Player>
> >>>>>>> http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_f
> >>>>>>> or_Web-based_Signage_Player
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> What we should discuss now is what features should be
> >>>>>>>
> >>>>>>> included in the Core Profile or not.
> >>>>>>>
> >>>>>>> I don't want the Core Profile to be overengineer.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>> 8 Playlist
> >>>>>>>> “…Each scene must have the duration. If the duration isn't
> >>>>>>>> specified, application is encouraged to adapt the default
> >>>>>>>> duration (for example, 60seconds).”
> >>>>>>>>> Sequence can have indefinite duration because intrinsic media
> >>>>>>>>> duration
> >>>>>>>> (video or rss after unknown flow of items)…
> >>>>>>> >>>
> >>>>>>> Right.
> >>>>>>>
> >>>>>>> But the "Core Profile" doesn't treat media files such as video, audio.
> >>>>>>>
> >>>>>>> Video and audio are planed to be defined in the "Basic Media Profile"
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>> 9 Scheduling
> >>>>>>>>> Why don’t advice full features of iso8601
> >>>>>>>> ( <http://en.wikipedia.org/wiki/ISO_8601> http://en.wikipedia.org/wiki/ISO_8601) :
> >>>>>>> >>>
> >>>>>>> Though the documents we are planning don't define the format,
> >>>>>>>
> >>>>>>> It seems to be really helplul. I didn't know it.
> >>>>>>>
> >>>>>>> >>>
> >>>>>>>>> Repeated Date/Time Events with some examples :
> >>>>>>>>> On the top of every hour starting 9AM on January 1st, 2010
> >>>>>>>>> R/2010-01-01T09:00/PT1H On midnight of each of the first 6
> >>>>>>>>> Mondays in the year 2010 R6/2010-01-01+w1/P1W
> >>>>>>> >>>
> >>>>>>> It seems to be useful.
> >>>>>>>
> >>>>>>> How about we plan to make "Scheduling Profile" or
> >>>>>>>
> >>>>>>> "Scheduling Extension"?
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> Futomi
> >>>>>>>
> >>>>>>> >>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Newphoria Corporation
> >>>>>>>
> >>>>>>> Chief Technology Officer
> >>>>>>>
> >>>>>>> Futomi Hatano
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> <mailto:futomi.hatano@newphoria.co.jp>
> >>>>>>> futomi.hatano@newphoria.co.jp
> >>>>>>>
> >>>>>>> <http://www.newphoria.co.jp/> http://www.newphoria.co.jp/
> >>>>>>>
> >>>>>> -- >> 株式会社ニューフォリア
> >>>>>> 取締役 最高技術責任者
> >>>>>> 羽田野 太巳 （はたの ふとみ）
> >>>>>> futomi.hatano@newphoria.co.jp
> >>>>>> http://www.newphoria.co.jp/
> >>>>>>
>
>
--
株式会社ニューフォリア
取締役 最高技術責任者
羽田野 太巳 （はたの ふとみ）
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/
Received on Saturday, 25 May 2013 07:33:44 UTC