Topic       : TOS - The Operating System
Author      : 
Version     : tos.hyp (December 19, 2008)
Subject     : Programmieren/Atari
Nodes       : 3010
Index Size  : 93790
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Title
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File13.14.2.2  xFSL Questions and Answers                              TOS

How can I find out which features the font-selector offers?

Directly, this can be done for some features by using the function 
xfsl_info. Indirectly, further features can be inquired for with the 
control field in the xFSL_PAR structure: After a successful xfsl_init 
call the font-selector will clear those control-flags that it does not 
understand.

How should my program behave when it realizes that the font-selector 
does not support the desired feature?

If some kind of font-selector is installed, then it also ought to be 
used in any case. Depending on how important the missing feature is, 
your program could look for alternatives (e.g. via the Font protocol) 
or attempt to compensate for the missing feature.

Once again: The user wanted a font-selector, not an error-message! If 
the missing feature can be compensated for only with difficulty, then 
you should inform the user once(!) with a corresponding note, but call 
up the font-selector nevertheless. Even if the selection can then not 
be made with the desired convenience, it is still far less frustrating 
for the user than not being able to select a font at all.

Some examples: If the popup is to be used to set the font for a given 
program window, then if the popup is missing the font should be set 
for the topped window of the program. If the font-selector does not 
support the locking of size-changes, then the returned size should 
simply be ignored and - if it differs from the desired size - the user 
informed about this by a note.

Incidentally, one should not rely on the font-selector supporting the 
same features the next time it is called! The font-selectors that work 
with an overlay (XFSL.OVL) can be substituted at any time without a 
Reset by re-copying the overlay.

What's all this 'mapping' about?

Vector fonts generally contain more than the familiar 256 characters, 
and furthermore they are not normally in the accustomed ASCII coding 
(for example the space character may lie at position 0 instead of 32). 
Therefore the pertinent characters of the font are 'mapped' to the 
'normal' 256 characters, so that the space character lies as usual in 
position 32, no matter what position it has within the font. This is 
designated as 'ASCII mapping'.

The ASCII mapping is active by default, but due to this one cannot 
access the characters that lie outside the ASCII character set. Hence 
a second mapping, 'Direct mapping', is available. Here one has access 
to all characters of a font. However, for this one also has to know 
what type of font one is dealing with and how many characters the font 
contains: Speedo fonts usually have 564 characters, TrueType fonts can 
(theoretically) contain up to 65536 characters. One can get this 
information after switching to Direct mapping with the VDI function 
vqt_fontinfo:

int minADE, maxADE;

vst_charmap(handle,0); 
vqt_fontinfo(handle,&minADE,&maxADE,dumarray,&dummy,dumarray);

In minADE one gets the smallest, in maxADE the largest valid character 
index.

Direct mapping only has limited use for normal applications. Unlike 
ASCII mapping which provides consistent mapping for all types of 
fonts, one needs to know here exactly what kind of font one is dealing 
with. Thus, for instance, the Speedo symbol fonts have a different 
coding to the 'normal' Speedo fonts. This means that at position 64 of 
such a symbol font, say, one will not find the same character as for a 
'normal' Speedo font.

Other mappings than ASCII are therefore of no interest to the majority 
of programs at present. But future GDOSes or equivalents may possibly 
also offer other consistent mappings (e.g. Unicode or BICS), where one 
can once more rely on the same character appearing always at a given 
position (similar to ASCII mapping but also including positions higher 
than 255).

Note: NVDI from NVDI 4 onwards is able to use Unicode mapping.