I have created a special font for my app which acts in part as a
front end to a Firebird db. My Windows ANSI True Type font has
special symbols inhabiting most of the high numbers (128 to 254).
Some of these high numbers are problematical (at least in Windows
True Type, and perhaps other formats as well) and are best not used,
such as 160 (No-Break Space) and 173 (Soft hyphen). Through trial and
error over the years, I have, until now, thought that the 'bugs' had
been worked out of my scheme, since all of my characters appear and
can be keyed (Alt+Num) in many apps.

However, I have just discovered that #150 (normally encoded as en
dash) and #151 (normally em dash), while they appear correct (i.e.,
my symbols) pasted or keyed (in my db connected edit components) as I
have designed and encoded them in my font, are returned from Fb1.5
BLOB SUB_TYPE 1 fields both as dashes.

I have created the db with both WIN1252 and ISO8859_1 DEFAULT
CHARACTER SETS with the same incorrect results returned only for
these two characters.

I may also need to explore the potential that this is a Windows True
Type auto-replace 'feature', but since documents in various apps
(including pdf) can be saved, stored, and opened, retaining all of my
correct characters, I need to also explore if the replacement of
characters #150 and #151 by dashes is a Firebird feature.