On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak wrote:
>> The proposed fix makes fonts with and without fallback components
>> distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This
>> is
On Wed, 20 Apr 2022 17:04:09 GMT, Alexander Zuev wrote:
> Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting
> keyboard events to the system queue.
I assumed that whatever keys we set on an event being posted using
`CGEventPost`, are delivered unchanged to the 'receiving' a
On Wed, 20 Apr 2022 17:04:09 GMT, Alexander Zuev wrote:
> Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting
> keyboard events to the system queue.
Just a note - with the proposed fix, some generated events will be different
from those generated by a real keyboard - namely
On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak wrote:
>> The proposed fix makes fonts with and without fallback components
>> distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This
>> is
On Thu, 24 Mar 2022 02:49:49 GMT, Phil Race wrote:
>> Dmitry Batrak has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove 'headful' requirement from test case
>
> I know .. I know .. I just (a)
On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan
wrote:
>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced
>> Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one
> additional comm
On Fri, 11 Mar 2022 17:53:12 GMT, Phil Race wrote:
> Yes, the sequence.fallback but I am relaying my observation that adding
korean.allfonts=..
did not work even though sequence.fallback lists korean whereas adding
korean-foo.allfonts=..
and adding korean-foo into sequence.fallback DID work.
It'
On Fri, 11 Mar 2022 12:47:28 GMT, Prasanta Sadhukhan
wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert dialogInput. Add Bolditalic
>
> I tested with this test and I got the following output which seems
On Fri, 11 Mar 2022 03:33:38 GMT, Phil Race wrote:
> So if you remove the allfonts entry, does it pick up serif.plain.korean (etc)
> ?
JDK picks up `..korean` entries regardless of
whether `allfonts.korean` entry is present - the former take precedence over
the latter. Yes, it goes against th
On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak wrote:
>> The proposed fix makes fonts with and without fallback components
>> distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This
>> is
On Fri, 4 Mar 2022 18:16:22 GMT, Phil Race wrote:
> But serif.plain.korean isn't used unless it is a Korean locale
That's not the case, and is easily verifiable for English locale - whatever
font is specified there will become a component of Serif composite. 'korean'
here is a script id, which
On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan
wrote:
>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced
>> Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one
> additional comm
On Sun, 6 Feb 2022 19:53:45 GMT, Phil Race wrote:
>> Dmitry Batrak has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove 'headful' requirement from test case
>
>> As you say, one could
On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak wrote:
>> The proposed fix makes fonts with and without fallback components
>> distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This
>> is
On Wed, 2 Feb 2022 21:29:28 GMT, Sergey Bylokhov wrote:
>> src/java.desktop/share/classes/java/awt/Font.java line 1861:
>>
>>> 1859: pointSize == font.pointSize &&
>>> 1860: withFallback == font.withFallback &&
>>> 1861: name.equals(font.name)) {
>
a 'real' created
> font (the one obtained using `Font.createFont` method) to be equal to the
> same font after serialization and
> deserialization.
Dmitry Batrak has updated the pull request incrementally with one additional
commit since the last revision:
remove 'head
On Tue, 1 Feb 2022 19:50:47 GMT, Sergey Bylokhov wrote:
>> The proposed fix makes fonts with and without fallback components
>> distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This
>> is achieved by adding a new b
On Tue, 1 Feb 2022 19:47:59 GMT, Sergey Bylokhov wrote:
>> The proposed fix makes fonts with and without fallback components
>> distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This
>> is achieved by adding a new b
The proposed fix makes fonts with and without fallback components
distinguishable (in terms of `equals` method), so that
font metrics cache (and other similar code) can handle them separately. This is
achieved by adding a new boolean field
to `Font` class, specifically denoting fonts with fallbac
On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak wrote:
> The fix just removes the explicit normalization of text obtained from system
> clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS
> version.
> The sa
On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak wrote:
> The fix just removes the explicit normalization of text obtained from system
> clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS
> version.
> The sa
On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak wrote:
> The fix just removes the explicit normalization of text obtained from system
> clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS
> version.
> The sa
On Tue, 11 Jan 2022 05:51:10 GMT, Sergey Bylokhov wrote:
> Just to clarify, according to your investigation the "CFStringNormalize" is
> not needed to use for the file names?
I didn't state that. AFAIU, in most typical cases, file names come from OS in
NFD form, and `CFStringNormalize` does co
On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak wrote:
> The fix just removes the explicit normalization of text obtained from system
> clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS
> version.
> The sa
On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak wrote:
> The fix just removes the explicit normalization of text obtained from system
> clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS
> version.
> The sa
On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak wrote:
> The fix just removes the explicit normalization of text obtained from system
> clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS
> version.
> The sa
The fix just removes the explicit normalization of text obtained from system
clipboard in JDK code, as I've found no
good justification for such a normalization, at least for the latest macOS
version.
The same fix was performed in JetBrains Runtime by a user's request more than 4
years ago, and
On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak wrote:
> The problem is related to the implementation of font fallback on macOS,
> specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists.
> `CTFontCopyDefaultCascadeList
On Wed, 15 Dec 2021 01:13:04 GMT, Sergey Bylokhov wrote:
> I would like to clarify why we cannot merge the results of the
> availableFontFamilies and availableFonts?
We can do it, if everyone is OK with increasing the scope of the change, due to
the following factors:
* The number of fonts adv
On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak wrote:
> The problem is related to the implementation of font fallback on macOS,
> specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists.
> `CTFontCopyDefaultCascadeList
On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak wrote:
> The problem is related to the implementation of font fallback on macOS,
> specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists.
> `CTFontCopyDefaultCascadeList
On Wed, 1 Dec 2021 17:34:58 GMT, Phil Race wrote:
> FWIW the rendering being present in the non-layout case is likely due to the
> magic JRS fall back code .. some day we need to unify this so that at least
> we are consistent.
That's what I'm working on now - getting rid of
`JRSFontCreateFal
The problem is related to the implementation of font fallback on macOS,
specifically to the path used when text layout
is performed, i.e. the one using `FontSubstitution` and cascade lists.
`CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the
font, able to render Armenia
On Tue, 12 Oct 2021 12:23:02 GMT, Dmitry Batrak wrote:
> This is a small fix for a mistake in JDK-8257853 implementation, replacing
> DECLARE_METHOD JNI lookup macro with DECLARE_STATIC_METHOD in
> [AWTWindow_Normal postGesture:as:a🅱].
> I did not created a test for the fix,
This is a small fix for a mistake in JDK-8257853 implementation, replacing
DECLARE_METHOD JNI lookup macro with DECLARE_STATIC_METHOD in [AWTWindow_Normal
postGesture:as:a🅱].
I did not created a test for the fix, as AWT Robot doesn't currently support
touchpad gestures.
-
Commit me
spatching can quite as well be done on
EDT.
So, what do you think about the idea in general, and about starting to
realize it in
Wayland toolkit implementation?
Best regards,
Dmitry Batrak
36 matches
Mail list logo
