On Wednesday, July 16, 2003 12:33 PM, William Overington <[EMAIL PROTECTED]> 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...
