On 4/15/20, 10:32 PM, Jayathirth D v wrote:
Hi Phil,
Thanks for the detailed evaluation in bug and here.
Change looks good to me.
Newly added file has copyright year 2018. Please update it before pushing.
Ok.
I ran smaller set of rotate tests for font and they all pass with this change.
Does this new change handle non-bold use cases also as mentioned in bug description
“However, if we use "MS P Gothic" as a font, even normal alphabet characters
are drawn at wrong positions.” ?
He wasn't saying "non-bold" here. He was saying still BOLD but "not
wide" characters.
It all depends which characters come from a font that needs to be bolded.
So with DIALOG for Latin (eg) he is probably getting Arial used and that
has a bold version
When using P Gothic, then all chars come from the font that need to be
synthetically bolded.
So in short this bug is about synthetic bolding, nothing else.
-phil
Thanks,
Jay
On 16-Apr-2020, at 2:30 AM, Philip Race<philip.r...@oracle.com> wrote:
Bug : https://bugs.openjdk.java.net/browse/JDK-8233006
Webrev : http://cr.openjdk.java.net/~prr/8233006
The bug here is that the freetype function for synthesising bold is not ready
to handle rotation.
In the process I noticed it did not adjust the advance used by the fractional
metrics case,
even though the outline is bolded.
Also, in what seems to be a completely wrong thing to do, freetype would
widen the advance of glyphs which have zero advance.
So I decided that the best thing to do was to write our own.
A chunk of the heavy lifting - widening the outline - is still done by freetype
but there were a lot of details to get right and test.
I wrote a test to visualise the problem but the actual test checks by looking
at the bounding rectangle of the drawn pixels and compares its height to
the declared metrics of the font, failing if they disagree by too much.
Note that the code path is only exercised when synthetic bolding is needed.
So real bold fonts don't test this code.
Since there's not an easy way to say which fonts have real bold, I decided the
test should use a BOLD version of every font on the system, which on almost
all systems will test some significant number of such cases.
I kept the UI for visualising as it will be useful for later debugging of
failures.
Also it made me notice that the case where the text was not rotated at all was
drawing shorter than all the other cases.
I traced this back to the fix for 8203485 which added a macro FT26Dot6ToInt
and used it to get the integer advance in the unrotated, integer metrics case.
The idea there wasn't completely wrong, but I don't think it was completely
right either.
I got rid of the macro and instead used the same FT26Dot6ToFloat macro as used
in the rotation cases. So we now return the exact floating point value to the
calling
Java code. That then can round appropriately as it needs to. This fixed the
inconsistency
and the test for 8203485 still passes as do all other tests.
This change will likely lead to some cases where unrotated advances now round
up one pixel wider,
but so far it looks correct to me. They'll be restored to something more like
what they were
before 8203485, since that removed rounding and added truncation instead to fix
a problem
with the rounding being incorrect for rotations because it could round down
when it should round up.
Now we just let the Java code handle it.
I've run these tests on all platforms and they pass. Mac isn't using this
freetype path so it is not affected
but it is still good to know the tests pass there ...
-phil
