On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier
wrote:
> removing dead code.
> When looking into the font code, I've noticed that this code is no longer
> used, so I thought I should make a PR with a minor cleanup.
Marked as reviewed by prr (Reviewer).
I'm quite confident the build will
On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier
wrote:
> removing dead code.
> When looking into the font code, I've noticed that this code is no longer
> used, so I thought I should make a PR with a minor cleanup.
Marked as reviewed by prr (Reviewer).
-
PR:
On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race wrote:
> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on
> the eyes.
> Retina diminishes it rather than cures it.
>
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyp
On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race wrote:
> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on
> the eyes.
> Retina diminishes it rather than cures it.
>
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyp
On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the
eyes.
Retina diminishes it rather than cures it.
The problem is a mix of a couple of things
1) CoreText no longer generates LCD glyphs (except perhaps if you change some
system settings at your own risk)
2) Prism's
On Wed, 15 Sep 2021 23:06:39 GMT, Kevin Rushforth wrote:
>> Added a paragraph indicating that a review of a clean backport to an update
>> release is optional, if the bug in question has been approved for inclusion
>> into the release.
>
> Kevin Rushforth has updated the pull request
On Fri, 16 Jul 2021 21:26:52 GMT, Kevin Rushforth wrote:
> Yes, this null check is needed, since we specify that setting the `printer`
> property to `null` will use the default printer.
oh yeah. So nothing to do here.
The only question is about the behaviour of
public static final
On Fri, 16 Jul 2021 13:41:15 GMT, Kevin Rushforth wrote:
> > looks good..
> > However I have a different question...I was looking at printerProperty and
> > I saw In l182, we are not checking for getDefaultPrinter() returns null or
> > not but in l120, we do...Is it not required in l182?
>
>
On Mon, 12 Jul 2021 18:50:34 GMT, Phil Race wrote:
> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it,
> with an exception for the special case of JobSettings.setPageRanges()
> - Overr
On Thu, 15 Jul 2021 04:30:42 GMT, Prasanta Sadhukhan
wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8269638: Property methods, setters, and getters in printing API should be
>> fin
n't delegate
> to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass
> or fail, just informative.
>
> This will need a CSR but I won't create that until the review is done.
Phil Race has updated the pull request incrementally
On Wed, 14 Jul 2021 20:44:47 GMT, Phil Race wrote:
>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it,
>> with an exception for the special case of JobSettings.setPageRanges()
>
On Wed, 14 Jul 2021 06:29:22 GMT, Prasanta Sadhukhan
wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8269638: Property methods, setters, and getters in printing API should be
>> f
n't delegate
> to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass
> or fail, just informative.
>
> This will need a CSR but I won't create that until the review is done.
Phil Race has updated the pull request incrementally
On Mon, 12 Jul 2021 22:04:25 GMT, Phil Race wrote:
>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it,
>> with an exception for the special case of JobSettings.setPageRanges()
>
On Mon, 12 Jul 2021 18:50:34 GMT, Phil Race wrote:
> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it,
> with an exception for the special case of JobSettings.setPageRanges()
> - Overr
On Mon, 12 Jul 2021 21:28:41 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8269638: Property methods, setters, and getters in printing API should be
>> final
&
n't delegate
> to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass
> or fail, just informative.
>
> This will need a CSR but I won't create that until the review is done.
Phil Race has updated the pull request incrementally
- Make various setters and getters and properties final as needed
- Move documentation to the property so the setters and getters inherit it,
with an exception for the special case of JobSettings.setPageRanges()
- Override toString() on the properties in JobSettings so it doesn't delegate
to the
On Thu, 24 Jun 2021 22:06:37 GMT, Phil Race wrote:
> This enhancement adds the String property outputFileProperty() to the
> JobSettings class.
> The value should be a string that references a local file encoded as a URL.
> If this is non-null and set to a location that the user ha
On Fri, 2 Jul 2021 18:29:12 GMT, Phil Race wrote:
>> They are in there. But with the current approach for CT glyph-parsing, I see
>> no other way. The parsing is done in native code (e.g.
>> OS.CTLineCreateWithAttributedString()) but we extract the required font from
>>
On Fri, 2 Jul 2021 12:34:32 GMT, Johan Vos wrote:
>> Another thought .. after doing this do these "." fonts appear in the list of
>> fonts reported by
>> javafx.scene.text.Font.getFontNames() ?
>>
>> I suspect they really should not ..
>
> They are in there. But with the current approach for
On Tue, 29 Jun 2021 14:20:30 GMT, Johan Vos wrote:
>> Make sure the returned fullName of a created font matches the requested
>> name. Since the name is used as a key/identifier in some cases, some
>> internal code relies on this.
>> Added a test to check the case of "System Font Regular" on
On Thu, 1 Jul 2021 20:53:36 GMT, Phil Race wrote:
>> [Mac only] register system fonts.
>> Fix for JDK-8246104
>>
>> The list of available fonts returned by
>> CTFontCollectionCreateFromAvailableFonts does not contain internal fonts (at
>> least not by defa
On Sat, 26 Jun 2021 15:40:47 GMT, Johan Vos wrote:
> [Mac only] register system fonts.
> Fix for JDK-8246104
>
> The list of available fonts returned by
> CTFontCollectionCreateFromAvailableFonts does not contain internal fonts (at
> least not by default, although this is not documented). By
On Wed, 30 Jun 2021 22:30:47 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - 8223717: javafx printing: Support Specifying Print to File in the API
>> - 822
n can also see what it was set to, and cancel or alter it if
> necessary.
>
> A simple manual test is provided, manual mainly because the few real printing
> functional tests are all manual as they are only useful if run with a printer
> configured.
Phil Race has updated the pull req
On Mon, 28 Jun 2021 19:47:39 GMT, Phil Race wrote:
>> This enhancement adds the String property outputFileProperty() to the
>> JobSettings class.
>> The value should be a string that references a local file encoded as a URL.
>> If this is non-null and set to a lo
n can also see what it was set to, and cancel or alter it if
> necessary.
>
> A simple manual test is provided, manual mainly because the few real printing
> functional tests are all manual as they are only useful if run with a printer
> configured.
Phil Race has updated the pull request
On Fri, 25 Jun 2021 04:08:30 GMT, Prasanta Sadhukhan
wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8223717: javafx printing: Support Specifying Print to File in the API
>
> modules
On Fri, 25 Jun 2021 21:10:16 GMT, Kevin Rushforth wrote:
>> But the JobSettings class is final .. is it still necessary ?
>
> It's still a good idea to follow the pattern, so yes let's make the new
> methods final. We can file a cleanup bug for the existing ones (and since the
> class is
On Fri, 25 Jun 2021 21:13:31 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8223717: javafx printing: Support Specifying Print to File in the API
>
> modules/javafx
On Thu, 24 Jun 2021 22:53:33 GMT, Phil Race wrote:
>> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 490:
>>
>>> 488: * setting will be ignored.
>>> 489: * If the URL specifies a non-existent path, or does not specify
>>
On Fri, 25 Jun 2021 21:08:31 GMT, Kevin Rushforth wrote:
>> I agree with @kevinrushforth that if a String without protocol is passed, it
>> should be treated as a file (absolute or relative to ?)
>> I'm also not sure that the URL should be exposed here. I understand it's
>> needed in the
On Fri, 25 Jun 2021 21:20:53 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java
>> line 839:
>>
>>> 837: security.checkPrintJobAccess();
>>> 838: String file = settings.getOutputFile();
>>> 839: if
n can also see what it was set to, and cancel or alter it if
> necessary.
>
> A simple manual test is provided, manual mainly because the few real printing
> functional tests are all manual as they are only useful if run with a printer
> configured.
Phil Race has updated the pull req
On Thu, 24 Jun 2021 23:19:22 GMT, Kevin Rushforth wrote:
>> We aren't ignoring it .. its just handed on, so its going to be the same as
>> the other non-writable case .. file could not be created .. printing error
>> ..
>> we could do some up-front validation if that seems like the way we
On Thu, 24 Jun 2021 22:42:00 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - 8223717: javafx printing: Support Specifying Print to File in the API
>> - 822
On Thu, 24 Jun 2021 22:53:57 GMT, Scott Palmer wrote:
>> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 474:
>>
>>> 472: * encoded name of a filesystem file, to which the platform printer
>>> 473: * driver should spool the rendered print data.
>>> 474: *
n can also see what it was set to, and cancel or alter it if
> necessary.
>
> A simple manual test is provided, manual mainly because the few real printing
> functional tests are all manual as they are only useful if run with a printer
> configured.
Phil Race has updated the pull req
On Thu, 24 Jun 2021 22:38:40 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8223717: javafx printing: Support Specifying Print to File in the API
>
> modules/javafx
n can also see what it was set to, and cancel or alter it if
> necessary.
>
> A simple manual test is provided, manual mainly because the few real printing
> functional tests are all manual as they are only useful if run with a printer
> configured.
Phil Race has updated the pull reque
This enhancement adds the String property outputFileProperty() to the
JobSettings class.
The value should be a string that references a local file encoded as a URL.
If this is non-null and set to a location that the user has permission to write
to,
then the printer output will be spooled there
On Wed, 5 May 2021 13:45:39 GMT, Kevin Rushforth wrote:
> Update OpenGL headers to latest versions from Mesa project. I ran a sanity
> test on all three platforms. I also checked the diffs against the Java2D
> patch in openjdk/jdk#3854 and they match, excluding the Java2D-specific
> ifdefs.
On Tue, 9 Feb 2021 21:59:58 GMT, Jose Pereda wrote:
> This PR allows rendering Myanmar script correctly, following up on
> https://bugs.openjdk.java.net/browse/JDK-8223558.
Marked as reviewed by prr (Reviewer).
-
PR: https://git.openjdk.java.net/jfx/pull/399
On Wed, 16 Dec 2020 13:20:23 GMT, Kevin Rushforth wrote:
>> Replace archaic/non-inclusive words in JavaFX with more neutral terms. See
>> [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for
>> background information.
>>
>> The following changes are made:
>>
>> 1. Rename
what printer, driver, and os?
did you call any methods to verify the values being passed are supported ?
-Phil.
> On Aug 17, 2020, at 9:01 PM, Tobias Oelgarte
> wrote:
>
> I just experimented with the JavaFX printing API and I'm confused about the
> results.
>
> If I request to print in
On Sat, 18 Jul 2020 14:57:08 GMT, Kevin Rushforth wrote:
> This removes the obsolete OpenPiscesRasterizer (Java-based) and
> NativePiscesRasterizer implementations. The Marlin
> rasterizer was added in FX 9 and was made the default in FX 10. Marlin both
> outperforms Pisces and is more robust.
On Wed, 15 Jul 2020 23:54:59 GMT, Phil Race wrote:
> For a Media that had no defined size - eg a "custom" paper - the code was
> creating a mapping
> that over-rode the NA_LETTER size. This might cause multiple problems but
> definitely meant that
> we ended up with de
> For a Media that had no defined size - eg a "custom" paper - the code was
> creating a mapping
> that over-rode the NA_LETTER size. This might cause multiple problems but
> definitely meant that
> we ended up with default margins.
Phil Race has updated the pull reque
For a Media that had no defined size - eg a "custom" paper - the code was
creating a mapping
that over-rode the NA_LETTER size. This might cause multiple problems but
definitely meant that
we ended up with default margins.
-
Commit messages:
- 8248908: Printer.createPageLayout()
On Tue, 16 Jun 2020 07:59:02 GMT, Bhawesh Choudhary
wrote:
>> Print function of WebEngine.java ignores page range setting and prints given
>> number of pages starting from first page,
>> which is the root cause of this issue. To fix it, put check for page ranges
>> and if it available, use it
On Mon, 15 Jun 2020 05:22:48 GMT, Bhawesh Choudhary
wrote:
>> Print function of WebEngine.java ignores page range setting and prints given
>> number of pages starting from first page,
>> which is the root cause of this issue. To fix it, put check for page ranges
>> and if it available, use it
On Mon, 15 Jun 2020 16:04:05 GMT, Johan Vos wrote:
>> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348
>
> Johan Vos has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove trailing whitespace
Marked as reviewed by prr
On Mon, 1 Jun 2020 15:37:09 GMT, Bhawesh Choudhary
wrote:
>> Print function of WebEngine.java ignores page range setting and prints given
>> number of pages starting from first page,
>> which is the root cause of this issue. To fix it, put check for page ranges
>> and if it available, use it
On Fri, 12 Jun 2020 15:01:35 GMT, Johan Vos wrote:
>> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348
>
> Johan Vos has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use LinkedHashMap instead of HashMap
> Only store the
On Fri, 12 Jun 2020 13:05:03 GMT, Johan Vos wrote:
>> I agree. the text array is now the subset for the run, so effectively
>> run.getStart() should be zero,
>> so there should be no need for that call. This probably looks OK when there
>> is one run not otherwise.
>
> You're both correct. I
On Fri, 12 Jun 2020 14:49:50 GMT, Johan Vos wrote:
>> Oh, right. It will be a Long 0, not null. If you store it you will still
>> have the problem I mentioned with dispose
>> unless you add back in the `str != 0` check. And you would need a check for
>> `str != 0` in the layout method so that
On Thu, 11 Jun 2020 19:20:05 GMT, Kevin Rushforth wrote:
>> I did a quick test, and setting `start = str` fixes the spurious assertions
>> and intermittent crash.
>
> I should add that this is without any attempt to filter out `0` chars. Both
> `UnicodeTextTest` and `UnicodeTextTest2`
> run
On Tue, 9 Jun 2020 19:33:01 GMT, Johan Vos wrote:
> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348
modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java
line 140:
> 139: runUtf8.put(run, str);
> 140: if (check(str,
On Tue, 9 Jun 2020 19:33:01 GMT, Johan Vos wrote:
> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348
Instead of a space you could use a ZWNJ U+FEFF. Because that is also the
endian-ness
mark, Unicode actually prefers you now to use U+2060 but you need to make sure
these
are
PS the spacing is very uneven. That does not look right.
-Phil.
> On May 24, 2020, at 5:16 PM, Phil Race wrote:
>
> That looks normal.
>
> -Phil.
>
>> On May 24, 2020, at 4:27 PM, Rob Nikander wrote:
>>
>>
>>
>>> On May 24, 2020, at 5:46
That looks normal.
-Phil.
> On May 24, 2020, at 4:27 PM, Rob Nikander wrote:
>
>
>
>> On May 24, 2020, at 5:46 PM, Philip Race wrote:
>>
>> That's likely LCD sub-pixel text. Its normal to see it if you squint. Not
>> new.
>
> I’m doubting that this is normal, but let me try to share a
On Fri, 15 May 2020 16:36:29 GMT, Bhawesh Choudhary
wrote:
> Print function of WebEngine.java ignores page range setting and prints given
> number of pages starting from first page,
> which is the root cause of this issue. To fix it, put check for page ranges
> and if it available, use it for
On Fri, 24 Apr 2020 01:50:11 GMT, Kevin Rushforth wrote:
>> I think most of those are good suggestions going forward. As for the
>> performance drop, the only place we've seen it so
>> far is on graphics accelerators that are a few years old by now. Integrated
>> graphics chipsets (such as
On Thu, 16 Apr 2020 12:40:24 GMT, Kevin Rushforth wrote:
>> As per JavaFx 700 font weight is considered to be bold but webkit is using
>> 600 font weight for text to become bold. to
>> fix issue, use boldWeightValue() function which uses 700 font weight rather
>> than isFontWeightBold() which
On Wed, 4 Mar 2020 20:27:46 GMT, Kevin Rushforth wrote:
> This is a follow-on to
> [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474).
>
> This fix removes the custom subclasses of NSSavePanel and NSOpenPanel that
> are optionally used by the glass implementation of file open,
Changeset: 95bf2c00
Author:Phil Race
Date: 2020-01-31 18:22:52 +
URL: https://git.openjdk.java.net/jfx/commit/95bf2c00
8237782: Only read advances up to the minimum of the numHorMetrics or the
available font data.
Reviewed-by: kcr
! modules/javafx.graphics/src/main/java/com
Changeset: d05e8fc4
Author:Phil Race
Date: 2020-01-31 18:21:51 +
URL: https://git.openjdk.java.net/jfx/commit/d05e8fc4
8237833: Check glyph size before adding to glyph texture cache
Reviewed-by: kcr
! modules/javafx.graphics/src/main/java/com/sun/prism/impl/GlyphCache.java
On Thu, 30 Jan 2020 23:07:53 GMT, Kevin Rushforth wrote:
> This is a fix for
> [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable
> the use of `CGEventTap` when running on macOS 10.15 or later.
>
> The effect of this bug is that a scary dialog is shown for all users
Check if the glyph will fit before trying to cache it.
-
Commits:
- fbfb2473: 8237833: Check glyph size before adding to glyph texture cache
Changes: https://git.openjdk.java.net/jfx/pull/96/files
Webrev: https://webrevs.openjdk.java.net/jfx/96/webrev.00
Issue:
… the available font data.
-
Commits:
- 059ec788: 8237782: Only read advances up to the minimum of the numHorMetrics
or the available font data.
Changes: https://git.openjdk.java.net/jfx/pull/95/files
Webrev: https://webrevs.openjdk.java.net/jfx/95/webrev.00
Issue:
On Fri, 24 Jan 2020 15:12:50 GMT, Kevin Rushforth wrote:
> Fix for [JDK-8237823](https://bugs.openjdk.java.net/browse/JDK-8237823).
>
> The javafx.graphics unit test `TextTest.testTabSize` fails intermittently --
> see [JDK-8236728](https://bugs.openjdk.java.net/browse/JDK-8236728).
>
> This
On Mon, 6 Jan 2020 21:01:25 GMT, Kevin Rushforth wrote:
>> This PR is a fix for
>> [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474), a crash in
>> the code that shows a file open or save dialog.
>>
>> In order to provide additional support for Copy (CMD-C), Cut (CMD-X), and
>>
On Mon, 6 Jan 2020 18:11:29 GMT, Kevin Rushforth wrote:
>> Well then you'll just have to come back to it. If its not critical I'd
>> remove it now so that FX 15 (or is this for 14 ?) behaves consistently
>
> This is targeted for JavaFX 14, which is another reason to go with a more
> targeted
On Mon, 6 Jan 2020 16:24:33 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 1 additional commit.
>
> Looks good to me, Verified that all tests pass on Mojave 10.14.6
Based on my reading of https://bugs.openjdk.java.net/browse/JDK-8092977, this
means the support for edit
On Sat, 21 Dec 2019 18:35:26 GMT, Scott Palmer wrote:
>> I'm not sure if I'me supposed to try to integrate now that I've made that 10
>> -> 0 change, or if the new change resets the need for review... Also, note
>> that the link in the bot msg for "project specific requirements" is giving
>>
On Fri, 20 Dec 2019 22:18:29 GMT, Scott Palmer wrote:
>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute
>> to both. TextFlow's tab size overrides that of contained Text nodes.
>
> The pull request has been updated with 1 additional commit.
-
Marked
It would have to allow anyone who has reviewer status to add that comment.
Not just the author since if they knew we would have less need for it.
-Phil.
> On Dec 18, 2019, at 11:31 AM, Kevin Rushforth
> wrote:
>
> That's an interesting idea. It would, of course, need to disallow reducing
>
On Thu, 12 Dec 2019 22:02:53 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1273:
>>
>>> 1272: /**
>>> 1273: * The size of a tab stop in spaces.
>>> 1274: * Values less than 1 are treated as 1.
>>
>> "tab stop" seems to be an
Changeset: 4ddf5542
Author:Jose Pereda
Committer: Phil Race
Date: 2019-12-05 20:13:53 +
URL: https://git.openjdk.java.net/jfx/commit/4ddf5542
8234916: [macos 10.15] Garbled text running with native-image
Reviewed-by: prr
! modules/javafx.graphics/src/main/native-font
On Wed, 27 Nov 2019 17:06:13 GMT, Jose Pereda wrote:
> Running on MacOS Catalina, when doing static builds of `libjavafx_font.a` and
> linking against this in a JavaFX app compiled with GraalVM native-image, if
> default fonts are used, the rendered text is garbled, and a warning message
> is
On Tue, 26 Nov 2019 17:26:33 GMT, Scott Palmer wrote:
> The pull request has been updated with a complete new set of changes
> (possibly due to a rebase).
>
>
>
> Commits:
> - 254c40de: Merge remote-tracking branch 'upstream/master'
> - a670c4f8: 8130738: TextFlow's tab
On Sat, 23 Nov 2019 16:40:11 GMT, Kevin Rushforth wrote:
> We discovered three minor differences between the `libxslt.md` file and the
> libxslt-1.1.34 source bundle:
>
> 1. The copyright years didn't match the source
>
> 2. The following line was missing:
> Licence for libxslt except
On Sat, 23 Nov 2019 16:40:11 GMT, Kevin Rushforth wrote:
> We discovered three minor differences between the `libxslt.md` file and the
> libxslt-1.1.34 source bundle:
>
> 1. The copyright years didn't match the source
>
> 2. The following line was missing:
> Licence for libxslt except
On Fri, 22 Nov 2019 21:13:05 GMT, Kevin Rushforth wrote:
> Now that we have switched to using gradle 6 we can switch to using JDK 13 as
> the boot JDK for JavaFX 14 builds. The latest JDK 13 update release is JDK
> 13.0.1.
>
> This will not change the minimum JDK version needed to build or
On Thu, 14 Nov 2019 23:31:34 GMT, Kevin Rushforth wrote:
> [JDK-8233421](https://bugs.openjdk.java.net/browse/JDK-8233421)
>
> This bumps the windows compiler version to VS2017 version 15.9.16 to match
> JDK 14. I have run a full build and test, including WebKit and media.
>
>
On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote:
> This PR updates the header files we use the build the OpenGL ES2 pipeline to
> Mesa 19.2.1. See [this review
> thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html)
> for the equivalent change that is under
On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote:
> This PR updates the header files we use the build the OpenGL ES2 pipeline to
> Mesa 19.2.1. See [this review
> thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html)
> for the equivalent change that is under
On Wed, 30 Oct 2019 00:43:08 GMT, Sergey Bylokhov wrote:
> On Tue, 29 Oct 2019 23:05:46 GMT, Kevin Rushforth wrote:
>
>> On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote:
>>
>>> This PR updates the header files we use the build the OpenGL ES2 pipeline
>>> to Mesa 19.2.1. See [this
On Sat, 26 Oct 2019 11:33:15 GMT, Laurent Bourgès
wrote:
> On Fri, 25 Oct 2019 20:18:48 GMT, Phil Race wrote:
>
>> I have added an evaluation in
>> https://bugs.openjdk.java.net/browse/JDK-8207839
>> Please read that for more detail, but basically we are not
I have added an evaluation in https://bugs.openjdk.java.net/browse/JDK-8207839
Please read that for more detail, but basically we are not properly preventing
or
handling cases where fontconfig causes us to overflow the byte storage used
for a font "slot".
Commits:
- b6c19466:
s a number of spaces. With units it would be a
‘length’ but nothing supports that.
So I think it makes sense to add -fx-tab-size as a CSS property, only
supporting a number with no units.
Scott
On Oct 17, 2019, at 2:32 PM, Phil Race wrote:
Really ? It defaults to pixels ? Is that just
-tab-size
In this spec, the value of 'tab-size' is a (or length -which no browsers
support). For all intents and purposes, indicates a number of spaces.
-Original Message-
From: openjfx-dev On Behalf Of
Phil Race
Sent: Thursday, October 17, 2019 2:25 PM
To: Scott Palmer
Cc: openjfx-dev
with other values, then
I agree it makes sense. As long as the behaviour is documented, I can’t think
of any significant downside either way.
Regards,
Scott
On Oct 17, 2019, at 12:45 PM, Phil Race wrote:
Hi,
Some more points which I thought about but for whatever reason did not pen ..
First
her values, then I agree it
makes sense. As long as the behaviour is documented, I can’t think
of any significant downside either way.
Regards,
Scott
On Oct 17, 2019, at 12:45 PM, Phil Race wrote:
Hi,
Some more points which I thought about but for whatever reason did
not pen ..
First one m
can’t think
of any significant downside either way.
Regards,
Scott
On Oct 17, 2019, at 12:45 PM, Phil Race wrote:
Hi,
Some more points which I thought about but for whatever reason did not pen ..
First one minor thing: tabWidth is an OK name, but it does not
conjure up that the value
.
-phil.
On 10/15/19 12:17 PM, Phil Race wrote:
Hi,
I've looked over this and I don't see any issues - meaning gotchas.
It just provides a way to over-ride the hard-coded 8,
whether using a Text node directly or a TextFlow.
Two observations of what one might call limitations
1) This is
Hi,
I've looked over this and I don't see any issues - meaning gotchas.
It just provides a way to over-ride the hard-coded 8,
whether using a Text node directly or a TextFlow.
Two observations of what one might call limitations
1) This is a rendering time property, which is controlled by the
Approved.
-phil.
On 10/15/19 9:44 AM, Kevin Rushforth wrote:
> I request approval to backport the changes from the just-released
April 2019 CPU to 11-dev and 13-dev.
Typo: that should be October 2019 CPU
On 10/15/2019 9:43 AM, Kevin Rushforth wrote:
Hi Johan,
I request approval to
1 - 100 of 218 matches
Mail list logo
