June 2009 - Dillo-dev - lists.mailman3.com

two image problems

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > Some websites seems to send images with a charset set in the header, > > e.g: Content-Type: image/jpeg;charset=ISO-8859-1 > > In that case dillo seems to decode the data resulting in: > > Not a JPEG file: starts with 0xc3 0xbf > > Not sure whether we can/want to do anything about that. > > It seems like it would make sense to restrict decoding to text/*. > I'll look in the rfc to see whether it says something relevant. Fix committed. RFC 2046 defines a charset parameter for text/* (and it's also mentioned in the RFCs for text/html and text/css media types). Nothing mentions any parameters defined for image/*, or for the specific image types that dillo displays. Interestingly, I learned of RFC 5147, which is a proposed standard involving URI fragments and text/plain: http://tools.ietf.org/html/rfc5147#section-5

June 7, 2009

[PATCH] fix dillorc path

by jcid＠dillo.org

On Sun, Jun 07, 2009 at 02:08:22AM +0000, corvid wrote: > Jorge wrote: > > On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > > > 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. > > > > Yes, a '/dillo' suffix looks OK. > > Please merge both ideas and commit. > > I defined a DILLO_SYSCONF instead of DILLORC_SYS > so that a system keysrc will work someday. > Please test. dillorc and dpidrc got into "/usr/local/etc". (I was expecting them in "/usr/local/etc/dillo"). -- Cheers Jorge.-

June 7, 2009

two image problems

by corvid＠lavabit.com

Johannes wrote: > I noticed two problems related to images: > > Some websites seems to send images with a charset set in the header, > e.g: Content-Type: image/jpeg;charset=ISO-8859-1 > In that case dillo seems to decode the data resulting in: > Not a JPEG file: starts with 0xc3 0xbf > Not sure whether we can/want to do anything about that. It seems like it would make sense to restrict decoding to text/*. I'll look in the rfc to see whether it says something relevant. It might be good to have text decoded outside of cache to UTF-8 in the same way that images are decoded outside of cache to RGB. (Right now that would be a problem with view src using getbuf, and perhaps for text/css following @charset="..." eventually, but still it would be nice to have one way of doing things.) Speaking of the rfc, I noticed just recently that it says "The value of Content-Location also defines the base URI for the entity." and I wonder whether that's ever a problem in practice because dillo makes no use of this header. > I don't understand the other problem: > http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg > loads and displays fine. > from html however it doesn't work > <img src="http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg" /> When you load it by itself, dillo follows the redirection to http://szmimg.sueddeutsche.de/upl/images/user/8059/17337.jpg

June 7, 2009

two image problems

by Johannes.Hofmann＠gmx.de

Hi, I noticed two problems related to images: Some websites seems to send images with a charset set in the header, e.g: Content-Type: image/jpeg;charset=ISO-8859-1 In that case dillo seems to decode the data resulting in: Not a JPEG file: starts with 0xc3 0xbf Not sure whether we can/want to do anything about that. I don't understand the other problem: http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg loads and displays fine. from html however it doesn't work <img src="http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg" /> Cheers, Johannes

June 7, 2009

[PATCH] fix dillorc path

by corvid＠lavabit.com

Jorge wrote: > On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > > 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. > > Yes, a '/dillo' suffix looks OK. > Please merge both ideas and commit. I defined a DILLO_SYSCONF instead of DILLORC_SYS so that a system keysrc will work someday. Please test.

June 7, 2009

form widgets, ascent/descent

by jcid＠dillo.org

On Thu, Jun 04, 2009 at 06:11:43PM +0000, corvid wrote: > 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... Not knowing exactly about the details, I'd be very careful in changing ascents, descents and friends because the may interfere with correct handling of CSS. If you're sure it's OK to do it, even considering the "details" (e.g. reliefs, spacings, paddings), then why not. -- Cheers Jorge.-

June 7, 2009

[PATCH] fix dillorc path

by jcid＠dillo.org

On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > 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. Yes, a '/dillo' suffix looks OK. Please merge both ideas and commit. -- Cheers Jorge.-

June 7, 2009

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