[HarfBuzz] Fwd: Harfbuzz with linebreaking

[Kelvin Ma]

On Mon, Jun 13, 2016 at 10:53 PM, Simon Cozens <simon at simon-cozens.org>
wrote:

> On 14/06/2016 12:42, Kelvin Ma wrote:
> > What I need is something to bridge that gap between the 1-line of
> > unbroken text that harfbuzz generates, and the fragments I need to be
> > able to assemble a multi-line paragraph.
>
> Right. You need that, but it's not Harfbuzz's job. Write some code. :-)
>
> > The only way to get these
> > pieces is to find the spots in the shaped text where the whole line can
> > be shaped in two pieces with an identical result.
>
> Wrong. What you need to find is the potential line breaks. That's not a
> shaping issue specifically; it's a text issue, and needs to be dealt
> with at the text level.


No, this is also a shaping issue and i’ll explain why.

*Take these five sentences which I need to break into a paragraph. The
shaper is always going to be involved in this. Did you only count two?*

It has potential breakpoints here:

|Take |these |five |sen-|ten|-ces |which |I |need |to |break |into |a
|para-|graph. |The |sha-|per |is |al-|ways |go-|ing |to |be |in-|vol-|ved
|in |this. |Did |you |on-|ly |count |two?|

The problem is, I have no idea where, in terms of x-coordinate, any of
these breakpoints are going to be until I shape them. So I will have to
shape the entire sentence.

Then I find that the first glyph that overruns the width of the line is the
‘e’ in “sentences”:

*Take these five sente*

Now I know that I can cut this down to a correct line break by just shaping
the text “*Take these five sen-*” and testing to see if that fits (with the
“safe-to-break” thing, I can probably just keep the old “Take these five
se” glyphs and append a newly shaped “n-”.)

The problem comes with what to do with the text that comes after the
breakpoint. Without “safe-to-break” I have to reshape the *entire*
remainder of the paragraph, the whole text “*tences which I need to break
into a paragraph. The shaper is always going to be involved in this. Did
you only count two?*”. If the paragraph is long, this can be a very long
string. If I had the “safe-to-break” thing, I could find that I could keep
that portion of the originally shaped line, or at worst, maybe have to
reshape a “te” or something and append the old “*nces which I need to break
into a paragraph. The shaper is always going to be involved in this. Did
you only count two?*” to it.

The amount of text that has to be laid out is the entire length of the
paragraph, PLUS *half the entire length of the paragraph times the number
of lines*. That last part is crucial. With “safe-to-break” it’s just the
length of the paragraph, plus a few bits and pieces of fractured text here
and there.


> Taking the example of a ligature, it *is* allowable to break (with
> hyphenation) in the middle of a ligature like "fi". Indeed, your
> justification engine might decide, for the good of the rest of the lines
> in the paragraph, that this is the best place to break. If all you are
> dealing with is the glyph output from Harfbuzz, you won't be able to
> spot that breakpoint.
>
> Once you get into non-Latin scripts, things get worse. Finding
> breakpoints is a matter that depends entirely on the rules of the script
> or language that your text is written in. Right now I'm fighting with
> Javanese, where line breaks are permissible at the end of syllables. You
> need to parse the text, not the glyphs, to determine the appropriate
> breaks. Like others have said: use ICU or similar.
>
> And so you need to deal with two sets of information at the same time:
> the text-level information about breaks, and the shaper-level
> information about glyphs. This is why Harfbuzz returns you an index into
> your text string, so that you can keep those two sets of information in
> sync. The hard part of writing a typesetting system is dealing with the
> interplay between those two representations of a text.
>

You are right. But I hope I explained why the shaping information has to
come before the textual-breakpoint information, because without shaping,
you don’t know *where* the breakpoints lie, and if you don’t know where
they lie, they don’t function as breakpoints anymore.


>
> It took me quite a while to get my head around this, and a lot of help
> from others. You can see the record of me banging my head against this
> particular wall at https://github.com/simoncozens/sile/issues/179 ,
> which has a nice explanation of the issues involved.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/harfbuzz/attachments/20160613/2d35397f/attachment.html>