In article <[email protected]>, Chris Young <[email protected]> wrote: > On Mon, 11 Feb 2013 00:10:08 +0000 (GMT), Michael Drake wrote:
> > For example, see: > > http://www.netsurf-browser.org/welcome/index.ja > > If you only split at spaces, that paragraph will only ever be one long > > line. (There are no spaces to split on.) > Which it is here. Indeed. It always has been on all platforms. Until now, the GTK front end was paying the performance price of proper Unicode handling, but then it had to search back the string from that point to find a space to satisfy the API constraint. (Then it had to measure the width of what it actually ended up deciding to split at.) > I don't see why all this needs to be in the frontend. It stops the core from preventing any perfectly good Unicode line breaking available in the front end. > The core can do all that. Sure. But the HTML layout code needed fixing to handle splits on non-space characters anyway. Now that that is done, it was trivial to add full Unicode line breaking support on platforms that provide it, so I did. In the long term we'll get it working everywhere, but it's not going to happen right now. > Advantages: > * nsfont_split is no longer needed (core can use > nsfont_position_in_string and nsfont_width) Position in string should find the offset nearest the passed coordinate. So if you click on the left hand side of a letter 'm', then the caret is placed to the left, and on the right, the right. nsfont_split is looking for a point less than an available width as priority. > * Consistent splitting behaviour across all platforms - splitting on > characters other than space only needs to be added once That once will be a lot of developer effort. > * More complex splitting could be added, for example splitting > mid-word and hyphenating depending on language rules We need to implement the Unicode line breaking algorithm: http://www.unicode.org/reports/tr14/ > Disadvantage: > nsfont_width might need to be called in addition to > nsfont_position_in_string. There's a potential speed penalty if the > actual width post-split is needed by the core, depending on the > current implementations of nsfont_split, although I can't see why it > would need that information very frequently (only if it reaches #6?) It always needs the actual width of the text post-split. In the HTML handler, the text box is actually split into two boxes. (See how underlines on e.g. hyperlinks break at spaces after the space has been used for a line break.) The width of the split box is needed because when the page reflows, it uses the cached box width for layout decisions and positioning. -- Michael Drake (tlsa) http://www.netsurf-browser.org/
