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

[Bill-McLean]

trafficstars

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

• Version used: OpenType 1.3.3

• Font used: GraphikArabic

• Browser Name and version: Chrome 50 and greater

• Operating System and version (desktop or mobile): MacOS, Linux and Windows

• Link to your project: Using the library with SignAgent.com. It is not a Github project but a private bitbucket project Example.html.zip

[Typogram]

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]

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

[ILOVEPIE]

@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]

@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]

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

[Connum]

@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?