Hi, is it correct that we use a soft hyphen (0xc2 0xad) to draw the hyphen when breaking words? It seems to draw ok with fltk/X11, but wouldn't an unconditional hyphen 0xE2 0x80 0x90 be more correct? I'm asking because e.g the Apple drawing library doesn't seem to draw the soft hyphen if it thinks there should be no line break. Cheers, Johannes
On Mon, Nov 26, Johannes Hofmann wrote:
is it correct that we use a soft hyphen (0xc2 0xad) to draw the hyphen when breaking words? It seems to draw ok with fltk/X11, but wouldn't an unconditional hyphen 0xE2 0x80 0x90 be more correct? I'm asking because e.g the Apple drawing library doesn't seem to draw the soft hyphen if it thinks there should be no line break.
I see no problem with using unconditional breaks, and it seems to work well with fltk/X11, so I've pushed the changes to hg.dillo.org. (BTW: unconditional hyphens should also added do dillo_hyphen.) Sebastian
I just wanted to mention that if you compile with -pedantic, it complains like textblock.cc:941:22: warning: overflow in implicit constant conversion [-Woverflow] about text[p++] = 0xe2; text[p++] = 0x80; text[p++] = 0x90;
On Mon, Nov 26, corvid wrote:
I just wanted to mention that if you compile with -pedantic,
I get 633 warnings when I compile with -pedantic. :-)
it complains like
textblock.cc:941:22: warning: overflow in implicit constant conversion [-Woverflow]
about
text[p++] = 0xe2; text[p++] = 0x80; text[p++] = 0x90;
I don't know how to deal best with this, but following change seems to work: text[p++] = '\xe2'; text[p++] = '\x80'; text[p++] = '\x90'; Sebastian
Sebastian wrote:
On Mon, Nov 26, corvid wrote:
I just wanted to mention that if you compile with -pedantic,
I get 633 warnings when I compile with -pedantic. :-)
Yeah, I went through maybe a month ago and fixed a few assorted ones, but the rest fell into a couple of categories that seemed best left alone...
On Tue, Nov 27, 2012 at 06:22:34PM +0100, Sebastian Geerken wrote:
On Mon, Nov 26, corvid wrote:
I just wanted to mention that if you compile with -pedantic,
I get 633 warnings when I compile with -pedantic. :-)
it complains like
textblock.cc:941:22: warning: overflow in implicit constant conversion [-Woverflow]
about
text[p++] = 0xe2; text[p++] = 0x80; text[p++] = 0x90;
I don't know how to deal best with this, but following change seems to work:
text[p++] = '\xe2'; text[p++] = '\x80'; text[p++] = '\x90';
I know, I brought this up in the first place, but now I noticed, that the unconditional hyphen (0xe2 0x80 0x90) seems not be available in all fonts (e.g. I only see squares for it on heise.de). So maybe a hyphen-minus aka '-' might be simpler and commonly available (also see [1]). What do you think? Cheers and sorry for the confusion, Johannes [1] http://www.cs.tut.fi/~jkorpela/dashes.html
Johannes wrote:
I know, I brought this up in the first place, but now I noticed, that the unconditional hyphen (0xe2 0x80 0x90) seems not be available in all fonts (e.g. I only see squares for it on heise.de). So maybe a hyphen-minus aka '-' might be simpler and commonly available (also see [1]). What do you think?
hyphen-minus sounds safest to me. I wish we had a good way to deal with the squares...
On Tue, Nov 27, corvid wrote:
Johannes wrote:
I know, I brought this up in the first place, but now I noticed, that the unconditional hyphen (0xe2 0x80 0x90) seems not be available in all fonts (e.g. I only see squares for it on heise.de). So maybe a hyphen-minus aka '-' might be simpler and commonly available (also see [1]). What do you think?
hyphen-minus sounds safest to me.
What about making it configurable, with hyphen-minus as default?
I wish we had a good way to deal with the squares...
One could think of testing which character is available, and so switch to other characters, but probably this is unnecessarily complex. Sebastian
Sebastian wrote:
On Tue, Nov 27, corvid wrote:
Johannes wrote:
I know, I brought this up in the first place, but now I noticed, that the unconditional hyphen (0xe2 0x80 0x90) seems not be available in all fonts (e.g. I only see squares for it on heise.de). So maybe a hyphen-minus aka '-' might be simpler and commonly available (also see [1]). What do you think?
hyphen-minus sounds safest to me.
What about making it configurable, with hyphen-minus as default?
In general, it feels a little unusual to have so much configuration related to hyphenation specifically, but...
I wish we had a good way to deal with the squares...
One could think of testing which character is available, and so switch to other characters, but probably this is unnecessarily complex.
Is there a way to do that?
On Wed, Nov 28, corvid wrote:
Sebastian wrote:
On Tue, Nov 27, corvid wrote:
Johannes wrote:
I know, I brought this up in the first place, but now I noticed, that the unconditional hyphen (0xe2 0x80 0x90) seems not be available in all fonts (e.g. I only see squares for it on heise.de). So maybe a hyphen-minus aka '-' might be simpler and commonly available (also see [1]). What do you think?
hyphen-minus sounds safest to me.
What about making it configurable, with hyphen-minus as default?
In general, it feels a little unusual to have so much configuration related to hyphenation specifically, but...
See my latest change. Could be made configurable in a simple way.
I wish we had a good way to deal with the squares...
One could think of testing which character is available, and so switch to other characters, but probably this is unnecessarily complex.
Is there a way to do that?
If there is a way, it is probably still quite much work. Certainly not something for the next release. Sebastian
participants (3)
-
corvid＠lavabit.com -
Johannes.Hofmann＠gmx.de -
sgeerken＠dillo.org