8360136: RFE: Add TextAttributes for OpenType font figure style features

[VISTALL]

Introducing to API constants, and implementation for controlling Figure Styles

Target font: Inter

Example screenshot

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires a CSR request matching fixVersion 26 to be approved (needs to be created)

Issue

• JDK-8360136: RFE: Add TextAttributes for OpenType font figure style features (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26144/head:pull/26144
$ git checkout pull/26144

Update a local copy of the PR:
$ git checkout pull/26144
$ git pull https://git.openjdk.org/jdk.git pull/26144/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26144

View PR using the GUI difftool:
$ git pr show -t 26144

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26144.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

Hi @VISTALL, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user VISTALL" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[VISTALL]

/issue JDK-8360136

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@VISTALL The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[openjdk]

@VISTALL This issue is referenced in the PR title - it will now be updated.

[VISTALL]

/signed

[bridgekeeper]

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[VISTALL]

/signed

[bridgekeeper]

You are already a known contributor!

[mlbridge]

Webrevs

• 02: Full - Incremental (7767aaa0)
• 01: Full - Incremental (0bb773d0)
• 00: Full (a3b6912e)

[prrace]

Even if there's no easy way to verify it, there should be a test that at least uses these new values.

Also we need a CSR for this.

[prrace]

True. So at an API level, should it be allowed to specify both at the same time ?
Perhaps instead the attribute should be called FIGURE_WIDTH and have values of PROPORTIONAL and TABULAR
But what about the other figure related 'standard' opentype features : lining and old style ?

https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#lnum
https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#onum

They are the same idea but it affects height / vertical positioning instead of width

So do we add FIGURE_HEIGHT too with values of LINING and OLDSTYLE ?

Or .. do we add
FIGURE_STYLE and provide the combinations like
TABULAR_LINING and PROPORTIONAL_OLDSTYLE ?

There'd be 16 values so I am not sure about that.
May be have the WIDTH and HEIGHT options and let people select the pairs they want.
Also it means if they 'don't care" about one or the other they can just not set it instead of thinking.

[VISTALL]

Hello. Main idea - is to provide access to control this features in a simple way, without modification native & java too much.

Conflict described only in JavaDoc since - I don't want add special throws inside Font constructor with this options.

About what you say. Yes - I thought about that, but it's too big change.

For example - will be nice move control hb features control from C++ code to Java. For now it's controlled by flags, and not flexable.

What do you think about this api:

// internal api in sun.font

// enum for better control values, since there no sense give access to set 3,4,5+ values
public enum EFigureWidth {
    // unset? unknown? undefined?
    UNSET,
    PROPORTIONAL_FIGURES, // pnum=1
    TABULAR_FIGURES       // tnum=1
}

// public api
public class TextAttribute {

    public static final TextAttribute FIGURE_WIDTH = new TextAttribute("figure-width");

    public static final Object FIGURE_WIDTH_UNSET = EFigureWidth.UNSET;
    
    public static final Object FIGURE_WIDTH_TABULAR = EFigureWidth.TABULAR_FIGURES;

    public static final Object FIGURE_WIDTH_PROPORTIONAL = EFigureWidth.PROPORTIONAL_FIGURES;

    // same for figure height
}

[prrace]

/csr

[openjdk]

@prrace has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@VISTALL please create a CSR request for issue JDK-8360136 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[prrace]

I have changed the bug summary so you will need to change the PR summary to match -
8360136: RFE: Add TextAttributes for OpenType font figure style features

[openjdk]

@VISTALL Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

[VISTALL]

Sure. My mistake

[VISTALL]

@prrace about tests. I can draw test image with font which is support tnum feature, and validate without it. Primitive one.

For example

• at start - need load font, which supports this features. For example Inter (also need attach license of it inside repo?)
• draw image 0123456789 with pnum
• 
• draw image 0123456789 with tnum
• 
• if all bytes of images equals - it's means tnum not works.

Also check default instance of Font without options

We can add this images inside repo, and validate image drawing (not sure)

[YaaZ]

Given that this needs to go through specification review anyway, I suggest to consider the more general solution with passing arbitrary OpenType features instead of a few more attributes. This would definitely be beneficial for other AWT users.
We have similar functionality implemented in JBR after requests of JetBrains users, wanting to customize their font appearance: JetBrains/JetBrainsRuntime@a2900b0

[YaaZ]

@VISTALL You can take a look at https://github.com/openjdk/jdk/blob/bcd86d575fe0682a234228c18b0c2e817d3816da/test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java - it has a good example of synthetic font generated specifically for the test and embedded into the test as base64. This avoids the hussle with licences and whatnot.
I would also suggest to avoid golden-image tests, as those tend to be burdensome to maintain. But in your case you can probably inspect line metrics and compare the widths of a sample text.

[VISTALL]

@YaaZ Thanks for example. About API. Will be good to make universal api - but I think it's too big task will be.

Maybe introduce api like nio2 - CopyOption* etc.

for example

interface FontFeature<V> (FontExtension?) {
   // some code
}

// V is Integer? or delegate to impl
class OpenTypeFontFeature implements FontFeature<Integer > {
   OpenTypeFontFeature (String name) {
   }
}

public final class OpenTypeFontFeatures {
    FontFeature<Integer> TABULAR_NUMBERS = new OpenTypeFontFeature<> ("tnum");
} 

There few questions:

• conflicting features?
• need method Font#supportsFeature(FontFeature) ?
• need opentype class? or utilize to default font naming? (eg FontFeatureImpl)
• need make public OpenTypeFontFeature class? (accesing from clients)
• FontFeature will be extends TextAttribute?