On 04/21/11 21:42, Khaled Hosny wrote: > I was thinking about adding HB support to FontForge's "metrics" view, > which input can as well be a mix of characters and glyph indices, but I > did no actual work so far. > > I was wondering if hb_shape() accepts a buffer that contains glyphs > indices? if it is true, may be one can first convert characters to > corresponding "base" glyph indices using some FT function (or something > like Cairo's "toy" text API) and then pass the "pure" glyph indices > buffer to HB, any ideas?
I thought about this use-case more. While it's impossible to do shaping on glyph indices, I think you can get away with what you (and Eric) want by implementing a custom get_glyph() call back. Simply encode the glyph indices in your "character" space by, for example, adding 0x80000000 to the glyph value. Then in your get_glyph() function, which would normally map characters to glyphs, handle the encoded glyphs differently and just return the glyph index. In the design Ryan and I came up with you can in fact subclass hb_font_funcs_t objects to do things like this. I probably get to implement that in a day or two. behdad > Regards, > Khaled > > On Thu, Apr 21, 2011 at 04:57:35PM -0400, Behdad Esfahbod wrote: >> Hi Eric, >> >> I understand your request, but I don't think we want to handle that. The way >> such a case would work, IMO, is that the higher level will break the text >> into >> text and glyph-index segments, and only pass the text runs to the shaper. >> Shaping glyph indices makes little sense. >> >> behdad >> >> On 04/21/11 16:51, Eric Wasylishen wrote: >>> Hi, >>> I have a use case where I want to shape some text which might contain a mix >>> of glyph indices and unicode characters. For example, a string like "hello >>> <glyph 123> world". >>> >>> I get the feeling that just having strings like this is discouraged. There >>> are, however, files in the wild that do this (e.g. Apple RTF files will >>> sometime contain glyph indices). >>> >>> What would you think about allowing a Harfbuzz user preparing their buffer >>> to call hb_buffer_add_glyph with a mask to indicate that the glyph being >>> inserted is already a glyph index? It looks like the first few phases of >>> hb_ot_shape_execute_internal, up to when hb_substitute_default is called, >>> would have to check for this mask and ignore the glyph or treat it as some >>> placeholder unicode character. >>> >>> Cheers, >>> Eric >>> >>> P.S. I'm looking at adding Harfbuzz support to GNUstep, which is where this >>> problem comes up. >> _______________________________________________ >> HarfBuzz mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/harfbuzz > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
