Support 'justified' alignment as an option for textAlign

[dhowe]

Support 'JUSTIFIED' alignment as an option for textAlign(), so that we can have text that looks like below. Note: we would need to check that the optional 'width' param was specified to text() when using this alignment. If I remember correctly there is an nice dynamic programming solution to this problem.

[rdslade]

Planning to work on this issue!

[dhowe]

Great. Note that in some of the approaches discussed online, extra space characters are added to extend the line, however this is not what we want here - rather we need to adjust the start position of each word

[aditya-shrivastavv]

Does anybody have an idea on how to implement this

[dhowe]

There is a somewhat well-known algorithm for this by Knuth/Plass (included in TeX/LaTeX) that uses dynamic programming - you can read about it here. There are also existing js libraries (here is one) that implement it, though I haven't tried any...

[aditya-shrivastavv]

I found a new way of doing it. since we have opentype.js library already being used in the project we can make use of it's letter spacing method if possible.
check here - opentypejs/opentype.js#219

[aditya-shrivastavv]

@davepagurek @dhowe should i try to implement this leetcode question's algorithm here ?

[davepagurek]

@aditya-shrivastavv I think something like that would be good, specifically the approach of first placing words into each line until they no longer fit before breaking to the next line. However, for us, width is based on pixels rather than characters. Then, rather than padding with spaces to reach a total character count, we would split lines on spaces and position the x value of each word so that they are evenly spaced, with the first word is aligned with the left of the block and the last word of the line is aligned with the right of the block.

[dhowe]

a few things to note:

• we may also need to test that we get similar alignment when using the DOM's text-justify property with the inter-word property
• we may also want to measure the performance hit for rendering each word separately, as we don't want sketches to slow down when a user switches to 'justified' alignment from some other method
• we may also want to specify what happens when a line (for example, with very few words) ends up with very large spaces
• also, while the greedy approach is a good exercise, it results in noticeably less optimal lines than the approach I've linked above, at least for the inter-character case (not sure about inter-word, but my intuition is that it would be similar) - some more info on the tradeoffs

[davepagurek]

For performance, from my own testing, I've found that rendering in smaller chunks can be fine as long as we avoid push/pop, which saves and restores a fair amount of state. So this could mean keeping track of incremental position changes and then manually resetting with a translate. Anyway, agreed, it's a good thing to keep in mind and measure!

[limzykenneth]

Just to mention, we may need to take into account hyphenated word break or quite often justified text would look quite weird with large gaps between words or characters. That will require its own algorithm as well if we want to do it properly as there are specific rules around how English word should be broken up with hyphens, and that's also not considering other languages and scripts as well.

Ideally there is a library or even browser API that can do all the implementation for us so we don't have to start from scratch.

[dhowe]

This library seems to do all of what we need, including handling hyphenization, as @limzykenneth correctly notes, but it would require non-trivial testing to make sure it can be integrated smoothly with our existing text-rendering routines

[munusshih]

I almost feel like instead of relying on another library, we can probably hard code something like this: https://riptutorial.com/html5-canvas/example/19482/justified-text

But then at the same time, I feel like incorporating this might requires more discussions and thinking.
One of the issues with the library suggested by @dhowe is that it's using another library hyphen which only supports English right now. I've test it on Mandarin and Arabic, and it didn't seem to work on neither of them.