[OpenJDK 2D-Dev] [PATCH] 8210058: Algorithmic Italic font leans opposite angle in Printing

[Dmitry Batrak]

That's what I did locally - copied the file. I was surprised by the
representation of that operation in webrev. I hope this will be applied in
the same way during committing.

Best regards,
Dmitry Batrak

On Tue, Nov 26, 2019 at 11:45 PM Phil Race <philip.race at oracle.com> wrote:

> This looks good to me, so long as this is not actually moving the A.ttf
> file
> and instead just making a new copy - despite how it appears here :-
>
> ------ ------ ------ ------ --- New
> <http://cr.openjdk.java.net/~dbatrak/8210058/webrev.01/test/jdk/java/awt/font/Rotate/A.ttf.html>
> Patch
> <http://cr.openjdk.java.net/~dbatrak/8210058/webrev.01/test/jdk/java/awt/font/Rotate/A.ttf.patch>
> Raw
> <http://cr.openjdk.java.net/~dbatrak/8210058/webrev.01/raw_files/new/test/jdk/java/awt/font/Rotate/A.ttf>
> *test/jdk/java/awt/font/Rotate/A.ttf* *(was
> test/jdk/java/awt/FontClass/CreateFont/A.ttf)*
>
> -phil.
>
> On 11/25/19 1:43 AM, Dmitry Batrak wrote:
>
> Please find the link to the updated webrev below. A test was added, which
> verifies the change.
>
> http://cr.openjdk.java.net/~dbatrak/8210058/webrev.01/
>
> Best regards,
> Dmitry Batrak
>
> On Fri, Nov 22, 2019 at 11:48 AM Prasanta Sadhukhan <
> prasanta.sadhukhan at oracle.com> wrote:
>
>> Only thing to be concerned about is the copyright of the ttf file. If it
>> is not self-generated or GPL licensed or we are not sure of of its
>> origin(most of will be copyrighted to Adobe or such, which are not ok to be
>> checked in), It's better to reuse the A.ttf file already present in the repo
>>
>> Regards
>>
>> Prasanta
>> On 22-Nov-19 1:52 PM, Jayathirth Rao wrote:
>>
>> Hi Dmitry,
>>
>> There are some test cases which use .ttf file for test case and they keep
>> regression test and its corresponding .ttf file in same path.
>> So we can follow same approach.
>>
>> Usage of hardcoded value seems reasonable here.
>>
>> Thanks,
>> Jay
>>
>> On 22-Nov-2019, at 12:56 PM, Dmitry Batrak <dmitry.batrak at jetbrains.com>
>> wrote:
>>
>> Hello Jay,
>>
>> Thanks for looking into this!
>> Since JDK-8218854 JDK already hardcoded the value of FreeType's oblique
>> modifier (to calculate max advance). After the proposed change, the
>> hardcoded value will also be used for the actual transform applied to
>> glyphs, making the code, in a way, more consistent (against the potential
>> case of FreeType changing the oblique modifier at some point).
>> As for creating a test for the fix, the test could verify that certain
>> pixels are filled or not filled to confirm the correct slant direction. I
>> think it's even possible to do without using Robot - by drawing into a
>> BufferedImage. But to make the test more reliable, it should use a fixed
>> font. Is it OK to add some font to JDK codebase along with test code? Or
>> maybe A.ttf already used in some test cases can be reused? If the latter is
>> acceptable, should it be copied to the location near the test's source
>> code, or it can be loaded by a relative reference?
>>
>> Best regards,
>> Dmitry Batrak
>>
>> On Mon, Nov 18, 2019 at 1:29 PM Jayathirth Rao <jayathirth.d.v at oracle.com>
>> wrote:
>>
>>> Hi Dmitry,
>>>
>>> Thanks for the patch.
>>> I can sponsor this.
>>>
>>> I went through the change and it looks okay.
>>> But I have a concern about using specific values for matrix based on
>>> Freetype version for Oblique type. I have less idea about that maybe Phil
>>> or others can clarify the same.
>>>
>>> Regarding adding regression test along with the patch, i think we can
>>> use AWT Robot to get pixel data to verify the patch.
>>>
>>> Thanks,
>>> Jay
>>>
>>> On 18-Nov-2019, at 2:49 PM, Dmitry Batrak <dmitry.batrak at jetbrains.com>
>>> wrote:
>>>
>>> Hello,
>>>
>>> Still trying.
>>> Any volunteers to sponsor/review?
>>>
>>> Best regards,
>>> Dmitry Batrak
>>>
>>> On Tue, Nov 5, 2019 at 11:27 AM Dmitry Batrak <
>>> dmitry.batrak at jetbrains.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Let me repeat the request.
>>>> Any volunteers to sponsor/review?
>>>>
>>>> Best regards,
>>>> Dmitry Batrak
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: Dmitry Batrak <dmitry.batrak at jetbrains.com>
>>>> Date: Thu, Aug 29, 2019 at 1:58 PM
>>>> Subject: [PATCH] 8210058: Algorithmic Italic font leans opposite angle
>>>> in Printing
>>>> To: 2d-dev <2d-dev at openjdk.java.net>
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I'd like to submit a patch for JDK-8210058. I'm not a Committer, so
>>>> I'll need someone to sponsor this change.
>>>>
>>>> The issue is related to the implementation of algorithmic italics in
>>>> FreeType font scaler. At the moment it uses FT_GlyphSlot_Oblique, but its
>>>> implementation doesn't take into account the glyph transform, previously
>>>> set using FT_Set_Transform, and FreeType developers don't seem to have any
>>>> interest in changing that (see
>>>> https://savannah.nongnu.org/bugs/index.php?54565).
>>>> The proposed solution is to include corresponding shear transform
>>>> explicitly in matrix passed to FT_Set_Transform instead of using
>>>> FT_GlyphSlot_Oblique.
>>>> Proposed patch doesn't add any tests, as the change only impacts glyph
>>>> rendering, and I couldn't think of a reliable way to test that
>>>> automatically. Existing automated tests from OpenJDK pass after the fix.
>>>>
>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8210058
>>>> Webrev: http://cr.openjdk.java.net/~dbatrak/8210058/webrev.00/
>>>>
>>>> Best regards,
>>>> Dmitry Batrak
>>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20191127/a50b36c7/attachment.html>