Improvements

[egilll]

Hi. Over at egilll/tex-linebreak2 I've added some features to this excellent project. There is a demo here.

Features:

• Support for negative widths
• Significant speed improvements (mainly due to not using DOM Ranges)
• Breakpoints in accordance with the Unicode line breaking algorithm
• Support for ragged left alignment (possible now that negative widths are supported)
• Hanging punctuation
• Better support for HTML elements:
  • Can now handle display:none and position:absolute elements
  • Will expand the space in inline-block elements
  • Will collapse HTML whitespace in the same way as browsers do (although I haven't tested nested elements)
• Fixes a very annoying and counter-intuitive thing in Knuth's algorithm in which single-word lines were absolutely prohibited (see here)
• A variety of options:
  • Support for custom breaking rules (i.e. patterns describing where not to break)
  • Support for custom space stretching factors
  • Support for making the soft hyphen uncopiable
  • Can forcibly split long words
• Re-renders on window resize
• Fixes issue HTML justification does not handle floats #1 (for most normal purposes): Can handle floating elements (as long as the element doesn't begin in the middle of the text)
• Fixes issue Break points are incorrect if items exactly fill line width #2

There are still many edge cases that I haven't covered and need to write multiple test cases (many of these things, especially regarding HTML, are however quite difficult to test). The fork is still in a state of "work-in-progress".

---

Would you be interested in a pull request? In that case I would try to maintain backwards compatibility with the previous version. Would be interested in hearing your thoughts.

I am aware that this is a somewhat old project, so no problem at all if you do not wish to invest time into this at the moment.

[robertknight]

Hello @egilll,

Your demo looks cool! Thanks for your offer. I welcome contributions that are focused and have good documentation / tests. I'd like the core layout code to remain accessible for educational purposes, which means being judicious about extra options/complexity added there.

What I would suggest to do if you'd like to submit PRs is to start with one or two of the smaller / easier improvements from your list and make PRs specifically for those.

[egilll]

The basic changes here are somewhat difficult to separate, I believe, unless the intention were to merge them all sequentially anyways. While it would be possible to e.g. only add support for Unicode's line breaking algorithm, I wouldn't view it as being useful enough to users by itself given that justifyContent doesn't quite handle whitespace correctly, etc. A major revamp of the helper functions would therefore be in order, which I think would be most pragmatic to cover as a whole.

These changes mainly affect the helper functions and the API, while the core algorithm (breakLines) only really has two changes of note: limitations on negative widths (following the paper) and this change regarding single-word lines.

[robertknight]

The basic changes here are somewhat difficult to separate, I believe, unless the intention were to merge them all sequentially anyways. While it would be possible to e.g. only add support for Unicode's line breaking algorithm, I wouldn't view it as being useful enough to users by itself given that justifyContent doesn't quite handle whitespace correctly, etc. A major revamp of the helper functions would therefore be in order, which I think would be most pragmatic to cover as a whole.

If there are structural changes it might not make sense to chunk up the changes exactly by feature, that's OK. The main point I'm making is that smaller, incremental changes are generally easier to understand and review. So if there is a way to do that, it increases the chances that I can actually integrate and release them. This is especially true given I've only got a limited amount of time in the week for side projects.

These changes mainly affect the helper functions and the API, while the core algorithm (breakLines) only really has two changes of note: limitations on negative widths (following the paper) and this change regarding single-word lines.

Perhaps these two changes to the core algorithm are a good place to start. These certainly sound like something that can be separated from the rest.

[basil]

I backported support for negative widths in #77. In my opinion this is the most important change made in @egill's fork. Backporting this change will allow consumers of this repository's low-level API to implement ragged-right and ragged-centered text.