BlueScale validation bug

[Georg Mayr-Duffner]

Bug report #630 from Fontforge (https://github.com/fontforge/fontforge/issues/630) affects smtools too, it’s about hickups with localized decimal-points (I’m not sure if BlueScale validation is the only location affected–I’ll have to investigate on this):

As noted by "gluk" on the mailing list, the routine ValidatePrivate() in splinechar.c uses strtod() to read the BlueScale value from a Type 1 font dictionary. However, strtod() respects locale-specific "decimal point" characters, unlike Type 1, so that when reading fonts with locales where the decimal point is a comma, the number is misinterpreted, causing validation failures.

I count six uses of strtod() in splinechar.c, so this whole area needs reviewing and making locale-independent.

---

Initial message on the mailing list: http://sourceforge.net/mailarchive/forum.php?thread_name=201307141319.32541.digital%40joescat.com&forum_name=fontforge-devel

led to bug report #629 (https://github.com/fontforge/fontforge/pull/629) which suffered from premature closing.

[Khaled Hosny]

Glib has a locale-independent g_ascii_strtod, so may be we should use it.

[Khaled Hosny]

Or c_strtod() from gnulib, hough that one seems to simply use setlocale (LC_NUMERIC, "C").

[Khaled Hosny]

Use gnulib’s locale-independent c_strtod()

It uses strtod_l() when available, and resorts to setlocale() otherwise.

Fixes #40

→ <<cset c794abe06733>>