From: Philippe Verdy (firstname.lastname@example.org)
Date: Wed Jul 16 2003 - 08:29:45 EDT
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
> 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
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