https://bugs.freedesktop.org/show_bug.cgi?id=70666
--- Comment #13 from László Németh <nem...@numbertext.org> --- (In reply to comment #12) > On Fri, 04 Apr 2014 12:12:38 +0000 > bugzilla-dae...@freedesktop.org wrote: > > > https://bugs.freedesktop.org/show_bug.cgi?id=70666 > > > > --- Comment #9 from László Németh <nem...@numbertext.org> --- > > Martin: I have forgot to use the original gr_count_unicode_characters() in > > my > > last patch. It works well, but is there a performance issue here? > > > > [Also I am very interested in the word and line end dependent font features, > > yet. Maybe I have to add an extra space here to fix the explicit space > > related > > italic correction feature of Linux Libertine G.] > > > > > mst__ 13.45.40 > > nemeth, hello do i see it right that > > https://bugs.freedesktop.org/show_bug.cgi?id=70666 is fixed only on master > > but > > not release branches? any reason why not? > > > mst__: It seems, I have forgot it. (Precisely, I had an idea to change my > > > last patch to add the Graphite Unicode helper function, as in the > > > original code of Martin Hosken, maybe it would be an optimization, but I > > > haven’t done it. I will ask Martin in the issue.) > > If you are using UTF16, it is still worth using the > gr_count_unicode_characters() in case there are any surrogate pairs in the > text. If there are none, then the character count is the same as the number > of words, but if there are any surrogate pairs then the count will be less > than the number of words. In addition, the text reading code is strict about > using the number of characters passed in. So if your number is too high, it > will try to read beyond the end of the string even if there is a guard NULL > there. > > BTW in case folks are feeling edgy about graphite's speed, there is special > speedup code in there such that, for example, if you use Charis with plain > old ASCII text, it will execute twice as fast as the new harfbuzz. OK, so to > get that kind of speedup one does have to think about about one's gdl, but > it's not that hard. And even without the speed up, it's about the same > speed. gr_count_unicode_characters() is no slouch either. > > Yours, > Martin Martin, many thanks for your explanation! It seems, OUString of LibreOffice is based on UTF-16, so I will restore gr_count_unicode_characters() call (as I planned), combined with the hyphenation fix. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
