Composite fonts are imperfect. Hence exclusion ranges
which create other problems. And monospaced fonts, well, aren't ..
But I think opentype layout likes to take as much as it can from the
same font, and other cases should be the same. If VS were common
you might say otherwise.. or make sure the VS enabled font were the
preferred one. But we can leave it as is until we see a problem in practice.
-phil.
On 6/20/18, 4:47 PM, Toshio 5 Nakamura wrote:
Hi Phil,
Thank you for your comments.
That situation (mixing fonts by characters) sometimes
occurs in Japanese environment, and I naturally thought
displaying specified glyph has priority.
For example, a composite font has
FontA (contains Japanese Kanji Level 1/2 (basic)) and
FontB (contains Kanji Level 1/2/3/4 (basic+extension)).
Then, if using a Kanji Level 3 character among Kanji
Level 1/2 characters, FontB appears among FontA.
The behavior of composite font with VS is not described
in Unicode Standard. I'm not sure which behavior should
be chosen.
Best regards,
Toshio Nakamura
Inactive hide details for Phil Race ---2018/06/20 05:38:24---On
06/18/2018 10:28 AM, Toshio 5 Nakamura wrote: >Phil Race ---2018/06/20
05:38:24---On 06/18/2018 10:28 AM, Toshio 5 Nakamura wrote: >
From: Phil Race <philip.r...@oracle.com>
To: Toshio 5 Nakamura <toshi...@jp.ibm.com>, "Steven R. Loomis"
<s...@icu-project.org>
Cc: 2d-dev <2d-dev@openjdk.java.net>, srl...@gmail.com
Date: 2018/06/20 05:38
Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
Selectors(Resend)
------------------------------------------------------------------------
On 06/18/2018 10:28 AM, Toshio 5 Nakamura wrote:
Hi Phil,
Thank you very much for your great comments.
I tried to handle your comment as much as I could. Could you
kindly rereview it?
(So far, it contains only our contribution.)
> Updated webrev 02
_http://cr.openjdk.java.net/~srl/8187100/webrev.02/_
<http://cr.openjdk.java.net/%7Esrl/8187100/webrev.02/>
The following points were not directly applicable. I'd like to
explain them.
- Performance concern of fast path
We'd like to handle direct drawing such as
Graphics2D.drawString, and layout is not used in this case.
I tired to separate the original methods and VS capable ones
to minimize a impact.
Only if VS character appears, VS capable method will be called.
right and I was saying in my email of 11th June, that your way of
detecting if a VS char is there could be more efficient
It is somewhat improved in this update ..
(except FontRunIterator.java:next, which uses a member
variable and couldn't use that way.)
- Complex code of CMap
Composite fonts need to search a glyph by two steps.
1 - Search VS specific glyph in each composed font.
2 - If it's not available in all fonts, search a glyph without VS.
I changed getGlyph method with allowFallback parameter,
hope it clears our purpose.
I believe that if you are looking for a glyph for (say) U+NNNN then it
should always come
from the same slot of a composite font whether a variation selector is
specified or not.
Otherwise you may get glyphs with variations from a different font
than the glyphs from
the same script without variations and that may look very wrong.
So I am not sure about that and maybe we'll change it in the future.
I am running some general font tests to make sure this does not break
anything,
If that passes OK then we should be OK.
-phil.
- isVariationSelector for two blocks
VS characters are U+FE00-U+FE0F and U+E0100-U+E01FF.
The latter is represented by Surrogate pair in a char array.
My previous code named the same for them, and it may cause a
confusion.
I updated the names to isVariationSelectorBMP and
isVariationSelectorExt.
Steven,
Thank you for your kind support.
Best regards,
Toshio Nakamura, IBM Japan
Inactive hide details for "Steven R. Loomis" ---2018/06/19
02:02:35---Updated webrev 02
https://urldefense.proofpoint.com/v2/ur"Steven R. Loomis"
---2018/06/19 02:02:35---Updated webrev 02 _INVALID URI
REMOVED_ <INVALID%20URI%20REMOVED>
From: "Steven R. Loomis" _<s...@icu-project.org>_
<mailto:s...@icu-project.org>
To: Toshio 5 Nakamura _<toshi...@jp.ibm.com>_
<mailto:toshi...@jp.ibm.com>
Cc: Philip Race _<philip.r...@oracle.com>_
<mailto:philip.r...@oracle.com>, 2d-dev
_<2d-dev@openjdk.java.net>_ <mailto:2d-dev@openjdk.java.net>
Date: 2018/06/19 02:02
Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support
Variation Selectors(Resend)
Sent by: _srl295@gmail.com_ <mailto:srl...@gmail.com>
------------------------------------------------------------------------
Updated webrev 02
_http://cr.openjdk.java.net/~srl/8187100/webrev.02/_
<http://cr.openjdk.java.net/%7Esrl/8187100/webrev.02/>
On Thu, May 31, 2018 at 3:19 PM, Steven R. Loomis
<_srl@icu-project.org_ <mailto:s...@icu-project.org>> wrote:
Updated webrev:
_
__http://cr.openjdk.java.net/~srl/8187100/webrev.01/_
<http://cr.openjdk.java.net/%7Esrl/8187100/webrev.01/>
On Fri, May 18, 2018 at 9:16 AM, Toshio 5 Nakamura
<_toshi...@jp.ibm.com_ <mailto:toshi...@jp.ibm.com>>
wrote:
Thank you for your review, Phil.
I'm working to handle your points.
Toshio Nakamura
Philip Race <_philip.race@oracle.com_
<mailto:philip.r...@oracle.com>> wrote on 2018/05/18
13:39:35:
> From: Philip Race <_philip.race@oracle.com_
<mailto:philip.r...@oracle.com>>
> To: Toshio 5 Nakamura <_toshi...@jp.ibm.com_
<mailto:toshi...@jp.ibm.com>>
> Cc: 2d-dev <_2d-...@openjdk.java.net_
<mailto:2d-dev@openjdk.java.net>>
> Date: 2018/05/18 13:39
> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100:
support Variation
> Selectors(Resend)
>
> There's a lot to think about here but I have some
requests to first
> clean up the proposed code to conform to coding
standards.
>
> I see lots of lines > 80 chars. Please fix
>
> I see if(foo){ and else{ which should be "if (foo)
{" and "else {"
>
> Basically always have a space before { and after )
and around "=" and "=="
>
> One line that WAS
> 51 hb_codepoint_t u = (variation_selector==0)
? unicode :
> variation_selector;
>
> has no spaces around "==" almost certainly to avoid
going over 80 chars.
> Now you've broken the line you can fix that.
>
> Eliminate all wild card imports and import exactly
what is needed.
> Maybe this is only about the test.
>
> remove what looks like SCCS style comments on the
@test line.
> Make the test simply print a warning if the person
didn't install
> fonts where you expected.
> Why? Because @ignore defaults to .. not being ignored.
>
> For the JNI methods calls read the spec and see if
calling them may
> throw an exception
>
> I'm looking at sequences like
> env->SetIntArrayRegion(unicodes, 0, 2, tmp);
> 71 env->CallVoidMethod(font2D,
> sunFontIDs.f2dCharsToGlyphsMID, 2, unicodes, results);
> 72 env->GetIntArrayRegion(results, 0, 2, tmp);
> 73 *glyph = tmp[0];
> 74 cleanup:
> 75 if (unicodes != NULL)
env->DeleteLocalRef(unicodes);
> 76 if (results != NULL)
env->DeleteLocalRef(results);
>
> If call GetIntArrayRegion may leave a pending
exception it needs to
> be checked and cleared
> before you make another call.
>
> Look at the performance implications of things like
the extra
> work done now in FontUtilities.isSimpleChar() and
see how to minimise
> it since it could affect all text rendering in a way
that is measurable
> in at least some way.
>
> I idly wonder if
>
>
> public static boolean isBaseChar(int
charCode){ ...
>
> might be more cleanly or efficiently implemented
with a switch ?
>
> Not sure.
>
> -phil.
>
> On 5/14/18, 1:28 AM, Toshio 5 Nakamura wrote:
> Could someone review our proposal to support Unicode
Variation Selectors?
> > Bug:
_https://bugs.openjdk.java.net/browse/JDK-8187100_
> > Webrev:
_http://cr.openjdk.java.net/~srl/8187100/webrev.00/_
<http://cr.openjdk.java.net/%7Esrl/8187100/webrev.00/>
>
> Toshio Nakamura
>
> > From: "Steven R. Loomis" <_srl295@gmail.com_
<mailto:srl...@gmail.com>>
> > To: 2d-dev <_2d-...@openjdk.java.net_
<mailto:2d-dev@openjdk.java.net>>
> > Date: 2018/05/03 03:27
> > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100:
support Variation
> > Selectors (Resend)
> > Sent by: "2d-dev"
<_2d-dev-boun...@openjdk.java.net_
<mailto:2d-dev-boun...@openjdk.java.net>>
> >
> > I added a screenshot to
_https://bugs.openjdk.java.net/browse/JDK-8187100_
> > if anyone wants to see what the impact of this fix is
> >
> > On Wed, Apr 25, 2018 at 8:39 AM, Steven R. Loomis
<_srl295@gmail.com_ <mailto:srl...@gmail.com>> wrote:
> > (Retrying as actual text)
> >
> > Support Unicode Variation Selectors.
> >
> > Code by my colleague Toshio Nakamura, I added a
simple test, and
> > include a test that was part of JDK 8187100. (Both
tests are run manually.)
> >
> > Bug:
_https://bugs.openjdk.java.net/browse/JDK-8187100_
> > Webrev:
_http://cr.openjdk.java.net/~srl/8187100/webrev.00/_
<http://cr.openjdk.java.net/%7Esrl/8187100/webrev.00/>
> >
> > On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote:
> > >
> > > Hello
> > >
> > > IBM would like to propose Unicode Variation
Selector[1] capability to AWT
> > > and Swing components.
> > > (This proposal was posted to i18n-dev first, and
I got a suggestion to
> > > discuss
> > > in 2d-dev.)
> > >
> > > This proposal changed the following files:
> > > src/java.desktop/share/classes/sun/font/CMap.java
> > >
src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java
> > >
src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java
> > > src/java.desktop/share/classes/sun/font/Font2D.java
> > >
src/java.desktop/share/classes/sun/font/FontRunIterator.java
> > >
src/java.desktop/share/classes/sun/font/FontUtilities.java
> > >
src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java
> > >
src/java.desktop/share/native/common/font/sunfontids.h
> > >
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc
> > >
src/java.desktop/share/native/libfontmanager/sunFont.c
> > >
src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java
> > > 542 lines will be changed.
> > >
> > > There are three parts.
> > > 1) Adding CMap format 14 support
> > > 2) Adding CharsToGlyphs functions support
Variation Selector Sequences
> > > 3) Swing text component's DEL and BS key
operations change
> > >
> > >
> > > How would I go about obtaining a sponsor?
> > >
> > > [1]
__http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf__
> > > Chapter 23.4 Variation Selectors
> > >
> > > Best regards,
> > >
> > > Toshio Nakamura
> > > IBM Japan
> >
