opentypejs / opentype.js

Read and write OpenType fonts using JavaScript.
https://opentype.js.org/
MIT License
4.45k stars 475 forks source link

Opentype.js outline rendering does not match browser text rendering for the font family GraphikArabic #520

Open Bill-McLean opened 2 years ago

Bill-McLean commented 2 years ago

Expected Behavior

The rendering of a path and text within a browser should be the same. The example provided shows four lines of Arabic. The first two lines are Arabic as rendered by the browser. The third and fourth lines are exactly the same as the first two lines but rendered as path as generated by a call to the getPath(text, fonsSize, options) where the options are set:

let options = {
    kerning: kern,
    features: {
        liga: true,
        rlig: true
    },
    hinting: true
};

Note that the .. character is rendered correctly on the first line and overlaps the previous glyphs (reading right to left).

The rendering by the browser and rendering the path should be the same. There should be an offset between the .. and the previous glyph.

Current Behavior

The inter-character spacing between the .. and the previous glyph needs to match what is happening in the browser.

Possible Solution

Steps to Reproduce (for bugs)

  1. Look at the attached HTML file that references the GraphicArabic font family.

Context

I'm generating SVGs that need to render correctly whether generated with outlined (PATH) text or with embedded text.

Your Environment

Typogram commented 2 years ago

Wondering if this could be caused by kerning info not properly read by OpenType.js? I submitted another issue related to kerning data not read properly by OpenType.js, eg. for a certain font, the AV kerning should be -140 but it is returned as 0 https://github.com/opentypejs/opentype.js/issues/515

Connum commented 1 year ago

Could this be related to #546 @ILOVEPIE, or is it something different?

ILOVEPIE commented 1 year ago

@Connum It could be related to #546 but there's also some other ways that kerning may be implemented that we don't support yet (GPOS type 9 for example).

ILOVEPIE commented 1 year ago

@Connum This is related to us not falling back to another table if GPOS is empty i think, there's another issue on this problem but i can't remember which one.

ILOVEPIE commented 1 year ago

@Bill-McLean try it with the default feature settings for arabic.

Connum commented 10 months ago

@Connum This is related to us not falling back to another table if GPOS is empty i think, there's another issue on this problem but i can't remember which one.

I guess it's #501

@Bill-McLean could you check if this is resolved by #557?