- Dillo-dev - lists.mailman3.com

valgrind complaints when running datauri

by corvid＠lavabit.com

Johannes wrote: > Unfortunately I can't reproduce the problem here, but I see an > issue in a_Url_decode_hex_str() (datauri.c): > In line 154 two possibly unrelated pointers are subtracted. Could > you try the following: It doesn't crash anymore! :)

Nov. 25, 2012

valgrind complaints when running datauri

by Johannes.Hofmann＠gmx.de

On Sun, Nov 25, 2012 at 07:46:42PM +0000, corvid wrote: > > Jeremy's valgrind logs have had a couple of these recently, e.g., > http://starurchin.org/dillo/valgrind/5b601af9ce7facc17690b88c4323c194fded01… > > I found that > - after dpidc stop > - valgrind --leak-check=full --trace-children=yes dillo > - going to http://jimbojw.com/wiki/index.php?title=Data_URI_Explained > - and pasting in the second example (the percent-encoded one, not the > base64 one) > gets me: > > ==20817== Invalid read of size 4 > ==20817== at 0x804AED5: dStr_insert_l (dlib.c:287) > ==20817== by 0x804AFB5: dStr_append_l (dlib.c:308) > ==20817== by 0x8049317: main (datauri.c:332) > ==20817== Address 0x41cbbb0 is 0 bytes after a block of size 664 alloc'd > ==20817== at 0x402AE29: realloc (vg_replace_malloc.c:662) > ==20817== by 0x804A736: dRealloc (dlib.c:53) > ==20817== by 0x804918B: datauri_get_data (datauri.c:273) > ==20817== by 0x80492E1: main (datauri.c:324) > ==20817== > ==20817== > ==20817== Process terminating with default action of signal 11 (SIGSEGV): dumping core > > > Valgrind has options for debugging, but I haven't had any luck with > getting them to work so far. > > I'm imagining that this might have to do with only being able to send > part of the data at a time when everything's sluggish due to valgrind, > but I don't know datauri/dpip well enough to go straight for the most > likely spots... > > PS I don't trust the "by 0x8049317: main (datauri.c:332)" line because > I have -O0, and sometimes it's had some 0x40... address instead that it > describes as being below main. Unfortunately I can't reproduce the problem here, but I see an issue in a_Url_decode_hex_str() (datauri.c): In line 154 two possibly unrelated pointers are subtracted. Could you try the following: diff -r 74833d000780 dpi/datauri.c --- a/dpi/datauri.couldThu Nov 15 23:09:50 2012 +0100 +++ b/dpi/datauri.couldSun Nov 25 21:52:22 2012 +0100 @@ -150,8 +150,8 @@ } *dest = 0; + *p_sz = (size_t)(dest - new_str); new_str = dRealloc(new_str, sizeof(char) * (dest - new_str + 1)); - *p_sz = (size_t)(dest - new_str); return new_str; } Cheers, Johannes

Nov. 25, 2012

valgrind complaints when running datauri

by corvid＠lavabit.com

Jeremy's valgrind logs have had a couple of these recently, e.g., http://starurchin.org/dillo/valgrind/5b601af9ce7facc17690b88c4323c194fded01… I found that - after dpidc stop - valgrind --leak-check=full --trace-children=yes dillo - going to http://jimbojw.com/wiki/index.php?title=Data_URI_Explained - and pasting in the second example (the percent-encoded one, not the base64 one) gets me: ==20817== Invalid read of size 4 ==20817== at 0x804AED5: dStr_insert_l (dlib.c:287) ==20817== by 0x804AFB5: dStr_append_l (dlib.c:308) ==20817== by 0x8049317: main (datauri.c:332) ==20817== Address 0x41cbbb0 is 0 bytes after a block of size 664 alloc'd ==20817== at 0x402AE29: realloc (vg_replace_malloc.c:662) ==20817== by 0x804A736: dRealloc (dlib.c:53) ==20817== by 0x804918B: datauri_get_data (datauri.c:273) ==20817== by 0x80492E1: main (datauri.c:324) ==20817== ==20817== ==20817== Process terminating with default action of signal 11 (SIGSEGV): dumping core Valgrind has options for debugging, but I haven't had any luck with getting them to work so far. I'm imagining that this might have to do with only being able to send part of the data at a time when everything's sluggish due to valgrind, but I don't know datauri/dpip well enough to go straight for the most likely spots... PS I don't trust the "by 0x8049317: main (datauri.c:332)" line because I have -O0, and sometimes it's had some 0x40... address instead that it describes as being below main. PPS I find myself wishing that we could have the dpis back in dillo.

Nov. 25, 2012

Extensions for hyphenation

by Johannes.Hofmann＠gmx.de

Hi Sebastian, On Sun, Nov 18, 2012 at 02:29:32PM +0100, Sebastian Geerken wrote: > Hi! > > At http://flpsed.org/hgweb/dillo_hyphen, you'll find some extensions > for hyphenation I've not yet merged into the main repository. Still > needs some documentation, but here is an overview: > > There are now configuration variables for dillorc (see source): > penalties for hyphens, as well as the left and right side of an > em-dash. The suffix "_2" means that this value is used for lines > following a line which ends already with a hyphen. When this value is > larger, two adjacent lines ending with a hyphen are avoided. > > For values, see the definition of the "badness". Typical values: > > 0 = Penalty used for normal spaces. > 1 = A justified line with spaces having 150% or 67% of the ideal space > width has this as badness. > 8 = A justified line with spaces twice as wide as ideally has this as > badness. > > "inf" may be used (preventing a break in any case); also "-inf" > (forcing a break), although the latter makes no sense and may lead to > strange results. > > There is a text page, test/hyphens-etc.html, to play around. 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? The table column width issue you are discussing with Jorge also exists in main line, right? So we can improve on that there. Johannes

Nov. 25, 2012

Extensions for hyphenation

by jcid＠dillo.org

On Fri, Nov 23, 2012 at 01:05:39PM +0100, Sebastian Geerken wrote: > Hi Jorge, > > On Wed, Nov 21, Jorge Arellano Cid wrote: > > On Sun, Nov 18, 2012 at 02:29:32PM +0100, Sebastian Geerken wrote: > > [...] > > I wonder how breaking a single word in a line can be penalized > > with these controls. > > See below ... > > > For instance [1], with both main dillo and dillo_hyphen the > > word "hyphenation" is broken twice: > > > > hy- > > phen- > > ation > > > > With the new controls, it could become: > > > > hyphen- > > ation > > > > but, in this particular case it should have been: > > > > hyphenation > > That there is a difference between dillo and dillo_hyphen is probably > just accidental. Ack. > 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. > > [...] > > 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. 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! ;-) -- Cheers Jorge.-

Nov. 24, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

Hi Jorge, On Wed, Nov 21, Jorge Arellano Cid wrote: > On Sun, Nov 18, 2012 at 02:29:32PM +0100, Sebastian Geerken wrote: > > At http://flpsed.org/hgweb/dillo_hyphen, you'll find some extensions > > for hyphenation I've not yet merged into the main repository. Still > > needs some documentation, but here is an overview: > > > > There are now configuration variables for dillorc (see source): > > penalties for hyphens, as well as the left and right side of an > > em-dash. The suffix "_2" means that this value is used for lines > > following a line which ends already with a hyphen. When this value is > > larger, two adjacent lines ending with a hyphen are avoided. > > > > For values, see the definition of the "badness". Typical values: > > > > 0 = Penalty used for normal spaces. > > 1 = A justified line with spaces having 150% or 67% of the ideal space > > width has this as badness. > > 8 = A justified line with spaces twice as wide as ideally has this as > > badness. > > > > "inf" may be used (preventing a break in any case); also "-inf" > > (forcing a break), although the latter makes no sense and may lead to > > strange results. > > > > There is a text page, test/hyphens-etc.html, to play around. > > I wonder how breaking a single word in a line can be penalized > with these controls. See below ... > For instance [1], with both main dillo and dillo_hyphen the > word "hyphenation" is broken twice: > > hy- > phen- > ation > > With the new controls, it could become: > > hyphen- > ation > > but, in this particular case it should have been: > > hyphenation That there is a difference between dillo and dillo_hyphen is probably just accidental. Calculating width extremes, and so table rendering, is independent of the actual penalty values (except for the value "inf"i; see below). > In the same page, there're several cases of the same problem > (one line above, a 1 row x 8 col table) where words are broken > into a maximum of 4 times! > > In the web case, it's common to use the longest word in a line > as minimal width. OTOH there's also the problem of too long > "word" strings. I remember your other post some months ago. > In [1] clearly the browser tries to optimize for a minimal page > width. Which is not the case, but that could perfectly have been > as an external constraint to the algoritm (by means of screen > size, TABLE element directives, floats, etc). So it is non > trivial. > > I've worked enough on table rendering to know that making a > decision based on the current textblock's min/max width would > introduce too much complexity. e.g. in [1], just imagine the > problem of deciding which words to break and where for a dynamic > optimum of the table width. :-P > > A much simpler approach would be to introduce a penalty for > breaking single words in a line, above a certain threshold that > could be relative to the browser window's width. > > For instance: > > penalty_one_word_line=5 > /* Penalty = (word_length > 1/4 window width) ? 0 : 5 */ Penaltie values cannot actually influence table rendering: 1. Column widths depend on column min/max widths and available width (window width at the top). 2. Column min/max widths depend on cell min/max widths (maximum of the respective values). 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.) So changing penalties (say, to 5 instead of 1), won't make a difference. > 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. > 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. Sebastian

Nov. 23, 2012

Extensions for hyphenation

by jcid＠dillo.org

Hi Sebastian, On Sun, Nov 18, 2012 at 02:29:32PM +0100, Sebastian Geerken wrote: > Hi! > > At http://flpsed.org/hgweb/dillo_hyphen, you'll find some extensions > for hyphenation I've not yet merged into the main repository. Still > needs some documentation, but here is an overview: > > There are now configuration variables for dillorc (see source): > penalties for hyphens, as well as the left and right side of an > em-dash. The suffix "_2" means that this value is used for lines > following a line which ends already with a hyphen. When this value is > larger, two adjacent lines ending with a hyphen are avoided. > > For values, see the definition of the "badness". Typical values: > > 0 = Penalty used for normal spaces. > 1 = A justified line with spaces having 150% or 67% of the ideal space > width has this as badness. > 8 = A justified line with spaces twice as wide as ideally has this as > badness. > > "inf" may be used (preventing a break in any case); also "-inf" > (forcing a break), although the latter makes no sense and may lead to > strange results. > > There is a text page, test/hyphens-etc.html, to play around. I wonder how breaking a single word in a line can be penalized with these controls. For instance [1], with both main dillo and dillo_hyphen the word "hyphenation" is broken twice: hy- phen- ation With the new controls, it could become: hyphen- ation but, in this particular case it should have been: hyphenation In the same page, there're several cases of the same problem (one line above, a 1 row x 8 col table) where words are broken into a maximum of 4 times! In the web case, it's common to use the longest word in a line as minimal width. OTOH there's also the problem of too long "word" strings. In [1] clearly the browser tries to optimize for a minimal page width. Which is not the case, but that could perfectly have been as an external constraint to the algoritm (by means of screen size, TABLE element directives, floats, etc). So it is non trivial. I've worked enough on table rendering to know that making a decision based on the current textblock's min/max width would introduce too much complexity. e.g. in [1], just imagine the problem of deciding which words to break and where for a dynamic optimum of the table width. :-P A much simpler approach would be to introduce a penalty for breaking single words in a line, above a certain threshold that could be relative to the browser window's width. For instance: penalty_one_word_line=5 /* Penalty = (word_length > 1/4 window width) ? 0 : 5 */ 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. These are just ideas, not meant to be *the* solution. They have relatively simple implementations that could be field tested. HTH. [1] http://www.thefreedictionary.com/hyphenation -- Cheers Jorge.-

Nov. 21, 2012

missing redraw?

by Johannes.Hofmann＠gmx.de

On Sun, Nov 18, 2012 at 08:18:13AM +0000, corvid wrote: > > I was looking at the source for http://omicsomics.blogspot.com/ , > and there was a little bit of first-column background color visible in > the second column. Switching to another tab and back shows that the > first column is really a little wider than what is initially seen. > > This problem appears to pre-date the inclusion of hyphenation. I can't reproduce it here for some reason, but I suspect that in dw/table.cc redrawY is not reset properly when the first column get's wider as line numbers have more digits.

Nov. 18, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

Hi! At http://flpsed.org/hgweb/dillo_hyphen, you'll find some extensions for hyphenation I've not yet merged into the main repository. Still needs some documentation, but here is an overview: There are now configuration variables for dillorc (see source): penalties for hyphens, as well as the left and right side of an em-dash. The suffix "_2" means that this value is used for lines following a line which ends already with a hyphen. When this value is larger, two adjacent lines ending with a hyphen are avoided. For values, see the definition of the "badness". Typical values: 0 = Penalty used for normal spaces. 1 = A justified line with spaces having 150% or 67% of the ideal space width has this as badness. 8 = A justified line with spaces twice as wide as ideally has this as badness. "inf" may be used (preventing a break in any case); also "-inf" (forcing a break), although the latter makes no sense and may lead to strange results. There is a text page, test/hyphens-etc.html, to play around. Sebastian

Nov. 18, 2012

missing redraw?

by corvid＠lavabit.com

I was looking at the source for http://omicsomics.blogspot.com/ , and there was a little bit of first-column background color visible in the second column. Switching to another tab and back shows that the first column is really a little wider than what is initially seen. This problem appears to pre-date the inclusion of hyphenation.

Nov. 18, 2012

Handling preferences

by jcid＠dillo.org

On Fri, Nov 16, 2012 at 03:14:41PM +0100, Sebastian Geerken wrote: > On Thu, Nov 15, Jorge Arellano Cid wrote: > > [...] > > AFAICS an init(p1, p2, ...) function is very good for setting > > the whole prefs pack at once, but it doesn't seem as convenient > > for changing just one of those vars at run time; which may be > > necessary for instance if we ever implement a preferences dpi or > > enable a custom UI (as with change panel size). > > > > I'm a bit more inclined towards the separate functions for each > > var approach. > > Yes, probably this is a good idea. However, should these methods be > static or not? That is, should it be possible that different instances > of dw::Textblock have different values set? > > One problem is that dw::Textblock is instanciated at a couple of > postions, and how configuration looks like eventually is not clear > yet; so I'd like to follow a more pragmatical approach to set the at > one position in the code. I'd go for the simple solution now (a global setting). i.e. a CLI parameter sets the whole browser. If the need arises in the future we may re-evaluate enabling the change of a particular textblock var on the fly. -- Cheers Jorge.-

Nov. 16, 2012

Handling preferences

by corvid＠lavabit.com

Sebastian wrote: > Does this affect the following arguments? When called > > dillo --opt1 url1 --opt2 url2 > > should --opt2 only affect url2 or also url1? In the former case, > non-static configuration is indeed necessary. Command line parsing requires all of the arguments before all of the urls.

Nov. 16, 2012

Handling preferences

by sgeerken＠dillo.org

On Thu, Nov 15, Jorge Arellano Cid wrote: > Hi Sebastian, > > On Thu, Nov 15, 2012 at 01:42:29PM +0100, Sebastian Geerken wrote: > > Hi! > > > > I'm just working on making some values related to hyphenation > > configurable via dillorc. A long time ago (before the Fltk port), Dw > > directy accessed the prefs module for the value limit_text_width. When > > Dw was ported to Fltk (which was largely a rewrite), it was seperated, > > so it does not depend on prefs anymore. However, this made it > > necessary to pass the value of prefs.limit_text_width to dw::Textblock > > in the constructor. > > > > Now, I do not want to extend dw::Textblock::Textblock() by a couple of > > new parameters. Instead, I though of storing the values directly in Dw > > (initialized by feasable standard values), and the prefs parser must > > store them there. This way, Dw is still independent. This could be > > adapted in other modules. > > > > Currenty, my code is this: > > > > 1. The new values are still stored in DilloPrefs. > > > > 2. There is a static method dw::Textblock::init, which called in main, > > after the prefs parser: > > > > @@ -50,6 +50,7 @@ > > #include "auth.h" > > > > #include "dw/fltkcore.hh" > > +#include "dw/textblock.hh" > > > > /* > > * Command line options structure > > @@ -359,6 +360,8 @@ > > a_Cookies_init(); > > a_Auth_init(); > > > > + dw::Textblock::init (prefs.penalty_hyphen, prefs.penalty_hyphen_2); > > + > > /* command line options override preferences */ > > if (options_got & DILLO_CLI_FULLWINDOW) > > prefs.fullwindow_start = TRUE; > > > > Any thoughts/comments? > > Incidentally, today I was looking into the scrolling step (both > for keyboard and mousewheel/scrollpad), and there's this method: > > void FltkViewport::setScrollStep(int step); > > also CustomButton has: > > void CustomButton::hl_color(Fl_Color col); > > etc. > > AFAICS an init(p1, p2, ...) function is very good for setting > the whole prefs pack at once, but it doesn't seem as convenient > for changing just one of those vars at run time; which may be > necessary for instance if we ever implement a preferences dpi or > enable a custom UI (as with change panel size). > > I'm a bit more inclined towards the separate functions for each > var approach. Yes, probably this is a good idea. However, should these methods be static or not? That is, should it be possible that different instances of dw::Textblock have different values set? One problem is that dw::Textblock is instanciated at a couple of postions, and how configuration looks like eventually is not clear yet; so I'd like to follow a more pragmatical approach to set the at one position in the code. > BTW, your example also implicitly touches this point: dillorc > may set a certain value, and a CLI parameter override it. In this > case the separate functions approach seems cleaner. Does this affect the following arguments? When called dillo --opt1 url1 --opt2 url2 should --opt2 only affect url2 or also url1? In the former case, non-static configuration is indeed necessary. Sebastian

Nov. 16, 2012

Handling preferences

by corvid＠lavabit.com

This reminds me that we still have #define prefs_show_msg 1 in lout/msg.h

Nov. 15, 2012

Handling preferences

by jcid＠dillo.org

Hi Sebastian, On Thu, Nov 15, 2012 at 01:42:29PM +0100, Sebastian Geerken wrote: > Hi! > > I'm just working on making some values related to hyphenation > configurable via dillorc. A long time ago (before the Fltk port), Dw > directy accessed the prefs module for the value limit_text_width. When > Dw was ported to Fltk (which was largely a rewrite), it was seperated, > so it does not depend on prefs anymore. However, this made it > necessary to pass the value of prefs.limit_text_width to dw::Textblock > in the constructor. > > Now, I do not want to extend dw::Textblock::Textblock() by a couple of > new parameters. Instead, I though of storing the values directly in Dw > (initialized by feasable standard values), and the prefs parser must > store them there. This way, Dw is still independent. This could be > adapted in other modules. > > Currenty, my code is this: > > 1. The new values are still stored in DilloPrefs. > > 2. There is a static method dw::Textblock::init, which called in main, > after the prefs parser: > > @@ -50,6 +50,7 @@ > #include "auth.h" > > #include "dw/fltkcore.hh" > +#include "dw/textblock.hh" > > /* > * Command line options structure > @@ -359,6 +360,8 @@ > a_Cookies_init(); > a_Auth_init(); > > + dw::Textblock::init (prefs.penalty_hyphen, prefs.penalty_hyphen_2); > + > /* command line options override preferences */ > if (options_got & DILLO_CLI_FULLWINDOW) > prefs.fullwindow_start = TRUE; > > Any thoughts/comments? Incidentally, today I was looking into the scrolling step (both for keyboard and mousewheel/scrollpad), and there's this method: void FltkViewport::setScrollStep(int step); also CustomButton has: void CustomButton::hl_color(Fl_Color col); etc. AFAICS an init(p1, p2, ...) function is very good for setting the whole prefs pack at once, but it doesn't seem as convenient for changing just one of those vars at run time; which may be necessary for instance if we ever implement a preferences dpi or enable a custom UI (as with change panel size). I'm a bit more inclined towards the separate functions for each var approach. BTW, your example also implicitly touches this point: dillorc may set a certain value, and a CLI parameter override it. In this case the separate functions approach seems cleaner. -- Cheers Jorge.-

Nov. 15, 2012

Handling preferences

by sgeerken＠dillo.org

Hi! I'm just working on making some values related to hyphenation configurable via dillorc. A long time ago (before the Fltk port), Dw directy accessed the prefs module for the value limit_text_width. When Dw was ported to Fltk (which was largely a rewrite), it was seperated, so it does not depend on prefs anymore. However, this made it necessary to pass the value of prefs.limit_text_width to dw::Textblock in the constructor. Now, I do not want to extend dw::Textblock::Textblock() by a couple of new parameters. Instead, I though of storing the values directly in Dw (initialized by feasable standard values), and the prefs parser must store them there. This way, Dw is still independent. This could be adapted in other modules. Currenty, my code is this: 1. The new values are still stored in DilloPrefs. 2. There is a static method dw::Textblock::init, which called in main, after the prefs parser: @@ -50,6 +50,7 @@ #include "auth.h" #include "dw/fltkcore.hh" +#include "dw/textblock.hh" /* * Command line options structure @@ -359,6 +360,8 @@ a_Cookies_init(); a_Auth_init(); + dw::Textblock::init (prefs.penalty_hyphen, prefs.penalty_hyphen_2); + /* command line options override preferences */ if (options_got & DILLO_CLI_FULLWINDOW) prefs.fullwindow_start = TRUE; Any thoughts/comments? Sebastian

Nov. 15, 2012

fill in that little square that the scrollbars form

by sgeerken＠dillo.org

On Wed, Nov 14, corvid wrote: > I don't know this drawing/damage code well enough to know whether this > is the best way to go about it, but it appears to work. Looks correct to me. Feel free to commit. Sebastian

Nov. 14, 2012

Tooltip bugs revisited

by jcid＠dillo.org

Hi, After some more testing I decided to commit the custom tooltip handler patchset for you to try. I has worked very well here so far. Please see details with: $hg log -v :-) -- Cheers Jorge.-

Nov. 14, 2012

fill in that little square that the scrollbars form

by corvid＠lavabit.com

I don't know this drawing/damage code well enough to know whether this is the best way to go about it, but it appears to work.

Nov. 14, 2012

Tooltip bugs revisited

by corvid＠lavabit.com

Jorge wrote: > On Sun, Nov 11, 2012 at 09:18:08PM +0000, corvid wrote: > > Jorge wrote: > > > Testing revealed the workaround concealed another problem, > > > which I don't remember whether it was detected before, and this > > > is that viewport mouse events get "through" the panel UI!. > > > > > > How?, placing the mouse pointer over the panel (e.g. to the > > > right of the Tools button, or even inside the Location), and > > > scrolling a page full of links under it, will make the mouse > > > pointer change to a hand, and the destination link appear in the > > > status bar area. > > > > > > This bug is revealed by disabling the workaround: just apply > > > the small attached patch. > > > > > > Clearly there's a viewport offset problem somewhere. Correcting > > > it may save us lots of headaches in the future. > > > > > > Does anybody know or has a clue of where this may be happening? > > > > > > TIA. > > > > Does this work for you? > > > diff -r 8b4259cdc6da dw/fltkviewport.cc > > --- a/dw/fltkviewport.cc Sat Nov 10 17:55:34 2012 +0000 > > +++ b/dw/fltkviewport.cc Sun Nov 11 21:14:40 2012 +0000 > > @@ -318,6 +318,10 @@ > > mouse_y = Fl::event_y(); > > positionChanged(); > > break; > > + > > + case FL_LEAVE: > > + mouse_x = mouse_y = -1; > > + break; > > } > > > > return FltkWidgetView::handle (event); > > Yes! It works. > > Please elaborate a bit. > > Some history: FLTK2 had widget coordinates relative to the > parent. When we ported dillo to FLTK-1.3 which has absolute > coords, a bunch of offset problems sprung here and there. I > remember hunting/fixing most of them. > > I thought this bug could be related to widget offsets, although > that's just one possibility, not a certainty. I had removed that code in the recent text selection / scrolling changes because I no longer thought I had any need for it, but: FltkViewport::scrollTo() calls positionChanged(), and it still remembered old mouse_x,mouse_y values from when the pointer was in the viewport.

Nov. 12, 2012

Tooltip bugs revisited

by jcid＠dillo.org

On Sun, Nov 11, 2012 at 09:18:08PM +0000, corvid wrote: > Jorge wrote: > > Testing revealed the workaround concealed another problem, > > which I don't remember whether it was detected before, and this > > is that viewport mouse events get "through" the panel UI!. > > > > How?, placing the mouse pointer over the panel (e.g. to the > > right of the Tools button, or even inside the Location), and > > scrolling a page full of links under it, will make the mouse > > pointer change to a hand, and the destination link appear in the > > status bar area. > > > > This bug is revealed by disabling the workaround: just apply > > the small attached patch. > > > > Clearly there's a viewport offset problem somewhere. Correcting > > it may save us lots of headaches in the future. > > > > Does anybody know or has a clue of where this may be happening? > > > > TIA. > > Does this work for you? > diff -r 8b4259cdc6da dw/fltkviewport.cc > --- a/dw/fltkviewport.cc Sat Nov 10 17:55:34 2012 +0000 > +++ b/dw/fltkviewport.cc Sun Nov 11 21:14:40 2012 +0000 > @@ -318,6 +318,10 @@ > mouse_y = Fl::event_y(); > positionChanged(); > break; > + > + case FL_LEAVE: > + mouse_x = mouse_y = -1; > + break; > } > > return FltkWidgetView::handle (event); Yes! It works. Please elaborate a bit. Some history: FLTK2 had widget coordinates relative to the parent. When we ported dillo to FLTK-1.3 which has absolute coords, a bunch of offset problems sprung here and there. I remember hunting/fixing most of them. I thought this bug could be related to widget offsets, although that's just one possibility, not a certainty. -- Cheers Jorge.-

Nov. 12, 2012

tab state

by corvid＠lavabit.com

How much trouble would it be to make tabs show whether they are - waiting for reply - receiving data - done It'd be quite useful...

Nov. 11, 2012

Tooltip bugs revisited

by corvid＠lavabit.com

Jorge wrote: > Testing revealed the workaround concealed another problem, > which I don't remember whether it was detected before, and this > is that viewport mouse events get "through" the panel UI!. > > How?, placing the mouse pointer over the panel (e.g. to the > right of the Tools button, or even inside the Location), and > scrolling a page full of links under it, will make the mouse > pointer change to a hand, and the destination link appear in the > status bar area. > > This bug is revealed by disabling the workaround: just apply > the small attached patch. > > Clearly there's a viewport offset problem somewhere. Correcting > it may save us lots of headaches in the future. > > Does anybody know or has a clue of where this may be happening? > > TIA. Does this work for you?

Nov. 11, 2012

Tooltip bugs revisited

by jcid＠dillo.org

Hi there, These days I've devoted some more effort to the tooltips bug [1] and its workaround patch [2]. The motivation is that the current workaround involves a full UI and viewport expose (i.e. a full erase/redraw) that produces annoying flickering when the mouse is in the UI but outside the viewport (e.g. over the panel). Over time I've learnt to move the mouse pointer outside the panel and into the viewport to scroll without flickering (but probably I'm among the few that know this trick). So far (and despite the warning inside FLTK), I've experimented with a custom tooltip handling class, and a couple custom UI widgets, that seem to work well together (i.e. solve the problem without the workaround :) ). Testing revealed the workaround concealed another problem, which I don't remember whether it was detected before, and this is that viewport mouse events get "through" the panel UI!. How?, placing the mouse pointer over the panel (e.g. to the right of the Tools button, or even inside the Location), and scrolling a page full of links under it, will make the mouse pointer change to a hand, and the destination link appear in the status bar area. This bug is revealed by disabling the workaround: just apply the small attached patch. Clearly there's a viewport offset problem somewhere. Correcting it may save us lots of headaches in the future. Does anybody know or has a clue of where this may be happening? TIA. [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-July/008494.html [2] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-July/008515.html -- Cheers Jorge.-

Nov. 11, 2012

fltk linkage

by corvid＠lavabit.com

Jorge wrote: > On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > > > In September 2011, I wrote: > > > Do we still have a reason for telling people to stick with > > > static linkage when building fltk? > > > > I was thinking about what our installation instructions should look like > > these days, and how everyone has a decent chance of having a fltk-1.3 > > package available and it may not be best to tell them to run off and > > compile fltk unless fltk-config --version doesn't tell them any good news > > and they can't get a pkg... and this led me to wonder about the > > necessity/appropriateness of static linking. > > > > All that I found in the archive was me wondering about it last year and > > no one replying to me. Well, except this now. I'm replying to me, if that > > counts. > > FWIW, I build in a Debian system now and: > > $ ldd dillo > [...] > libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000) > libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000) > [...] > > I thought this meant it was linked with a shared version of FLTK. > What am I missing? *digs through fltk for a minute* So it's a matter of whether fltk is configured with --enable-shared, then? The main page of the website still says "statically-linked by default!", and all along I've had the impression that it had to do with the form of how we link in the Makefile. I guess it makes sense to rm that mention from the website, then. I could've sworn that it was in our documentation somewhere, too, but I don't see it anywhere at the moment. PS I think we will be able to get rid of the warning about --enable-cairo , since it doesn't seem to do anything bad with fltk-1.3.

Nov. 10, 2012

fltk linkage

by jcid＠dillo.org

On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > In September 2011, I wrote: > > Do we still have a reason for telling people to stick with > > static linkage when building fltk? > > I was thinking about what our installation instructions should look like > these days, and how everyone has a decent chance of having a fltk-1.3 > package available and it may not be best to tell them to run off and > compile fltk unless fltk-config --version doesn't tell them any good news > and they can't get a pkg... and this led me to wonder about the > necessity/appropriateness of static linking. > > All that I found in the archive was me wondering about it last year and > no one replying to me. Well, except this now. I'm replying to me, if that > counts. FWIW, I build in a Debian system now and: $ ldd dillo [...] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000) libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000) [...] I thought this meant it was linked with a shared version of FLTK. What am I missing? -- Cheers Jorge.-

Nov. 10, 2012

fltk linkage

by Johannes.Hofmann＠gmx.de

On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > In September 2011, I wrote: > > Do we still have a reason for telling people to stick with > > static linkage when building fltk? > > I was thinking about what our installation instructions should look like > these days, and how everyone has a decent chance of having a fltk-1.3 > package available and it may not be best to tell them to run off and > compile fltk unless fltk-config --version doesn't tell them any good news > and they can't get a pkg... and this led me to wonder about the > necessity/appropriateness of static linking. > > All that I found in the archive was me wondering about it last year and > no one replying to me. Well, except this now. I'm replying to me, if that > counts. I would leave the decision to link statically or not to the package maintainers of the various distros. They will do anyway what they consider best.

Nov. 10, 2012

fltk linkage

by corvid＠lavabit.com

In September 2011, I wrote: > Do we still have a reason for telling people to stick with > static linkage when building fltk? I was thinking about what our installation instructions should look like these days, and how everyone has a decent chance of having a fltk-1.3 package available and it may not be best to tell them to run off and compile fltk unless fltk-config --version doesn't tell them any good news and they can't get a pkg... and this led me to wonder about the necessity/appropriateness of static linking. All that I found in the archive was me wondering about it last year and no one replying to me. Well, except this now. I'm replying to me, if that counts.

Nov. 10, 2012

dFree()

by p37sitdu＠lavabit.com

On Fri, Nov 09, 2012 at 05:18:45PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Nov 09, 2012 at 12:47:14AM +0000, corvid wrote: > > > > > > If dFree() is just free() now, is there a good reason not to remove it? > > > > Yes, it matches dNew & dNew0 (mnemonic). > > > > Also, it gets simpler to profile/debug memory allocation, > > by instrumenting those primitives. > > How about #define dFree() as free(), then? Or #define free when you need to debug. Or use LD_PRELOAD.

Nov. 9, 2012

dFree()

by corvid＠lavabit.com

Jorge wrote: > On Fri, Nov 09, 2012 at 12:47:14AM +0000, corvid wrote: > > > > If dFree() is just free() now, is there a good reason not to remove it? > > Yes, it matches dNew & dNew0 (mnemonic). > > Also, it gets simpler to profile/debug memory allocation, > by instrumenting those primitives. How about #define dFree() as free(), then?

Nov. 9, 2012

dFree()

by jcid＠dillo.org

On Fri, Nov 09, 2012 at 12:47:14AM +0000, corvid wrote: > > If dFree() is just free() now, is there a good reason not to remove it? Yes, it matches dNew & dNew0 (mnemonic). Also, it gets simpler to profile/debug memory allocation, by instrumenting those primitives. -- Cheers Jorge.-

Nov. 9, 2012

dFree()

by corvid＠lavabit.com

If dFree() is just free() now, is there a good reason not to remove it?

Nov. 9, 2012

Tab closing order

by jcid＠dillo.org

On Thu, Nov 08, 2012 at 03:22:47AM +0000, corvid wrote: > > The valgrind logs found something with this: > http://starurchin.org/dillo/valgrind/b8b4ffc070d8c2dc439c384f0b9d7a57fe5ee6… > > I think line 337 in Jeremy's dillo corresponds to 326 in stock dillo, which > would be "if (btn->focus_num() > fbtn->focus_num())", so probably tabs that > have never been focused just need a focus_num of 0 or something... Patch committed. -- Cheers Jorge.-

Nov. 8, 2012

hyphenation in dillo

by sgeerken＠dillo.org

On Wed, Nov 07, corvid wrote: > Sebastian wrote: > > On Mon, Sep 10, corvid wrote: > > > I was looking at the src for http://distrowatch.com , and the > > > source page is very wide -- wider than any lines, so far as I > > > could see. > > > > There is one line, which is very long (number 54), but the current > > release breaks this line into multiple ones. Can someone provide > > details about the vsource plugin? > > The vsource page has > <style type="text/css">PRE {white-space: pre-wrap} > and the css2 spec says > "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces > (U+0020) unbroken by an element boundary is treated as a sequence of > non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity > exists at the end of the sequence." So "pre-wrap" can be broken. Fixed. Sebastian

Nov. 8, 2012

fltk release

by onepoint＠starurchin.org

corvid wrote: > I was thinking of making README and the website not so > 1.3.0-specific now that 1.3.1 is out, but it would be nice to get a > few reports of it working fine for you first. I just upgraded. I'll report next weeek whether anything has broken. Regards, Jeremy Henty

Nov. 8, 2012

Tab closing order

by corvid＠lavabit.com

The valgrind logs found something with this: http://starurchin.org/dillo/valgrind/b8b4ffc070d8c2dc439c384f0b9d7a57fe5ee6… I think line 337 in Jeremy's dillo corresponds to 326 in stock dillo, which would be "if (btn->focus_num() > fbtn->focus_num())", so probably tabs that have never been focused just need a focus_num of 0 or something...

Nov. 8, 2012

'#' in file url

by corvid＠lavabit.com

Jorge wrote: > Please check the committed patch. I added the change for the open file dialog as well...

Nov. 8, 2012

fltk release

by corvid＠lavabit.com

I was thinking of making README and the website not so 1.3.0-specific now that 1.3.1 is out, but it would be nice to get a few reports of it working fine for you first. (I update from their repository from time to time, and all has been well here.)

Nov. 8, 2012

'#' in file url

by jcid＠dillo.org

On Wed, Nov 07, 2012 at 08:05:54PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Nov 07, 2012 at 05:41:12PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Wed, Nov 07, 2012 at 03:20:20AM +0000, corvid wrote: > > > > > > > > > > I had two files with '#' in their names that I wanted to view -- > > > > > file#1.png and file#2.png -- and dillo showed me the same file in > > > > > each tab. > > > > > > > > That's because '#' is not a valid character inside a URL. > > > [snip] > > > > i.e. anything after '#' is a 'fragment'. > > > > > > > > and BTW, that's why the file dpi escapes '#' as '%23' to be able > > > > to show the file. > > > > > > Right, it may be %23 at some point in its journey, but it's back to > > > '#' eventually -- and breaks. > > > > I tried: > > > > $ echo "hello" > /tmp/a#b > > $ dillo /tmp > > <click on the file link> > > > > and it works. > > If you make two files, a#1 and a#2, then run > dillo a#1 a#2 > you won't be shown two different files. Please check the committed patch. -- Cheers Jorge.-

Nov. 8, 2012

hyphenation in dillo

by corvid＠lavabit.com

Sebastian wrote: > On Mon, Sep 10, corvid wrote: > > I was looking at the src for http://distrowatch.com , and the > > source page is very wide -- wider than any lines, so far as I > > could see. > > There is one line, which is very long (number 54), but the current > release breaks this line into multiple ones. Can someone provide > details about the vsource plugin? The vsource page has <style type="text/css">PRE {white-space: pre-wrap} and the css2 spec says "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity exists at the end of the sequence."

Nov. 7, 2012

hyphenation in dillo

by sgeerken＠dillo.org

On Mon, Sep 10, corvid wrote: > I was looking at the src for http://distrowatch.com , and the > source page is very wide -- wider than any lines, so far as I > could see. There is one line, which is very long (number 54), but the current release breaks this line into multiple ones. Can someone provide details about the vsource plugin? Sebastian

Nov. 7, 2012

hyphenation in dillo

by sgeerken＠dillo.org

On Wed, Oct 31, corvid wrote: > With tip, I can't see the option in: > > <div> > <select> > <option value="100">object</option> > </select> > </div> > > With a dillo that I have around from right before the hyphenation merge, > the option appears. Fixed. Sebastian

Nov. 7, 2012

'#' in file url

by corvid＠lavabit.com

Jorge wrote: > On Wed, Nov 07, 2012 at 05:41:12PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Nov 07, 2012 at 03:20:20AM +0000, corvid wrote: > > > > > > > > I had two files with '#' in their names that I wanted to view -- > > > > file#1.png and file#2.png -- and dillo showed me the same file in > > > > each tab. > > > > > > That's because '#' is not a valid character inside a URL. > > [snip] > > > i.e. anything after '#' is a 'fragment'. > > > > > > and BTW, that's why the file dpi escapes '#' as '%23' to be able > > > to show the file. > > > > Right, it may be %23 at some point in its journey, but it's back to > > '#' eventually -- and breaks. > > I tried: > > $ echo "hello" > /tmp/a#b > $ dillo /tmp > <click on the file link> > > and it works. If you make two files, a#1 and a#2, then run dillo a#1 a#2 you won't be shown two different files.

Nov. 7, 2012

'#' in file url

by jcid＠dillo.org

On Wed, Nov 07, 2012 at 05:41:12PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Nov 07, 2012 at 03:20:20AM +0000, corvid wrote: > > > > > > I had two files with '#' in their names that I wanted to view -- > > > file#1.png and file#2.png -- and dillo showed me the same file in > > > each tab. > > > > That's because '#' is not a valid character inside a URL. > [snip] > > i.e. anything after '#' is a 'fragment'. > > > > and BTW, that's why the file dpi escapes '#' as '%23' to be able > > to show the file. > > Right, it may be %23 at some point in its journey, but it's back to > '#' eventually -- and breaks. I tried: $ echo "hello" > /tmp/a#b $ dillo /tmp <click on the file link> and it works. -- Cheers Jorge.-

Nov. 7, 2012

' and xhtml

by jcid＠dillo.org

On Wed, Nov 07, 2012 at 05:50:44PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Nov 05, 2012 at 11:53:06PM +0000, corvid wrote: > > > > > > Jeremy wanted to add apos a long time ago, and it didn't happen then, > > > but we did give in and accept application/xhtml+xml--let's see--two > > > years ago now, so I wonder whether conditions have changed. > > > > Yep, things change in time... > > > > Although HTML 4.01 and other SPECS never succeeded to the point > > of making serving valid HTML/XHTML a rule of thumb, or best > > practice, things seem to have improved a bit since our early days > > (just my perception out of finding more and more dillo-readable > > sites these days). > > > > Escaping ' as APOS finds a solid reason in server contexts > > where there's a need to accept untrusted input for scripts or > > databases. > > > > I'd say, +1, feel free to commit. > > > > > > PS: Please post a sample URL. Just to get the feel of it. ;) > > It was brought to mind when I couldn't retrieve mail the other day > and checked http://lavabit.com . One of the news bits says > "We've updated our SSL certificate." > > > > Hmmm.... looking at the source now, I see that, on one hand, it has > > <?xml version="1.0" encoding="utf-8"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > > ..but, on the other hand, it says > > <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> > > ..instead of application/xhtml+xml. Yes, that's the state of things these days... There's almost no other way than heuristics -- Cheers Jorge.-

Nov. 7, 2012

' and xhtml

by corvid＠lavabit.com

Jorge wrote: > On Mon, Nov 05, 2012 at 11:53:06PM +0000, corvid wrote: > > > > Jeremy wanted to add apos a long time ago, and it didn't happen then, > > but we did give in and accept application/xhtml+xml--let's see--two > > years ago now, so I wonder whether conditions have changed. > > Yep, things change in time... > > Although HTML 4.01 and other SPECS never succeeded to the point > of making serving valid HTML/XHTML a rule of thumb, or best > practice, things seem to have improved a bit since our early days > (just my perception out of finding more and more dillo-readable > sites these days). > > Escaping ' as APOS finds a solid reason in server contexts > where there's a need to accept untrusted input for scripts or > databases. > > I'd say, +1, feel free to commit. > > > PS: Please post a sample URL. Just to get the feel of it. ;) It was brought to mind when I couldn't retrieve mail the other day and checked http://lavabit.com . One of the news bits says "We've updated our SSL certificate." Hmmm.... looking at the source now, I see that, on one hand, it has <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> ..but, on the other hand, it says <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ..instead of application/xhtml+xml.

Nov. 7, 2012

'#' in file url

by corvid＠lavabit.com

Jorge wrote: > On Wed, Nov 07, 2012 at 03:20:20AM +0000, corvid wrote: > > > > I had two files with '#' in their names that I wanted to view -- > > file#1.png and file#2.png -- and dillo showed me the same file in > > each tab. > > That's because '#' is not a valid character inside a URL. [snip] > i.e. anything after '#' is a 'fragment'. > > and BTW, that's why the file dpi escapes '#' as '%23' to be able > to show the file. Right, it may be %23 at some point in its journey, but it's back to '#' eventually -- and breaks.

Nov. 7, 2012

' and xhtml

by jcid＠dillo.org

On Mon, Nov 05, 2012 at 11:53:06PM +0000, corvid wrote: > > Jeremy wanted to add apos a long time ago, and it didn't happen then, > but we did give in and accept application/xhtml+xml--let's see--two > years ago now, so I wonder whether conditions have changed. Yep, things change in time... Although HTML 4.01 and other SPECS never succeeded to the point of making serving valid HTML/XHTML a rule of thumb, or best practice, things seem to have improved a bit since our early days (just my perception out of finding more and more dillo-readable sites these days). Escaping ' as APOS finds a solid reason in server contexts where there's a need to accept untrusted input for scripts or databases. I'd say, +1, feel free to commit. PS: Please post a sample URL. Just to get the feel of it. ;) -- Cheers Jorge.-

Nov. 7, 2012

'#' in file url

by jcid＠dillo.org

On Wed, Nov 07, 2012 at 03:20:20AM +0000, corvid wrote: > > I had two files with '#' in their names that I wanted to view -- > file#1.png and file#2.png -- and dillo showed me the same file in > each tab. That's because '#' is not a valid character inside a URL. Technically: /* * Regular Expression as given in RFC3986 for URL parsing. * * ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? * 12 3 4 5 6 7 8 9 * * scheme = $2 * authority = $4 * path = $5 * query = $7 * fragment = $9 * [...] i.e. anything after '#' is a 'fragment'. and BTW, that's why the file dpi escapes '#' as '%23' to be able to show the file. HTH. -- Cheers Jorge.-

Nov. 7, 2012

'#' in file url

by corvid＠lavabit.com

I had two files with '#' in their names that I wanted to view -- file#1.png and file#2.png -- and dillo showed me the same file in each tab.

Nov. 7, 2012