textAlign wrong for Arabic

[munusshih]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build Process
• Unit Testing
• Internalization
• Friendly Errors
• Other (specify if possible)

p5.js version

1.7.0

Web browser and version

chrome://version

Operating System

MacOSX

Steps to reproduce this

Steps:

1. Import any Arabic font through preload()
2. See how it is rendered incorrectly in p5

I personally don't read or write arabic. I just noticed this stackoverflow discussion.

This is heavily related to how opentype.js didn't know how to handle arabic. The only current solution would be, instead of using preload(), use CSS @font-face to render it so that it is drawing through the native HTML Canvas.

[priyankuhazarika]

@munusshih the loadFont() method of p5.js typography section does the same thing as mentioned as one solution in the stackoverflow link (Workaround 1) that you have shared! But the problem here is that, the font is applied only as @font-face css rule, and for the arabic to work i think we have to change the direction css rule to "rtl" and this needs to be applied to the particular html element of the text along with the font-family, because @font-face css rule only loads a particular font, but does not completely applies it to the html elements according to my knowledge!

[davepagurek]

I believe if the user is using a font from loadFont, we don't use the CSS font declaration at all, and rely on OpenType converting the line to paths:

p5.js/src/core/p5.Renderer2D.js

Lines 1267 to 1269 in 558505e

	// an opentype font, let it handle the rendering
	this._textFont._renderPath(line, x, y, { renderer: this });

[munusshih]

@priyankuhazarika @davepagurek
In fact, p5.js exclusively employs opentype.js only when the user explicitly invokes loadFont(). When you load fonts using any other methods, it resorts to rendering the text through the native HTML Canvas API.

That is why in workaround 1, it utilized CSS @font-face. It would not activate opentype.js to function as intended, thus earning it the label of a workaround.

Like I said, apparently this is because opentype.js doesn't support rendering of arabic correctly, which is a known and open issue here: opentypejs/opentype.js#364

[priyankuhazarika]

Hmm might be the case, but i also found this piece of code @munusshih @davepagurek

https://github.com/processing/p5.js/blob/558505e852aacca890d33f1c8f3f5e53d059e9ae/src/typography/loading_displaying.js#L125C3-L134C6

Also opentypejs/opentype.js#364 might be the case, needs further experiments on this!

[davepagurek]

@munusshih pointed out in another issue somewhere that we add that line but then never actually make use of it anywhere else. Relying on it more could be one direction we go in, as it would have better RTL support than opentype! We have some active discussion about that going on here if you're interested: #6391

[priyankuhazarika]

Ohhh i see, thanks for the reference @davepagurek

[dhowe]

would be great to have a range of test cases for this in v2.0