JEP Proposal update, and JavaOne

[Doug Felt]

For the JEP, I'd just like to state that

1) even when both engines support a language, the GlyphVectors output by
ICU LayoutEngine and HarfBuzz will not always be the same.  In particular,
ICU uses 'filler glyphs' and tries to arrange the glyph to char mapping to
be as exact as possible.  HarfBuzz does not natively use filler glyphs or
generate a close mapping, so the icu-le-hb compatibility shim generates an
emulation of this.  Anyone who depends in detail on the placement of filler
glyphs or the glyph-to-char mapping will see changes. We expect there to be
very few such clients, but they should be aware of this possibility.

2) Given that we expect few such clients, and some of them will possibly
break anyway, another option is to not generate the filler glyphs at all,
but instead generate HarfBuzz's native output and adjust the layers inside
the JDK (not API) that consume them to use the HarfBuzz native output
instead.

3) Third party clients are unable to effectively use the current
glyphvector data (all that is exposed in the API) to determine the
boundaries of glyph clusters, which is necessary for client layout of text
on a path. If we change the GlyphVector data, we might consider reworking
it so that it is useful for this purpose.

On Mon, Sep 29, 2014 at 10:30 PM, Steven R. Loomis <steven.loomis at oracle.com
> wrote:

> On 08/01/2014 10:44 PM, Steven R. Loomis wrote:
> > Forgot to mention!
> > We'll be talking about HarfBuzz at this session - if you are at JavaOne
> > come by!
> >
> >
> >
> https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=2890
> >
> Hello.
> I've updated the JEP here: http://goo.gl/n5SSMV
>
> See some of you at 9pm tomorrow in SF hopefully!
>
> Steven
>
>


-- 

Doug Felt | Software Engineer | dougfelt at google.com
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=dougfelt@google.com> |
 1-650-253-2089