Hi all. I created new subject thread since the original one becomes quite long and. I found one difference between dillo-2.0 and dillo-css. there was a_Decode_charset_init calling at Cache_parse_header in cache.c when HTTP server Content-Type was detected but there isn't this in dillo-css. Because if HTTP server Content-Type is same as META content-type, there isn't any chance to call a_Decode_charset_init. This is one reason why the page is drawn properly. I still don't figure out another timing issue yet. Regards, furaisanjin
On Sun, Jan 18, 2009 at 10:33:39PM +0900, furaisanjin wrote:
Hi all.
I created new subject thread since the original one becomes quite long and.
I found one difference between dillo-2.0 and dillo-css. there was a_Decode_charset_init calling at Cache_parse_header in cache.c when HTTP server Content-Type was detected but there isn't this in dillo-css. Because if HTTP server Content-Type is same as META content-type, there isn't any chance to call a_Decode_charset_init. This is one reason why the page is drawn properly.
Yes, there were cleanups on charset decoding. Please clarify me whether 2.1 behaviour is right or wrong! :-) And if you can send an example, better. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Hi, 2009/1/19 Jorge Arellano Cid <jcid@dillo.org>:
Please clarify me whether 2.1 behaviour is right or wrong! :-)
I think the behavior is wrong.
And if you can send an example, better.
This is one example (this page is news archive so the page may be removed some day). http://www.so-net.ne.jp/news/cgi-bin/article.cgi?gid=mai&aid=20090119-570-OYT1T00946 This is HTTP server response. HTTP/1.1 200 OK Date: Mon, 19 Jan 2009 14:23:11 GMT Server: Apache Cache-control: private, max-age=300 Content-Type: text/html; charset=SHIFT-JIS Transfer-Encoding: chunked And the page contains <meta http-equiv="Content-Type" content="text/html; charset=shift-jis" /> Regards, furaisanjin
On Mon, Jan 19, 2009 at 11:29:27PM +0900, furaisanjin wrote:
Hi,
2009/1/19 Jorge Arellano Cid <jcid@dillo.org>:
Please clarify me whether 2.1 behaviour is right or wrong! :-)
I think the behavior is wrong.
And if you can send an example, better.
This is one example (this page is news archive so the page may be removed some day).
http://www.so-net.ne.jp/news/cgi-bin/article.cgi?gid=mai&aid=20090119-570-OYT1T00946
This is HTTP server response.
HTTP/1.1 200 OK Date: Mon, 19 Jan 2009 14:23:11 GMT Server: Apache Cache-control: private, max-age=300 Content-Type: text/html; charset=SHIFT-JIS Transfer-Encoding: chunked
And the page contains
<meta http-equiv="Content-Type" content="text/html; charset=shift-jis" />
Got it! Yes, there're bugs and a timing issue. I'm looking at them... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
2009/1/20 Jorge Arellano Cid <jcid@dillo.org>:
Yes, there're bugs and a timing issue. I'm looking at them...
Ok, thanks. This is timing issue example page. http://www.picfun.com/app00.html HTTP server response is HTTP/1.1 200 OK Date: Mon, 19 Jan 2009 22:21:11 GMT Server: Apache Last-Modified: Sun, 11 Jan 2009 01:58:25 GMT ETag: "15e47-43cb-53585240" Accept-Ranges: bytes Content-Length: 17355 Content-Type: text/html the page contains <META http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> At first time charset conversion is something wrong but if I go somewhere and come back, charset conversion looks OK. I think this type of page doesn't contain CSS or contains embedded style. So I'm guessing repush timing is different. Regards, furaisanjin
On Tue, Jan 20, 2009 at 07:29:46AM +0900, furaisanjin wrote:
2009/1/20 Jorge Arellano Cid <jcid@dillo.org>:
Yes, there're bugs and a timing issue. I'm looking at them...
Ok, thanks. This is timing issue example page.
http://www.picfun.com/app00.html
HTTP server response is
HTTP/1.1 200 OK Date: Mon, 19 Jan 2009 22:21:11 GMT Server: Apache Last-Modified: Sun, 11 Jan 2009 01:58:25 GMT ETag: "15e47-43cb-53585240" Accept-Ranges: bytes Content-Length: 17355 Content-Type: text/html
the page contains
<META http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
At first time charset conversion is something wrong but if I go somewhere and come back, charset conversion looks OK. I think this type of page doesn't contain CSS or contains embedded style. So I'm guessing repush timing is different.
Yes, I have a combinatorial case table of things to manage, some work some doesn't. The idea is to get to a design that handles them cleanly. BTW (@all), the "tools" button is 60% done, but stopped. As it also uses repush to enable/disable CSS parsing, is better to fix the above issues before testing it. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Hi. This is work around. 1) HTTP server and meta have charset. One example is http://www.so-net.ne.jp/news/cgi-bin/article.cgi?gid=mai&aid=20090119-570-OYT1T00946 diff -r a0230b2a4a32 src/cache.c --- a/src/cache.c Fri Jan 16 14:45:17 2009 -0300 +++ b/src/cache.c Wed Jan 21 20:21:49 2009 +0900 @@ -628,6 +628,7 @@ { char *header = entry->Header->str; char *Length, *Type, *location_str, *encoding; + char *charset; #ifndef DISABLE_COOKIES Dlist *Cookies; #endif @@ -753,6 +754,13 @@ entry->TypeHdr = Type; _MSG("TypeHdr {%s} {%s}\n", Type, URL_STR(entry->Url)); _MSG("TypeMeta {%s}\n", entry->TypeMeta); + a_Misc_parse_content_type(Type, NULL, NULL, &charset); + if (charset) { + entry->CharsetDecoder = a_Decode_charset_init(charset); + if (entry->CharsetDecoder) + entry->UTF8Data = dStr_new(""); + dFree(charset); + } } } 2) Only meta has charset. One example is http://www.picfun.com/app00.html diff -r a0230b2a4a32 src/html.cc --- a/src/html.cc Fri Jan 16 14:45:17 2009 -0300 +++ b/src/html.cc Wed Jan 21 20:22:00 2009 +0900 @@ -2789,6 +2789,7 @@ * this code in another bw might have already changed it for us. */ if (a_Misc_content_type_cmp(html->content_type, new_content)) { + html->stop_parser = true; html->repush_after_head = true; } } Regards, furaisanjin
On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote:
Hi.
This is work around.
This so called "work around" works very well. While working on this, I used the testcases in the following table: load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_C OK OK OK C = has remote CSS stylesheet HMC OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __C OK OK OK _MC OK OK OK ---------------------------- Both patches pass all of them! I committed a similar approach that has a single code path for calling a_Decode_charset_init(). Please test and comment. -- Cheers Jorge.-
Hi, On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote:
On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote:
Hi.
This is work around.
This so called "work around" works very well.
While working on this, I used the testcases in the following table:
load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_C OK OK OK C = has remote CSS stylesheet HMC OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __C OK OK OK _MC OK OK OK ----------------------------
Both patches pass all of them!
I committed a similar approach that has a single code path for calling a_Decode_charset_init().
Please test and comment.
Starting with revision d29cdb5b842e I get repeatable crashes when clicking on the "Home" link in about:splash. Cheers, Johannes Program received signal SIGBUS, Bus error. DilloHtml::getCurTagLineNumber (this=0x28778500) at html.cc:596 596 if (p[i] == '\n') (gdb) bt #0 DilloHtml::getCurTagLineNumber (this=0x28778500) at html.cc:596 #1 0x08063e38 in DilloHtml::bugMessage (this=0x28778500, format=0x80f8198 "HEAD section lacks the TITLE element\n") at html.cc:149 #2 0x08063f2a in Html_tag_close_head (html=0x28778500, TagIdx=32) at html.cc:1569 #3 0x080684de in Html_tag_cleanup_at_close (html=0x28778500, TagIdx=32) at html.cc:1306 #4 0x08068957 in DilloHtml::finishParsing (this=0x28778500, ClientKey=2) at html.cc:627 #5 0x0805a566 in Cache_process_queue (entry=0x287418c0) at cache.c:1153 #6 0x0805b378 in a_Cache_process_dbuf (Op=2, buf=0x0, buf_size=0, Url=0x28741c80) at cache.c:886 #7 0x0805c871 in a_Capi_ccc (Op=4, Branch=2, Dir=1, Info=0x2874fd60, Data1=0x0, Data2=0x0) at capi.c:618 #8 0x08058288 in a_Chain_fcb (Op=0, Info=0x287a3000, Data1=0x0, Data2=0x0) at chain.c:112 #9 0x08078cee in a_Dpi_ccc (Op=4, Branch=2, Dir=1, Info=0x2874f140, Data1=0x0, Data2=0x0) at dpi.c:671 #10 0x08058288 in a_Chain_fcb (Op=0, Info=0x287a3000, Data1=0x0, Data2=0x0) at chain.c:112 #11 0x0807969e in a_IO_ccc (Op=4, Branch=2, Dir=1, Info=0x2874f6c0, Data1=0x2874f8c0, Data2=0x0) ---Type <return> to continue, or q <return> to quit--- ---Type <return> to continue, or q <return> to quit--- at IO.c:418 #12 0x08079980 in IO_callback (io=0x2874f8c0) at IO.c:211 #13 0x080799ff in IO_fd_read_cb (fd=7, data=0x2) at IO.c:287 #14 0x080ca465 in fltk::wait () #15 0x080ca615 in fltk::run () #16 0x0804f03a in main (argc=1, argv=0xbfbff864) at dillo.cc:334 (gdb)
On Thu, Jan 22, 2009 at 10:22:39AM +0100, Hofmann Johannes wrote:
Hi,
On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote:
On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote:
Hi.
This is work around.
This so called "work around" works very well.
While working on this, I used the testcases in the following table:
load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_C OK OK OK C = has remote CSS stylesheet HMC OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __C OK OK OK _MC OK OK OK ----------------------------
Both patches pass all of them!
I committed a similar approach that has a single code path for calling a_Decode_charset_init().
Please test and comment.
Starting with revision d29cdb5b842e I get repeatable crashes when clicking on the "Home" link in about:splash.
Please try the current tip. -- Cheers Jorge.-
On Thu, Jan 22, 2009 at 08:34:32AM -0300, Jorge Arellano Cid wrote:
On Thu, Jan 22, 2009 at 10:22:39AM +0100, Hofmann Johannes wrote:
Hi,
On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote:
On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote:
Hi.
This is work around.
This so called "work around" works very well.
While working on this, I used the testcases in the following table:
load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_C OK OK OK C = has remote CSS stylesheet HMC OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __C OK OK OK _MC OK OK OK ----------------------------
Both patches pass all of them!
I committed a similar approach that has a single code path for calling a_Decode_charset_init().
Please test and comment.
Starting with revision d29cdb5b842e I get repeatable crashes when clicking on the "Home" link in about:splash.
Please try the current tip.
Yes, it's fixed! Cheers, Johannes
On Thu, Jan 22, 2009 at 09:18:00PM +0900, furaisanjin wrote:
Hi.
And charset conversion works fine.
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic" However looking at japanese pages, it seems that word wrapping is still an issue, see: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-November/005427.html Do you have an idea about a possible solution? Cheers, Johannes
Hi, 2009/1/22 Hofmann Johannes <Johannes.Hofmann@gmx.de>:
On Thu, Jan 22, 2009 at 09:18:00PM +0900, furaisanjin wrote: However looking at japanese pages, it seems that word wrapping is still an issue, see: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-November/005427.html
Do you have an idea about a possible solution?
No, I don't think there is good solution but I added these code in html.cc. --- a/src/html.cc Thu Jan 22 08:31:44 2009 -0300 +++ b/src/html.cc Thu Jan 22 21:33:56 2009 +0900 @@ -58,6 +58,8 @@ #define TAB_SIZE 8 +#define UTF8_NONE_1WORD(x) ((x)&0x80) + /*----------------------------------------------------------------------------- * Name spaces *---------------------------------------------------------------------------*/ @@ -111,6 +113,7 @@ DilloImage *image); static void Html_callback(int Op, CacheClient_t *Client); static void Html_tag_cleanup_at_close(DilloHtml *html, int TagIdx); +static int Html_utf8_size (char c); /*----------------------------------------------------------------------------- * Local Data @@ -1117,6 +1120,7 @@ { int i, j, start; char *Pword, ch; + int utf8size; DilloHtmlParseMode parse_mode = S_TOP(html)->parse_mode; if (parse_mode == DILLO_HTML_PARSE_MODE_STASH || @@ -1159,7 +1163,20 @@ } else { if (!memchr(word,'&', size)) { /* No entities */ - DW2TB(html->dw)->addText(word, html->styleEngine->wordStyle ()); + for (start = 0; start < (int) strlen (word); ) { + if (UTF8_NONE_1WORD(word[start])) { + utf8size = Html_utf8_size (word[start]); + DW2TB(html->dw)->addText(dStrndup(&word[start],utf8size), html->styleEngine->wordStyle()); + start += utf8size; + } else { + for (i=0; i < (int) strlen (word)-start; i++) { + if (UTF8_NONE_1WORD(word[start+i])) + break; + } + DW2TB(html->dw)->addText(dStrndup(&word[start],i), html->styleEngine->wordStyle()); + start += i; + } + } } else { /* Collapse white-space entities inside the word (except ) */ Pword = a_Html_parse_entities(html, word, size); @@ -1167,7 +1184,20 @@ if (strchr("\t\f\n\r", Pword[i])) for (j = i; (Pword[j] = Pword[j+1]); ++j) ; - DW2TB(html->dw)->addText(Pword, html->styleEngine->wordStyle ()); + for (start = 0; start < (int) strlen (Pword); ) { + if (UTF8_NONE_1WORD(Pword[start])) { + utf8size = Html_utf8_size (Pword[start]); + DW2TB(html->dw)->addText(dStrndup(&Pword[start],utf8size), html->styleEngine->wordStyle()); + start += utf8size; + } else { + for (i=0; i < (int) strlen (Pword)-start; i++) { + if (UTF8_NONE_1WORD(Pword[start+i])) + break; + } + DW2TB(html->dw)->addText(dStrndup(&Pword[start],i), html->styleEngine->wordStyle()); + start += i; + } + } dFree(Pword); } } @@ -3700,4 +3730,20 @@ return token_start; } +static int Html_utf8_size (char c) +{ + if ((c&0xfc) == 0xfc) + return 6; + if ((c&0xf8) == 0xf8) + return 5; + if ((c&0xf0) == 0xf0) + return 4; + if ((c&0xe0) == 0xe0) + return 3; + if ((c&0xc0) == 0xc0) + return 2; + return 1; +} + Then dillo appearance is something I mentioned here. http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-November/005430.html By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has this problem? Regards, furaisanjin
2009/1/22 furaisanjin <furaisanjin@gmail.com>:
By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has this problem?
bookmark problem is solved by this patch. --- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 +++ b/src/cache.c Thu Jan 22 23:03:33 2009 +0900 @@ -512,8 +512,10 @@ if (entry->CharsetDecoder) a_Decode_free(entry->CharsetDecoder); a_Misc_parse_content_type(ctype, NULL, NULL, &charset); - entry->CharsetDecoder = a_Decode_charset_init(charset); - dFree(charset); + if (charset) { + entry->CharsetDecoder = a_Decode_charset_init(charset); + dFree(charset); + } curr = Cache_current_content_type(entry); /* Invalidate UTF8Data */ Regards, furaisanjin
On Thu, Jan 22, 2009 at 11:06:01PM +0900, furaisanjin wrote:
2009/1/22 furaisanjin <furaisanjin@gmail.com>:
By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has this problem?
bookmark problem is solved by this patch.
--- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 +++ b/src/cache.c Thu Jan 22 23:03:33 2009 +0900 @@ -512,8 +512,10 @@ if (entry->CharsetDecoder) a_Decode_free(entry->CharsetDecoder); a_Misc_parse_content_type(ctype, NULL, NULL, &charset); - entry->CharsetDecoder = a_Decode_charset_init(charset); - dFree(charset); + if (charset) { + entry->CharsetDecoder = a_Decode_charset_init(charset); + dFree(charset); + } curr = Cache_current_content_type(entry);
/* Invalidate UTF8Data */
Have you added charset to the content-type given by the bookmarks dpi? or have you added a META or both? I would like to know the problem in detail, because it looks like adding an extra parameter to a_Cache_set_content_type() would make its API, and code cleaner. e.g. ({CA_Header|CA_Meta} as last parameter). If the problem can be solved with that API change, great, hence the above question. BTW AFAIS, with the above patch if CharsetDecoder was already set, and a_Misc_parse_content_type() fails, CharsetDecoder is left in an unknown state. -- Cheers Jorge.-
On Thu, Jan 22, 2009 at 12:24:41PM -0300, Jorge Arellano Cid wrote:
On Thu, Jan 22, 2009 at 11:06:01PM +0900, furaisanjin wrote:
2009/1/22 furaisanjin <furaisanjin@gmail.com>:
By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has this problem?
bookmark problem is solved by this patch.
--- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 +++ b/src/cache.c Thu Jan 22 23:03:33 2009 +0900 @@ -512,8 +512,10 @@ if (entry->CharsetDecoder) a_Decode_free(entry->CharsetDecoder); a_Misc_parse_content_type(ctype, NULL, NULL, &charset); - entry->CharsetDecoder = a_Decode_charset_init(charset); - dFree(charset); + if (charset) { + entry->CharsetDecoder = a_Decode_charset_init(charset); + dFree(charset); + } curr = Cache_current_content_type(entry);
/* Invalidate UTF8Data */
Have you added charset to the content-type given by the bookmarks dpi? or have you added a META or both?
I would like to know the problem in detail, because it looks like adding an extra parameter to a_Cache_set_content_type() would make its API, and code cleaner. e.g. ({CA_Header|CA_Meta} as last parameter).
If the problem can be solved with that API change, great, hence the above question.
Does something like the attached patch solve the problem? -- Cheers Jorge.-
Hi. 2009/1/23 Jorge Arellano Cid <jcid@dillo.org>:
Have you added charset to the content-type given by the bookmarks dpi? or have you added a META or both?
I did hg revert cache.c to cancel my local modification and then built dillo again. However I can't reproduce the problem anymore. I don't add content-type on dpi nor meta on bookmark because if encoding type is UTF-8, no conversion is required. I assume dillo native encoding is UTF-8 now. Sorry for confusion. Please ignore bookmark problem. Regards, furaisanjin
On Fri, Jan 23, 2009 at 07:31:56AM +0900, furaisanjin wrote:
Hi.
2009/1/23 Jorge Arellano Cid <jcid@dillo.org>:
Have you added charset to the content-type given by the bookmarks dpi? or have you added a META or both?
I did hg revert cache.c to cancel my local modification and then built dillo again. However I can't reproduce the problem anymore. I don't add content-type on dpi nor meta on bookmark because if encoding type is UTF-8, no conversion is required. I assume dillo native encoding is UTF-8 now.
Sorry for confusion. Please ignore bookmark problem.
OK, but I still want to commit the proposed patch. Please test it and comment. -- Cheers Jorge.-
Hi 2009/1/23 Jorge Arellano Cid <jcid@dillo.org>:
On Fri, Jan 23, 2009 at 07:31:56AM +0900, furaisanjin wrote: OK, but I still want to commit the proposed patch. Please test it and comment.
I have browsed several pages and I don't encounter problem. Still www.amazon.de causes dillo crashed but I guess that would be different issue. Regards, furaisanjin
Hi. This is work around for www.amazon.de. diff -r 93de73875a8c src/cache.c --- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 +++ b/src/cache.c Sat Jan 24 14:53:50 2009 +0900 @@ -747,6 +747,7 @@ dStr_free(entry->Data, 1); entry->Data = dStr_sized_new(MIN(entry->ExpectedSize, MAX_INIT_BUF)); } + Cache_ref_data(entry); /* Get Content-Type */ if ((Type = Cache_parse_field(header, "Content-Type")) == NULL) { @@ -762,7 +763,6 @@ _MSG("TypeMeta {%s}\n", entry->TypeMeta); dFree(Type); } - Cache_ref_data(entry); } /* I found that Cache_ref_data position was moved to the bottom. I don't fully understand the logic but somehow this change helps. Regards, furaisanjin
On Sat, Jan 24, 2009 at 03:00:33PM +0900, furaisanjin wrote:
Hi.
This is work around for www.amazon.de.
diff -r 93de73875a8c src/cache.c --- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 +++ b/src/cache.c Sat Jan 24 14:53:50 2009 +0900 @@ -747,6 +747,7 @@ dStr_free(entry->Data, 1); entry->Data = dStr_sized_new(MIN(entry->ExpectedSize, MAX_INIT_BUF)); } + Cache_ref_data(entry);
/* Get Content-Type */ if ((Type = Cache_parse_field(header, "Content-Type")) == NULL) { @@ -762,7 +763,6 @@ _MSG("TypeMeta {%s}\n", entry->TypeMeta); dFree(Type); } - Cache_ref_data(entry); }
/*
I found that Cache_ref_data position was moved to the bottom. I don't fully understand the logic but somehow this change helps.
You're using repo's tip, right? Cache_ref_data() also updates UTF8Data according to CharsetDecoder (yes it's a trick). That's why moving it after a_Cache_set_content_type() has the effect of initializing the UTF8Data biffer. -- Cheers Jorge.-
After pulling from http://freehg.org/u/dillo/main and updating dillo, the charset conversion problem appeared again. Goto http://headlines.yahoo.co.jp/hl (this page is OK) and click some of article like http://headlines.yahoo.co.jp/hl?a=20090125-00000013-yom-soci. Charset conversion doesn't happen on this page. These pages don't contain meta but HTTP server specifies charset. Regards, furaisanjin
Please ignore this one. I found that my cache.c was corrupted. My local change still remained after updating and that caused this behaviour. 2009/1/25 furaisanjin <furaisanjin@gmail.com>:
After pulling from http://freehg.org/u/dillo/main and updating dillo, the charset conversion problem appeared again.
Goto http://headlines.yahoo.co.jp/hl (this page is OK) and click some of article like http://headlines.yahoo.co.jp/hl?a=20090125-00000013-yom-soci. Charset conversion doesn't happen on this page. These pages don't contain meta but HTTP server specifies charset.
Regards, furaisanjin
Johannes wrote:
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic"
If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.
On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote:
Johannes wrote:
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic"
If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.
True. We need to make new config options sans-serif_fontname serif_fontname cursive_fontname fantasy_fontname monospace_fontname maybe even dropping the "_fontname" suffix. But of course that would no longer be compatible with older versions of dillorc. Opinions? Cheers, Johannes
Johannes wrote:
On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote:
Johannes wrote:
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic"
If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.
True. We need to make new config options
sans-serif_fontname serif_fontname cursive_fontname fantasy_fontname monospace_fontname
maybe even dropping the "_fontname" suffix.
But of course that would no longer be compatible with older versions of dillorc.
I would add the new options and remove the old options. CSS is big and certainly worth some incompatibility. Related to this, I've been wondering whether we should have a policy about the dillorc on the website -- whether it should follow tip, or follow the most recent release, or always add new options but never delete old options...
On Thu, Jan 22, 2009 at 06:53:46PM +0000, corvid wrote:
Johannes wrote:
On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote:
Johannes wrote:
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic"
If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.
True. We need to make new config options
sans-serif_fontname serif_fontname cursive_fontname fantasy_fontname monospace_fontname
maybe even dropping the "_fontname" suffix.
But of course that would no longer be compatible with older versions of dillorc.
I would add the new options and remove the old options. CSS is big and certainly worth some incompatibility.
Ok, attached is a patch for discussion. Cheers, Johannes
Related to this, I've been wondering whether we should have a policy about the dillorc on the website -- whether it should follow tip, or follow the most recent release, or always add new options but never delete old options...
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Johannes wrote:
On Thu, Jan 22, 2009 at 06:53:46PM +0000, corvid wrote:
Johannes wrote:
On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote:
Johannes wrote:
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic"
If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.
True. We need to make new config options
sans-serif_fontname serif_fontname cursive_fontname fantasy_fontname monospace_fontname
maybe even dropping the "_fontname" suffix.
But of course that would no longer be compatible with older versions of dillorc.
I would add the new options and remove the old options. CSS is big and certainly worth some incompatibility.
Ok, attached is a patch for discussion.
You meant to write font_monospace in dialog.cc and plain.cc. PS I approve of cursive and fantasy defaulting to sans :)
On Fri, Jan 23, 2009 at 03:54:42AM +0000, corvid wrote:
Johannes wrote:
On Thu, Jan 22, 2009 at 06:53:46PM +0000, corvid wrote:
Johannes wrote:
On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote:
Johannes wrote:
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic"
If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.
True. We need to make new config options
sans-serif_fontname serif_fontname cursive_fontname fantasy_fontname monospace_fontname
maybe even dropping the "_fontname" suffix.
But of course that would no longer be compatible with older versions of dillorc.
I would add the new options and remove the old options. CSS is big and certainly worth some incompatibility.
Ok, attached is a patch for discussion.
You meant to write font_monospace in dialog.cc and plain.cc.
Yes, that's what I meant.
PS I approve of cursive and fantasy defaulting to sans :)
:) Cheers, Johannes
On Thu, Jan 22, 2009 at 06:53:46PM +0000, corvid wrote:
Johannes wrote:
On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote:
Johannes wrote:
BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic"
If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.
True. We need to make new config options
sans-serif_fontname serif_fontname cursive_fontname fantasy_fontname monospace_fontname
maybe even dropping the "_fontname" suffix.
But of course that would no longer be compatible with older versions of dillorc.
I would add the new options and remove the old options. CSS is big and certainly worth some incompatibility.
I agree with corvid. And, dillo should be able to pick some sane defaults when we figure how to deal with them right through FLTK.
Related to this, I've been wondering whether we should have a policy about the dillorc on the website -- whether it should follow tip, or follow the most recent release, or always add new options but never delete old options...
The current practice is to make it compatible with the last release, and to update the one in the source tree for those using the repository. -- Cheers Jorge.-
On Thu, Jan 22, 2009 at 08:34:32AM -0300, Jorge Arellano Cid wrote:
On Thu, Jan 22, 2009 at 10:22:39AM +0100, Hofmann Johannes wrote:
Hi,
On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote:
On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote:
Hi.
This is work around.
This so called "work around" works very well.
While working on this, I used the testcases in the following table:
load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_C OK OK OK C = has remote CSS stylesheet HMC OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __C OK OK OK _MC OK OK OK ----------------------------
Both patches pass all of them!
I committed a similar approach that has a single code path for calling a_Decode_charset_init().
Please test and comment.
Starting with revision d29cdb5b842e I get repeatable crashes when clicking on the "Home" link in about:splash.
Please try the current tip.
I noticed one more issue, still present in tip. On http://amazon.de dillo crashes with: Program terminated with signal 11, Segmentation fault. b#0 0x08069f2e in Html_write_raw (html=0x2866f500, buf=0x2874303d <Address 0x2874303d out of bounds>, bufsize=33743, Eof=0) at html.cc:3398 3398 if (*start == '/' || /* </x> */ (gdb) bt #0 0x08069f2e in Html_write_raw (html=0x2866f500, buf=0x2874303d <Address 0x2874303d out of bounds>, bufsize=33743, Eof=0) at html.cc:3398 #1 0x0806a53a in DilloHtml::write (this=0x2866f500, Buf=0x28743000 <Address 0x28743000 out of bounds>, BufSize=675537188, Eof=0) at html.cc:577 #2 0x0806a58e in Html_callback (Op=0, Client=0x2862ea40) at html.cc:3564 #3 0x0805a706 in Cache_process_queue (entry=0x28653700) at cache.c:1143 #4 0x08058288 in a_Chain_fcb (Op=675537188, Info=0x1, Data1=0x286b8210, Data2=0x80f573c) at chain.c:112 #5 0x0807899c in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x2862e400, Data1=0x286b8c20, Data2=0x0) at dpi.c:219 #6 0x08058288 in a_Chain_fcb (Op=675537188, Info=0x1, Data1=0x286b8c20, Data2=0x0) at chain.c:112 #7 0x08079311 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x2862ee20, Data1=0x2862e4a0, Data2=0x0) at IO.c:414 #8 0x0807949e in IO_callback (io=0x2862e4a0) at IO.c:201 #9 0x0807956f in IO_fd_read_cb (fd=4, data=0x4) at IO.c:287 #10 0x080c9fd5 in fltk::wait () #11 0x080ca185 in fltk::run () #12 0x0804f03a in main (argc=2, argv=0xbfbff850) at dillo.cc:334 Cheers, Johannes
participants (4)
-
corvid＠lavabit.com -
furaisanjin＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de