WIN1252 should treat #150 and #151 as separate characters. In ISO
8859-1, the range from #128 to #159 is undefined (empty). WIN1252 ist
just ISO 8859-1 *plus* 32 characters in the #128..#159 range.

Best Regards

Stefan

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

--
Stefan Heymann
www.destructor.de/firebird