experimental patch: zero width space (Thai, Lao, Cambodian...)
I just learned that some languages don't use spaces but can only break in certain places, and that they tend to insert Zero Width Space to make life easier for software that doesn't know the complex rules. So here's a quick little patch for them: http://www.dillo.org/test/zero_width_space.patch PS I did just start trying to move the ideographic test to dw, but I got stuck when I realized that I can't exactly call fltk's utf8decode() directly in Textblock, and am not excited by the idea of calling it through Layout.
On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote:
I just learned that some languages don't use spaces but can only break in certain places, and that they tend to insert Zero Width Space to make life easier for software that doesn't know the complex rules.
So here's a quick little patch for them: http://www.dillo.org/test/zero_width_space.patch
Looks good to me, but do we really need to add a space? Wouldn't it be enough to just start a new word? At least dw-example seems to wrap words with textblock->addSpace(wordStyle); commented out.
PS I did just start trying to move the ideographic test to dw, but I got stuck when I realized that I can't exactly call fltk's utf8decode() directly in Textblock, and am not excited by the idea of calling it through Layout.
I think we could make the utf8 methods in fltkplatform.cc static members. Cheers, Johannes
Johannes wrote:
On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote:
I just learned that some languages don't use spaces but can only break in certain places, and that they tend to insert Zero Width Space to make life easier for software that doesn't know the complex rules.
So here's a quick little patch for them: http://www.dillo.org/test/zero_width_space.patch
Looks good to me, but do we really need to add a space? Wouldn't it be enough to just start a new word? At least dw-example seems to wrap words with textblock->addSpace(wordStyle); commented out.
I was thinking that it would be good to remember that it's there so that the iterator could be made to do the right thing for copying and pasting text, but maybe that's too much of a picky corner case akin to soft hyphens. (And maybe stripping them out would make life simpler for findtext anyway.)
PS I did just start trying to move the ideographic test to dw, but I got stuck when I realized that I can't exactly call fltk's utf8decode() directly in Textblock, and am not excited by the idea of calling it through Layout.
I think we could make the utf8 methods in fltkplatform.cc static members.
In this case, that would save us... carrying along a this pointer that we weren't using? Does it save an indirection? (in any case, maybe I should static-ize all of our current fltkplatform functions that just call fltk functions)
On Tue, Sep 29, 2009 at 07:30:22PM +0000, corvid wrote:
Johannes wrote:
On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote:
I just learned that some languages don't use spaces but can only break in certain places, and that they tend to insert Zero Width Space to make life easier for software that doesn't know the complex rules.
So here's a quick little patch for them: http://www.dillo.org/test/zero_width_space.patch
Looks good to me, but do we really need to add a space? Wouldn't it be enough to just start a new word? At least dw-example seems to wrap words with textblock->addSpace(wordStyle); commented out.
I was thinking that it would be good to remember that it's there so that the iterator could be made to do the right thing for copying and pasting text, but maybe that's too much of a picky corner case akin to soft hyphens. (And maybe stripping them out would make life simpler for findtext anyway.)
Hm, don't know what's better...
PS I did just start trying to move the ideographic test to dw, but I got stuck when I realized that I can't exactly call fltk's utf8decode() directly in Textblock, and am not excited by the idea of calling it through Layout.
I think we could make the utf8 methods in fltkplatform.cc static members.
In this case, that would save us... carrying along a this pointer that we weren't using? Does it save an indirection?
(in any case, maybe I should static-ize all of our current fltkplatform functions that just call fltk functions)
Wait. Making them static is not a good idea. Currently we could have different platforms in a single process and the right methods would be called. Are you concerned about speed or readability? Cheers, Johannes
Johannes wrote:
On Tue, Sep 29, 2009 at 07:30:22PM +0000, corvid wrote:
Johannes wrote:
On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote:
PS I did just start trying to move the ideographic test to dw, but I got stuck when I realized that I can't exactly call fltk's utf8decode() directly in Textblock, and am not excited by the idea of calling it through Layout.
I think we could make the utf8 methods in fltkplatform.cc static members.
In this case, that would save us... carrying along a this pointer that we weren't using? Does it save an indirection?
(in any case, maybe I should static-ize all of our current fltkplatform functions that just call fltk functions)
Wait. Making them static is not a good idea. Currently we could have different platforms in a single process and the right methods would be called. Are you concerned about speed or readability?
It sounded slow to go through layout, but then we do our share of nextGlyph, textWidth, etc, and haven't died from it. Maybe it's time to get gprof out again anyway.
participants (2)
-
corvid＠lavabit.com -
Johannes.Hofmann＠gmx.de