Re: [Private Use Area] Audio Description, Subtitle, Signing

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Jul 16 2003 - 08:29:45 EDT

  • Next message: Michael Everson: "Re: [Private Use Area] Audio Description, Subtitle, Signing"

    On Wednesday, July 16, 2003 12:33 PM, William Overington <WOverington@ngo.globalnet.co.uk> wrote:

    > Peter Constable wrote as follows.
    >
    > I have posted the suggested code points within the Cenelec hosted
    > discussion some time ago.
    >
    > > > and who might like to know of this
    > > > suggestion. Also, the symbols might well be used in hardcopy
    > > > television programme listing magazines, so it would be desirable
    > > > to have them available in fonts.
    > >
    > > Think about the workflow for such magazines and then tell me again
    > > you're not suggesting PUA codepoints for use in interchange.
    >
    > Well, I am here suggesting Private Use Area code points for
    > interchange, both in interactive broadcasting and in typesetting of
    > magazines.
    >
    > Where I was specifically not suggesting interchange of Private Use
    > Area code points was (in other threads) in the use of Private Use
    > Area code points for precomposed characters which are display glyphs
    > for sequences of Unicode characters, where such display glyphs are
    > accessed using a eutocode typography file.

    Given that Java already allows using resources such as icon bitmaps or
    classes, and that it also fully supports the PUA. Given that the buil-in
    core Java engine will certainly include the appropriate minimum fonts
    to support these characters. Given that it will work within the private
    domain of interactive television.

    Given that the navigation code will be broadcasted as compiled Java
    file archives that may contain all the necessary resources as
    completely embedded documents.

    Do we really need to define these characters in Unicode? Your
    experimentation can still start using some PUA of its choices,
    and embedded fonts for the symbols you need, and it will not
    require an allocation.

    The definition of an open-standard normally requires a prior definition,
    approvals from distinct actors, regulators or standardization organism
    or forum or a community of independant users, and an effective
    implementation. The initial launch of the service does not need a fixed
    assignment for these symbols in Unicode. Such usage of symbols
    will start using private collections of symbols in icons or fonts.

    This does not restrict the required usage for documentation of these
    symbols and their usage, which can use a custom font used either
    in the broadcasted Java application (and can be changed at anytime
    on each broadcasted program, according to editor's needs). Use of
    conventional symbols that will look ugly in various countries or
    cultures will start by a lot of experimentation (including meteorological
    symbols whose use in plain-text seems ugly, when viewers will prefer
    see maps or will want to benefit from a rich-text layout).

    Why couldn't this service use a web-like (HTML) navigation system,
    with hyperlinks? When I look at my remote command for my
    Teletex-enabled TV set, I already have most of the tools needed,
    and I would not like to have more than a dozen of supplementary
    buttons. In fact there already is 4 navigation buttons (with colors
    Red, Green, Blue, Yellow), and the numeric keypad to specify the
    page number to view.

    In the existing Teletext service, which is based on the legacy
    Videotex and ANSI escape sequences to control the layout
    and presentation, users don't care about the encoding.

    But Teletext applications are limited in their presentation by:
    - the number of supported characters
    - no support for bitmaps (only mosaic graphics)
    - very few variations for the font sizes
    - limited content of the screen, typically 24x40 characters
    - few colors (8)

    Adding the suppor of Unicode and Java will allow using a
    richer and more interesting experience on this revized
    Teletext service which was designed 20 years ago, and
    widely available on TV sets only since 10 years (before that
    you needed a separate "decoder").

    Which content will be appropriate to broadcast on interactive
    TV channels is still something to discuss.

    But the audio description system for subtitles already exists
    on most European broadcasted channels (page 888 of their
    Teletext service), which are encoded in the normally not
    displayed top and bottom rows of video frames (that's why
    they are often removed on satellite or cable services, to
    limit the necessary bandwidth for each analogic channel).

    Digital broadcasts with MPEG4 will change the panorama,
    but there are still other competing technologies, notably within
    the MPEG standard itself, which supports extensions
    commonly found on DVDs... If the intent is too reduce costs
    by reusing other existing standards, I can't see why the
    existing technologies used in Video-DVD can't be used on
    interactive broadcasted numeric technologies.

    In any case, the system will not use only plain-text: it will
    support many media-formats, and it will require an "enveloppe"
    format to embed and multiplex them in the broadcasted
    program. This format will be rich enough to allow specifying
    non textual data (such as Java classes or JARs) or meta-data.

    Why then is there a need to encode all these functions
    in Unicode? This seems as ugly as the past encoding of
    layout in the middle of text (like in Videotex and Teletext,
    or even in the printers "languages") with controls and escape
    sequences.

    Today we can do these things much better than in the past
    because the processing power is not the same as 20 years
    ago when Teletext standards were created...



    This archive was generated by hypermail 2.1.5 : Wed Jul 16 2003 - 09:09:17 EDT