On 26/1/15 22:33, Behdad Esfahbod wrote:
This is by no ways to promote non-Unicode encodings. This is an entry
point that takes Unicode codepoints that happen to all be the first
256 characters and hence fit in 8bit strings. This is useful eg in Chrome
where strings that can fit in 8bit are implemented that way, and this
avoids copying into UTF-8 or UTF-16.
Seems reasonable. We might well adopt hb_buffer_add_latin1() in Gecko,
too, as we have a similar 8-bit string type for strings where all
characters are <= U+00FF. Currently, we expand those strings to UTF-16
before calling harfbuzz; this will allow us to avoid that.
Perhaps we should rename this to hb_buffer_add_codepoints8(). I'm also
curious if anyone would be really interested in
hb_buffer_add_codepoints16().
Meaning basically an API that accepts 16-bit codepoints but does not
handle surrogate pairs, so it would in effect support UCS-2 rather than
UTF-16? I doubt there's much of a use-case for that.
JK
_______________________________________________
HarfBuzz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
