- Dillo-dev - lists.mailman3.com

hyphenation pattern files

by sgeerken＠dillo.org

On Tue, Nov 06, corvid wrote: > Speaking of keeping things small, doc/not-so-simple-container.png is > currently 150K. I've reduced the colors: now it is only 16K. (Whoever is good at using drawing software is welcome to replace this.) Sebastian

Nov. 6, 2012

hyphenation pattern files

by corvid＠lavabit.com

Johannes wrote: > On Tue, Nov 06, 2012 at 01:39:21AM +0000, corvid wrote: > > > > What do we plan to distribute? > > Not sure. Any opinions? I wonder whether it would make sense to gather lots of hyphenation files into a separate .tar.gz or something. Speaking of keeping things small, doc/not-so-simple-container.png is currently 150K.

Nov. 6, 2012

Tab closing order

by jcid＠dillo.org

Hi there, Just committed a patch that improves the workflow for those of use that make regular use of tabbed browsing. Now, upon closing the active tab, the browser focuses the previously visited one (before it was just an adjacent one). Dillo now remembers the full focus history of them. I hope you like it as much as I do. ;) -- Cheers Jorge.-

Nov. 6, 2012

hyphenation pattern files

by johannes.hofmann＠gmx.de

On Tue, Nov 06, 2012 at 01:39:21AM +0000, corvid wrote: > > What do we plan to distribute? Not sure. Any opinions? > > I was looking up where the ones in test/ come from, and for instance > http://mirrors.ctan.org/language/hyphenation/ushyph/ushyph.tex says: > > % Copyright (C) 1990, 2004, 2005 Gerard D.C. Kuiken. > % Copying and distribution of this file, with or without modification, > % are permitted in any medium without royalty provided the copyright > % notice and this notice are preserved. > > ..but we just have this bare pattern list available in the repository. Good point. I will fix that. Cheers, Johannes

Nov. 6, 2012

hyphenation pattern files

by corvid＠lavabit.com

What do we plan to distribute? I was looking up where the ones in test/ come from, and for instance http://mirrors.ctan.org/language/hyphenation/ushyph/ushyph.tex says: % Copyright (C) 1990, 2004, 2005 Gerard D.C. Kuiken. % Copying and distribution of this file, with or without modification, % are permitted in any medium without royalty provided the copyright % notice and this notice are preserved. ..but we just have this bare pattern list available in the repository.

Nov. 6, 2012

' and xhtml

by corvid＠lavabit.com

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.

Nov. 5, 2012

Changes in hyphenation

by jcid＠dillo.org

Hi Sebastian, On Fri, Nov 02, 2012 at 04:04:52PM +0100, Sebastian Geerken wrote: > On Fri, Nov 02, Sebastian Geerken wrote: > [...] > Johannes patch is (with some changes) applied. I have no problems with the latest patch. The code respects PRE formatted code inserting a horizontal scroll when necessary. FWIW, without this last patch, I had problems with the attached test case. BTW, what will happen with HTML pages that quote full-paragraph-in-one-line emails with PRE? (unfortunately I don't have an example page at hand). -- Cheers Jorge.-

Nov. 3, 2012

Changes in hyphenation

by furaisanjin＠gmail.com

2012/11/3 Sebastian Geerken <sgeerken at dillo.org>: > On Fri, Nov 02, Sebastian Geerken wrote: > Johannes patch is (with some changes) applied. Furaisanjin: are there > still issues? Now dillo is much better but still http://news.google.co.jp shows the issue. There are 3 columns in main area but balance of them aren't suitable to fit them on one screen so that horizontal scroll bar appears. Another language page like http://news.google.com/news?ned=uk has same appearance. Regards, furaisanjin

Nov. 3, 2012

Changes in hyphenation

by sgeerken＠dillo.org

On Fri, Nov 02, Sebastian Geerken wrote: > On Mon, Oct 29, Johannes Hofmann wrote: > > On Mon, Oct 29, 2012 at 08:08:16PM +0100, Sebastian Geerken wrote: > > > I just pulled some change to make <pre> work. Please test it again, > > > even things which have worked recently, so that we can be sure that > > > nothing is broken again. > > > > Works very nice for me! With the following change: > > > > diff -r 5e7a06855f37 dw/textblock.hh > > --- a/dw/textblock.hhMon Oct 29 20:05:20 2012 +0100 > > +++ b/dw/textblock.hhMon Oct 29 22:23:15 2012 +0100 > > @@ -552,8 +552,7 @@ > > { > > if (style->whiteSpace != core::style::WHITE_SPACE_NOWRAP && > > style->whiteSpace != core::style::WHITE_SPACE_PRE) > > - if (word->badnessAndPenalty.lineMustBeBroken()) > > - word->badnessAndPenalty.setPenalty (0); > > + word->badnessAndPenalty.setPenalty (0); > > } > > > > void addHyphen(); > > > > ideographic characters also seem to work again, but I'm not sure > > about all the side-effects. > > Er ... this patch modifies Textblock::addBreakOption(), which is not > used anymore (neither of the two variants), so how can this change > anything? Sorry, I see it now. Johannes patch is (with some changes) applied. Furaisanjin: are there still issues? Sebastian

Nov. 2, 2012

Changes in hyphenation

by sgeerken＠dillo.org

On Mon, Oct 29, Johannes Hofmann wrote: > On Mon, Oct 29, 2012 at 08:08:16PM +0100, Sebastian Geerken wrote: > > I just pulled some change to make <pre> work. Please test it again, > > even things which have worked recently, so that we can be sure that > > nothing is broken again. > > Works very nice for me! With the following change: > > diff -r 5e7a06855f37 dw/textblock.hh > --- a/dw/textblock.hhMon Oct 29 20:05:20 2012 +0100 > +++ b/dw/textblock.hhMon Oct 29 22:23:15 2012 +0100 > @@ -552,8 +552,7 @@ > { > if (style->whiteSpace != core::style::WHITE_SPACE_NOWRAP && > style->whiteSpace != core::style::WHITE_SPACE_PRE) > - if (word->badnessAndPenalty.lineMustBeBroken()) > - word->badnessAndPenalty.setPenalty (0); > + word->badnessAndPenalty.setPenalty (0); > } > > void addHyphen(); > > ideographic characters also seem to work again, but I'm not sure > about all the side-effects. Er ... this patch modifies Textblock::addBreakOption(), which is not used anymore (neither of the two variants), so how can this change anything? Sebastian

Nov. 2, 2012

Keyboard shortcuts for (long) options menu

by jcid＠dillo.org

On Thu, Nov 01, 2012 at 06:14:46PM +0000, corvid wrote: > Jorge wrote: > > BTW, I remember corvid made a comment on this long ago, but > > couldn't find the post... > > This doesn't immediately sound familiar to me... IIRC it was something along the lines of something you'd like to have but had not time enough to devote to. -- Cheers Jorge.-

Nov. 1, 2012

Keyboard shortcuts for (long) options menu

by corvid＠lavabit.com

Jorge wrote: > BTW, I remember corvid made a comment on this long ago, but > couldn't find the post... This doesn't immediately sound familiar to me...

Nov. 1, 2012

Keyboard shortcuts for (long) options menu

by jcid＠dillo.org

Hi there, I Just committed a patch for those long option menus that take a long time to scroll to the desired item. It jumps to the next menuitem whose label starts with the pressed key. If there's more than one item starting with the same letter, it goes to the next one, then wraps. This works when the OPTION menu is _focused_, not displayed. FLTK has a hacked way of handling menus which will change in FLTK3 [1] [2] (It still amazes me how some simple things can take so much guess work with FLTK). Making shortcuts work when the menu is displayed would involve copying a lot of code and dealing with hackish FLTK internals, which is not stable, and most probably not worth the effort. It seems wiser to use this workaround until FLTK3 solves the problem [2]. So far it works quite well for a page with a very long option menu I happen to use very often. Please test. How? just focus the option menu with two clicks (one popups, the next one closes it, but leaving it focused), then press the desired key (first letter of your item label), and voila. BTW, I remember corvid made a comment on this long ago, but couldn't find the post... @corvid: you may feel like adding utf8 support. HTH [1] http://fltk.org/newsgroups.php?s1060+gfltk.general+v1070+T0+Qmenu+scrolling [2] http://fltk.org/newsgroups.php?s1080+gfltk.general+v1087+T0+Qmenu+scrolling -- Cheers Jorge.-

Nov. 1, 2012

Changes in hyphenation

by jcid＠dillo.org

Hi Sebastian, On Mon, Oct 29, 2012 at 08:08:16PM +0100, Sebastian Geerken wrote: > Hi! > > I just pulled some change to make <pre> work. Please test it again, > even things which have worked recently, so that we can be sure that > nothing is broken again. What should we test? All of whitespace formatting in PRE? Should we use Johannes' patch? -- Cheers Jorge.-

Oct. 31, 2012

hyphenation in dillo

by corvid＠lavabit.com

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.

Oct. 31, 2012

Changes in hyphenation

by furaisanjin＠gmail.com

Hello all. 2012/10/30 Johannes Hofmann <Johannes.Hofmann at gmx.de>: > Works very nice for me! With the following change: Is this chnage necessary to test ideographic character pages? I just recompiled with changeset 2516:5e7a06855f37 and saw http://www.nhk.or.jp/audio/index.html as I reported last time but I don't see improvement yet. Regards, furaisanjin

Oct. 30, 2012

Changes in hyphenation

by Johannes.Hofmann＠gmx.de

Hi Sebastian, On Mon, Oct 29, 2012 at 08:08:16PM +0100, Sebastian Geerken wrote: > Hi! > > I just pulled some change to make <pre> work. Please test it again, > even things which have worked recently, so that we can be sure that > nothing is broken again. Works very nice for me! With the following change: diff -r 5e7a06855f37 dw/textblock.hh --- a/dw/textblock.hhMon Oct 29 20:05:20 2012 +0100 +++ b/dw/textblock.hhMon Oct 29 22:23:15 2012 +0100 @@ -552,8 +552,7 @@ { if (style->whiteSpace != core::style::WHITE_SPACE_NOWRAP && style->whiteSpace != core::style::WHITE_SPACE_PRE) - if (word->badnessAndPenalty.lineMustBeBroken()) - word->badnessAndPenalty.setPenalty (0); + word->badnessAndPenalty.setPenalty (0); } void addHyphen(); ideographic characters also seem to work again, but I'm not sure about all the side-effects. furaisanjin, could you please test this? Cheers, Johannes

Oct. 29, 2012

Changes in hyphenation

by sgeerken＠dillo.org

Hi! I just pulled some change to make <pre> work. Please test it again, even things which have worked recently, so that we can be sure that nothing is broken again. Sebastian

Oct. 29, 2012

experimental code: highlighting and scrolling

by corvid＠lavabit.com

Johannes wrote: > Maybe 6 could be replaced with scrollbar->linesize()? Yeah, linesize and repeating after 0.025 seems to work well enough for me...

Oct. 21, 2012

experimental code: highlighting and scrolling

by Johannes.Hofmann＠gmx.de

On Sat, Oct 20, 2012 at 08:41:11AM +0000, corvid wrote: > > I was thinking how unpleasant it is when you are highlighting text and > you release the button outside the viewport, and the text doesn't get > copied. (Even harder to keep in mind is when the canvas is shorter than > the viewport, and you go past the bottom of the canvas.) > > > ..and then I wanted to see whether I could make the page scroll when > highlighting outside the viewport like firefox does... Nice! I used to press Space to scoll down while keeping the mouse button pressed. Maybe 6 could be replaced with scrollbar->linesize()? Cheers, Johannes

Oct. 21, 2012

experimental code: highlighting and scrolling

by corvid＠lavabit.com

I was thinking how unpleasant it is when you are highlighting text and you release the button outside the viewport, and the text doesn't get copied. (Even harder to keep in mind is when the canvas is shorter than the viewport, and you go past the bottom of the canvas.) ..and then I wanted to see whether I could make the page scroll when highlighting outside the viewport like firefox does...

Oct. 20, 2012

https unpleasantness

by corvid＠lavabit.com

higuita wrote: > Its really your system, i'm in a slackware64 14.0 and just rebuild > latest fltk, the latest dillo, https dpi and all works fine. That's good. > Are you sure that you dont have a stale https.dpi somewhere? Yup. I don't install dillo, but rather copy the dpi manually into ~/.dillo/dpi/https/ , plus I went through a few rounds of adding debugging info to it and seeing the effects of that info each time.

Oct. 18, 2012

https unpleasantness

by higuita7＠yahoo.co.uk

Hi > > > I recompiled the https dpi today, and it no longer wanted to work. > > > I had upgraded slackware in recent weeks, so my openssl version has > > > gone from 0.9.8x to 1.0.1c, which may or may not be relevant at all. > Yeah, I couldn't imagine that I wouldn't have heard of this before if it > were happening to others... I wonder what's weird about my system... Its really your system, i'm in a slackware64 14.0 and just rebuild latest fltk, the latest dillo, https dpi and all works fine. Are you sure that you dont have a stale https.dpi somewhere? Good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Oct. 18, 2012

https unpleasantness

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > > I recompiled the https dpi today, and it no longer wanted to work. > > > > I had upgraded slackware in recent weeks, so my openssl version has > > gone from 0.9.8x to 1.0.1c, which may or may not be relevant at all. > > I think it is very unlikely to be relevant. I upgraded to 1.0.1c in > mid-August and I have rebuilt Dillo many times since then (pretty much > every time I see a commit). Yeah, I couldn't imagine that I wouldn't have heard of this before if it were happening to others... I wonder what's weird about my system...

Oct. 18, 2012

https unpleasantness

by onepoint＠starurchin.org

corvid wrote: > I recompiled the https dpi today, and it no longer wanted to work. > > I had upgraded slackware in recent weeks, so my openssl version has > gone from 0.9.8x to 1.0.1c, which may or may not be relevant at all. I think it is very unlikely to be relevant. I upgraded to 1.0.1c in mid-August and I have rebuilt Dillo many times since then (pretty much every time I see a commit). Jeremy

Oct. 18, 2012

https unpleasantness

by abe＠deuxchevaux.org

Hi, On Thu, Oct 18, 2012 at 02:32:10AM +0000, corvid wrote: > I had upgraded slackware in recent weeks, so my openssl version > has gone from 0.9.8x to 1.0.1c, which may or may not be relevant > at all. At least on Debian dillo 3.0.2 builds fine with OpenSSL 1.0.1c: http://packages.debian.org/wheezy/dillo http://packages.debian.org/wheezy/libssl1.0.0 (currently version 1.0.1c) Just tried it on an uptodate Debian Unstable. And I don't use any patches against the original source. I just update config.guess, config.sub and friends to the autotools version in Debian. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Oct. 18, 2012

https unpleasantness

by jcid＠dillo.org

On Thu, Oct 18, 2012 at 02:32:10AM +0000, corvid wrote: > > I recompiled the https dpi today, and it no longer wanted to work. > > I had upgraded slackware in recent weeks, so my openssl version > has gone from 0.9.8x to 1.0.1c, which may or may not be relevant > at all. > > The SSL_connect() was failing. > > Adding in some error-printing got me > "error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol". > > The search engine suggested that one possibility was that a server > could be displeased with a cipher that's offered, so I changed > SSL_set_cipher_list(ssl_connection, "ALL"); > to "TLSv1" randomly, and it now worked. > > https://www.openssl.org/docs/apps/ciphers.html shows lots of > possibilities, and I tried "DEFAULT". This worked as well. > It sounds like the difference is that the default doesn't include > aNULL ciphers. Another page says that aNULL means cipher suites > that do not offer authentication. > > I don't really know what's going on here, obviously. Neither me. -- Cheers Jorge.-

Oct. 18, 2012

https unpleasantness

by corvid＠lavabit.com

I recompiled the https dpi today, and it no longer wanted to work. I had upgraded slackware in recent weeks, so my openssl version has gone from 0.9.8x to 1.0.1c, which may or may not be relevant at all. The SSL_connect() was failing. Adding in some error-printing got me "error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol". The search engine suggested that one possibility was that a server could be displeased with a cipher that's offered, so I changed SSL_set_cipher_list(ssl_connection, "ALL"); to "TLSv1" randomly, and it now worked. https://www.openssl.org/docs/apps/ciphers.html shows lots of possibilities, and I tried "DEFAULT". This worked as well. It sounds like the difference is that the default doesn't include aNULL ciphers. Another page says that aNULL means cipher suites that do not offer authentication. I don't really know what's going on here, obviously.

Oct. 18, 2012

website readability/appearance

by corvid＠lavabit.com

Jorge wrote: > What do you think of tmp1 and tmp2? The first one makes me think "for children" somehow. With the second one, I like the gray but not so much the purple...

Oct. 10, 2012

website readability/appearance

by corvid＠lavabit.com

Rogut?s wrote: > I find the colors of corvid's version ok, but the whole visual appearance > looks dated. Do you have any thoughts on what a more contemporary appearance consists of?

Oct. 10, 2012

website readability/appearance

by jcid＠dillo.org

On Wed, Oct 10, 2012 at 08:47:18PM +0300, Rogut??s Sparnuotos wrote: > corvid (2012-10-10 16:49): > > Jorge wrote: > > > IIRC your problem with the current color scheme was fuzzy contrast > > > on your monitor. A technical issue, similar OTOH to high contrast > > > headaches. > > > > Everything appears okay on my current one. The one that I had a few years > > ago had grown dim and reddish. > > > > > AFAIR long ago people preferred the current scheme over presented > > > alternatives, despite the low contrast issue being acknowledged. I > > > assume a trade off for aesthetics. > > > > Part of it is that I would look around to see what people were saying > > about dillo, and there would be comments that the dillo developers must > > be colorblind. And part of it is that, after changing monitors, I > > particularly haven't liked the purple. > > dillo.org colors look very bad to me. The white text on blueish background > would be ok, but the background for headings and the gray color for links > makes it all unbearable to my taste. > > I find the colors of corvid's version ok, but the whole visual appearance > looks dated. > > I am merely a bystander and my intention is to express my opinion, not > criticism. What do you think of the 3 alternatives presented? -- Cheers Jorge.-

Oct. 10, 2012

website readability/appearance

by jcid＠dillo.org

On Wed, Oct 10, 2012 at 04:49:38PM +0000, corvid wrote: > > [...] > > As aesthetics is a matter of personal taste, I've prepared a couple > > of alternatives with better contrast palette: > > > > http://www.dillo.org/test/dillo2.tmp1.html > > http://www.dillo.org/test/dillo2.tmp2.html > > > > I like both over "dillo2.html". > > > > I like tmp1 for its lively colors (though "waterish"), and also > > like tmp2 for its more integrated "airish" palette (a bit "serious" too). > > I looked around the web a little bit at the time with firefox to see what > the style of the day is, and there seemed to be a lot of whites and pale > grays and pale blues. What do you think of tmp1 and tmp2? > > > PS I wonder about the anybrowser gif in the sidebar. It screams 1996 to me. > > > > It can be replaced with something better. > > Let's see... A couple that appeal to me are: > > http://www.anybrowser.org/campaign/bvgraphics/anyb02.png > > http://www.anybrowser.org/campaign/bvgraphics/abblue.gif Yes, both look much better. -- Cheers Jorge.-

Oct. 10, 2012

website readability/appearance

by rogutes＠googlemail.com

corvid (2012-10-10 16:49): > Jorge wrote: > > IIRC your problem with the current color scheme was fuzzy contrast > > on your monitor. A technical issue, similar OTOH to high contrast > > headaches. > > Everything appears okay on my current one. The one that I had a few years > ago had grown dim and reddish. > > > AFAIR long ago people preferred the current scheme over presented > > alternatives, despite the low contrast issue being acknowledged. I > > assume a trade off for aesthetics. > > Part of it is that I would look around to see what people were saying > about dillo, and there would be comments that the dillo developers must > be colorblind. And part of it is that, after changing monitors, I > particularly haven't liked the purple. dillo.org colors look very bad to me. The white text on blueish background would be ok, but the background for headings and the gray color for links makes it all unbearable to my taste. I find the colors of corvid's version ok, but the whole visual appearance looks dated. I am merely a bystander and my intention is to express my opinion, not criticism. -- Rogut?s

Oct. 10, 2012

website readability/appearance

by corvid＠lavabit.com

Jorge wrote: > IIRC your problem with the current color scheme was fuzzy contrast > on your monitor. A technical issue, similar OTOH to high contrast > headaches. Everything appears okay on my current one. The one that I had a few years ago had grown dim and reddish. > AFAIR long ago people preferred the current scheme over presented > alternatives, despite the low contrast issue being acknowledged. I > assume a trade off for aesthetics. Part of it is that I would look around to see what people were saying about dillo, and there would be comments that the dillo developers must be colorblind. And part of it is that, after changing monitors, I particularly haven't liked the purple. > As aesthetics is a matter of personal taste, I've prepared a couple > of alternatives with better contrast palette: > > http://www.dillo.org/test/dillo2.tmp1.html > http://www.dillo.org/test/dillo2.tmp2.html > > I like both over "dillo2.html". > > I like tmp1 for its lively colors (though "waterish"), and also > like tmp2 for its more integrated "airish" palette (a bit "serious" too). I looked around the web a little bit at the time with firefox to see what the style of the day is, and there seemed to be a lot of whites and pale grays and pale blues. > > PS I wonder about the anybrowser gif in the sidebar. It screams 1996 to me. > > It can be replaced with something better. Let's see... A couple that appeal to me are: http://www.anybrowser.org/campaign/bvgraphics/anyb02.png http://www.anybrowser.org/campaign/bvgraphics/abblue.gif

Oct. 10, 2012

website readability/appearance

by jcid＠dillo.org

On Tue, Oct 09, 2012 at 03:15:33AM +0000, corvid wrote: > > Back in February, I was playing around with the website appearance > a bit. Today I happened upon that file again, and I still rather like > the look of it. > > http://www.dillo.org/test/dillo2.html > > Any thoughts? IIRC your problem with the current color scheme was fuzzy contrast on your monitor. A technical issue, similar OTOH to high contrast headaches. AFAIR long ago people preferred the current scheme over presented alternatives, despite the low contrast issue being acknowledged. I assume a trade off for aesthetics. As aesthetics is a matter of personal taste, I've prepared a couple of alternatives with better contrast palette: http://www.dillo.org/test/dillo2.tmp1.html http://www.dillo.org/test/dillo2.tmp2.html I like both over "dillo2.html". I like tmp1 for its lively colors (though "waterish"), and also like tmp2 for its more integrated "airish" palette (a bit "serious" too). > PS I wonder about the anybrowser gif in the sidebar. It screams 1996 to me. It can be replaced with something better. -- Cheers Jorge.-

Oct. 10, 2012

website readability/appearance

by corvid＠lavabit.com

Back in February, I was playing around with the website appearance a bit. Today I happened upon that file again, and I still rather like the look of it. http://www.dillo.org/test/dillo2.html Any thoughts? PS I wonder about the anybrowser gif in the sidebar. It screams 1996 to me.

Oct. 9, 2012

hyphenation and ideographic characters

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Oct 06, 2012 at 01:36:34PM +0900, furaisanjin wrote: > Hi all. > > After hyphenation feature was merged into main branch, line break > doesn't seem to work well for ideographic characters. > > This is screenshot from 2387:81f484e70da6 (I think this is the last > changeset before hyphenation). > > http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/1-c9360.… > > But the current one (2493:f99afbd38ae7) shows something like this. > > http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/2-fe1a8.… > > I added red box to highlight the difference. We had similar problem > before adding a_Utf8_ideographic on Html_process_word in html.cc. > Hyphenation also needs similar checking. Thanks for the detailed bug report. We are currently looking into this issue. I'll let you now once we have something to retest. Regards, Johannes

Oct. 8, 2012

hyphenation and ideographic characters

by furaisanjin＠gmail.com

Hi all. After hyphenation feature was merged into main branch, line break doesn't seem to work well for ideographic characters. This is screenshot from 2387:81f484e70da6 (I think this is the last changeset before hyphenation). http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/1-c9360.… But the current one (2493:f99afbd38ae7) shows something like this. http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/2-fe1a8.… I added red box to highlight the difference. We had similar problem before adding a_Utf8_ideographic on Html_process_word in html.cc. Hyphenation also needs similar checking. Regards, furaisanjin

Oct. 6, 2012

copying to clipboard

by corvid＠lavabit.com

I was thinking how I sometimes see where newbies suppose that dillo can't copy and paste because they think ctrl-c must be how everything does copying...and I thought I'd find out what it would take to make that work. Some not-scrutinized code attached. There is this circuitous part where control goes from Layout to SelectionState to Layout again to Platform, which isn't too pleasing...

Oct. 6, 2012

domainrc to manage cross-domain requests (was Re: RequestPolicy-like patch)

by p37sitdu＠lavabit.com

On Thu, Oct 04, 2012 at 12:28:38AM +0000, corvid wrote: > I thought I'd removed all of it; did I overlook something? No, it is me who overlooked one of the two commits (a18a70e099aa).

Oct. 4, 2012

domainrc to manage cross-domain requests (was Re: RequestPolicy-like patch)

by corvid＠lavabit.com

p37sitdu wrote: > You did not remove filter_auto_requests preference (see my patch [1]). I thought I'd removed all of it; did I overlook something?

Oct. 4, 2012

domainrc to manage cross-domain requests (was Re: RequestPolicy-like patch)

by p37sitdu＠lavabit.com

On Wed, Oct 03, 2012 at 02:04:45AM +0000, corvid wrote: > Committed with a little dilloification, etc. You did not remove filter_auto_requests preference (see my patch [1]). It is not necessary: no domainrc can work as filter_auto_requests=allow_all and when domainrc with "default deny" is present it is the same as filter_auto_requests=same_domain. [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2012-August/009394.html

Oct. 3, 2012

domainrc to manage cross-domain requests (was Re: RequestPolicy-like patch)

by corvid＠lavabit.com

I should mention that I was playing around with printing a summary at freeall time in order to see which sites are the worst offenders. Diff attached.

Oct. 3, 2012

domainrc to manage cross-domain requests (was Re: RequestPolicy-like patch)

by corvid＠lavabit.com

p37sitdu wrote: > Patch implements functions similar to Firefox addon RequestPolicy. [1] > It allows user to control automatic requests more flexible than > filter_auto_requests option. Patch removes this option and replaces it > with file .dillo/domainrc that looks like this: > > default deny > wikipedia.org .wikimedia.org > wikisource.org .wikimedia.org > wikitionary.org .wikimedia.org > wikiversity.org .wikimedia.org > > That way most requests are denied, but images on wikipedia are loaded > from wikimedia.org without clicking on them. > > Patterns can start with "." to allow subdomains. > > Special pattern "*" can be used to allow requests to any domains from > some domain (for example if it is a website full of external images) or > to allow requests from any domain to some domain (maybe CDN). > > Without domainrc file all cross-domain requests are denied. > > [1] https://www.requestpolicy.com/ Committed with a little dilloification, etc. At the moment, I have the default set to accept rather than deny, thinking that it might be easier for us to build up a sample or default domainrc with a bunch of notorious ad sites to blacklist than it would be to whitelist enough common sites that use a [site]images.com or suchlike.

Oct. 3, 2012

Key binding for viewing page source

by corvid＠lavabit.com

Jorge wrote: > On Thu, Sep 20, 2012 at 08:45:08PM +0200, Johannes Hofmann wrote: > > On Wed, Sep 19, 2012 at 09:06:22PM +0000, corvid wrote: > > > Alexander wrote: > > > > I use the "view page source" function from the right-click popup menu > > > > very often and so I created a key binding for this (see attached > > > > patch). Since I find this very handy, please consider this patch for > > > > the repository. > > > > > > This would be good to have. > > > > I'd also like to have that feature. > > +1 Committed.

Sept. 28, 2012

hyphenation in dillo

by corvid＠lavabit.com

The borders on the "Search results" and "Nutrient values" boxes are overlapping on http://www.bitelog.com/mega-food-search.htm?q=masa

Sept. 27, 2012

hyphenation in dillo

by sgeerken＠dillo.org

On Wed, Sep 26, Jorge Arellano Cid wrote: > On Fri, Sep 14, 2012 at 12:38:46PM +0200, Sebastian Geerken wrote: > > On Thu, Sep 13, Alexander Voigt wrote: > > > On Mon, Sep 10, 2012 at 08:45:22PM +0200, Sebastian Geerken wrote: > > > > No, not yet. BTW: I haven't understood whether "xml:" is a normal > > > > namespace prefix (for which namespace?) or is specialy reserved (and > > > > may so not be used as namespace prefix). In the latter case, support > > > > would be rather simple. > > > > > > As written in [1], the "xml:" prefix is bound to the namespace > > > http://www.w3.org/XML/1998/namespace , which is reseved for the W3C. > > > This means that the nobody, except the W3C, can reuse this prefix for > > > their own namespace. > > > > > > So, as long as the meaning of "xml:lang" does not change (which is > > > very unlikely), it can be interpreted in the same way as the "lang" > > > attribute. > > > > So, this simple patch (or similar): > > > > ---------------------------------------------------------------------- > > [...] > > ---------------------------------------------------------------------- > > > > would work, without bothering about XML namespaces (in the near > > future). What do the other developers think? > > Yes, it looks OK to me. > > I'd go with the attached patch (a bit more explicit, +comments) > > Feel free to commit. Done. Sebastian

Sept. 27, 2012

hyphenation in dillo

by jcid＠dillo.org

Hi Sebastian, On Fri, Sep 14, 2012 at 12:38:46PM +0200, Sebastian Geerken wrote: > On Thu, Sep 13, Alexander Voigt wrote: > > On Mon, Sep 10, 2012 at 08:45:22PM +0200, Sebastian Geerken wrote: > > > No, not yet. BTW: I haven't understood whether "xml:" is a normal > > > namespace prefix (for which namespace?) or is specialy reserved (and > > > may so not be used as namespace prefix). In the latter case, support > > > would be rather simple. > > > > As written in [1], the "xml:" prefix is bound to the namespace > > http://www.w3.org/XML/1998/namespace , which is reseved for the W3C. > > This means that the nobody, except the W3C, can reuse this prefix for > > their own namespace. > > > > So, as long as the meaning of "xml:lang" does not change (which is > > very unlikely), it can be interpreted in the same way as the "lang" > > attribute. > > So, this simple patch (or similar): > > ---------------------------------------------------------------------- > diff -r d0a8d2a5ede3 src/html.cc > --- a/src/html.cc Thu Sep 13 12:35:54 2012 +0200 > +++ b/src/html.cc Fri Sep 14 12:35:38 2012 +0200 > @@ -3448,6 +3448,15 @@ > html->styleEngine->setNonCssHint(PROPERTY_X_LANG, > CSS_TYPE_STRING, > attrbuf); > } > + > + if (tagsize >= 14) { /* TODO prefs.hyphenate? */ > + /* length of "<t xml:lang=i>" */ > + attrbuf = Html_get_attr2(html, tag, tagsize, "xml:lang", > + HTML_LeftTrim | HTML_RightTrim); > + if (attrbuf) > + html->styleEngine->setNonCssHint(PROPERTY_X_LANG, > CSS_TYPE_STRING, > + attrbuf); > + } > } > > static void Html_display_block(DilloHtml *html) > ---------------------------------------------------------------------- > > would work, without bothering about XML namespaces (in the near > future). What do the other developers think? Yes, it looks OK to me. I'd go with the attached patch (a bit more explicit, +comments) Feel free to commit. -- Cheers Jorge.-

Sept. 26, 2012

Doxyfile

by sgeerken＠dillo.org

On Sun, May 27, 123 wrote: > By the way new Doxygen supports Markdown[1] and it is enabled by > default. It is easier to read and write than HTML. index.doc rewritten > using markdown is attached. Existing documentation (especially .txt > files) can be converted to markdown too. > > [1] http://daringfireball.net/projects/markdown/ Yes, this looks interesting, and I've started new documentation using Markdown (in the floats repository). Although I do not plan to convert the existing documentations, at least as long as there are different repositories to merge. Thank you for the hint. Sebastian

Sept. 26, 2012

Key binding for viewing page source

by Hole.destructor＠gmx.de

Hi. Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > > BTW, as you use viewsource very often, what do you like best for > > displayed HTML lines, one long scrollable line or wrapping? > > Pardon me for butting in here, but I use view source quite a lot and I > would definitely prefer wrapping. (Is wrapping supported at the > moment?) Many Web sites ship HTML with absurdly long lines which > makes viewing their source practically impossible - horizontal > scrolling is very little help when the line is around 50 screen widths > long (sadly this is not an exaggeration). I also like line wrapping more than scrolling horizontally. When you want to read the HTML code with long lines, it is more convenient to have only one scrolling direction (vertically) instead of two (vertically + horizontally). Best, Alex

Sept. 23, 2012