November 2012 - Dillo-dev - lists.mailman3.com

pedantic (Re: soft hyphen and hyphenation)

by corvid＠lavabit.com

Sebastian wrote: > On Mon, Nov 26, corvid wrote: > > I just wanted to mention that if you compile with -pedantic, > > I get 633 warnings when I compile with -pedantic. :-) Yeah, I went through maybe a month ago and fixed a few assorted ones, but the rest fell into a couple of categories that seemed best left alone...

Nov. 27, 2012

soft hyphen and hyphenation

by sgeerken＠dillo.org

On Mon, Nov 26, corvid wrote: > I just wanted to mention that if you compile with -pedantic, I get 633 warnings when I compile with -pedantic. :-) > it complains like > > textblock.cc:941:22: warning: overflow in implicit constant conversion [-Woverflow] > > about > > text[p++] = 0xe2; > text[p++] = 0x80; > text[p++] = 0x90; I don't know how to deal best with this, but following change seems to work: text[p++] = '\xe2'; text[p++] = '\x80'; text[p++] = '\x90'; Sebastian

Nov. 27, 2012

soft hyphen and hyphenation

by corvid＠lavabit.com

I just wanted to mention that if you compile with -pedantic, it complains like textblock.cc:941:22: warning: overflow in implicit constant conversion [-Woverflow] about text[p++] = 0xe2; text[p++] = 0x80; text[p++] = 0x90;

Nov. 26, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

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

Nov. 26, 2012

soft hyphen and hyphenation

by sgeerken＠dillo.org

On Mon, Nov 26, Johannes Hofmann wrote: > is it correct that we use a soft hyphen (0xc2 0xad) to draw the > hyphen when breaking words? It seems to draw ok with fltk/X11, but > wouldn't an unconditional hyphen 0xE2 0x80 0x90 be more correct? > I'm asking because e.g the Apple drawing library doesn't seem to > draw the soft hyphen if it thinks there should be no line break. I see no problem with using unconditional breaks, and it seems to work well with fltk/X11, so I've pushed the changes to hg.dillo.org. (BTW: unconditional hyphens should also added do dillo_hyphen.) Sebastian

Nov. 26, 2012

soft hyphen and hyphenation

by Johannes.Hofmann＠gmx.de

Hi, is it correct that we use a soft hyphen (0xc2 0xad) to draw the hyphen when breaking words? It seems to draw ok with fltk/X11, but wouldn't an unconditional hyphen 0xE2 0x80 0x90 be more correct? I'm asking because e.g the Apple drawing library doesn't seem to draw the soft hyphen if it thinks there should be no line break. Cheers, Johannes

Nov. 26, 2012

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