- Dillo-dev - lists.mailman3.com

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