- Dillo-dev - lists.mailman3.com

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