Here you go.

old pref	new CSS rule
bg_color=purple	body {background-color: purple}
text_color=black	body {color: black}
link_color=blue	:link {color: blue}
visited_color=0x808080	:visited {color: #808080}

To prevent web pages from overriding one of your CSS rules, add "!important" to it.
To replace the force_my_colors preference, you could use, e.g.:

* {background-color: green !important; color:red !important}   :link {color: orange !important}   :visited {color: brown !important}

The asterisk means that this rule should be applied to all HTML elements that are not otherwise specified.

If you configured fltk2 with --enable-cairo, there's your problem. Don't do that :)

OSX users are also reporting problems, but no developers have regular access to OSX. Any help with this matter would be appreciated. (changing buffered_drawing in your dillorc might help, though)

The FLTK2 library is normally statically linked into dillo2, so you would only need to get this library itself if you are building dillo for yourself.

Scripts with right-to-left display (e.g., Arabic, Hebrew) or complex rendering rules (e.g., Arabic, Indic scripts) will not be displayed properly, as these features are not currently supported under FLTK2.

Dillo 2.2 will have improved line wrapping for Chinese and Japanese text (see screenshots for an example), and there is a patch available to support zero-width space characters for languages that tend to use them to show where linebreaks are legal (Thai, Lao, Cambodian...)

The current Dillo developers use Latin-1 languages, so i18n testing and commentary would be particularly valued.

In the lower right corner of Dillo you'll see a bug-shaped icon. This is Dillo's bug meter. Click on it to see the HTML errors that have been detected.

Our policy is not to work around broken HTML. To learn why, see our links, and especially read "The decommoditization of protocols" by Raph Levien.

Any HTML parsing patch should be backed up with information from the HTML 4.01 spec. Note that previous HTML specs can be considered as well.

Configuring cookies in Dillo is easy. Something like the following inside ~/.dillo/cookiesrc could be enough to get you started:

   #domain action
   DEFAULT DENY
   fltk.org ACCEPT
   .host.com ACCEPT_SESSION


dpidc stop

The cookies dpi will write any permanent (ACCEPT) cookies to disk, and temporary (ACCEPT_SESSION) cookies will be discarded as the dpi exits.

Second, get rid of the permanent cookies by removing or editing your ~/.dillo/cookies.txt file.

It's disabled by default.

If you want to enable it (e.g. to read forums in https),

dillo-2.1 and later:

configure it using --enable-ssl

dillo-2.0:

Change the following line in dpi/https.c from
#undef ENABLE_SSL
to:
#define ENABLE_SSL

If you want to help us to improve the plugin, please let us know!

      ps aux | grep dpid
      dpidc stop
      kill <dpid PID>
      ps aux | grep dpi
      kill <dpi PIDs>
    

Also: If you built dillo from source yourself, did you configure it so that 'make install' put dpid in a directory that's in your path?

[PS dpis have never worked for me when using install-dpi-local unless I add a few things —corvid]

So what do I do?

Allow him a week for urgent messages and two for less pressing matters. If he hasn't answered, send a reminder.

Search the dillo-dev mailing list archive.

Subscribe to dillo-dev.