[dwrite] Provide an experimental API for justification

[ebraminio]

This is just created to start brain storming around the way we could have some initial justification API of at least directwrite backend on harfbuzz.

Ideally, from the start, we should think about how current harfbuzz can be developed in a way to provide a justification API that would be possible to be integrated with caching word shapers solutions where the "line" concept itself is less relevant...

Obviously harfbuzz API differs from paragraph like API such as DirectWrite and that's why integrating justification with the current state of harfbuzz and its clients usage needs some considerate and innovative thinking :)

[ebraminio]

@behdad: Lets change direction of this and assume we just want to have some way to set lineWidth, what do you suggest for the name of API to show it meant to be experimental and will likely be broken in future and where lineWidth parameter should go, inside font_data or face_data or buffer?

[ebraminio]

This has failed to gain any attention around and as I used master branch for the pull request, it somehow blocks my other patches so let's close it for now.

[behdad]

@behdad: Lets change direction of this and assume we just want to have some way to set lineWidth, what do you suggest for the name of API to show it meant to be experimental and will likely be broken in future and where lineWidth parameter should go, inside font_data or face_data or buffer?

The way I always thought about justification is that we will have a different hb_shape() call that takes a desired-width parameter, and perhaps a justification-strategy...

[khaledhosny]

The bigger problem, IMHO, is how the clients will use such an API? If you have more than one run per line, how do you distribute the desired width on them and what if some runs can be stretched more than the others. It gets even more interesting for applications doing (variation of) Knuth and Plass whole paragraph justification, who will need to know the stretchability and shrinkability of each run (word?) before doing the line breaking.

[ebraminio]

The way I always...

Is it now more similar (hb_shape_dwrite_experimental_width) to what it should be?

The bigger problem, ...

Indeed it is, lets not call it "lineWidth" but fragment width, aren't clients able to pass some destined widths at least on second round of shaping? We don't have concept of line and paragraph so that is the only thing I can think about to move forward. I know [not very surely of course] clients like Chromium are currently doing two or more steps shaping, first for measuring and line breaking then for actual shaping which performance is improved by caching word shaping of the fonts that don't involve space on GPOS table or such but if a client destinies to have [kashida] justification, second round of full shaping is something worth to do I guess for it anyway.

The idea here however is to first provide some way to play with directwrite API of justification, specially, kashida justification.

[ebraminio]

It gets even more interesting for applications doing (variation of) Knuth and Plass whole paragraph justification, who will need to know the stretchability and shrinkability of each run (word?) before doing the line breaking.

I didn't think about that of course, I guess that would be something we should ignore for now 😅 (or let clients to somehow figure out based on changed widths if is possible)

[behdad]

It's a hard problem indeed, and that's why no one has implemented it properly so far...

Last time I talked to @jfkthame, our conclusion was that clients will probably want to shape normally first, decide line break, then reshape the runs in the line, with prorated width per run and adjust as they reshape. Something as handwavy as that...

[ebraminio]

Can we merge this Behdad? Since hb-directwrite is not provided on releases this is not a harmful thing to have I guess. I should also note that result of justification itself is far from perfect and the intention of the API is not providing it to hb clients, just like the development of the backend as whole.

[behdad]

Feel free to merge. Thanks.