- Dillo-dev - lists.mailman3.com

<button> rendering

by corvid＠lavabit.com

As Html_tag_open_button() says, /* * Buttons are rendered on one line, this is (at several levels) a * bit simpler. May be changed in the future. */ For some time I've wondered: How hard would it be to fix that?

Dec. 10, 2012

BUG #1109

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > If you open [1] with dillo, the "Component:" selection list > > gets overdrawn over and over. > > I see what you mean about the overdrawing now. I had been seeing wait times > of like 20 seconds with this page, but I just tried linking with 1.3.0, > and now it's fast but scribbles all over itself. Hmm... Redraws: Problem with 1.3.0, but not with 1.3.1 or newer. Slowness: A very, very, very, very, very extreme case of what can happen if you have -g -pg -O0. The Fl_Tree code is a touch sluggish with 18000 options and ordinary optimisation, but nothing that I'd feel bad about having in 3.0.3.

Dec. 9, 2012

BUG #1109

by corvid＠lavabit.com

Jorge wrote: > If you open [1] with dillo, the "Component:" selection list > gets overdrawn over and over. I see what you mean about the overdrawing now. I had been seeing wait times of like 20 seconds with this page, but I just tried linking with 1.3.0, and now it's fast but scribbles all over itself. Hmm...

Dec. 9, 2012

BUG #1109

by corvid＠lavabit.com

Jorge wrote: > On Sun, Dec 09, 2012 at 06:59:01PM +0000, corvid wrote: > > Jorge wrote: > > > As from the backtraces, it crashed with event 11 (MOVE) inside > > > a FLTK menu. I wonder what makes this particular menu different from > > > the others in the same page. > > > > Do you know which of the option menus it broke in? > > Unfortunately not. > > Sergio reports it having crashed a few times, but he can't force > it to crash, nor succeeded when I asked him to try to find a way to > reproduce the crash. In the backtrace, I saw a "numitems = 146", and the Product menu has 145 items, but that uses the selection list instead of selection option menu because it very plainly says 'multiple="multiple"'. Strange.

Dec. 9, 2012

Unused?: the url tag in the DPI start_send_page command

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Sun, Dec 09, 2012 at 04:14:01PM +0000, Jeremy Henty wrote: > > > > Everything that sends the start_send_page DPI command also sends a > > url attribute with it, but I think this attribute is always > > ignored. > > > > Dillo processes the command in capi.c but it does nothing with it > > because the Cache is already set up to receive the following raw > > data. So it doesn't look at any attributes. The only other thing > > that receives a start_send_page is the view source DPI and it > > doesn't look at any of the attributes either (it extracts a url > > from the previous tag in the stream, which it then sends back to > > Dillo to be ignored). > > View source shows the URL as page title. Yes, but it gets that url from the open_url tag that Dillo sends first. The DPI then reads the start_send_page tag but ignores its url attribute. Nothing reads the url attribute from any start_send_page tag. Regards, Jeremy Henty

Dec. 9, 2012

BUG #1109

by jcid＠dillo.org

On Sun, Dec 09, 2012 at 06:59:01PM +0000, corvid wrote: > Jorge wrote: > > If you open [1] with dillo, the "Component:" selection list > > gets overdrawn over and over. > > That list has over 18000 options. > > This was the final thing that prompted me to try changing the Fl_Tree to > Fl_Browser, since gprof showed problems where the code would iterate through > the tree by going into the parent, searching for which child we were, and then > going into the next one. This resulted in something like 300000000 calls to > various Fl_Tree_Item functions with child in the name. I was able to rewrite > some code to do things differently, but some was just internal. > > 1. With a somewhat older dillo with a somewhat older fltk, I wasn't seeing > this slowness, though. When I spent a little time trying to find out what > was the root of this, results seemed inconsistent. I...suppose it's worth > digging into again for the sake of 3.0.3. > > 2. You're supposed to get a better Fl_Tree algorithm if you set > #define FLTK_ABI_VERSION 10301 , but that's not a good option for us. > > > Some more details here [2] (backtraces, etc). > > > > As from the backtraces, it crashed with event 11 (MOVE) inside > > a FLTK menu. I wonder what makes this particular menu different from > > the others in the same page. > > Do you know which of the option menus it broke in? Unfortunately not. Sergio reports it having crashed a few times, but he can't force it to crash, nor succeeded when I asked him to try to find a way to reproduce the crash. -- Cheers Jorge.-

Dec. 9, 2012

BUG #1109

by corvid＠lavabit.com

Jorge wrote: > If you open [1] with dillo, the "Component:" selection list > gets overdrawn over and over. That list has over 18000 options. This was the final thing that prompted me to try changing the Fl_Tree to Fl_Browser, since gprof showed problems where the code would iterate through the tree by going into the parent, searching for which child we were, and then going into the next one. This resulted in something like 300000000 calls to various Fl_Tree_Item functions with child in the name. I was able to rewrite some code to do things differently, but some was just internal. 1. With a somewhat older dillo with a somewhat older fltk, I wasn't seeing this slowness, though. When I spent a little time trying to find out what was the root of this, results seemed inconsistent. I...suppose it's worth digging into again for the sake of 3.0.3. 2. You're supposed to get a better Fl_Tree algorithm if you set #define FLTK_ABI_VERSION 10301 , but that's not a good option for us. > Some more details here [2] (backtraces, etc). > > As from the backtraces, it crashed with event 11 (MOVE) inside > a FLTK menu. I wonder what makes this particular menu different from > the others in the same page. Do you know which of the option menus it broke in? > [1] https://bugzilla.redhat.com/query.cgi?format=advanced > [2] https://bugzilla.redhat.com/show_bug.cgi?id=884778

Dec. 9, 2012

BUG #1109

by jcid＠dillo.org

Hi, I contacted Sergio (submitter of BUG #1109), and here we have something weird. He reports crashes or weird behaviour. If you open [1] with dillo, the "Component:" selection list gets overdrawn over and over. Some more details here [2] (backtraces, etc). As from the backtraces, it crashed with event 11 (MOVE) inside a FLTK menu. I wonder what makes this particular menu different from the others in the same page. [1] https://bugzilla.redhat.com/query.cgi?format=advanced [2] https://bugzilla.redhat.com/show_bug.cgi?id=884778 -- Cheers Jorge.-

Dec. 9, 2012

Unused?: the url tag in the DPI start_send_page command

by jcid＠dillo.org

On Sun, Dec 09, 2012 at 04:14:01PM +0000, Jeremy Henty wrote: > > Everything that sends the start_send_page DPI command also sends a url > attribute with it, but I think this attribute is always ignored. > > Dillo processes the command in capi.c but it does nothing with it > because the Cache is already set up to receive the following raw data. > So it doesn't look at any attributes. The only other thing that > receives a start_send_page is the view source DPI and it doesn't look > at any of the attributes either (it extracts a url from the previous > tag in the stream, which it then sends back to Dillo to be ignored). View source shows the URL as page title. > So what is this attribute for? Future use? Or is it something that > just never got used? In general terms, there were ideas that went unused, and some extensions that were necessary to solve an unforeseen situation; as dpi authentication to avoid a local socket spoofing attack. The dpi framework is the same for several quite different dpi programs (aka plugins). The interface was kept more or less uniform, and each dpi chooses whether to use the info or not. -- Cheers Jorge.-

Dec. 9, 2012

Unused?: the url tag in the DPI start_send_page command

by onepoint＠starurchin.org

Everything that sends the start_send_page DPI command also sends a url attribute with it, but I think this attribute is always ignored. Dillo processes the command in capi.c but it does nothing with it because the Cache is already set up to receive the following raw data. So it doesn't look at any attributes. The only other thing that receives a start_send_page is the view source DPI and it doesn't look at any of the attributes either (it extracts a url from the previous tag in the stream, which it then sends back to Dillo to be ignored). So what is this attribute for? Future use? Or is it something that just never got used? Regards, Jeremy Henty

Dec. 9, 2012

Dpi_connect_socket retry

by p37sitdu＠lavabit.com

Dpi_connect_socket function from src/IO/dpi.c (also duplicated in test/cookies.c) has retry argument. It is set to TRUE on first call, and Dpi_connect_socket calls itself recursively with retry == FALSE in case of error. This retry function is not working. If connection fails, at line 645 sock_fd is set, but ret is still set to -1. Even if the second attempt to connect is successful, -1 is returned and conected sock_fd is lost. It is possible to fix it by adding "ret = sock_fd", but I think it is better to just remove retries completely. It is unlikely that connecting using loopback interface will fail on first try and succeed on retry. Also, comment says "the server closes sock_fd on error". However, sock_fd should still be closed by client to free allocated file descriptor. OS don't know if Dillo is going to read from it (in which case error such as ECONNRESET should happen) so file descriptor can't be reused. File descriptor should be closed in case of error in a_Dpip_build_cmd too. Patch to fix this function and its calls in src/IO/dpi.c and test/cookies.c is attached.

Dec. 9, 2012

rm test/fltk_browser

by sgeerken＠dillo.org

On Sun, Dec 09, corvid wrote: > I'd like to delete test/fltk_browser.cc. > > I was just reimplementing FltkListResource to use Fl_Browser instead > of Fl_Tree (not to put in this release, although it seems to be working), > and the existence of that little file doesn't...test anything, or make > some obscure concepts clear, or anything... Oh, there is even my name in the copyright notice ... but I do not remember anything, so simply remove it. Sebastian

Dec. 9, 2012

rm test/fltk_browser

by corvid＠lavabit.com

I'd like to delete test/fltk_browser.cc. I was just reimplementing FltkListResource to use Fl_Browser instead of Fl_Tree (not to put in this release, although it seems to be working), and the existence of that little file doesn't...test anything, or make some obscure concepts clear, or anything...

Dec. 9, 2012

Extensions for hyphenation

by corvid＠lavabit.com

Sebastian wrote: > On Fri, Dec 07, corvid wrote: > > For instance, > > > > dillo -geometry 850x700 http://fltk.org > > > > makes the names of the snapshots very narrow, and if I try > > > > penalty_hyphen=inf > > > > part of the fltk-2 snapshot link is obscured by the image. I still see this, or at least the penalty_hyphen=inf case. I didn't try the default penalty_hyphen case. > On Sat, Dec 08, corvid wrote: > > Sebastian wrote: > > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > > > far, but please take another look. > > > > Text files are giving me segfaults... > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x0809f0b8 in dw::Textblock::handleWordExtremes (this=0x819fdd8, > > wordIndex=38684) at textblock_linebreaking.cc:676 > > 676 par->maxParMin = prevPar->maxParMin; > > I was not able to reproduce any of these bugs, but I found another > bug, by which <http://www.dillo.org/CSS.html> was rendered with much > too wide columns. > > Since this fixed a memory problems, chances are high that a couple of > other problems are fixed, so please test again. Not getting segfaults on the files that broke yesterday, but I note that I'm still getting messages from valgrind like: ==24632== Conditional jump or move depends on uninitialised value(s) ==24632== at 0x8115600: fl_utf8fwd (fl_utf.c:228) ==24632== by 0x80A275E: dw::fltk::FltkPlatform::nextGlyph(char const*, int) (fltkplatform.cc:594) ==24632== by 0x8099B1C: dw::core::Layout::nextGlyph(char const*, int) (layout.hh:316) ==24632== by 0x809836C: dw::Textblock::addText(char const*, unsigned int, dw::core::style::Style*) (textblock.cc:1469) ==24632== by 0x8071123: DilloPlain::addLine(char*, unsigned int) (plain.cc:146) ==24632== by 0x8071246: DilloPlain::write(void*, unsigned int, int) (plain.cc:179) ==24632== by 0x8071400: Plain_callback(int, _CacheClient*) (plain.cc:229) ==24632== by 0x8064F6A: Cache_process_queue (cache.c:1214) ==24632== by 0x80645A9: a_Cache_process_dbuf (cache.c:899) ==24632== by 0x80682F9: a_Capi_ccc (capi.c:742) ==24632== by 0x805F83C: a_Chain_fcb (chain.c:114) ==24632== by 0x808BC25: Dpi_parse_token (dpi.c:220)

Dec. 8, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

On Fri, Dec 07, corvid wrote: > Sebastian wrote: > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > > far, but please take another look. > > Is everything about hyphenation supposed to work at this point? It was supposed to work. > For instance, > > dillo -geometry 850x700 http://fltk.org > > makes the names of the snapshots very narrow, and if I try > > penalty_hyphen=inf > > part of the fltk-2 snapshot link is obscured by the image. On Sat, Dec 08, corvid wrote: > Sebastian wrote: > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > > far, but please take another look. > > Text files are giving me segfaults... > > Program received signal SIGSEGV, Segmentation fault. > 0x0809f0b8 in dw::Textblock::handleWordExtremes (this=0x819fdd8, > wordIndex=38684) at textblock_linebreaking.cc:676 > 676 par->maxParMin = prevPar->maxParMin; I was not able to reproduce any of these bugs, but I found another bug, by which <http://www.dillo.org/CSS.html> was rendered with much too wide columns. Since this fixed a memory problems, chances are high that a couple of other problems are fixed, so please test again. Sebastian

Dec. 8, 2012

Extensions for hyphenation

by corvid＠lavabit.com

Sebastian wrote: > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > far, but please take another look. Text files are giving me segfaults... Program received signal SIGSEGV, Segmentation fault. 0x0809f0b8 in dw::Textblock::handleWordExtremes (this=0x819fdd8, wordIndex=38684) at textblock_linebreaking.cc:676 676 par->maxParMin = prevPar->maxParMin;

Dec. 8, 2012

Extensions for hyphenation

by corvid＠lavabit.com

Sebastian wrote: > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > far, but please take another look. Is everything about hyphenation supposed to work at this point? For instance, dillo -geometry 850x700 http://fltk.org makes the names of the snapshots very narrow, and if I try penalty_hyphen=inf part of the fltk-2 snapshot link is obscured by the image.

Dec. 7, 2012

[patch] dpid/dpid.c unused variable

by corvid＠lavabit.com

p37sitdu wrote: > Patch removes unused variable usr_srv_num. Committed.

Dec. 7, 2012

[patch] dpid/dpid.c unused variable

by p37sitdu＠lavabit.com

Patch removes unused variable usr_srv_num.

Dec. 7, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

On Fri, Dec 07, Jorge Arellano Cid wrote: > On Thu, Dec 06, 2012 at 09:38:28PM +0100, Sebastian Geerken wrote: > > 2. How to deal with tables? > > > > a) I've pushed my changes regarding extremes calculation to > > <http://flpsed.org/hgweb/dillo_hyphen>, but I'd like to push it into > > the main repository as soon as possible. The current state has some > > bugs, but I hope it should be stable soon. > > > > This is, BTW, generally some cleanup and so useful independent of this > > special purpose. (Might be even somewhat faster than the old > > implementation.) > > Probably this is the way to go. Just push it into the main repo > as soon as you find it stable enough. Just pushed to http://hg.dillo.org/dillo. I've found no problems so far, but please take another look. Something which came to my mind: should this new rule, to exclude hyphenation breaks from minimal width calculation, also be applied to soft hyphens? Currently it is applied to both, but letting minimal width calculation consider soft hyphens as possible breaks may be feasable, since soft hyphens are set by the author himself (who, OTOH, is surprised by the fact that there is a browser also hyphenating automatically ;-) ). This would be rather simple: diff -r 6a525e279c5d dw/textblock.cc --- a/dw/textblock.cc Fri Dec 07 19:32:40 2012 +0100 +++ b/dw/textblock.cc Fri Dec 07 19:45:52 2012 +0100 @@ -41,7 +41,7 @@ Textblock::DivChar Textblock::divChars[NUM_DIV_CHARS] = { // soft hyphen (U+00AD) - { "\xc2\xad", true, false, true, PENALTY_HYPHEN, -1 }, + { "\xc2\xad", true, false, false, PENALTY_HYPHEN, -1 }, // simple hyphen-minus: same penalties like automatic or soft // hyphens { "-", false, true, true, -1, PENALTY_HYPHEN }, // (unconditional) hyphen (U+2010): handled exactly like // minus-hyphen. See test/table-h1.html for the effect. Sebastian

Dec. 7, 2012

Extensions for hyphenation

by jcid＠dillo.org

On Fri, Dec 07, 2012 at 10:51:03AM +0100, Sebastian Geerken wrote: > Just one comment: > > On Thu, Dec 06, Jorge Arellano Cid wrote: > > In that case, AFAIU, a dillorc option can be formulated as: > > > > Breaking a single word in a line is not possible unless it is > > wider than XX chars (e.g. single_word_max_length). > > > > (I assume knowing whether a word is alone in a line is possible > > by comparing the start and end indexes of the array, but haven't > > checked it...) > > Yet again, the problem is to calculate the correct extremes, to avoid > too narrow columns. However, at this point, we do not have lines: > these are calculated as soon as a given column width is calculated > (which depends on the correct extremes). Ahhh!, now I see what you mean. > After the release, other approaches could be discussed. If that's the case, then we only have a set of words to work with; It may be possible to devise a different heuristic. -- Cheers Jorge.-

Dec. 7, 2012

Extensions for hyphenation

by jcid＠dillo.org

On Thu, Dec 06, 2012 at 09:38:28PM +0100, Sebastian Geerken wrote: > Hi! > > Sorry for cutting this a bit off, but I'd like to suggest the > following steps: > > 1. Concentrate on the next release, with hyphenation support. Which > issues are open? I recall these: (a) How to deal with the pattern > files, and (b) tables. Did I forget something? Are there some pages > not rendering which were rendering before? Not that I'm aware of (besides the table issue). > For dealing with tables, see below, step 2 (after step 3). > > 3. Floats: will not be part of the next release, but I'd like to > finish this rather soon; this has been delayed already long enugh. > (There has been some progress, BTW, see > <http://flpsed.org/hgweb/dillo_floats_geerken>.) Great. > 2. How to deal with tables? > > a) I've pushed my changes regarding extremes calculation to > <http://flpsed.org/hgweb/dillo_hyphen>, but I'd like to push it into > the main repository as soon as possible. The current state has some > bugs, but I hope it should be stable soon. > > This is, BTW, generally some cleanup and so useful independent of this > special purpose. (Might be even somewhat faster than the old > implementation.) Probably this is the way to go. Just push it into the main repo as soon as you find it stable enough. > b) I'd like to use it for my approach: not using hyphenation for > calculation the extremes, but of course, using hyphenation when > breaking lines (also in table cells). This gives us: > > (i) full advantages of hyphenation; > > (ii) no risk regarding table rendering: table columns will be the same > as before, and similar to other browsers (without hyphenation), so the > problems Jorge mentioned will not occure; > > (iii) finally, this would make one bug obsolete: > > | **Incorrect calculation of extremes:** The minimal width of a text > | block (as part of the width extremes, which are mainly used for > | tables) is defined by everything between two possible breaks. A > | possible break may also be a hyphenation point; however, hyphenation > | points are calculated in a lazy way, when the lines are broken, and > | not when extremes are calculated. So, it is a matter of chance whether > | the calculation of the minimal width will take the two parts "dil-" > | and "lo" into account (when "dillo" has already been hyphenated), or > | only one part, "dillo" (when "dillo" has not yet been hyphenated), > | resulting possibly in a different value for the minimal width. > > (See "dw-line-breaking.doc" for more. This would leave only "low > priority" issues.) > > After the release, other approaches could be discussed. This looks like the simplest approach. -- Cheers Jorge.-

Dec. 7, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

Just one comment: On Thu, Dec 06, Jorge Arellano Cid wrote: > In that case, AFAIU, a dillorc option can be formulated as: > > Breaking a single word in a line is not possible unless it is > wider than XX chars (e.g. single_word_max_length). > > (I assume knowing whether a word is alone in a line is possible > by comparing the start and end indexes of the array, but haven't > checked it...) Yet again, the problem is to calculate the correct extremes, to avoid too narrow columns. However, at this point, we do not have lines: these are calculated as soon as a given column width is calculated (which depends on the correct extremes). Sebastian

Dec. 7, 2012

ideographic, zero-width space

by sgeerken＠dillo.org

On Tue, Nov 27, corvid wrote: > Would it make the most sense for the handling of ideographic characters > and zero-width space to go somewhere in textblock these days instead of > html.cc? I'd tend to this shift, especally since now everything is represented as CSS (and so dw style attributes). In the past, it was the HTML parser who now about HTML tags like <pre> etc. Thinking this further to an extreme, there would not be a method for adding words, but a method adding characters; breaking into words is then done by the textblock widget. (Not sure about the this, OTOH.) Sebastian

Dec. 6, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

Hi! Sorry for cutting this a bit off, but I'd like to suggest the following steps: 1. Concentrate on the next release, with hyphenation support. Which issues are open? I recall these: (a) How to deal with the pattern files, and (b) tables. Did I forget something? Are there some pages not rendering which were rendering before? For dealing with tables, see below, step 2 (after step 3). 3. Floats: will not be part of the next release, but I'd like to finish this rather soon; this has been delayed already long enugh. (There has been some progress, BTW, see <http://flpsed.org/hgweb/dillo_floats_geerken>.) 2. How to deal with tables? a) I've pushed my changes regarding extremes calculation to <http://flpsed.org/hgweb/dillo_hyphen>, but I'd like to push it into the main repository as soon as possible. The current state has some bugs, but I hope it should be stable soon. This is, BTW, generally some cleanup and so useful independent of this special purpose. (Might be even somewhat faster than the old implementation.) b) I'd like to use it for my approach: not using hyphenation for calculation the extremes, but of course, using hyphenation when breaking lines (also in table cells). This gives us: (i) full advantages of hyphenation; (ii) no risk regarding table rendering: table columns will be the same as before, and similar to other browsers (without hyphenation), so the problems Jorge mentioned will not occure; (iii) finally, this would make one bug obsolete: | **Incorrect calculation of extremes:** The minimal width of a text | block (as part of the width extremes, which are mainly used for | tables) is defined by everything between two possible breaks. A | possible break may also be a hyphenation point; however, hyphenation | points are calculated in a lazy way, when the lines are broken, and | not when extremes are calculated. So, it is a matter of chance whether | the calculation of the minimal width will take the two parts "dil-" | and "lo" into account (when "dillo" has already been hyphenated), or | only one part, "dillo" (when "dillo" has not yet been hyphenated), | resulting possibly in a different value for the minimal width. (See "dw-line-breaking.doc" for more. This would leave only "low priority" issues.) After the release, other approaches could be discussed. Comments and thoughts? Regards Sebastian

Dec. 6, 2012

Extensions for hyphenation

by jcid＠dillo.org

On Wed, Dec 05, 2012 at 11:59:01AM +0100, Sebastian Geerken wrote: > On Sat, Nov 24, Jorge Arellano Cid wrote: > > > Calculating width extremes, and so table rendering, > > > is independent of the actual penalty values (except for the value > > > "inf"i; see below). > > > > I beg to differ. > > > > > [...] > > > Penaltie values cannot actually influence table rendering: > > > > > > 1. Column widths depend on column min/max widths and available width > > > (window width at the top). > > > > Agreed. > > > > > 2. Column min/max widths depend on cell min/max widths (maximum of the > > > respective values). > > > > Agreed. > > > > > 3. Cell widths (calculated in dw::Textblock::getExtremesImpl) do not > > > take the penalty values into account, only three cases are > > > distinguished: inf (no break allowed), -inf (break forced), and > > > other values (break possible.) > > > > Agreed. > > > > > So changing penalties (say, to 5 instead of 1), won't make a > > > difference. > > > > Here I differ. Please let me know what I'm missing. > > > > If a penalty can increase the badness of breaking certain word, > > to the point of it not being broken (ar at least be broken less times), > > > > e.g. > > becomes or > > hy- hyphenation hyphen- > > phen- ation > > ation > > > > and that word is the only word in a cell, and that cell is the > > widest in its column (as in the URL example [1]), then cell max > > is affected (as you explain in point 2), an so table rendering. > > Penalties are useful for decisions regarding actual line breaking, but > calculating the minimal width must regard all possible breaks; so > there is only a decision whether a break is possible at all, or *not* > possible at all. Both breaks, with penalties of 1 or 5, respectively, > are possible breaks. Ack! > So, as long as table calculation is kept this simple way (and not > replaced by something more complex), the only possibility is to regard > some breaks as not possible at all, when the minimal width is > calculated. In that case, AFAIU, a dillorc option can be formulated as: Breaking a single word in a line is not possible unless it is wider than XX chars (e.g. single_word_max_length). (I assume knowing whether a word is alone in a line is possible by comparing the start and end indexes of the array, but haven't checked it...) > > > > [...] > > > > or even simpler, in characters: > > > > > > > > penalty_one_word_line=18 > > > > /* Don't try to break words shorter than 18 chars, when > > > > alone in a single line */ > > > > > > > > > > > > The advantage I see to a penalty that handles this case is that > > > > it can help a lot with web rendering and also with more precise > > > > book rendering with a simple dillorc option. > > > > > > Could be, but it sounds a bit hackish, and with an uncertain result. > > > Could be worth a test, however. > > > > It sounds a bit strange, but also the problem is: if we have to > > format text into a narrow column, breaking a long word to make it > > fit in, is clearly the way to go. Now, if breaking that word also > > makes the column narrower for the whole text (as narrow as the > > broken word's widest split part), then we have to choose which of > > both cases is better. > > Generally, yes. But notice the order: 1. min/max width of the cell, > and so min/max width of the column, 2. *actual* width of the column, > 3. line breaking, based on the actual width. Any change must be made > in #1, otherwise it is too late. > > So, the decision has to be simplified: regarding a given point as > possible break or not. The actual column width (as you describe it) > cannot be regarded. I understand the point. But can it be decided beforehand (i.e. without knowing the actual width of the column), as stated above? (e.g. declaring via dillorc option that columns narrower than 18 characters are "bad" when a single word in a line needs hyphenation.). > > [...] > > I'd like to have the best choice rendered! ;-) > > Independant of the approach actually implemented (perhaps both should > be tested), the calculation of extremes has to be re-implemented, to > decouple it from the line breaking. This is some more work, and rather > risky (now half finished, but unstable). Is this something for the > next release, or should we ignore it, on the short term? I don't know the complexity of this task, it certainly sounds daunting to me. I'd *like* to have full hyphenation in our next release, but also priorize floating objects over it. Certainly you're in a better position to evaluate the effort, side effects of it, and also decide. > I can push my changes in another repository, if you want to take a > look at it. If we were working in the same physical place, perhaps I could be of more help. My feeling is I would be more of a burden to explain the whole problem to by email than of help. If you feel otherwise, we may try. -- Cheers Jorge.-

Dec. 6, 2012

Patch set: improve window titles

by jcid＠dillo.org

On Wed, Dec 05, 2012 at 06:54:43PM +0000, corvid wrote: > Jeremy wrote: > > Please comment. There is nothing complicated or disruptive here - > > just some minor polishing of the GUI and the code base. No > > functionality is changed. > > These are a good improvement... Looks good and clean, +1 -- Cheers Jorge.-

Dec. 6, 2012

Patch set: improve window titles

by corvid＠lavabit.com

Jeremy wrote: > Please comment. There is nothing complicated or disruptive here - > just some minor polishing of the GUI and the code base. No > functionality is changed. These are a good improvement...

Dec. 5, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

On Sat, Nov 24, Jorge Arellano Cid wrote: > > Calculating width extremes, and so table rendering, > > is independent of the actual penalty values (except for the value > > "inf"i; see below). > > I beg to differ. > > > [...] > > Penaltie values cannot actually influence table rendering: > > > > 1. Column widths depend on column min/max widths and available width > > (window width at the top). > > Agreed. > > > 2. Column min/max widths depend on cell min/max widths (maximum of the > > respective values). > > Agreed. > > > 3. Cell widths (calculated in dw::Textblock::getExtremesImpl) do not > > take the penalty values into account, only three cases are > > distinguished: inf (no break allowed), -inf (break forced), and > > other values (break possible.) > > Agreed. > > > So changing penalties (say, to 5 instead of 1), won't make a > > difference. > > Here I differ. Please let me know what I'm missing. > > If a penalty can increase the badness of breaking certain word, > to the point of it not being broken (ar at least be broken less times), > > e.g. > becomes or > hy- hyphenation hyphen- > phen- ation > ation > > and that word is the only word in a cell, and that cell is the > widest in its column (as in the URL example [1]), then cell max > is affected (as you explain in point 2), an so table rendering. Penalties are useful for decisions regarding actual line breaking, but calculating the minimal width must regard all possible breaks; so there is only a decision whether a break is possible at all, or *not* possible at all. Both breaks, with penalties of 1 or 5, respectively, are possible breaks. So, as long as table calculation is kept this simple way (and not replaced by something more complex), the only possibility is to regard some breaks as not possible at all, when the minimal width is calculated. > > > [...] > > > or even simpler, in characters: > > > > > > penalty_one_word_line=18 > > > /* Don't try to break words shorter than 18 chars, when > > > alone in a single line */ > > > > > > > > > The advantage I see to a penalty that handles this case is that > > > it can help a lot with web rendering and also with more precise > > > book rendering with a simple dillorc option. > > > > Could be, but it sounds a bit hackish, and with an uncertain result. > > Could be worth a test, however. > > It sounds a bit strange, but also the problem is: if we have to > format text into a narrow column, breaking a long word to make it > fit in, is clearly the way to go. Now, if breaking that word also > makes the column narrower for the whole text (as narrow as the > broken word's widest split part), then we have to choose which of > both cases is better. Generally, yes. But notice the order: 1. min/max width of the cell, and so min/max width of the column, 2. *actual* width of the column, 3. line breaking, based on the actual width. Any change must be made in #1, otherwise it is too late. So, the decision has to be simplified: regarding a given point as possible break or not. The actual column width (as you describe it) cannot be regarded. > The above dillorc setting is just a very simple (in the sense > of: no need to calculate) heuristic to try to answer the > question. > > > > These are just ideas, not meant to be *the* solution. They have > > > relatively simple implementations that could be field tested. > > > > I've thought on another approach, which unfortunately turned out to be > > more complicated than I first thought: calculating width extremes > > without considering hyphenation. In this case, "hyphenation" is still > > hyphenated, but the minimal width of this cell is based on the whole > > word "hyphenation". This would have the following results: > > > > 1. table rendering is done the same way as by browsers not supporting > > hyphenation, and, > > 2. OTOH, hyphenation still works as desired. > > > > As I said, I stumbled about a difficult detail; I'd like to give it > > another though. > > Yes, it would solve the problem, but leaving out the advantage > when the answer to the above stated question, favors an > hyphenated solution. > > I'd like to have the best choice rendered! ;-) Independant of the approach actually implemented (perhaps both should be tested), the calculation of extremes has to be re-implemented, to decouple it from the line breaking. This is some more work, and rather risky (now half finished, but unstable). Is this something for the next release, or should we ignore it, on the short term? I can push my changes in another repository, if you want to take a look at it. Sebastian

Dec. 5, 2012

Patch set: improve window titles

by onepoint＠starurchin.org

OK: here is the complete set: Patch: dpi-downloads_window_titles Nice window titles for the Downloads DPI (which is the only DPI that creates windows). http://starurchin.org/dillo/patch/dpi-downloads_window_titles.html Patch: dillo_window_titles Nice window titles for Dillo. http://starurchin.org/dillo/patch/dillo_window_titles.html Patch: dillo_window_titles_parameterise Make all the window titles parameters of the functions that create them instad of hardwiring them. Rename some variables (some titles were named "msg") and swap two function parameters for consistency. Titles may be NULL or empty, in which case we default to what we had before. NB: choice5 also handles a NULL msg, since msg may be read from a DPIP tag in a "dialog" DPI command and this returns NULL if the tag does not contain the key "msg". Patch: dpip-dialog_titles Make all DPIs that use the "dialog" command supply a title. (There is one instance of this in the hello DPI and many in the https DPI.) http://starurchin.org/dillo/patch/dpip-dialog_titles.html Please comment. There is nothing complicated or disruptive here - just some minor polishing of the GUI and the code base. No functionality is changed. I will push after the weekend if noone objects. (It's nice to be hacking on Dillo again!) Regards, Jeremy Henty

Dec. 4, 2012

ask for ipv4 addresses only in getaddrinfo() if ipv6 is disabled

by corvid＠lavabit.com

Johannes committed: > This speeds up dns requests quite a bit in my setup. So much faster! :)

Dec. 1, 2012

Patch: improve window titles for the downloads DPI

by onepoint＠starurchin.org

corvid wrote: > I like the idea of better titles in general. > > Choice5 is one that I notice at times and wish it said something > different... Yes, I'd like to do the same for dillo itself next, but I'd thought I'd start with the downloads DPI first. Sorting the dillo dialogs out might mean changing some of the signatures in dialog.hh to add a title argument. Regards, Jeremy Henty

Dec. 1, 2012

valgrind log entry hyphenation related?

by corvid＠lavabit.com

http://starurchin.org/dillo/valgrind/5eaf94da6ca698708497c27cd3d3a50730f6f9…

Dec. 1, 2012

Patch: improve window titles for the downloads DPI

by corvid＠lavabit.com

Jeremy wrote: > Comments on this tiny patch? > > http://starurchin.org/dillo/patch/dpi-downloads_window_titles.html > > I thought it looked a little unprofessional to have default dialog > titles like "Unnamed". > > Any objections to me pushing this? I like the idea of better titles in general. Choice5 is one that I notice at times and wish it said something different...

Dec. 1, 2012

Patch: improve window titles for the downloads DPI

by onepoint＠starurchin.org

Comments on this tiny patch? http://starurchin.org/dillo/patch/dpi-downloads_window_titles.html I thought it looked a little unprofessional to have default dialog titles like "Unnamed". Any objections to me pushing this? Regards, Jeremy Henty

Nov. 30, 2012

hyphenation in dillo

by sgeerken＠dillo.org

On Wed, Nov 28, corvid wrote: > I wrote: > > The borders on the "Search results" and "Nutrient values" boxes > > are overlapping on http://www.bitelog.com/mega-food-search.htm?q=masa > > I got around to trimming it down to a small example of brokenness (attached). Thanks, this helped a lot. The bug is fixed now. > Interestingly, the "10000" protrudes out of the left end of the table on > firefox, which suggests there might be something wrong about this page > in a way that I'm not immediately grasping. (Although it's nicer to > think that firefox is buggy.) It seems that firefox is reserving a fixed space for list bullets/numbers, while dillo calculates the necessary space. Sebastian

Nov. 28, 2012

Extensions for hyphenation -- Merged!

by sgeerken＠dillo.org

On Mon, Nov 26, Sebastian Geerken wrote: > On Sun, Nov 25, Johannes Hofmann wrote: > > This looks great! To me it doesn't look as if it would involve any > > risky stuff. What do you think about merging dillo_hyphen into main > > line? Or should we wait until after the release? > > I'd agree here. Changes are simple and should be robust. If noone > complains, I'll merge tomorrow. > > > The table column width issue you are discussing with Jorge also > > exists in main line, right? So we can improve on that there. > > Yes, there is nothing new here. Since noone has complained, these changes are now in http://hg.dillo.org/dillo. Sebastian

Nov. 28, 2012

soft hyphen and hyphenation

by sgeerken＠dillo.org

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

Nov. 28, 2012

hyphenation in dillo

by corvid＠lavabit.com

I wrote: > The borders on the "Search results" and "Nutrient values" boxes > are overlapping on http://www.bitelog.com/mega-food-search.htm?q=masa I got around to trimming it down to a small example of brokenness (attached). Interestingly, the "10000" protrudes out of the left end of the table on firefox, which suggests there might be something wrong about this page in a way that I'm not immediately grasping. (Although it's nicer to think that firefox is buggy.)

Nov. 28, 2012

soft hyphen and hyphenation

by corvid＠lavabit.com

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?

Nov. 28, 2012

soft hyphen and hyphenation

by sgeerken＠dillo.org

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

Nov. 27, 2012

ideographic, zero-width space

by corvid＠lavabit.com

Would it make the most sense for the handling of ideographic characters and zero-width space to go somewhere in textblock these days instead of html.cc?

Nov. 27, 2012

soft hyphen and hyphenation

by corvid＠lavabit.com

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...

Nov. 27, 2012

soft hyphen and hyphenation

by Johannes.Hofmann＠gmx.de

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

Nov. 27, 2012

pedantic (Re: soft hyphen and hyphenation)

by corvid＠lavabit.com

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...

Nov. 27, 2012

soft hyphen and hyphenation

by sgeerken＠dillo.org

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

Nov. 27, 2012

soft hyphen and hyphenation

by corvid＠lavabit.com

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;

Nov. 26, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

On Sun, Nov 25, Johannes Hofmann wrote: > This looks great! To me it doesn't look as if it would involve any > risky stuff. What do you think about merging dillo_hyphen into main > line? Or should we wait until after the release? I'd agree here. Changes are simple and should be robust. If noone complains, I'll merge tomorrow. > The table column width issue you are discussing with Jorge also > exists in main line, right? So we can improve on that there. Yes, there is nothing new here. Sebastian

Nov. 26, 2012

soft hyphen and hyphenation

by sgeerken＠dillo.org

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

Nov. 26, 2012

soft hyphen and hyphenation

by Johannes.Hofmann＠gmx.de

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

Nov. 26, 2012