Conference bulova::decw_jan-89_to_nov-90

You can find out tons of information about character sets in the
conference LEVEL::DEC_STD_169 (hit KP7 to add).

To answer your direct question, yes, there is quite a bit of difference
internally between the different character sets.  The basic problem is
that our standard character size of 8 bits is enough to represent 256
different characters, but if you want to treat the Latin, Greek, Cyrillic,
Hebrew, Arabic, etc., characters as different characters, then you need to
represent far more than 256 characters.  There are two possible solutions:
either you expand the size of your characters, or you re-use the
character values and have some way to decide which character is meant.

Expanding the size of characters is in some respects the ideal solution,
and work is being done to define a universal character set.  However,
it should be obvious that without some sort of compression scheme, such
"wide characters" will chew up lots of memory and disk space.

Re-use of character values is what is most often done.  The mapping of
characters from a language (or set of languages) onto the 256 values
is called a character set.  The application must always be aware of
which mapping is intended.  All normal text files on VMS and Ultrix
use the Latin-1 character set mapping by default.  To use other character
sets, I believe it is best to use DDIF, as that format includes all the
necessary meta-data for applications to know which character set is
supposed to be used with each character string.

    If your question is what does a character set mean to compound strings,
    the answer is absolutely nothing.  The character set identifiers are
    mearly a means of matching compound string text segments to fonts in
    the font list; nothing else.  So, you can "cheat" and use the same
    mechanism to display a compound string in different size fonts.
    The *real* constraint is that the byte values in the text match the
    glyphs in the font that is gets matched to.  If the text if ISOLATIN1
    and the font is ISOLATIN1, you're all set.  Motif makes it a little
    easier to "cheat" since character set identifiers are strings rather
    than a set of hard-coded integers.  But there is still no *straight-
    forward* way to display text of the same character set in different
    size fonts in one compound string.
    
    Leo

    While the current implementation of compound strings in the DECwindows
    toolkit may not ascribe any real character set meaning to the character
    set field of each segment, it is a very bad idea indeed to cheat and
    not put the real character set in that field! It will certainly come
    back and bite you sometime later.
    
    Fonts and character sets are very different concepts -- and confused by
    many people and applications. Extremely briefly, a font is a collection
    of character shapes all in the same style (like Helvetica, Times,
    etc.). A character set (or, more properly, a coded character set) is
    the relationship between a set of values (usually 32-127, 160-255) and
    a set of characters. For example, 65 is A in ASCII. Assuming that
    you've named all characters (there is official ISO work in progress to
    do this) then you can map a value to a character name via some coded
    character set and then map a character name to a shape (glyph) via some
    font.
    
    Compound strings are intended to be data-only strings. So,
    appearance-only things like fonts are not usually stored in them. But,
    content information like the coded character set for the character
    values is always needed.

    Thanks a lot to Peter, Leo and Mark for the very clear explanations.
    
    I agree with Mark who wants to use the things legally, but as the
    compound string implementation is able to mix different fonts, it
    is a pity not being able to use it legally.
       Think to complexity of the problem to display a text with two
    fonts having not the same size. Try to do yourself: you will have
    to compute the size of the first text to set the position of the
    second, therefore you must do queries about the geometry of each
    characters and so on... 
       All this work is done and well done in the DECwindows widget
    and you are not allowed to use it without cheating.
      
    Thanks,
    Bernard
    

    I would be more likely to say cheating was OK if I thought that there
    was a roadblock in the way of a real solution. But, in this case, it is
    a "small matter of programming" to keep the use of compound strings
    compeltely legal *and* have multiple fonts!
    
    It would be done not by misusing the coded character set field, but by
    adding the code to enable the font field of compound strings! There are
    many defined fields of compound strings that are not yet enabled by the
    code. For example: bold, italic, underline, etc.

    Ok, .0 has shown me how to have 2 different "English-readable" fonts in
    the same string.
    
    2 questions:
    
    	Is this the way to do it?
    
    	And what if I want more than 2 different fonts in the same string?
    	How do I do that? Because in looking at it, only ISOLATINT1 & 2
    	produce "English-readable" text. Sure, I can have 3 fonts by .0's 
    	example, but I can only read 2; and only 2 ISOLATIN fonts are
    	defined.
    
    Help please,
    jjjones

    Geez... make me answer my own questions! ;^)
    
    Steve Klein's VToolKit has excellent examples on how to do just this.
    
    	DW_EXAMPLES TOPIC 404
    
    jjjones