- Dillo-dev - lists.mailman3.com

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

Jorge wrote: > On Sat, Jun 06, 2009 at 06:36:43AM +0000, corvid wrote: > > I wrote: > > > furaisanjin wrote: > > > > I just wonder why this condiction exists in the patch. > > > > > > > > if (*s&0xe2 == 0xe2) { > > > > > > > > There are characters which start from 0xe5 in Japanese. > > > > > > Ah yes, that is an error. Thank you. > > > > > > Any problems with "if (*s&0xe0 == 0xe0) {" instead? > > > I believe that would force everything above U+0800 > > > through the decoding, but oh well. > > > > Wait, why don't I just use > > if (*s >= 0xe2) > > > > (My excuse now is that I'm tired and it's time for bed, but > > I don't know what my excuse is for the other day :) > > > > How UTF-8 works, if anyone cares: > > 0x000000-00007F is 0xxxxxxx > > 0x000080-0007FF is 110xxxxx 10xxxxxx > > 0x000800-00FFFF is 1110xxxx 10xxxxxx 10xxxxxx > > 0x010000-1FFFFF is 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx > > > > so (*s >= 0xe2) is at least > > 1110xxxx 10xxxxxx 10xxxxxx > > 0010 000000 000000 == U+2000 > > FWIW, please consider this work "in progress". > Not to be committed into dillo-2.1 (to be released soon). Right, I'm not regarding it as anything that would go into 2.1. It's just something available for those who have a use for it.

June 6, 2009

experimental patch: Re: dillo2 wrapping Chinese

by jcid＠dillo.org

On Sat, Jun 06, 2009 at 06:36:43AM +0000, corvid wrote: > I wrote: > > furaisanjin wrote: > > > I just wonder why this condiction exists in the patch. > > > > > > if (*s&0xe2 == 0xe2) { > > > > > > There are characters which start from 0xe5 in Japanese. > > > > Ah yes, that is an error. Thank you. > > > > Any problems with "if (*s&0xe0 == 0xe0) {" instead? > > I believe that would force everything above U+0800 > > through the decoding, but oh well. > > Wait, why don't I just use > if (*s >= 0xe2) > > (My excuse now is that I'm tired and it's time for bed, but > I don't know what my excuse is for the other day :) > > How UTF-8 works, if anyone cares: > 0x000000-00007F is 0xxxxxxx > 0x000080-0007FF is 110xxxxx 10xxxxxx > 0x000800-00FFFF is 1110xxxx 10xxxxxx 10xxxxxx > 0x010000-1FFFFF is 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx > > so (*s >= 0xe2) is at least > 1110xxxx 10xxxxxx 10xxxxxx > 0010 000000 000000 == U+2000 FWIW, please consider this work "in progress". Not to be committed into dillo-2.1 (to be released soon). -- Cheers Jorge.-

June 6, 2009

experimental patch: Re: dillo2 wrapping Chinese

by jcid＠dillo.org

On Sat, Jun 06, 2009 at 06:36:43AM +0000, corvid wrote: > I wrote: > > furaisanjin wrote: > > > I just wonder why this condiction exists in the patch. > > > > > > if (*s&0xe2 == 0xe2) { > > > > > > There are characters which start from 0xe5 in Japanese. > > > > Ah yes, that is an error. Thank you. > > > > Any problems with "if (*s&0xe0 == 0xe0) {" instead? > > I believe that would force everything above U+0800 > > through the decoding, but oh well. > > Wait, why don't I just use > if (*s >= 0xe2) > > (My excuse now is that I'm tired and it's time for bed, but > I don't know what my excuse is for the other day :) > > How UTF-8 works, if anyone cares: > 0x000000-00007F is 0xxxxxxx > 0x000080-0007FF is 110xxxxx 10xxxxxx > 0x000800-00FFFF is 1110xxxx 10xxxxxx 10xxxxxx > 0x010000-1FFFFF is 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx > > so (*s >= 0xe2) is at least > 1110xxxx 10xxxxxx 10xxxxxx > 0010 000000 000000 == U+2000 Whatever the C code finally is, please be sure to comment it well (it had happen to me to forget later why my own code was doing something... ;). Sometimes I've "cleaned it up" to rediscover some days or months later (by bug reports) why it was there. -- Cheers Jorge.-

June 6, 2009

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

I wrote: > furaisanjin wrote: > > I just wonder why this condiction exists in the patch. > > > > if (*s&0xe2 == 0xe2) { > > > > There are characters which start from 0xe5 in Japanese. > > Ah yes, that is an error. Thank you. > > Any problems with "if (*s&0xe0 == 0xe0) {" instead? > I believe that would force everything above U+0800 > through the decoding, but oh well. Wait, why don't I just use if (*s >= 0xe2) (My excuse now is that I'm tired and it's time for bed, but I don't know what my excuse is for the other day :) How UTF-8 works, if anyone cares: 0x000000-00007F is 0xxxxxxx 0x000080-0007FF is 110xxxxx 10xxxxxx 0x000800-00FFFF is 1110xxxx 10xxxxxx 10xxxxxx 0x010000-1FFFFF is 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx so (*s >= 0xe2) is at least 1110xxxx 10xxxxxx 10xxxxxx 0010 000000 000000 == U+2000

June 6, 2009

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

furaisanjin wrote: > I just wonder why this condiction exists in the patch. > > if (*s&0xe2 == 0xe2) { > > There are characters which start from 0xe5 in Japanese. Ah yes, that is an error. Thank you. Any problems with "if (*s&0xe0 == 0xe0) {" instead? I believe that would force everything above U+0800 through the decoding, but oh well. (unicode blocks for the curious: http://unicode.org/Public/UNIDATA/Blocks.txt) Oh, by the way, I noticed in the line breaking document that they also listed 20000..2A6D6CJK UNIFIED IDEOGRAPHS EXTENSION B 2F800..2FA1DCJK COMPATIBILITY IDEOGRAPHS SUPPLEMENT but I wasn't sure whether anyone makes any real use of characters above U+FFFF.

June 6, 2009

experimental patch: Re: dillo2 wrapping Chinese

by furaisanjin＠gmail.com

Hi. I just wonder why this condiction exists in the patch. if (*s&0xe2 == 0xe2) { There are characters which start from 0xe5 in Japanese. Regards, furaisanjin

June 6, 2009

patch: NOP keybinding

by Johannes.Hofmann＠gmx.de

On Fri, Jun 05, 2009 at 01:50:58AM +0000, corvid wrote: > I think it would be nice to have a NOP binding to > get rid of a default binding. > > complicated patch: +1 maybe lowercase the "NOP"? Cheers, Johannes > diff -r fb041759363c src/keys.cc > --- a/src/keys.cc Fri Jun 05 01:22:16 2009 +0000 > +++ b/src/keys.cc Fri Jun 05 01:43:47 2009 +0000 > @@ -78,6 +78,7 @@ static const Mapping_t modifierNames[] = > }; > > static const KeyBinding_t default_keys[] = { > + { "NOP" , KEYS_NOP , 0 , 0 }, > { "open" , KEYS_OPEN , fltk::CTRL , 'o' }, > { "new-window" , KEYS_NEW_WINDOW , fltk::CTRL , 'n' }, > { "new-tab" , KEYS_NEW_TAB , fltk::CTRL , 't' }, > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 5, 2009

patch: NOP keybinding

by corvid＠lavabit.com

I think it would be nice to have a NOP binding to get rid of a default binding. complicated patch:

June 5, 2009

[PATCH] fix dillorc path

by corvid＠lavabit.com

Paul wrote: > When opening dillo from the CLI I noticed the following message: > > paths: Cannot open file '/home/user/.dillo/dillorc' > paths: Cannot open file '/etc/dillo/dillorc' > paths: Using internal defaults... > > Checked my system and saw that dillorc had been installed > in /usr/etc/dillorc > > Checking config.log showed sysconfdir='${prefix}/etc', so no > surprises there. But Paths::getPrefsFP() in src/paths.cc uses > PATHS_RC_SYS, which is "/etc/dillo/", so my patch uses DILLORC_SYS, > as specified in src/Makefile.am, instead. Now all is fine! In addition, perhaps we should make sysconfdir have '/dillo' at the end. If I look in an etc dir and see dillorc, I'd know what it's for, but I wouldn't know what uses keysrc.

June 4, 2009

form widgets, ascent/descent

by corvid＠lavabit.com

I was playing around in dw, and noticed that, whereas form widgets normally like to put much of their height into descent, when style sets the height, Textblock::calcWidgetSize() puts it all into ascent. I checked firefox and saw that their form widgets ascend. If we made everything ascend and just put font->descent into the descent, it would make life simpler. Or, nearly. I guess there is RELIEF_Y_THICKNESS, but I could almost ignore that...

June 4, 2009