[OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258
Philip Race
philip.race at oracle.com
Sat Nov 21 23:07:57 UTC 2015
http://cr.openjdk.java.net/~prr/8143177.2
is uploaded. See comments below.
On 11/21/15, 2:41 AM, Vadim Pakhnushev wrote:
> Phil,
>
> In the HBShaper.c in the init_JNI_IDs function I think CHECK_NULL is
> missing for the gvdIndicesFID.
> I guess it's just a copy from SunLayoutEngine.cpp but still.
Actually this points out that I only return from the init function
and don't return from the calling function. I will restructure this a
bit so that we
return a success value and the caller checks it.
> Calling init_JNI_IDs each time seems unneeded (not very harmful
> though), could it be somehow merged with the
> Java_sun_font_SunLayoutEngine_initGVIDs?
They are static and I have added a static flag that indicates they have
all been initialised.
If it fails then we will not proceed. In the normal case overhead should
be down to
near zero.
> What's the point of this super optimized euclidianDistance if it's
> called only 2 times while creating a layout?
I just copied this from ICU code so we are doing the same thing.
> pScaler is not used anywhere it seems, can it be removed altogether?
It was used when I was directly testing freetype (using harfbuzz's hb-ft.cc)
That was where I started out but I moved on to a different approach.
It is left it there in case I wanted to test ft to isolate any bugs.
>
> typo in the hb-jdk-font.cc:124 * which *be could* based on some
> on-the fly glyph analysis.
ok
I had to make one additional change. The hb call to create a coretext font
was being handed the pt size in device pixels as used elsewhere but in
the coretext path we must pass the user pt size so I had to pass that
down and in .. it does not affect anything except the coretext path for
AAT fonts on OS X. I spotted this when testing with a transform in
that code path.
-phil.
>
> Thanks,
> Vadim
>
> On 21.11.2015 2:09, Phil Race wrote:
>>
>> On 11/19/2015 12:51 PM, Steven Loomis wrote:
>>> I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/
>>> directory) and it looks good so far.
>>
>> Thanks. The harfbuzz code itself probably does not need careful
>> reviewing as it is just
>> the upstream harfbuzz. I have updated it to remove the gpl text from
>> the hb src files but
>> I haven't changed anything else :-
>> http://cr.openjdk.java.net/~prr/8143177.1/
>>
>> Any takers to be 2nd reviewer ?
>>
>> -phil.
>>
>>>
>>> -s
>>>
>>> On 11/17/2015 4:05 PM, Philip Race wrote:
>>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177
>>>>
>>>> This webrev contains the changes accumulated in the harfbuzz
>>>> project forest
>>>> that migrate JDK from using ICU for opentype font layout to
>>>> harfbuzz for the same.
>>>>
>>>> The change does not introduce API. It is mostly adding the harfbuzz
>>>> library.
>>>> The ICU library remains there but is no longer the default.
>>>> Eventually (not necessarily in 9) it may be removed once we are
>>>> comfortable
>>>> with harfbuzz.
>>>> You may select ICU by using -Dsun.font.layoutengine=icu
>>>>
>>>> You may see which layout engine is in use by using
>>>> -Dsun.font.layoutengine.verbose=true
>>>> it will print either "Using harfbuzz", or "Using ICU".
>>>>
>>>> The change has no impact on typical Latin script rendering but is a
>>>> big advance
>>>> for complex scripts and also applies if you select kerning or
>>>> ligatures for Latin.
>>>> However the latter is only detectable if the font implements
>>>> support for these.
>>>> By "big advance" I mean that ICU has not been updated to recognise
>>>> recent opentype features.
>>>> So harfbuzz should fix a number of things but unexpected changes
>>>> that look wrong
>>>> should be reported so we can investigate.
>>>>
>>>> To use harfbuzz we invoke its shaper and we provide a way to get
>>>> jdk font information.
>>>> This means that we do not need a different layer depending on
>>>> whether freetype or t2k
>>>> is used. It also enables some caching in the JDK font layer.
>>>>
>>>> On macosx harfbuzz does not natively read the AAT tables but will
>>>> invoke CoreText.
>>>> This does mean that an AAT font installed on Linux would not be
>>>> processed but
>>>> this is not a significant issue since AAT fonts are not found other
>>>> than on macosx.
>>>>
>>>> The majority of the files in the webrev are harfbuzz itself,
>>>> changed only to comply
>>>> with JDK whitespace rules. Reviewers should probably concentrate on
>>>> all of the rest.
>>>> I've listed it so that all those files are at the beginning and you
>>>> can ignore all those
>>>> that follow that are in the "harfbuzz" directory.
>>>>
>>>> The harfbuzz version used here is 1.0.6 which is the latest source
>>>> release (at the time of writing).
>>>> We expect to update this to keep reasonably current.
>>>>
>>>> I would like to push this in on Friday, but at the very latest
>>>> Monday because of the
>>>> upcoming Feature Complete date so there are a couple of days to
>>>> make small
>>>> tweaks for serious problems but there will be plenty of time after
>>>> integration to fix
>>>> remaining problems.
>>>>
>>>> -phil.
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151121/8473a76e/attachment.html>
More information about the 2d-dev
mailing list