Hi Nikita, On Tue, 13 May 2003, Nikita V. Borodikhin wrote:
Hello, all Dillo developers !
As mentioned in HTML 4.01 spec what should be done when html renderer cannot display a symbol is up to renderer. Current code renders all characters with code 0..255 but skip all the others silently. I prefer lynx/links approach to this problem. If they should display symbol which cannot be displayed properly in current locale they render ascii-only representation of this symbol, e.g. "α" -> "a", "Χ" -> "X", "∗" -> "*".
Included small patch does that for all entities mentioned in html.c and this table is much more compact than links' one and does not allow transliteration of foreign language as links does.
I believe that this patch is a temporary solution for this problem and when dillo migrates on GTK2 and this problem will be solved mush more reliable and elegant way by using standard symbol fonts via fontsets.
Yes, the plan is to handle them properly with GTK+2. Now, considering the current development plan, it'd be good to have an interim workaround. After reviewing the implementation in the patch, I'd prefer not to intermix it with the current (correct but incomplete) way of handling entities. For instance, defining another entities table that's to be used when the entity is not found in the current one is a good way to separate the workaround code! I'd like to add to this new table some important numeric character references (UTF-8) that are usually found in web pages these days. Things like: "—" "’" "“" "”" This could help our rendering while we get to GTK+2. Please let me know if you want to improve it this way! Cheers Jorge.- PS: With regard to "saving entered datas in forms", after some WEB research, I found it's somewhat obscure to know whether there's a way to do it the "standard way". Some sources like caching and some others hate it. As we know, caching form data can be a huge security threat. That mainly depends on what data is remembered and on the user's environment. For instance, some banks refuse to work with browsers that cache the pages (verifying browser signatures), with a view to protect their customers from eavesdropping (as it could happen when they make an operation and leave for a while to the bathroom; Any person in the same office can click a few Backs and read what was done and read the hand-typed camps). I'd appreciate some more research on this topic (certainly a time-comsuming task I can't work on now). To know what some serious browsers do, is a good starting point. One of our objectives is personal security and privacy, and it takes a lot of work.