<< Click to Display Table of Contents > 

SAMLight Manual > Global Settings > Extras > Flash Font Codepage

Flash Font Codepage
Previous pageReturn to chapter overviewNext page

The generation of a font in Flash depends on 2 parts:

1.Flash Font Codepage applied in SAMLight

2.font of the entity itself

 

In more detail, each single ASCII position of the Flash Font Codepage (0-255 positions) is taken and the Unicode number of its character is looked for in the applied font of the entity (0-65535 positions). This means that from the entities point of view, each character's Unicode number needs to be present in the selected Flash Font Codepage for a valid entry on flash.

 

Three cases can occur:

 

1. Identical case - good case
If a Unicode number of the Flash Font Codepage is found in the applied font of the entity, it is put at the corresponding position in the resulting font on flash (see example in figure 73: ASCII position 0xA3 in the Flash Font Codepage (Windows-1250) is occupied by Unicode character 0x141 (Ł), this Unicode character is present in the applied font and is thus mapped to ASCII position 0xA3 in flash.).

 

FlashFontCodepage-Win-OK
Figure 73: Example for successfully mapping Unicode character 0x141 from Windows-1250 Flash Font Codepage

2. Mixed case - good if on purpose

If a Unicode number of the Flash Font Codepage is found in the applied font of the entity, it is put at the corresponding position in the resulting font on flash. This does not mean that the vectors of the characters need to be the one of the Unicode number. You can easily modify the character in your applied font of the entity using for example the font converter (see example in figure 74: ASCII position 0xA3 in the Flash Font Codepage (Windows-1250) is occupied by Unicode character 0x141 (Ł). This Unicode character 0x141 is found in the applied font. But in the applied font, the content of position 0x141 was exchanged with a smiley in the font of the entity. Because the smiley is located at 0x141, it is recognized as the correct character and is put at position 0xA3 in the resulting font in flash.).

 

FlashFontCodepage-Win-OK-replaced

Figure 74: Example for successfully mapping Unicode character 0x141 from Windows-1250 Flash Font Codepage to a custom designed character

3. Missing case - bad case

a.If a Unicode number of the Flash Font Codepage is not found in the applied font of the entity, the corresponding ASCII position stays empty in the resulting font on flash (see example in figure 75: ASCII position 0xA3 in the Flash Font Codepage (Windows-1250) is occupied by Unicode character 0x141 (Ł) which is not present in the applied font. Thus, ASCII position 0xA3 stays empty in flash.).
FlashFontCodepage-Win-NOK
Figure 75: Example for not mapping Unicode character 0x141 from Windows-1250 Flash Font Codepage
 

b.If a Unicode number of the applied font of the entity is not found in the Flash Font Codepage, it will not be present in the result on flash (see example in figure 76: Unicode character 0x192 (ƒ) of the applied font of the entity is not present anywhere in the Flash Font Codepage (Windows-1250).).
FlashFontCodepage-applFont-NOK
Figure 76: Example for not mapping Unicode character 0x192 of the applied font of the entity

 

 

note

The Flash Font Codepage is only taken for the generation of characters in Flash. For the generation of characters in SAMLight, the font codepage of the windows system (applied for non-Unicode programs) is taken. For central Europe, this is usually the most common one: Windows-1252.