[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Withdrawn: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were ga
From:       duke <duke () openjdk ! java ! net>
Date:       2021-08-12 11:30:28
Message-ID: iCO2jDOnC7xFqL5oL1FhZAYqG1f5LoVyctnt5C1Vr3k=.6068b32b-3533-4f16-94c6-3f61aea01646 () github ! com
[Download RAW message or body]

On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura <tnakamura@openjdk.org> 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 composite fonts. 
> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font \
> was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph \
> was drawn.  
> This patch checks slot data of each character. If slot data exists, it will branch \
> to GlyphVector's drawing path. 
> Well, I couldn't create automatic test for this fix. This method seems to be called \
> for printing only. I appreciate any advice. Tested java/awt and javax/swing on \
> MacOS BigSur, and there was no regression. 
> Regards,
> Toshio Nakamura

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3619


[prev in list] [next in list] [prev in thread] [next in thread]