--- In firebird-support@yahoogroups.com, "bmckenna6" <bmckenna@...> wrote:

>
> 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.
>

I doubt it, a BLOB stores and retrieves bytes. You can store whatever
you want in it, text, images, sound, ISOs, literally anything that can
be represented by a sequence of bytes. All sorts of serious problems
would occur if Firebird started treating two different bytes as
identical with these other data types, so I can't see it being the case.

Possibly the subtype is causing some conversion to take place when
stored or read, have you tried any other subtype 0?

Adam