kap121@ztivax.UUCP (Thomas Oeser) (01/03/89)
In article #2716 (please excuse this delay, I spent some free days and have not yet read the 276 "new" articles droped in ...) David Rosenthal writes: ... Anyone who wants a font which has ISO Latin 1 encoding but doesn't care about other characteristics should consult the R3 document about font naming, ... I fully conform with David's opinion. Even more, I think, in distributed environments we should generally move from using `unknown' defaults to `expressing our intents and requirements'. What does this mean? Every application should announce those properties of an entity, it is interested in (e.g., in the case of a font the metrics and the sans serif style may be important for a particular implementation). Other properties may be left unspecified. It is the task of the receiving/remote/server/... system to fulfill the specified properties of an entity as best as possible. This does imply, that supportive systems m u s t provide means of expressing those `intents'. This mechanism is easily visible and understandable, if the entity (or should I better say resource?) is a font. In this case we should think of a `font reference' in a very general sense: - it may be a unique name in the world, by which we express the intent, that we want to use exactly this particular font and nothing else; - it may be a list of specified properties from the standardized(!!) set of properties a font may have and such reducing the number of choices for a font to use at a specific instance of our application. BTW, the encoding of the font may be such a property as well. Even more, why do we bind the encoding to the font? The same set of character shapes, character metrics, general font attributes, etc. should be available for several encodings. I.e., a mapping should exist, that translates the code referring to a particular meaning (e.g., code xxx to `capital letter A') to a character shape description, of which the font designer thinks of to be able to represent this meaning (e.g., for a font consisting of smaller and larger capital letters only the larger one may represent the meaning `capital letter A'). The font referencing techniques described in the new R3 documents (I have not yet got them...) seem to go in that direction. Anyway, I is worthwhile to compare them with the ongoing work for an ISO standard in that area (ISO 9541, Font and Character Information Interchange). It is a multi-part standard dealing with - the encoding independend referencing of character shape descriptions, metrics descriptions, etc. - the attributes available for a font as a whole; - the attributes available for each individual character; - etc. It is currently at a state of a Draft International Standard. In particular, part 5 `Font attributes and character' model may be very interesting, when looking at the set of standardized font properties. There are also intentions to provide means for specifying mappings from the several encoding standards (ISO 646 (old style), ISO 8859 (new style), ISO 6937 (to make CCITT happy)...) to the character image descriptions in a font. But there are more areas, where we should move to the method of specifying our intents and requirements. Another example is the use of color. In this area most people think in terms of absolute colors (e.g., by names like `black', `white', `read', etc. or by RGB values or indices pointing to RGB values in color maps that were created by specifying RGB values). In additon, there are currently sophisticated mechanisms to map colors to a reduced colour space (i.e. 256 colurs to 16, or colors to greyscale). But all this applies really to `real wolrd images' only (e.g. photographs). In this case the most important intent is to reproduce the image as close as possible to the original value. In other cases we use colors in a quite different sense and it is not so important to reproduce it as close as possible (therefore all the mechanisms fail more or less :-) ): - to highlight something; - to generate a composite area; - to focus on specific areas; - etc. Therefore, for referencing colors there should also similar means as there are for fonts (BTW, this would remove a lot of problems with applications going from grey scale displays to color displays and vice versa). Some examples for doing so are: - to introduce some abstract named values (i.e., `foreground' and `background') as valid color values; - to allow the specification of relationships of colours with respect to other colors (e.g. `color1 should be contrasting color to color2' or `color1 should be lighter than colour2', `color1 should be of same hue as color 2 but different in lightness and/or luminance', etc.); - to allow specification of a `color use' property (e.g. flashlight color, fading color, etc.). We may think of applying this to areas of output primitive attributes, too. Sometimes we want simply two different lines, not concerning whether they are different in style or thickness. But ese idears may go to far, since all systems are able to create lines of different styles or thicknesses, are they... Why do I have posted these statements into this newsgroup? Simply because X is a network transparent system, where several servers and machines of different features may be accessed by the same application. In addition, by using the X window system applications become highly portable. All this forces the application programmers to think of how they can write their applications without knowing the target systems they should running on, thus using e.g. the principle of specifying those properties of entities, that are important for their applications. But this principle should be supported generally on those systems and not only for fonts. Thomas Oeser ARPA: kap121@ztivax.siemens.com UUCP: kap121@ztivax.uucp (may work only in Europe...) Mail: Siemens AG, K Sys Ap 121 , Otto-Hahn-Ring 6, D-8000 Munich, West Germany Phone: + 49 89 636 47537 (office) + 49 89 672227 (private, for those who have to think of 9 hours time difference...)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/04/89)
Even
more, why do we bind the encoding to the font? The same set of character
shapes, character metrics, general font attributes, etc. should be
available for several encodings.
Right. With the R3 font naming scheme, it is certainly possible for
a server to synthesize fonts on the fly based on the character set
part of the name, taking a base set of glyphs and constructing an
appropriate index array.
Anyway, I is worthwhile to
compare them with the ongoing work for an ISO standard in that area
(ISO 9541, Font and Character Information Interchange).
We are definitely aware of 9541. Jim Flowers of DEC, who authored the
X font naming proposal, is actively involved in the 9541 work.
It is currently at a state of a Draft International Standard.
It was rejected as an IS in summer 1988, but is being reworked. Part of
it has been split off as a separate DIS, 10036.
In particular,
part 5 `Font attributes and character' model may be very interesting, when
looking at the set of standardized font properties.
Jim Flowers has been making recommendations in this area, so that 9541 provides
reasonable support in the X (or other bitmap font) environment. To the extent
that a real encoding comes out of this work, we will consider making it a
supported format in our distribution.