In addressing SDK-17370 two things were apparent. 1. Batik's parsing of @font-face unicode-ranges needed to be fixed (Batik bug 46055). 2. The syntax that Flex suggests for unicode range pairs was not compliant with the CSS2 specification. The second 'U+' is not needed in the range pair.
I've patched Batik to support the variants of unicode-ranges syntax and have rebuilt /lib/batik-all-flex.jar using "ant batik" with JDK 1.4.2_12 from the top level trunk ant script, but I retained support for the legacy (but incorrect) Flex syntax for unicode range pairs.
QE: Yes, can we go over our unicode-range tests and update them to use the correct syntax in unicode-range pairs? Also please review the CSS-2 specification to ensure we've covered the variants of wildcards and range syntax. http://www.w3.org/TR/CSS2/fonts.html#dataqual
Doc: Yes, can we please correct all code examples in our documentation for font embedding unicode-ranges to use the correct syntax for unicode-range pairs?
mxunit atembed: Pass (legacy Flex 2.0.1 based tests fail, though they fail prior to this change)
SDK-17370 - [DefineFont4] Inconsistent font embedding behavior between Gumbo and Halo when embedding a single character in a unicode range