On Thu, 31 Oct 2024 19:44:22 GMT, Anirvan Sarkar wrote:
>> modules/javafx.graphics/src/main/java/javafx/application/Preloader.java line
>> 107:
>>
>>> 105:
>>> 106: // Too bad this isn't already available in a Java core class
>>> 107: private static final String lineSeparator;
>>
>> S
On Tue, 15 Oct 2024 17:29:30 GMT, Nir Lisker wrote:
> It is at all possible to split the image loaders from the desktop module into
> its own? I would think it will be useful for more than just JavaFX.
That would still be dependent on the desktop module, so I don't see how that
would help any
On Tue, 15 Oct 2024 20:08:31 GMT, John Hendrikx wrote:
> Any idea why FX has custom image loaders at all, and doesn't simply always
> delegate to `ImageIO` for this? If the dependency burden is high, it could be
> further reduced by removing built-in decoders? In other words, what's the
> adva
On Wed, 9 Oct 2024 20:15:19 GMT, Andy Goryachev wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line
>> 35:
>>
>>> 33: *
>>> 34: * The snapshot is valid until the layout changes due to any change that
>>> 35: * triggers that, such as resizing of the contain
On Wed, 9 Oct 2024 20:58:21 GMT, Phil Race wrote:
>> thank you!
>>
>> I am struggling with how to explain that it should neither be cached, nor
>> compared to another snapshot.
>>
>> Maybe an example would help. Use case is an editable rich text componen
On Wed, 9 Oct 2024 19:30:06 GMT, Andy Goryachev wrote:
>> The RichTextArea control
>> ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom
>> control that needs non-trivial navigation within complex or wrapped text
>> needs a public API to get information about text layo
On Tue, 8 Oct 2024 16:07:54 GMT, Andy Goryachev wrote:
> The RichTextArea control
> ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom
> control that needs non-trivial navigation within complex or wrapped text
> needs a public API to get information about text layout.
On Fri, 30 Aug 2024 12:00:35 GMT, Jose Pereda wrote:
>> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that
>> make use of `FontConfigManager::getFontConfigFont`, which under certain
>> cases, can return null.
>>
>> I've tested this PR on both Linux (Ubuntu 22.04.4) and
On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda wrote:
> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that
> make use of `FontConfigManager::getFontConfigFont`, which under certain
> cases, can return null.
>
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Andr
On Tue, 20 Aug 2024 16:34:27 GMT, Phil Race wrote:
> Backport the fix for a crash
This pull request has now been integrated.
Changeset: 1094ee3f
Author: Phil Race
URL:
https://git.openjdk.org/jfx/commit/1094ee3f13f48a33bbfc858b2893daaf2cbe8f39
Stats: 87 lines in 1 file chan
Backport the fix for a crash
-
Commit messages:
- Backport 269d6897e4d4e62beff3a2179dcdabe8a0bf0bc7
Changes: https://git.openjdk.org/jfx/pull/1540/files
Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1540&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8338478
Stats: 87
On Sat, 17 Aug 2024 21:02:59 GMT, Phil Race wrote:
> The test in the bug report crashes reliably with JDK 22 on retina.
> It coincides with an update to the macOS compilers which seem likely to
> eagerly invalidate the target of a CFRelease on the native CTFontRef.
> Adding a Reach
The test in the bug report crashes reliably with JDK 22 on retina.
It coincides with an update to the macOS compilers which seem likely to eagerly
invalidate the target of a CFRelease on the native CTFontRef.
Adding a ReachabilityFence to prevent the GC from collecting CTFontStrike until
after th
On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth wrote:
>> 1. Added logic to look in the standard locations for Visual Studio 2022,
>> with a fallback to 2019 and then 2017 if 2022 is not found. It will look in
>> the following locations:
>>
>> C:("Program Files"|"Program Files (x86)")\Micros
On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth wrote:
>> 1. Added logic to look in the standard locations for Visual Studio 2022,
>> with a fallback to 2019 and then 2017 if 2022 is not found. It will look in
>> the following locations:
>>
>> C:("Program Files"|"Program Files (x86)")\Micros
On Mon, 12 Aug 2024 19:48:11 GMT, Kevin Rushforth wrote:
> > The wiki page for building OpenJFX will also need an update.
>
> Yes. I plan to (I meant to list that in the Description, but forgot to add
> it). Thanks for the reminder.
Yes indeed, Kevin and I discussed that at some length. What i
On Tue, 2 Jul 2024 20:04:39 GMT, Alexander Zvegintsev
wrote:
>> Most of the headful test failures on XWayland are due to screen capture is
>> not working.
>>
>> Wayland, unlike X11, does not allow arbitrary applications to capture the
>> screen contents directly.
>> Instead, screen capture fu
On Fri, 28 Jun 2024 18:07:52 GMT, Alexander Zvegintsev
wrote:
>> Since `SecurityException` is deprecated, we should not throw that.
>>
>> In a similar situation on macOS (user has not enabled screen capture), we
>> return a blank (all black) image, so I think that's what we would do here.
>
>
On Wed, 26 Jun 2024 11:25:37 GMT, Alexander Zvegintsev
wrote:
> Most of the headful test failures on XWayland are due to screen capture is
> not working.
>
> Wayland, unlike X11, does not allow arbitrary applications to capture the
> screen contents directly.
> Instead, screen capture functio
On Mon, 24 Jun 2024 22:01:09 GMT, Phil Race wrote:
> The problem is due to per-user install fonts on windows having full paths so
> they may be too long.
> This is identical to the JDK fix that was done some time ago
> https://github.com/openjdk/jdk/pull/13359
> I've tested
On Fri, 21 Jun 2024 12:50:45 GMT, Kevin Rushforth wrote:
> This PR enables two warnings that are now (or soon will be) enabled in the
> [jdk](https://github.com/openjdk/jdk) repo:
>
> 1. Binary file check -- this will alert the reviewers of a PR that the patch
> being reviewed includes one or
The problem is due to per-user install fonts on windows having full paths so
they may be too long.
This is identical to the JDK fix that was done some time ago
https://github.com/openjdk/jdk/pull/13359
I've tested that per-user fonts still work and so do the system-wide installed
fonts.
---
On Wed, 15 May 2024 19:00:57 GMT, Nir Lisker wrote:
>> Update the code review guidelines for JavaFX.
>>
>> The JavaFX
>> [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md)
>> guidelines includes guidance for creating, reviewing, and integrating
>>
On Wed, 15 May 2024 19:32:04 GMT, Kevin Rushforth wrote:
>> README-code-reviews.md line 103:
>>
>>> 101: To ensure that new features are consistent with the rest of the API
>>> and the desired direction of the Project, a CSR is required for a new
>>> Feature, API addition, or behavioral change
On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote:
> Update the code review guidelines for JavaFX.
>
> The JavaFX
> [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md)
> guidelines includes guidance for creating, reviewing, and integrating
> c
On Wed, 15 May 2024 18:56:29 GMT, Kevin Rushforth wrote:
>> README-code-reviews.md line 10:
>>
>>> 8:
>>> 9: __Project Co-Lead__: Kevin Rushforth (kcr)
>>> 10: __Project Co-Lead__: Johan Vos (jvos)
>>
>> There are two sets of ids - one for OpenJFX/JBS and one for Github. This
>> might be co
On Thu, 25 Apr 2024 19:28:47 GMT, Phil Race wrote:
> Backport to jfx22u
This pull request has now been integrated.
Changeset: 77e7e251
Author: Phil Race
URL:
https://git.openjdk.org/jfx22u/commit/77e7e2514c25fa5f653938a6d0cbd4b1b6abe74f
Stats: 7 lines in 1 file changed: 4 ins
Backport to jfx22u
-
Commit messages:
- Backport 5182ea16ace78c4f61e2c38981aab62f6153294e
Changes: https://git.openjdk.org/jfx22u/pull/27/files
Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=27&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8322251
Stats: 7 lines in
On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race wrote:
> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be
> quite a problem.
> I expect this fix is a candidate for backporting.
This pull request
On Thu, 18 Apr 2024 14:18:43 GMT, Andy Goryachev wrote:
> the code looks right, I just can't verify the fix on a real system.
Well, yes, I had to install 23.10 in a VirtualBox VM, then clone FX on to it
along with all the tools
needed to build and test.
So it is definitely something that needs
On Wed, 10 Apr 2024 19:09:52 GMT, Andy Goryachev wrote:
>> The Linux font lookup code is rejecting CFF OpenType fonts.
>> Since these are becoming common because of the Noto family this could soon
>> be quite a problem.
>> I expect this fix is a candidate for backporting.
>
> modules/javafx.grap
The Linux font lookup code is rejecting CFF OpenType fonts.
Since these are becoming common because of the Noto family this could soon be
quite a problem.
I expect this fix is a candidate for backporting.
-
Commit messages:
- 8322251
Changes: https://git.openjdk.org/jfx/pull/1439/f
On Wed, 21 Feb 2024 18:39:16 GMT, Kevin Rushforth wrote:
>> This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK
>> 21**.
>>
>> In order for JavaFX to be able to use newer JDK features, such as code
>> snippets (in API docs), record patterns, pattern matching for switch
On Fri, 9 Feb 2024 22:50:42 GMT, Kevin Rushforth wrote:
> Clean backport to jfx22u.
Marked as reviewed by prr (Reviewer).
-
PR Review: https://git.openjdk.org/jfx22u/pull/10#pullrequestreview-1873401759
On Fri, 9 Feb 2024 21:31:14 GMT, John Hendrikx wrote:
> > > I'm surprised this didn't get reported a long time ago.
> >
> >
> > I'm also surprised.
>
> I do a lot of transparent text, cross fades, animation and other stuff, but
> first thing I always do is turn lcd rendering off...
Which is
On Fri, 9 Feb 2024 16:24:21 GMT, Kevin Rushforth wrote:
>> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader
>> and alpha blending. The alpha channel is used is ways that interfere with
>> its use for transparency. The existing logic checks that the current blend
>> eq
On Thu, 11 Jan 2024 23:54:13 GMT, Kevin Rushforth wrote:
>> As described in the JBS bug, there is a long-standing deadlock that happens
>> on macOS between the AWT EDT and the JavaFX Application thread (which on
>> macOS is the AppKit thread) when processing Input Method Events (IME) in a
>> W
On Tue, 31 Oct 2023 11:46:57 GMT, Florian Kirmaier
wrote:
>> The Method javafx.print.getWidth and getHeight returns a double of points.
>> But the values are always rounded to full integers. This causes especially
>> problems,
>> with mm based Papers.
>>
>> I asked in the mailing list, with th
On Wed, 8 Nov 2023 19:43:24 GMT, Kevin Rushforth wrote:
>> Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows:
>>
>> 1. Override the `NSApplicationDelegate` method
>> `applicationSupportsSecureRestorableState` in `GlassApplication` and return
>> `YES`. This silences the
On Wed, 8 Nov 2023 15:04:44 GMT, Kevin Rushforth wrote:
> Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows:
>
> 1. Override the `NSApplicationDelegate` method
> `applicationSupportsSecureRestorableState` in `GlassApplication` and return
> `YES`. This silences the warni
On Fri, 13 Oct 2023 07:01:51 GMT, Karthik P K wrote:
>> The text run selected in `PrismTextLayout::getHitInfo()` method for
>> character index calculation was not correct when hitTest was invoked for
>> Text node in a TextFlow with more than one Text child. Hence wrong character
>> index value
On Mon, 9 Oct 2023 22:24:37 GMT, Andy Goryachev wrote:
>> what if you have a mixture of RTL and LTR text in JDK8?
>> I am going to double check the behavior in JTextArea as well.
>
> what is going on?? JTextArea inside a Scene with RTL orientation:
>
> src="https://github.com/openjdk/jfx/asset
On Mon, 9 Oct 2023 21:58:54 GMT, Phil Race wrote:
>> The fix uses character BreakIterator instead of the logic that relies on
>> caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
>>
>> I believe this is a more reliable method of navigation, a
On Tue, 22 Aug 2023 20:46:21 GMT, Andy Goryachev wrote:
> The fix uses character BreakIterator instead of the logic that relies on
> caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
>
> I believe this is a more reliable method of navigation, as it behaves in sync
> w
On Wed, 27 Sep 2023 15:32:17 GMT, Phil Race wrote:
>> Karthik P K has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments
>
> Changes requested by prr (Reviewer).
> @prrace could you please take
On Mon, 21 Aug 2023 18:25:08 GMT, Karthik P K wrote:
>> The text run selected in `PrismTextLayout::getHitInfo()` method for
>> character index calculation was not correct when hitTest was invoked for
>> Text node in a TextFlow with more than one Text child. Hence wrong character
>> index value
On Mon, 25 Sep 2023 16:32:31 GMT, Andy Goryachev wrote:
> looks good.
>
> I also think we should consider making the Paper constructor public to
> support other paper sizes (as a separate RFE).
That's a design decision of the API that it not be public since you are only
supposed to use
Paper
On Sat, 23 Sep 2023 06:24:26 GMT, John Hendrikx wrote:
> The sizes should be 8.5 wide for letter, and 3.875 wide for monarch.
Marked as reviewed by prr (Reviewer).
"The sizes should be 8.5 wide for letter, and 3.875 wide for monarch"
You mean legal, not letter.
8.4 -> 8.5 for that seems fine
On Tue, 19 Sep 2023 11:56:39 GMT, Florian Kirmaier
wrote:
> The Method javafx.print.getWidth and getHeight returns a double of points.
> But the values are always rounded to full integers. This causes especially
> problems,
> with mm based Papers.
>
> I asked in the mailing list, with the conc
On Mon, 5 Jun 2023 11:16:52 GMT, Karthik P K wrote:
>> Since surrogate pairs are internally considered as 2 characters and text
>> field is null in `HitInfo` when `getInsertionIndex` is invoked from
>> `TextFlow`, wrong insertion index was returned.
>>
>> Updated code to calculate insertion in
On Fri, 2 Jun 2023 19:41:04 GMT, Andy Goryachev wrote:
>> No, it wasn't due to null text. That is provably impossible.
>>
>> The exception from JDK-8302511 is as follows (copied from the bug report).
>>
>> Exception in thread "JavaFX Application Thread"
>> java.lang.IllegalArgumentException: o
On Fri, 2 Jun 2023 18:50:07 GMT, Andy Goryachev wrote:
>> I did note that TextFlow passed null which really looked like a WIP to me
>> but its a separate issue.
>> The exception in 8302511 which is the entire subject of that bug isn't
>> possible if text == null.
>> My point is that if you pass
On Fri, 2 Jun 2023 07:19:01 GMT, Karthik P K wrote:
>> The main issue is that insertion index was not computed in the
>> PrismTextLayout, supposedly to allow for delaying the computation until it's
>> needed (if needed at all). A good intention, but the execution had two
>> issues:
>> 1. HitI
On Thu, 1 Jun 2023 20:53:07 GMT, Phil Race wrote:
>>> I couldn't create the scenario to hit line 473. If you have any suggestions
>>> please let me know.
>>
>> I can't seem to trigger this code path (I wonder if it's possible to hit it
>> a
On Tue, 16 May 2023 17:53:00 GMT, Andy Goryachev wrote:
>> Initializing the insertion index directly with character index looks better.
>> In this way we can avoid additional conditional logic as well. Changed code
>> to do so.
>> Added additional test case. This tests the condition present in
On Wed, 10 May 2023 23:32:04 GMT, Andy Goryachev wrote:
>> Adding TextFlow.underlineShape() to add support for a spellchecker-like
>> decoration, using
>>
>> getRange(start, end, TextLayout.TYPE_UNDERLINE);
>>
>>
>> which mirrors an existing method in Text with exactly the same signature.
>
On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote:
> Adding TextFlow.underlineShape() to add support for a spellchecker-like
> decoration, using
>
> getRange(start, end, TextLayout.TYPE_UNDERLINE);
>
>
> which mirrors an existing method in Text with exactly the same signature.
Seems fin
On Fri, 24 Mar 2023 21:37:16 GMT, Phil Race wrote:
> This PR addresses some font problems on macOS.
> (1) Garbled Arabic with the System font
> (2) Non-ideal fallback fonts for all fonts
> (3) No bold for System font.
>
> In particular the standard System Font was garbling Ar
On Thu, 6 Apr 2023 18:57:34 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix NPE
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext/CTFontFi
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really need to ad
This fixes a problem with mixing Emoji and regular text in Webview.
The Prism implementation expects that Emoji will not be in the same call to
drawString as regular glyphs,
since they need very different handling.
This fix breaks up the runs webview hands to Prism.
The test program in the bug rep
On Thu, 6 Apr 2023 16:49:34 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix ranges
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFacto
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really need t
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really need to a
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really need to add
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really need to add co
On Tue, 4 Apr 2023 21:29:19 GMT, Phil Race wrote:
>> This PR addresses some font problems on macOS.
>> (1) Garbled Arabic with the System font
>> (2) Non-ideal fallback fonts for all fonts
>> (3) No bold for System font.
>>
>> In particular the standard
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really
On Tue, 4 Apr 2023 20:45:42 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix up Thai font name
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/core
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really
On Tue, 4 Apr 2023 18:17:55 GMT, Andy Goryachev wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> formatting and make some fields private
>
> modules/javafx.graphics/src
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really need to add co
complex
> text layout.
>
> The final thing this fixes is that "System Bold" was the same as "System
> Regular".
> The needed name getting lost along the way to constructing the native font.
>
> The work done here also highlighted that we really need to add co
On Tue, 4 Apr 2023 18:49:41 GMT, Andy Goryachev wrote:
> Thai does not render for me on Ventura 13.3/M1
>
> 
On macOS 12 Thai uses Thonburi from /System
On Mon, 3 Apr 2023 22:55:02 GMT, Andy Goryachev wrote:
> > You mention "Thai" amongst them .. but I do see Thai rendered ..
>
> Thai is not rendered for me, was Ventura 13.1, now Ventura 13.3 on Mac M1,
> (left - ventura 13.1 with the earlier commit, right - unpatched master)
So no worse off t
On Mon, 27 Mar 2023 16:56:16 GMT, Andy Goryachev wrote:
> * italic is rendered as bold
That was in the draft PR and I said a known issue to ignore. It is already
resolved.
The missing scripts are because macOS isn't enumerating supplemental fonts that
support them as fallbacks. That's a topic
This PR addresses some font problems on macOS.
(1) Garbled Arabic with the System font
(2) Non-ideal fallback fonts for all fonts
(3) No bold for System font.
In particular the standard System Font was garbling Arabic text - random glyphs
from another font.
The root of this issue is that several
On Tue, 28 Mar 2023 15:09:29 GMT, Kevin Rushforth wrote:
> A malformed unicode string containing only half of a surrogate pair (either a
> high or low surrogate without the other half) will cause a native exception
> in the macOS `NSPasteboardItem setString:forType:` method. This uncaught
> ex
On Tue, 7 Mar 2023 19:54:15 GMT, Phil Race wrote:
> This fixes an the AIOOBE when finding a line break point in RTL laid out
> glyphs.
> The comment in the bug report explains how we can end up trying to find an
> unachievable break point and yet there's no "stop&quo
hs so hence the exception.
>
> The fix uses a different method to choose a break point.
>
> A system test has been supplied which will fail on macOS (even with standard
> macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
Phil Race has updated the pull request i
forth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8302797
>
> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java
> line 46:
>
>> 44: import j
On Tue, 7 Mar 2023 20:18:59 GMT, Andy Goryachev wrote:
>> This fixes an the AIOOBE when finding a line break point in RTL laid out
>> glyphs.
>> The comment in the bug report explains how we can end up trying to find an
>> unachievable break point and yet there's no "stop" on the search when we
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
On Tue, 7 Mar 2023 21:29:20 GMT, Phil Race
hs so hence the exception.
>
> The fix uses a different method to choose a break point.
>
> A system test has been supplied which will fail on macOS (even with standard
> macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
Phil Race has updated the pull request i
This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
The comment in the bug report explains how we can end up trying to find an
unachievable break point and yet there's no "stop" on the search when we've run
out of glyphs so hence the exception.
The fix uses a differe
On Thu, 23 Feb 2023 20:43:29 GMT, Phil Race wrote:
> This fix properly supports colour rendering of Emoji on macOS
>
>
> On other platforms the Emoji will be rendered as ordinary greyscale glyphs -
> if there is font
> support for the requested code point.
>
>
On Fri, 24 Feb 2023 22:03:59 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8290866
>
> tests/manual/text/EmojiTest.java line 54:
>
>> 52:
ance via a CoreText
> API since
>the HMTX metrics were very wrong - causing overlapping glyphs
> - drawString checks if it is an Emoji run and redirects to a new
> drawColorGlyph method
>which draws the image as a texture
> - All 3 rendering pipelines have this support and
ance via a CoreText
> API since
>the HMTX metrics were very wrong - causing overlapping glyphs
> - drawString checks if it is an Emoji run and redirects to a new
> drawColorGlyph method
>which draws the image as a texture
> - All 3 rendering pipelines have this support and
ance via a CoreText
> API since
>the HMTX metrics were very wrong - causing overlapping glyphs
> - drawString checks if it is an Emoji run and redirects to a new
> drawColorGlyph method
>which draws the image as a texture
> - All 3 rendering pipelines have this support and
On Fri, 24 Feb 2023 19:28:49 GMT, Andy Goryachev wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java
>> line 1456:
>>
>>> 1454:private boolean isSbixGlyph(int glyphID) {
>>> 1455:if (sbixStrikes == null) {
>>> 1456:synchronized (this) {
On Fri, 24 Feb 2023 18:58:37 GMT, Kevin Rushforth wrote:
>> This fix properly supports colour rendering of Emoji on macOS
>>
>>
>> On other platforms the Emoji will be rendered as ordinary greyscale glyphs -
>> if there is font
>> support for the requested code point.
>>
>> A simple manual te
On Fri, 24 Feb 2023 19:17:08 GMT, Andy Goryachev wrote:
> > app works with no clipping on macOS 12.6.1
>
> clipping occurs on retina at any resolution, from "Larger Text" to "More
> Space". It might be specific to Ventura, and possibly to the flag emojis. I
> tried to paste random code blocks,
On Fri, 24 Feb 2023 18:57:54 GMT, Andy Goryachev wrote:
> > So I suspect something specific to what you are doing in your test .. not a
> > general emoji problem.
>
> or specific to my Mac Ventura 13.1. In my test, i am setting the font
> explicitly. A simpler test clips the flag symbols on bo
On Fri, 24 Feb 2023 16:50:05 GMT, Andy Goryachev wrote:
> Another question: on non-retina monitor, emojis appear blurry when text size
> is set to 12. I vaguely recall that when resizing down, the resizing
> operation might be followed by a sharpening filter (or perhaps some other op
> can be
On Fri, 24 Feb 2023 16:44:35 GMT, Andy Goryachev wrote:
> I see some clipping of the emoji flag sequence characters, for example
> \ud83c\uddfa\ud83c\udde6 when moving from the primary retina (scale=2) to
> secondary external (scale=1) monitor:
I tried the same size and sequence and in the pro
This fix properly supports colour rendering of Emoji on macOS
On other platforms the Emoji will be rendered as ordinary greyscale glyphs - if
there is font
support for the requested code point.
A simple manual test is provided which uses a Text node, Label control
and editable TextField control
On Thu, 16 Feb 2023 18:54:18 GMT, Kevin Rushforth wrote:
>> @prrace What is your preference here?
>> Since `enterNestedEventLoop` and `exitNestedEventLoop` throw an exception
>> when not on the fx user thread, I feel like it makes sense to also add it
>> here as well.
>
> Phil's comment got me
On Wed, 15 Feb 2023 21:39:02 GMT, Kevin Rushforth wrote:
>> Should I also adjust the `Toolkit` javadoc or only the `Platform` one?
>
> It might be a good idea to also adjust the Toolkit docs; it doesn't get
> generated as javadoc, but could be useful for someone looking at the code. If
> you do
On Tue, 31 Jan 2023 10:30:22 GMT, Jose Pereda wrote:
> This PR simply applies the patch from
> [JDK-8218914](https://bugs.openjdk.org/browse/JDK-8218914) that solved the
> same issue for the JDK.
>
> I've tested it on Windows 11 (Version 22H2 Build 22621.1105).
>
> I have the Roboto font ins
1 - 100 of 126 matches
Mail list logo
