On Wed, 11 May 2022 20:58:37 GMT, Phil Race wrote:
>> This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329
>> It is similar in the idea from what we converged on towards the end there but
>> 1) I'd like to preserve all the support for the old encodings since JEP-400
>> ex
On Wed, 4 May 2022 15:34:29 GMT, Toshio Nakamura wrote:
>> Japanese logical fonts are drawn with wrong size since Java 18.
>> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration`
>> (and `sun.awt.windows.WFontConfiguration`) seems to expect the native
On Thu, 21 Apr 2022 09:14:14 GMT, Toshio Nakamura wrote:
> Japanese logical fonts are drawn with wrong size since Java 18.
> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and
> `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding
On Tue, 3 May 2022 21:42:35 GMT, Phil Race wrote:
>> Toshio Nakamura has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved the fix to WFontConfiguration
>
> It looks to me as if we specify a latin font as
ges to use native encoding.
>
> Tested: jdk_desktop on Windows, Linux, and macOS
Toshio Nakamura has updated the pull request incrementally with one additional
commit since the last revision:
locale base fix
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/83
On Fri, 29 Apr 2022 00:12:53 GMT, Phil Race wrote:
>> The following diff seems to choose the right font:
>>
>> --- a/src/java.desktop/windows/data/fontconfig/fontconfig.properties
>> +++ b/src/java.desktop/windows/data/fontconfig/fontconfig.properties
>> @@ -230,7 +230,7 @@
>> sequence.dialog.x
On Tue, 26 Apr 2022 16:50:24 GMT, Phil Race wrote:
>> Toshio Nakamura has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved the fix to WFontConfiguration
>
> Hmm. I'm not sure I'm seeing what
On Fri, 22 Apr 2022 03:24:09 GMT, Phil Race wrote:
>> Japanese logical fonts are drawn with wrong size since Java 18.
>> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration`
>> (and `sun.awt.windows.WFontConfiguration`) seems to expect the native
>> encoding instead of the d
ges to use native encoding.
>
> Tested: jdk_desktop on Windows, Linux, and macOS
Toshio Nakamura has updated the pull request incrementally with one additional
commit since the last revision:
Moved the fix to WFontConfiguration
-
Changes:
- all: https://git.openjdk.java.net/jdk/
Japanese logical fonts are drawn with wrong size since Java 18.
It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and
`sun.awt.windows.WFontConfiguration`) seems to expect the native encoding
instead of the default encoding. This patch changes to use native encoding.
Test
On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura wrote:
> Hi,
>
> Could you review the fix?
> When non-English characters were printed from JTable on MacOS,
> CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However,
> CTextPipe seems not support glyph w
On Fri, 23 Apr 2021 06:49:10 GMT, Sergey Bylokhov wrote:
>> Hi,
>>
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS,
>> CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However,
>> CTextPipe seems not support glyph with slot number of
On Sat, 19 Feb 2022 00:43:39 GMT, Sergey Bylokhov wrote:
>> Toshio Nakamura has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request conta
a mask of GlyphVector is 0xff00. In my environment, Japanese
> font was loaded at slot 4, and glyph data is like [0x40003e5]. Then,
> unexpected glyph was drawn.
Toshio Nakamura has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes
On Thu, 6 Jan 2022 02:49:17 GMT, Toshio Nakamura wrote:
>> Hi,
>>
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS,
>> CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However,
>> CTextPipe seems n
On Wed, 26 Jan 2022 06:53:42 GMT, Toshio Nakamura wrote:
> JInternalFrame's bottom area is not properly drawn with Aqua LAF.
> This problem remained for long time, but we recognized it recently.
>
> According to the bug report, it depends on MacOS's version. I don't
On Thu, 27 Jan 2022 00:36:54 GMT, Phil Race wrote:
>> Toshio Nakamura has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Applied review comments
>
> Looks so much better.
@prrace @mrserb
Thank you for the
On Thu, 27 Jan 2022 00:36:54 GMT, Phil Race wrote:
>> Toshio Nakamura has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Applied review comments
>
> Looks so much better.
Thank you for reviewing, @prrace @m
the current MacOS can recreate the
> issue. I confirmed the following OS versions recreated this issue and this
> patch could solve it.
>
> Mojave 10.14.6
> Catalina 10.15.7
> Big Sur 11.6.2
> Monterey 12.1
>
> jtreg "javax/swing" and "java/awt" ha
JInternalFrame's bottom area is not properly drawn with Aqua LAF.
This problem remained for long time, but we recognized it recently.
According to the bug report, it depends on MacOS's version. I don't have old
ones (10.10 and 10.11 in the report), but the current MacOS can recreate the
issue. I
On Tue, 4 Jan 2022 02:12:41 GMT, Phil Race wrote:
>> Toshio Nakamura has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contain
a mask of GlyphVector is 0xff00. In my environment, Japanese
> font was loaded at slot 4, and glyph data is like [0x40003e5]. Then,
> unexpected glyph was drawn.
Toshio Nakamura has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes
On Thu, 21 Oct 2021 00:57:47 GMT, Toshio Nakamura wrote:
>> Hi,
>>
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS,
>> CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However,
>> CTextPipe seem
On Thu, 21 Oct 2021 00:57:47 GMT, Toshio Nakamura wrote:
>> Hi,
>>
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS,
>> CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However,
>> CTextPipe seem
On Fri, 23 Apr 2021 06:49:10 GMT, Sergey Bylokhov wrote:
>> Hi,
>>
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS,
>> CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However,
>> CTextPipe seems not support glyph with slot number of
On Thu, 17 Jun 2021 09:29:07 GMT, Toshio Nakamura wrote:
>> Hi,
>>
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS,
>> CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However,
>> CTextPipe seem
a mask of GlyphVector is 0xff00. In my environment, Japanese
> font was loaded at slot 4, and glyph data is like [0x40003e5]. Then,
> unexpected glyph was drawn.
Toshio Nakamura has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes
27 matches
Mail list logo
