- Dillo-dev - lists.mailman3.com

patch: fonts, utf-8 tabs

by corvid＠lavabit.com

The ui.cc changes are so that I can make a tabs screenshot with Asian script at some point. Similarly, the dialog.cc change is so that I can see Asian characters in source. Kept forgetting to deal with that...

Sept. 21, 2008

patch: making some concessions to aesthetics...

by corvid＠lavabit.com

I've decided to admit that highlighting checkboxes and radio buttons is always hideous. I had been trying to avoid the special case, but I know the horribleness would jump right out at someone trying dillo2... (And I decreased the RELIEF_X_THICKNESS because 5 makes <button>s look weird at my low resolution)

Sept. 21, 2008

cut off word ends with italic fonts

by jcid＠dillo.org

On Fri, Sep 19, 2008 at 04:09:44PM +0200, Johannes Hofmann wrote: > Hi, > > somtimes the end of italic words get cut off e.g. in > > <html> > <body> > <a href="foo">FUU</a>BAR > </body> > </html> > > when seen with vw_fontname="helvetica". > > This is due to a change in html.cc (I think it was introduced with > rev 1.36). This change sets the backgroundColor for all words which > means that for each word, the bounding box get's drawn before the > actual text. This obviously has a performance impact too. > > I'm not sure how to get back to the original behaviour > (backgroundColor == NULL for normal words) without breaking anything. > Can someone please have a look? I can't reproduce the problem here... -- Cheers Jorge.-

Sept. 21, 2008

[patch] minor optimization in StyleAttrs::equals()

by jcid＠dillo.org

On Fri, Sep 19, 2008 at 03:47:15PM +0200, Johannes Hofmann wrote: > Hi, > > this patch adds a missing optimization to StyleAttrs::equals(). > Similar checks are already in place in other equals() methods. Committed. -- Cheers Jorge.-

Sept. 20, 2008

Tabs!!!

by Johannes.Hofmann＠gmx.de

On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote: > I wrote: > > Sometimes the window closes when I click on a page. > > A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, > > and then HIDE. > > (I only had one tab, in case that matters.) > > Okay, that was not accurate. > It looks like PUSH and FOCUS_CHANGE is from clicking > and HIDE is from pressing Space to page down. I'm also seeing that. No idea yet... Johannes

Sept. 19, 2008

cut off word ends with italic fonts

by Johannes.Hofmann＠gmx.de

On Fri, Sep 19, 2008 at 03:05:17PM +0000, corvid wrote: > Johannes wrote: > > somtimes the end of italic words get cut off e.g. in > > > > <html> > > <body> > > <a href="foo">FUU</a>BAR > > </body> > > </html> > > > > when seen with vw_fontname="helvetica". > > > > This is due to a change in html.cc (I think it was introduced with > > rev 1.36). This change sets the backgroundColor for all words which > > means that for each word, the bounding box get's drawn before the > > actual text. This obviously has a performance impact too. > > > > I'm not sure how to get back to the original behaviour > > (backgroundColor == NULL for normal words) without breaking anything. > > Can someone please have a look? > > I've had the idea lately (not yet explored) that maybe I could rip out all > of my backgroundColor setting and get the background color > for the fltk widgets if it should turn out that getEmbed()->getBgColor() > has what I want. I'll dig into it. > > PS Is this the same reason that the tops of bold 5's are thin and > the right edge of fixed-width %'s are cut off (using DejaVu fonts, at least)? Not sure. But you can easily check by completely disabling word backgrounds as in attached patch. Cheers, Johannes

Sept. 19, 2008

Tabs!!!

by corvid＠lavabit.com

I wrote: > Sometimes the window closes when I click on a page. > A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, > and then HIDE. > (I only had one tab, in case that matters.) Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down. Since they're very close to each other on my keyboard and I am so accustomed to the click-and-space sequence, it can come from muscle memory even when I'm paying enough attention to think I know what happened before dillo disappeared.

Sept. 19, 2008

cut off word ends with italic fonts

by corvid＠lavabit.com

Johannes wrote: > somtimes the end of italic words get cut off e.g. in > > <html> > <body> > <a href="foo">FUU</a>BAR > </body> > </html> > > when seen with vw_fontname="helvetica". > > This is due to a change in html.cc (I think it was introduced with > rev 1.36). This change sets the backgroundColor for all words which > means that for each word, the bounding box get's drawn before the > actual text. This obviously has a performance impact too. > > I'm not sure how to get back to the original behaviour > (backgroundColor == NULL for normal words) without breaking anything. > Can someone please have a look? I've had the idea lately (not yet explored) that maybe I could rip out all of my backgroundColor setting and get the background color for the fltk widgets if it should turn out that getEmbed()->getBgColor() has what I want. I'll dig into it. PS Is this the same reason that the tops of bold 5's are thin and the right edge of fixed-width %'s are cut off (using DejaVu fonts, at least)?

Sept. 19, 2008

cut off word ends with italic fonts

by Johannes.Hofmann＠gmx.de

Hi, somtimes the end of italic words get cut off e.g. in <html> <body> <a href="foo">FUU</a>BAR </body> </html> when seen with vw_fontname="helvetica". This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too. I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look? Cheers, Johannes

Sept. 19, 2008

[patch] minor optimization in StyleAttrs::equals()

by Johannes.Hofmann＠gmx.de

Hi, this patch adds a missing optimization to StyleAttrs::equals(). Similar checks are already in place in other equals() methods. Cheers, Johannes

Sept. 19, 2008