- Dillo-dev - lists.mailman3.com

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