- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] White spaces handling

by Jorge Arellano Cid

On Sat, 22 May 2004, Sebastian Geerken wrote: > On Fri, May 21, Jorge Arellano Cid wrote: > > [...] > > Actually it's not the changes to the parser, but to dw_page.c. > > If you pick a vanilla 0.8.1 and apply: > > > > + if (page->words[nw].orig_space != 0) { > > + /* We have already a space, add a blank word before. */ > > + a_Dw_page_add_text (page, g_strdup(""), style); > > + nw = page->num_words - 1; > > + } > > > > It will render the black row, even on the splash page. > > Interestingly, if you take the modifications in html.c, without the > modifications in dw_page.c, everything works: the table above is > rendered correctly, the other tables are centered, and even the page > "underline-strike-and-spaces.html" looks like we want it to look like. Funny! I found a render fault on the HTML-4.01 sec 9.1 page (as a test case). There was a missing space in "(calledinter-word space)" and in "user agents shouldcollapse input". I Fixed that, and uploaded to CVS. Not to say this is _the_ way to do the parsing, but as it does better than the former code, let it be. The question of how to do it properly remains open... (I'm yet to study the parser in the CSS prototype) > Actually, the modifications in html.c should make the modifications in > dw_page.c obsolete, since the latters handle the case that > a_Dw_page_add_space is called twice in sucsession, without any new > words between them. I would have thought that the modified HTML parser > should avoid exactly this, but this does not seem the case. It would > be interesting to insert the line > > g_return_if_fail (page->words[nw].orig_space != 0); > > instead of the code, which is inserted by the patch, and start dillo > in gdb with the option "--g-fatal-warnings", to see, under which > circumstances the code would have been called. I uploaded this test code to CVS: + /* todo: remove this test case */ + if (page->words[nw].orig_space != 0) { + g_warning("a_Dw_page_add_space:: already existing space!!!\n"); + } and found an interesting test case: <table> <tr> <td> <table> <tr> <td>1</td> <td>2</td> <td>3</td> </tr> </table> </td> </tr> </table> This code triggers one warning message, from the "<td>3</td>" line. If you remove it, there's no warning anymore. The funny part is that the "offending" line is the same that the former two (as the parser is concerned), but only the last one triggers the warning. Moreover, if you add a "<td>4</td>" line, there'll be two warnings! HTH Jorge.-

May 23, 2004

[Dillo-dev]helper applications and their uses

by Randy

Hello, First of all,let me say that i don't know a command-line from a chorus line-my feeble knowlege of Linux consists mainly of downloading Apt and Synaptic for my RH7.3 and FC1 distros,and handling it all from the GUI. Just letting you know that your'e dealing with a novice here. : ) I like the concept behind Dillo,simple and fast.I understand that you might be working on a version for frames later on,which would be even better of course.My question though-without reliance on the usual Mozilla plug-ins(which Galeon,Epiphany and Firefox also use) is there anything I can download as a helper application? Would the full Java,for example,interact at all with Dillo when browsing the Web? Would Realplayer,or Gxine with Real plug-ins(i'm on Gnome,of course). Thanks in Advance, Randy

May 22, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Sebastian Geerken

On Fri, May 21, Jorge Arellano Cid wrote: > [...] > > > If we "collapse" as the SPEC says should be done, we have two > > > possibilities: > > > > What part of the spec do you refer to? > > HTML-4.01, sec 9.1: > > <q> > [...] > Note that a sequence of white spaces between words in the source > document may result in an entirely different rendered inter-word > spacing (except in the case of the PRE element). In particular, > user agents should collapse input white space sequences when ^^^^^ Again, I understand this, that this refers to the lowest processing level, this is what the HTML parser has already done before. > producing output inter-word space. This can and should be done > even in the absence of language information (from the lang > attribute, the HTTP"Content-Language" header field (see > [RFC2616], section 14.12), user agent settings, etc.). > [...] > </q> > > [...] > > Generally, I'd like to stick to this tree view, and especially regard, > > in this example, the words "Some " and "text" as lying in different > > levels in the tree, not within a flat list. In the history, this was > > not always very clear for HTML, but it is much clearer for XHTML. The > > current parser does not actually build a tree, but should a bit like > > as it does. > > Sorry, my english, what does "a bit like as it does" mean? Sorry, this should say "[should behave] a bit like as *if* it does [build a tree]". > [...] > > > Now, this solution would also account for the special SGML line > > > break rules: > > > > > > <q source='HTML-4.01 SPEC B.3.1'> > > > > > > SGML (see [ISO8879], section 7.6.1) specifies that a line break > > > immediately following a start tag must be ignored, as must a line > > > break immediately before an end tag. This applies to all HTML > > > elements without exception. > > > > > > The following two HTML examples must be rendered identically: > > > > > > Thomas is watching TV. > > > > > > > > > Thomas is watching TV. > > > > > > > > > So must the following two examples: > > > > > > <A>My favorite Website</A> > > > > > > <A> > > > My favorite Website > > > </A> > > > > > > </q> > > > > Rhis is actually something different: It is only about line breaks, > > and it applies to *all* elements, including <pre>. > > If you consider that line breaks are also white space > characters (HTML-4.01 sec 9.1), this becomes a special case of > general white space handling. Since this rule applies always, it should be handles at a level below (if I understand this correctly). I.e., first remove these linke breaks (also for <pre>, and then (except for <pre>), remove white spaces. BTW, I do not know whether this is also valid for XML, I did not find something equivalent in the XML spec. > PS: It seems like we'll have to modify the parser to produce a > parsing tree for CSS/XML to be supported properly. This is already halfway done in the CSS prototype, since CSS does indeed depend on a document tree (mostly because CSS is processed asynchronously). It has still to be considered, on which levels what white space handling is done. Sebastian

May 22, 2004

Re: [Dillo-dev] White spaces handling

by Sebastian Geerken

On Fri, May 21, Jorge Arellano Cid wrote: > On Fri, 21 May 2004, Sebastian Geerken wrote: > > On Mon, May 17, Jorge Arellano Cid wrote: > > > This HTML example shows the black row (after patch): > > > [...] > > > > The DwPage below the topmost table gets an additional word, most > > probably a break, which it should not (and which it does not get with > > the unmodified parser). What the modified HTML parser does, seems > > still a bit immature. > > Actually it's not the changes to the parser, but to dw_page.c. > If you pick a vanilla 0.8.1 and apply: > > + if (page->words[nw].orig_space != 0) { > + /* We have already a space, add a blank word before. */ > + a_Dw_page_add_text (page, g_strdup(""), style); > + nw = page->num_words - 1; > + } > > It will render the black row, even on the splash page. Interestingly, if you take the modifications in html.c, without the modifications in dw_page.c, everything works: the table above is rendered correctly, the other tables are centered, and even the page "underline-strike-and-spaces.html" looks like we want it to look like. Actually, the modifications in html.c should make the modifications in dw_page.c obsolete, since the latters handle the case that a_Dw_page_add_space is called twice in sucsession, without any new words between them. I would have thought that the modified HTML parser should avoid exactly this, but this does not seem the case. It would be interesting to insert the line g_return_if_fail (page->words[nw].orig_space != 0); instead of the code, which is inserted by the patch, and start dillo in gdb with the option "--g-fatal-warnings", to see, under which circumstances the code would have been called. Sebastian

May 22, 2004

[Dillo-dev]BugTrack

by Jorge Arellano Cid

Hi there! Dillo's bugtrack was just updated so email addresses are mangled with images to protect from SPAM robots. The "submitter" camp was also added, so we can contact the poster for details. Cheers Jorge.-

May 22, 2004

[Dillo-dev]javascript links

by Jorge Arellano Cid

Hi there, The CVS is just updated for 0.8.2-pre. The first patch is a tiny handler for javascript links. It's very simple, it will try to make a normal link from a javascript-based href. Please test it and tell me how it works. Cheers Jorge.-

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

On Fri, 21 May 2004, Sebastian Geerken wrote: > On Mon, May 17, Jorge Arellano Cid wrote: > > > > Hi Sebastian, > > > > This HTML example shows the black row (after patch): > > [...] > > The DwPage below the topmost table gets an additional word, most > probably a break, which it should not (and which it does not get with > the unmodified parser). What the modified HTML parser does, seems > still a bit immature. Actually it's not the changes to the parser, but to dw_page.c. If you pick a vanilla 0.8.1 and apply: + if (page->words[nw].orig_space != 0) { + /* We have already a space, add a blank word before. */ + a_Dw_page_add_text (page, g_strdup(""), style); + nw = page->num_words - 1; + } It will render the black row, even on the splash page. Cheers Jorge.-

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

On Fri, 21 May 2004, Sebastian Geerken wrote: > On Fri, May 14, Jorge Arellano Cid wrote: > > [...] > > but what do we do with this: > > > > 'Some text' > > > > If we ignore white space after the start tag and before the end > > tag, it becomes > > > > 'Sometext' (with no space at all!) > > What I find indeed reasonable. (See below for my reasons.) Agreed. > > > If we "collapse" as the SPEC says should be done, we have two > > possibilities: > > What part of the spec do you refer to? HTML-4.01, sec 9.1: <q> [...] Note that a sequence of white spaces between words in the source document may result in an entirely different rendered inter-word spacing (except in the case of the PRE element). In particular, user agents should collapse input white space sequences when producing output inter-word space. This can and should be done even in the absence of language information (from the lang attribute, the HTTP"Content-Language" header field (see [RFC2616], section 14.12), user agent settings, etc.). [...] </q> > From what I have understood, > spaces should be collapsed at the raw data level. > That is, if you have > the part "Some text", it will be parsed into the following > tree: > > ... > `- > +- > | `- "Some " > `- "text" > > Then, the question is, what should be done with the space at the end > of "Some ". If "the raw data level" means that this: Some   text would be parsed as: `- +- | `- "Some   " `- "text" and after that, the final space removed, producing: `- +- | `- "Some  " `- "text" it seems a good idea for an implementation to me. > Generally, I'd like to stick to this tree view, and especially regard, > in this example, the words "Some " and "text" as lying in different > levels in the tree, not within a flat list. In the history, this was > not always very clear for HTML, but it is much clearer for XHTML. The > current parser does not actually build a tree, but should a bit like > as it does. Sorry, my english, what does "a bit like as it does" mean? > This approach makes also the new HTML parser in the CSS > prototype simpler. Good. > > [...] > > AFAICT, the SPEC leaves the choice open, and advices HTML > > authors against whitespace inside the tags. > > > > IMO, always collapsing white space after the start tag and > ^^^^^^^^^^ > > I'd say, we should (for most elements) simply ignore whitespaces after > the opening tag, and before the closing tag. This solves generally the > problem with "Some underlined text.", and we should not > relate spaces in different elements, e.g. by collapsing them. Yes, "ignore" is a better word. > > Now, this solution would also account for the special SGML line > > break rules: > > > > <q source='HTML-4.01 SPEC B.3.1'> > > > > SGML (see [ISO8879], section 7.6.1) specifies that a line break > > immediately following a start tag must be ignored, as must a line > > break immediately before an end tag. This applies to all HTML > > elements without exception. > > > > The following two HTML examples must be rendered identically: > > > > Thomas is watching TV. > > > > > > Thomas is watching TV. > > > > > > So must the following two examples: > > > > <A>My favorite Website</A> > > > > <A> > > My favorite Website > > </A> > > > > </q> > > Rhis is actually something different: It is only about line breaks, > and it applies to *all* elements, including <pre>. If you consider that line breaks are also white space characters (HTML-4.01 sec 9.1), this becomes a special case of general white space handling. Cheers Jorge.- PS: It seems like we'll have to modify the parser to produce a parsing tree for CSS/XML to be supported properly.

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Sebastian Geerken

On Mon, May 17, Jorge Arellano Cid wrote: > > Hi Sebastian, > > This HTML example shows the black row (after patch): > [...] The DwPage below the topmost table gets an additional word, most probably a break, which it should not (and which it does not get with the unmodified parser). What the modified HTML parser does, seems still a bit immature. Sebastian

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Sebastian Geerken

On Fri, May 14, Jorge Arellano Cid wrote: > [...] > For instance: > > > A different case is "Some text". Your patch will make > > "Some text" of it, but it should be really be > > "Some text." > > Yes, I agree, "collapsing" here should be: > > 'Some text' => > 'Some text' > > as you note. > > but what do we do with this: > > 'Some text' > > If we ignore white space after the start tag and before the end > tag, it becomes > > 'Sometext' (with no space at all!) What I find indeed reasonable. (See below for my reasons.) > If we "collapse" as the SPEC says should be done, we have two > possibilities: What part of the spec do you refer to? From what I have understood, spaces should be collapsed at the raw data leve. That is, if you have the part "Some text", it will be parsed into the following tree: ... `- +- | `- "Some " `- "text" Then, the question is, what should be done with the space at the end of "Some ". Generally, I'd like to stick to this tree view, and especially regard, in this example, the words "Some " and "text" as lying in different levels in the tree, not within a flat list. In the history, this was not always very clear for HTML, but it is much clearer for XHTML. The current parser does not actually build a tree, but should a bit like as it does. This approach makes also the new HTML parser in the CSS prototype simpler. > 'Some text' (as it was: underline the whitespace) > > and > > 'Some text' (move the space out of the tag) > > > AFAICT, the SPEC leaves the choice open, and advices HTML > authors against whitespace inside the tags. > > IMO, always collapsing white space after the start tag and ^^^^^^^^^^ I'd say, we should (for most elements) simply ignore whitespaces after the opening tag, and before the closing tag. This solves generally the problem with "Some underlined text.", and we should not relate spaces in different elements, e.g. by collapsing them. > before the end tag is the simplest to implement. Even more, as > the SPEC doesn't define what to do in this case, it's an option > left to the User Agent: > > <q source='HTML4.01 SPEC, 9.1'> > In order to avoid problems with SGML line break rules and > inconsistencies among extant implementations, authors should not > rely on user agents to render white space immediately after a > start tag or immediately before an end tag. Thus, authors, and in > particular authoring tools, should write: > > We offer free <A>technical support</A> for subscribers. > > and not: > > We offer free<A> technical support </A>for subscribers. > </q> So, at least, the authors are warned ;-) > Now, this solution would also account for the special SGML line > break rules: > > <q source='HTML-4.01 SPEC B.3.1'> > > SGML (see [ISO8879], section 7.6.1) specifies that a line break > immediately following a start tag must be ignored, as must a line > break immediately before an end tag. This applies to all HTML > elements without exception. > > The following two HTML examples must be rendered identically: > > Thomas is watching TV. > > > Thomas is watching TV. > > > So must the following two examples: > > <A>My favorite Website</A> > > <A> > My favorite Website > </A> > > </q> Rhis is actually something different: It is only about line breaks, and it applies to *all* elements, including <pre>. Sebastian

May 21, 2004

[Dillo-dev]White space handling

by Sebastian Geerken

Hi! This mail is just to collect what I have found in the specs, and how I understand it. I'll comment Jorge's mails seperately. Sebastian. ---------------------------------------------------------------------- HTML ---- Unfortunately, I do not have the SGML spec at hand, so I only refer to the parts of the HTML spec, which refer to general SGML topics. There is something in chapter 6, although I did not find anything about how #PCDATA (which is used in the DTD for the texts, which are relevant in this context), only about #CDATA: > 6.2 SGML basic types > > The document type definition specifies the syntax of HTML element > content and attribute values using SGML tokens (e.g., PCDATA, CDATA, > NAME, ID, etc.). See [ISO8879] for their full definitions. The > following is a summary of key information: > > * CDATA is a sequence of characters from the document character set > and may include character entities. User agents should interpret > attribute values as follows: > > o Replace character entities with characters, > o Ignore line feeds, > o Replace each carriage return or tab with a single space. > > User agents may ignore leading and trailing white space in CDATA > attribute values (e.g., " myval " may be interpreted as > > "myval"). Authors should not declare attribute values with leading > or trailing white space. > > For some HTML 4 attributes with CDATA attribute values, the > specification imposes further constraints on the set of legal > values for the attribute that may not be expressed by the DTD. About HTML: > 9.1 White space > > [...] > For all HTML elements except PRE, sequences of white space separate > "words" (we use the term "word" here to mean "sequences of non-white > space characters"). When formatting text, user agents should > identify these words and lay them out according to the conventions > of the particular written language (script) and target medium. > [...] This is, what is currently the difference between calls to a_Dw_page_add_text() (which adds a word), and a_Dw_page_add_space(), which adds a "word separation". > B.3.1 Line breaks > SGML (see [ISO8879], section 7.6.1) specifies that a line break > immediately following a start tag must be ignored, as must a line > break immediately before an end tag. This applies to all HTML > elements without exception. > > The following two HTML examples must be rendered identically: > > Thomas is watching TV. > > > Thomas is watching TV. > > > So must the following two examples: > > <A>My favorite Website</A> > > <A> > My favorite Website > </A> Notice this: "This applies to all HTML elements without exception." That is, also for <pre>. But it does not say anything about white spaces in general. XHTML ----- First of all from the XML 1.1 spec: > 2.10 White Space Handling > > In editing XML documents, it is often convenient to use "white > space" (spaces, tabs, and blank lines) to set apart the markup for > greater readability. Such white space is typically not intended for > inclusion in the delivered version of the document. On the other > hand, "significant" white space that should be preserved in the > delivered version is common, for example in poetry and source code. > > An XML processor MUST always pass all characters in a document that > are not markup through to the application. A validating XML > processor MUST also inform the application which of these characters > constitute white space appearing in element content. First of all, we do not have a distinction between the (basic) XML processor, and the application. (In the CSS prototype, this is clearer, and because it is always a good decision to make the implementation structure resemble the structure of the specifications, this should be kept in mind.) How I understand this basicly: It is (in most cases, see below) the task of the application (in this case XHTML) to determine how to deal with whitespaces. Anyway, I did not find anything in the XHTML 1.0 specification, so I believe that the same rules apply, as for HTML 4.01. > A special attribute named xml:space MAY be attached to an element to > signal an intention that in that element, white space should be > preserved by applications. In valid documents, this attribute, like > any other, MUST be declared if it is used. When declared, it MUST be > given as an enumerated type whose values are one or both of > "default" and "preserve". For example: > > <!ATTLIST poem xml:space (default|preserve) 'preserve'> > <!ATTLIST pre xml:space (preserve) #FIXED 'preserve'> > > The value "default" signals that applications' default white-space > processing modes are acceptable for this element; the value > "preserve" indicates the intent that applications preserve all the > white space. This declared intent is considered to apply to all > elements within the content of the element where it is specified, > unless overridden with another instance of the xml:space > attribute. This specification does not give meaning to any value of > xml:space other than "default" and "preserve". It is an error for > other values to be specified; the XML processor MAY report the error > or MAY recover by ignoring the attribute specification or by > reporting the (erroneous) value to the application. Applications may > ignore or reject erroneous values. If you look at the DTDs of XHTML 1.1, you'll find three elements setting this: <style>, <script>, and <pre>. As to the patch: <style> and <script> are currently rather unimportant, while for <pre>, the HTML parser switches into the DILLO_HTML_PARSE_MODE_PRE mode, where white spaces are handled differently. > The root element of any document is considered to have signaled no > intentions as regards application space handling, unless it provides > a value for this attribute or the attribute is declared with a > default value.

May 21, 2004

Re: [Dillo-dev]Tabs/Frames/Kbnav

by Patrick Shanahan

* Jorge Arellano Cid <jcid(a)dillo.org> [05-20-04 13:01]: > > Now that dillo 0.8.1 is done, I want to clarify what happened > with the Tabs/Frames/KeybNav patch. Sometime has passed since, > but at the time we decided to not stir an already ungrateful > situation. perhaps 'ungraceful' unless you intend to pour salt ??? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711

May 21, 2004

Re: [Dillo-dev]Tabs/Frames/Kbnav

by Riccardo Mottola

Jorge Arellano Cid wrote: > > Hi, > > Now that dillo 0.8.1 is done, I want to clarify what happened > with the Tabs/Frames/KeybNav patch. Sometime has passed since, > but at the time we decided to not stir an already ungrateful > situation. > I'm very sorry to read this thread. It has this "deja vue". Something that comes on and on in open source software. Splits and forks. If by one side the reason may be evident, on the other side the effect is that resources spread and many projects either die or remain understaffed for the potential they have. I often hope that addition could be worked in into the main tree and maybe chosen at configure time (I'm thinking again of a motif or other backend like Amaya or VIM did) or they could be 'officially' forked, like mozilla, firefox and camino. This can ensure a tigher collaboration, like in the case of those three browsers, the core engine updates I don't think dillo should have tabbed browsing and I see keyboard navigation as a secondary feature, but Frames is something that is needed for serious navigation. Not that I like frames, but they happen to be popluar and in some circumstances they can be smart even for minimalist webdesign. That is my 2cents. Riccardo

May 20, 2004

[Dillo-dev]Tabs/Frames/Kbnav

by Jorge Arellano Cid

Hi, Now that dillo 0.8.1 is done, I want to clarify what happened with the Tabs/Frames/KeybNav patch. Sometime has passed since, but at the time we decided to not stir an already ungrateful situation. Here I'm forwarding a couple of emails that should be enough to do it (dillo-dev archives holds the rest). Sincerely Jorge.- -------------------------------------------------------------------------- From akemnade(a)informatik.uni-bremen.de Mon May 17 08:44:51 2004 Date: Sat, 27 Mar 2004 14:25:31 +0100 From: Andreas Kemnade <akemnade(a)informatik.uni-bremen.de> To: Sebastian Geerken <s.geerken(a)ping.de> Cc: jcid(a)dillo.org Subject: Re: [Dillo-dev]Frame support in CVS Hi Sebastian, Hi Jorge, On Sun, 7 Mar 2004 22:14:49 +0100 Sebastian Geerken <s.geerken(a)ping.de> wrote: > Hi Andreas. > > (I'm writing this in English to make forwarding etc. simpler.) > > Jorge and I would indeed like to incorporate Frank's work into the > main trunk, but unfortunately Frank refused to clean up the code, and > finally, he quit the project, and plans to make an own version of > dillo. I've a mail of 8 Jan, which I can forward you, if you are > interested. > Please send me that mail. Ok, perhaps I was not deep enough in the archives. I just did not find any statement about what has to be done with the patch. I think other readers of dillo-dev do not know about that, too. Perhaps it would be better if that was more clarified but I also understand that you do not want to repeat yourself too often. > If you want to commit some work, you may clean up the patch, > especially split it up into several parts. Most important, there are > three parts: DilloDoc (which I'd like to be renamed), frames, and > tabs. They are of course related, but it would be handy to have single > patches for them (because of the over-linear correlation of patch size > and review time). > Most the time I was just happy to be able to apply the frames patch. I was not forced to look at the code. But with the massive conflicts the patch produces when I applied it to 0.8 I really had to start to look at the patch. Sometimes being not a maintainer has really big advances... If I checked the patch size before fixing the conflicts I guess I would have given up. I have never noticed before how big the patch was. If splitting does not work, then there is something really wrong with the code. So let's divide and conquer. I think an important part is to remove nice (but not very important) features from the patch which can be added separetely later on. I think I can find time in the next month to split and clean up the frame patch. Greetings Andreas Kemnade -------------------------------------------------------------------------- From s.geerken(a)ping.de Mon May 17 08:44:37 2004 Date: Sat, 10 Jan 2004 13:04:11 +0100 From: Sebastian Geerken <s.geerken(a)ping.de> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Fwd: Re: Notes on keyboard navigation FYI. [ Part 2: "Included Message" ] Date: Thu, 08 Jan 2004 22:31:10 +0100 From: Frank de Lange <frank(a)unternet.org> To: Sebastian Geerken <s.geerken(a)ping.de> Subject: Re: Notes on keyboard navigation Sebastian Geerken wrote: >Hi Frank. > >First of all, a happy new year! > >Several notes on keyboard navigation: > >1. Jorge and I decided, that we do not immediately support keyboard > configuration, also because it is rather unclear what widget > toolkit will be used in the future. So the version of keyboard > navigation, which will be integrated the first time, should have > hard-coded keys. > >2. Some days ago, I committed some changes to iterators, you may be > interested in. There is some description within doc/Dw.txt, section > "Anchors and Scrolling", subsection "Scrolling". Especially, > scrolling has now two dimensions, there is a new scrolling > position, DW_[HV]POS_INTO_VIEW, and DwIterator::scroll_to has been > replaced by the more general DwIterator::get_allocation. > >3. I noticed some performance problems with stress tests, I'm not sure > they play a role in real life. Anyway, you wrote on the list that > you are already working on in. > >Sebastian > > Happy new year as well... and thanks for the notice. For keyboard navigation to work in a sensible way x coördinate support is useful... so useful that I had already implemented it. The performance problems have been solved in my tree as well, as I have stated in my last message to the list. They are caused by the use of g_list_search_custom to find the focusable in focus.c. Using a hash table solved this. But... I have decided to discontinue support to the Dillo project as of the 'infringer' message to the list, so I will no longer post or update patches to Dillo. Instead, I am working on a new browser which should fill the same niche as Dillo (small, fast, enough features for most sites so it can be used as main browser). Starting point for this is my patched version of Dillo, with additional changes: - dpi and dpid and related things are gone (DONE) - library plugins for everything dpi did, and more (mime decoders, schemes, etc) (DONE) - ccc is on the way out, to be replaced by something less convoluted and more general (WORK IN PROGRESS) - DOM support with new xml parser (WORK IN PROGRESS) The project currently uses GTK+ as toolkit, but might switch to something else (FLTK is a candidate). A side goal for this project is to be developer-friendly. Patches are welcome, they will get their own space on the site (which will be on savannah, which is still not completely recovered from the break-in yet... hence the delay). I may post a short notice to the list if/when the project is up and ready for testing. Good luck with Dillo. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

May 20, 2004

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

Hi Sebastian, One thing that puzzles me about the patch that collapses whitespace at the parser level, is that some tables no longer are centered! For instance: http://www.dillo.org/stats/ http://www.dillo.org/stats/usage_200405.html Cheers Jorge.-

May 19, 2004

[Dillo-dev]0.8.1 text centering error?

by Gregg

Hello, I have compiled and run Dillo 0.8.1 flawlessly on Debian woody. However, I notice the browser "centering text" that wasn't on 0.8.0 and earlier. Example: http://www.cknw.com - my daily news, now shows the headlines as centred. Is this supposed to be? Thanks, -- Gregg

May 18, 2004

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

Hi Sebastian, This HTML example shows the black row (after patch): <table border="1" cellspacing="1"> <tr> <td bgcolor=black> <table width=100% bgcolor=white> <tr> <td>1</td> <td>2</td> <td>3</td> </tr> </table> </td> </tr> </table> HTH Jorge.-

May 17, 2004

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

Sebastian, > [Jorge wrote:] > > (...) > At this point I see that applying patch 1, plus making the > parser ignore whitespaces after a start tag and before an end tag > is a correct solution that can endure a reality test. Now I have a patch that does this (your patch 1.-, plus whitespace ignoring at the parser level). It works very well so far and passes these test pages: 1.- underline-strike-and-spaces.html 2.- bms.html 3.- Underlining of "PRE" in HTML 4.01 SPEC section 9.1 (the page itself, as HTML, has a good test case) Please download it and send me your comments: http://www.dillo.org/download/Jdiff.SPC2 Note: if you modify the patch like this, html.c:1007: - if (html->PrevWasOpenTag) { + if (0 && html->PrevWasOpenTag) { then, the splash page's tables render with a black row at the bottom. It'd be interesting to find out why. Cheers Jorge.-

May 17, 2004

[Dillo-dev]dillo-0.8.1 was officialy released.

by Jorge Arellano Cid

Hi folks, The new dillo-0.8.1 is just released now, waiting to appear on the freshmeat front page. It's been a long road 'til here, so please let me thank all of you that have participated in dillo-dev. Now, let's party! ;-) Jorge.-

May 15, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Riccardo Mottola

Jorge Arellano Cid wrote: > > Hi there, > > Has anyone tested on *BSD yet? > and Solaris? It builds on OpenBSD 3.5 (sparc). I did onlz a quick testing by browsing some sites and it seems to work. Except download troubles with dpi stuff, whcih sometimes are not started the first time and I might end with a dpi.core in my home. I'll test it on solaris this weekend hopefully. -Riccardo

May 15, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Kelson Vibber

On Friday 14 May 2004 9:18 am, Jorge Arellano Cid wrote: > Has anyone tested on *BSD yet? It builds and runs on FreeBSD 4.8 for i386. (pthreads are detected.) -- Kelson Vibber www.hyperborea.org

May 15, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Jorge Arellano Cid

On Fri, 14 May 2004, Kelson Vibber wrote: > On Friday 14 May 2004 06:00 am, Jorge Arellano Cid wrote: > > On Fri, 14 May 2004, Maarten Sander wrote: > > > I've just compiled and used Dillo on my Fedore Core 1 (Athlon-)machine. > > > It's updated with all the latest and greatest (*cough*) packages from > > > Dag, ATrpms, etc. GCC is 3.3.2, glibc 2.3.2, GTK 1.2.10. During > > > ./configure it gave a big warning that it could not find libpng-config, > > > but it detected png.h after that and compiled without problems. > > > > libpng is not easy to detect, maybe the Fedora team decided to > > go back to the simple header/library pair to avoid problems. > > Don't worry. > > I think I can shed some light on this: For some reason, Red Hat has never > included libpng-config in their libpng packages. I assume it's related to > their practice of maintaining binary compatibility when possible by using > backported patches instead of moving to newer upstream versions. > > The stock libpng even in FC2 Test3 is still 1.2.2, and I suspect (though I > don't remember for certain) that libpng-config was added later in the 1.2 > series. > > This practice does make it easier to deal with third-party software. Last > night, just to try it, I built Dillo on Fedora Core 2. I was able to run it > on Red Hat 8 - three versions behind! By contrast, if you build Dillo on > Mandrake 8.2, it will not run on Mandrake 8.1! As a result, I only have to > post 3 RPMs to cover 4 years of Red Hat/Fedora releases. Thanks for the explanation. BTW, what's configure's warning message? > > > You have a quite current GNU/Linux. Can you tell whether Dillo > > was linked against NPTL? > > I'm curious - what should show up in the output from ldd? The binary I built > on a very similar system to the one Maarten described (Athlon, FC1, with > third-party packages from Dag, FreshRPMs, ATrpms and so on) is linked > like this: > libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00324000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00ee9000) > libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00f24000) > libm.so.6 => /lib/tls/libm.so.6 (0x0020a000) > libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x00a22000) > libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x00b84000) > libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x00111000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x00cac000) > libdl.so.2 => /lib/libdl.so.2 (0x004fe000) > libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x001ac000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00114000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0022c000) > libz.so.1 => /usr/lib/libz.so.1 (0x007e6000) > libc.so.6 => /lib/tls/libc.so.6 (0x00334000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00753000) I'm not an expert on RedHat/Fedora, but if you look at the libpthread line in the listing above, it appears under tls/, and TLS (GNU's SSL) is required for NPTL. That is a sign towards thinking it may be linked with NPTL, but NPTL also requires an NPTL enabled kernel (this you have to look for in the distro's spec), and finally there was an environment variable planned for RedHat 9, that could be set to keep using the old libpthread. I don't know if it survived but should be investigated too. Cheers Jorge.-

May 14, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Kelson Vibber

On Friday 14 May 2004 06:00 am, Jorge Arellano Cid wrote: > On Fri, 14 May 2004, Maarten Sander wrote: > > I've just compiled and used Dillo on my Fedore Core 1 (Athlon-)machine. > > It's updated with all the latest and greatest (*cough*) packages from > > Dag, ATrpms, etc. GCC is 3.3.2, glibc 2.3.2, GTK 1.2.10. During > > ./configure it gave a big warning that it could not find libpng-config, > > but it detected png.h after that and compiled without problems. > > libpng is not easy to detect, maybe the Fedora team decided to > go back to the simple header/library pair to avoid problems. > Don't worry. I think I can shed some light on this: For some reason, Red Hat has never included libpng-config in their libpng packages. I assume it's related to their practice of maintaining binary compatibility when possible by using backported patches instead of moving to newer upstream versions. The stock libpng even in FC2 Test3 is still 1.2.2, and I suspect (though I don't remember for certain) that libpng-config was added later in the 1.2 series. This practice does make it easier to deal with third-party software. Last night, just to try it, I built Dillo on Fedora Core 2. I was able to run it on Red Hat 8 - three versions behind! By contrast, if you build Dillo on Mandrake 8.2, it will not run on Mandrake 8.1! As a result, I only have to post 3 RPMs to cover 4 years of Red Hat/Fedora releases. > You have a quite current GNU/Linux. Can you tell whether Dillo > was linked against NPTL? I'm curious - what should show up in the output from ldd? The binary I built on a very similar system to the one Maarten described (Athlon, FC1, with third-party packages from Dag, FreshRPMs, ATrpms and so on) is linked like this: libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00324000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00ee9000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00f24000) libm.so.6 => /lib/tls/libm.so.6 (0x0020a000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x00a22000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x00b84000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x00111000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x00cac000) libdl.so.2 => /lib/libdl.so.2 (0x004fe000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x001ac000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00114000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0022c000) libz.so.1 => /usr/lib/libz.so.1 (0x007e6000) libc.so.6 => /lib/tls/libc.so.6 (0x00334000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00753000) -- Kelson Vibber www.hyperborea.org

May 14, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Kelson Vibber

On Friday 14 May 2004 05:56 am, Jorge Arellano Cid wrote: > On Fri, 14 May 2004, Kelson Vibber wrote: > > On Thursday 13 May 2004 3:33 pm, Jorge Arellano Cid wrote: > > > It is not yet announced, probably on Staurday, after Kelson is > > > ready with the RPMs. > > > > I've got most of them put together, and the new index page is standing > > by. There's one more I need to build at work, which I can do when I get > > in tomorrow morning. > > Wow, that was fast! Eh, I had a free evening. > Thanks Kelson, and let me know when you're ready. I've got the last one ready. All I have to do is switch in the new index page. Let me know when to make the switch! -- Kelson Vibber www.hyperborea.org

May 14, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Jorge Arellano Cid

Hi there, Has anyone tested on *BSD yet? and Solaris? Cheers Jorge.-

May 14, 2004

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

Hi Sebastian, > Just FYI: I remember from the old discussion, that DwPage originally > collapsed spaces (i.e. calls to a_Dw_page_add_space), and that I > suggested some changes, so that this is not done anymore. Your patch > would reverse this change again. > > The discussion goes attached. I read the whole thread you sent me. BTW, the whole whitespace issue re-started when I found one of the patches you mentioned. I then read the past emails, and started to try to follow. It is not easy to make a clean picture of it though! --This mainly because of the way it used to be handled inside Dillo and because the SPECS seem not definitive in this matter. Here I'll try to cite past emails and comment my current thoughts: > [...] > This is because a_Dw_page_add_space is called twice, and this function > does actually not add a space, but change the current one. I've worked > on two solutions: > > 1. The first patch (underlined-spaces-clean.diff) changes the > behavior of a_Dw_page_add_space, but needs some changes in the > HTML parser, to control better when this function is called, > i.e. to ignore spaces after <A> and before </A>. This one seems the best candidate. With regard to fixing the parser for ignoring these spaces, see my comments below. > 2. The second one (underlined-spaces-kludgy.diff) tries to adjust > spaces, depending on rather hairy conditions. It works already > (if I'm not wrong, it has quite the same results as the code > before, except the bug). This option is no longer valid. As you clearly described: <q> > > > 2. The second one (underlined-spaces-kludgy.diff) tries to adjust > > > spaces, depending on rather hairy conditions. It works already > > > (if I'm not wrong, it has quite the same results as the code > > > before, except the bug). > > As I've now noticed, this will not work for CSS, e.g. the following > code: > > One non-underlined word > > will be displayed: > > One non-underlined word > ---- ----- > > just because this patch lets DwPage assume something about the > document structure (change from non-underline to underline == > beginning of a tag) which it can (and should) not. > </q> Now, > > Despite of the file names, I'm not sure if the changes in the HTML > parser can be done cleanly. So, if you think that this is difficult to > realize, apply the second patch. Especially, there is probably also an > other DwPage function necessary to remove again the last space, when > </A> is read after a space. I believe the parser is not very hard to modify for ignoring the spaces as patch 1.- requires. The problem is that the SPEC is not clear about exactly how these spaces should be collapsed. For instance: > A different case is "Some text". Your patch will make > "Some text" of it, but it should be really be > "Some text." Yes, I agree, "collapsing" here should be: 'Some text' => 'Some text' as you note. but what do we do with this: 'Some text' If we ignore white space after the start tag and before the end tag, it becomes 'Sometext' (with no space at all!) If we "collapse" as the SPEC says should be done, we have two possibilities: 'Some text' (as it was: underline the whitespace) and 'Some text' (move the space out of the tag) AFAICT, the SPEC leaves the choice open, and advices HTML authors against whitespace inside the tags. IMO, always collapsing white space after the start tag and before the end tag is the simplest to implement. Even more, as the SPEC doesn't define what to do in this case, it's an option left to the User Agent: <q source='HTML4.01 SPEC, 9.1'> In order to avoid problems with SGML line break rules and inconsistencies among extant implementations, authors should not rely on user agents to render white space immediately after a start tag or immediately before an end tag. Thus, authors, and in particular authoring tools, should write: We offer free <A>technical support</A> for subscribers. and not: We offer free<A> technical support </A>for subscribers. </q> Now, this solution would also account for the special SGML line break rules: <q source='HTML-4.01 SPEC B.3.1'> SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception. The following two HTML examples must be rendered identically: Thomas is watching TV. Thomas is watching TV. So must the following two examples: <A>My favorite Website</A> <A> My favorite Website </A> </q> Note that Firebird doesn't follow the SGML line break rules! This is not to say we should follow, but that we may find some buggy pages out there, but at least at this point the SPEC is quite clear. ;) > I'm not completely sure, we should carefully evaluate the specs, I'd > suggest to delay this for the 0.8.2 release. Neither I am sure! :-) At this point I see that applying patch 1, plus making the parser ignore whitespaces after a start tag and before an end tag is a correct solution that can endure a reality test. I'll start coding it. Please let me know your thoughts or any point I'm still missing. Best Jorge.- PS: This work is for 0.8.2.

May 14, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Jorge Arellano Cid

On Fri, 14 May 2004, Maarten Sander wrote: > Hi, > > > It's a simple test, if you have a working dillo binary after > > 'make', it's OK. That's all. > > > > Please don't be shy and report success on your platform. If > > nobody reports problems before Kelson is done (or Saturday), it > > will be released. ;-) > > Well, it works overhere :) > > I've just compiled and used Dillo on my Fedore Core 1 (Athlon-)machine. > It's updated with all the latest and greatest (*cough*) packages from > Dag, ATrpms, etc. GCC is 3.3.2, glibc 2.3.2, GTK 1.2.10. During > ./configure it gave a big warning that it could not find libpng-config, > but it detected png.h after that and compiled without problems. libpng is not easy to detect, maybe the Fedora team decided to go back to the simple header/library pair to avoid problems. Don't worry. You have a quite current GNU/Linux. Can you tell whether Dillo was linked against NPTL? Cheers Jorge.-

May 14, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Jorge Arellano Cid

On Fri, 14 May 2004, Kelson Vibber wrote: > On Thursday 13 May 2004 3:33 pm, Jorge Arellano Cid wrote: > > It is not yet announced, probably on Staurday, after Kelson is > > ready with the RPMs. > > I've got most of them put together, and the new index page is standing by. > There's one more I need to build at work, which I can do when I get in > tomorrow morning. Wow, that was fast! Thanks Kelson, and let me know when you're ready. > > > - A fix on pthreads detection code. > > > > The last one _NEEDS_ testing, on every machine! I may have said > > only on non Linux-based ones, but the bug was detected on an old > > libc5 based GNU/Linux! > > Interestingly, the one I had the most trouble with was pthread-related. For > some reason Conectiva 8 was willing to build without libpthread.a, but > Conectiva 9 was not. Once I installed glic-devel-static, it was fine. I wrote a bit about pthreads in my answer to Bob. Probably the pthread library/environment is different in Conectiva 8 and 9 (BTW, RedHat planned to add an environment variable to chose whether to use the old pthreads or the NPTL). Once again, I don't know the state of that mess :-), I can only wonder when Dillo runs on them! ;) > > > PS: Please note that this release shifts the state from alpha to > > "very stable beta". > > I have noted the change on the new RPM index page. Congratulations! Thanks. It's a product of all of those that participate in dillo-dev. Testers are very important. > > P.S. I should be able to add two more distributions in the next few weeks. I > plan on trying out Mandrake 10 soon (Every once in a while I try the latest > Mandrake with the intent of switching. So far, every time I've ended up > going back to Red Hat), and I've ordered a PowerBook with Yellow Dog Linux > preinstalled. Great toy! I wish I could have one of those at my fingertips! Cheers Jorge.-

May 14, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final on ps2

by Jorge Arellano Cid

On Fri, 14 May 2004, robert w hall wrote: > works OK on playstation2-linux with a 2.2.21 kernel (from xrhino). > I haven't tried it on the default (sony) 2.2.1 kernel (kids seem to have > deleted it!) - but dimly recollect pthreads is a library not a kernel > feature, (so it shouldn't matter???) POSIX threads is one of "those" complex matters. It depends on several things including the kernel and glibc. To add flavour, Linux comes/came with linux threads, which is close to POSIX but not fully. The New POSIX Threads Library (NPTL) is POSIX compatible, and requires special kernel threading (as of 2.5.36), glibc 2.3 and other bindings (RedHat 9 was going to be the first to provide such environment). Furthermore, there are several different threading libraries among the platforms we support, so go figure! You can read much more than you wanted to know here: http://lwn.net/Articles/10465/ http://people.redhat.com/drepper/nptl-design.pdf As you may have begun to suspect after this short exposition, it's hard to know, and certainly I don't know, whether it will also run with Sony's 2.2.1 kernel! :-) Regards Jorge.-

May 14, 2004

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final

by Kelson Vibber

On Thursday 13 May 2004 3:33 pm, Jorge Arellano Cid wrote: > It is not yet announced, probably on Staurday, after Kelson is > ready with the RPMs. I've got most of them put together, and the new index page is standing by. There's one more I need to build at work, which I can do when I get in tomorrow morning. > - A fix on pthreads detection code. > > The last one _NEEDS_ testing, on every machine! I may have said > only on non Linux-based ones, but the bug was detected on an old > libc5 based GNU/Linux! Interestingly, the one I had the most trouble with was pthread-related. For some reason Conectiva 8 was willing to build without libpthread.a, but Conectiva 9 was not. Once I installed glic-devel-static, it was fine. > PS: Please note that this release shifts the state from alpha to > "very stable beta". I have noted the change on the new RPM index page. Congratulations! P.S. I should be able to add two more distributions in the next few weeks. I plan on trying out Mandrake 10 soon (Every once in a while I try the latest Mandrake with the intent of switching. So far, every time I've ended up going back to Red Hat), and I've ordered a PowerBook with Yellow Dog Linux preinstalled. -- Kelson Vibber www.hyperborea.org

May 14, 2004

Re: [Dillo-dev]pre release

by Jorge Arellano Cid

On Wed, 12 May 2004, Frank W McCormick wrote: > > Hi all > Compiled and running the pre on Linux 2.4.24. No problems yet, but > one thing that's been bothering me since Dillo was given DL > capabilities....right clicking on a direct link gives you the DL but > were it not for the eth0 indicator in ICEWM I wouldn't have any > indication that DL was going ahead. Is this normal ? Please read the help page, downloads section... Cheers Jorge.-

May 13, 2004

[Dillo-dev]dillo-0.8.1.tar.bz2 final

by Jorge Arellano Cid

Hi there, It's being a long period of testing. As I don't want to delay the next release anymore, the final tarball is there, ready for download! It is not yet announced, probably on Staurday, after Kelson is ready with the RPMs. The final tarball is not exactly the same as "pre2", it comes with a few fixes: - A fix on iterartors (on a very rare critical warning). - A fix to gray up the stop button on downloads (1 line fix). - A new link in the splash, magazines section. - A fix on pthreads detection code. The last one _NEEDS_ testing, on every machine! I may have said only on non Linux-based ones, but the bug was detected on an old libc5 based GNU/Linux! It should work because it more or less leaves the settings as they were before, but with the enhancement of not linking pthread to every binary. It's a simple test, if you have a working dillo binary after 'make', it's OK. That's all. Please don't be shy and report success on your platform. If nobody reports problems before Kelson is done (or Saturday), it will be released. ;-) Good Luck! Jorge.- PS: Please note that this release shifts the state from alpha to "very stable beta". PS2: http://www.dillo.org/download/dillo-0.8.1.tar.bz2

May 13, 2004

Re: [Dillo-dev]Re: null byte in HTML

by Francis Daly

On Thu, May 13, 2004 at 08:08:30AM -0400, Jorge Arellano Cid wrote: > From: Jukka K. Korpela <jkorpela(a)cs.tut.fi> > On Wed, 12 May 2004, Jorge Arellano Cid wrote: > > > I can't yet found whether the null byte character is allowed in > > HTML. Can you shed some light on this? > > It is not. You could use http://validator.w3.org to check for disallowed > characters (it reports "non SGML character number 0"), but the ultimate > reference is > a) for HTML 4, the SGML declaration > http://www.w3.org/TR/html4/sgml/sgmldecl.html > where UNUSED effectively means 'disallowed' > b) for XHTML, the XML specification, see > http://www.w3.org/TR/REC-xml/#charsets > which say, among other things, that all characters below 9 (HT) are > disallowed. That seems authoritative. But for completeness, even though the character isn't allowed, it can appear, and how a browser handles it might matter. As a specific example, the "rt" issue tracker has a web interface. The version I was evaluating accepted (as I recall) the name "Se�n" as part of its input (the non-ascii character there is 0xe1, "LATIN SMALL LETTER A WITH ACUTE"). When it presented that back to the browser, the 0xe1 had become 0x00, which caused oddness in the display on a few browsers. The content-type was declared as text/html;charset=utf-8. I don't know if that was a part of, or a trigger for, the display problem. But either way, storing or accessing text/html as a C string will not work in (broken but existing) cases like that. If there's a straightforward way of flagging "I saw a NUL, this isn't text, complain to the web server administrator" in the bugmeter, that would probably be a reasonable failure (error correction) mode. All the best, f -- Francis Daly francis(a)daoine.org

May 13, 2004

[Dillo-dev]Re: null byte in HTML

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Thu, 13 May 2004 12:33:13 +0300 (EEST) From: Jukka K. Korpela <jkorpela(a)cs.tut.fi> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: Is the null byte allowed in HTML? On Wed, 12 May 2004, Jorge Arellano Cid wrote: > I can't yet found whether the null byte character is allowed in > HTML. Can you shed some light on this? It is not. You could use http://validator.w3.org to check for disallowed characters (it reports "non SGML character number 0"), but the ultimate reference is a) for HTML 4, the SGML declaration http://www.w3.org/TR/html4/sgml/sgmldecl.html where UNUSED effectively means 'disallowed' b) for XHTML, the XML specification, see http://www.w3.org/TR/REC-xml/#charsets which say, among other things, that all characters below 9 (HT) are disallowed. Thanks for a good question - I'm just finalizing a book on XHTML (in Finnish, sorry) and I realized that I had forgotten to discuss the character issue in sufficient detail. (I just realized that various generators may produce data with control characters.) -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

May 13, 2004

[Dillo-dev]null byte in HTML

by Jorge Arellano Cid

Hi there! Does anyone know whether a null-byte ('\0') is allowed inside HTML or SGML or XML? Cheers Jorge.-

May 12, 2004

[Dillo-dev]pre release

by Frank W McCormick

Hi all Compiled and running the pre on Linux 2.4.24. No problems yet, but one thing that's been bothering me since Dillo was given DL capabilities....right clicking on a direct link gives you the DL but were it not for the eth0 indicator in ICEWM I wouldn't have any indication that DL was going ahead. Is this normal ? -- -------------- Frank McCormick Montreal --------------

May 12, 2004

Re: [Dillo-dev]download problem on OpenBSD

by Jorge Arellano Cid

On Sun, 1 Jan 1995, Riccardo Mottola wrote: > Riccardo Mottola wrote: > > > > Hello, > > > > using pre2 I went to sourceforge do download a file. On the mirror page > > I selected one and clicked on the "here" message for the non-stadard > > refresh which gives a direct link to the file (I could use it for d/l > > with wget). > > > > Clicking on it brought up a file location requester, I selected my home > > directory and gave ok. Dillo crashed with: > > I tried again with another site (after a computer reboot) and it crashed > the same way. > However, retrying, by restarting dillo, makes it work. It must be a dpi > launching problem ? I tried to reproduce it, but with no luck. Once running, the dpid daemon should not have trouble with the dpi_socket_dir file (it holds the directory name under /tmp used to create the unix domain sockets for each dpi server). BTW, it should survive a reboot! Maybe you have a cron job that removes the socket directory used by dillo or something like that. Please try to find a more precise way to reproduce it, as I can't with the first post's instructions. Can anyone else reproduce this? How does dillo crash? A Segfault, no download, silent exit? Cheers Jorge.-

May 11, 2004

Re: [Dillo-dev]dillo interface and motif, athena etc

by Jorge Arellano Cid

On Tue, 11 May 2004, Riccardo Mottola wrote: > david feldman wrote: > > > > I think your questions are very good, I hope you get good answer! > > > > unfortunately there was no follow up. I wonder if anyone else beside you > was interested. > > -R http://phaseit.net/claird/comp.windows.x.motif/motif.html

May 11, 2004

Re: [Dillo-dev]dillo interface and motif, athena etc

by Riccardo Mottola

david feldman wrote: > > I think your questions are very good, I hope you get good answer! > unfortunately there was no follow up. I wonder if anyone else beside you was interested. -R

May 11, 2004

[Dillo-dev]download problem on OpenBSD

by Riccardo Mottola

Hello, using pre2 I went to sourceforge do download a file. On the mirror page I selected one and clicked on the "here" message for the non-stadard refresh which gives a direct link to the file (I could use it for d/l with wget). Clicking on it brought up a file location requester, I selected my home directory and gave ok. Dillo crashed with: Nav_open_url: Url=>http://prdownloads.sourceforge.net/ayttm/ayttm-0.4.6.tar.gz?use_mirror=hean…< Connecting to 66.35.250.217 Nav_open_url: Url=>http://heanet.dl.sourceforge.net/sourceforge/ayttm/ayttm-0.4.6.tar.gz< Dns_server [0]: heanet.dl.sourceforge.net is 0x721cb8 Connecting to 193.1.219.87 HTTP warning: Unhandled MIME type: <application/x-gzip> dpi.c:71: a_Dpi_rd_dpi_socket_dir: fopen : No such file or directory - /home/multix/.dillo/dpi_socket_dir debug_msg - init_sockdir: The dpi_socket_dir file does not exist dpid started Riccardo

May 11, 2004

Re: [Dillo-dev]BUG#522

by Jim Nutt

On Mon, 10 May 2004 12:17:22 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Can anyone reproduce BUG#522? I can't reproduce it either: Linux moe 2.6.6-rc2 #1 Sun May 2 19:33:28 EDT 2004 i686 AMD Duron(tm) processor AuthenticAMD GNU/Linux Dillo CVS as of 09May2004 about 2100 EST -- jim nutt home: jim(a)nuttz.org jabber: jimnutt(a)jabber.com work: jimnutt(a)vestek.com ms msg: jim(a)nuttz.org pgp id: 1ECBCC78

May 10, 2004

Re: [Dillo-dev]BUG#522

by Jorge Arellano Cid

On Mon, 10 May 2004, Riccardo Mottola wrote: > Jorge Arellano Cid wrote: > > > > Hi, > > > > Can anyone reproduce BUG#522? > > [...] > > No I cannot reproduce it on solaris. > > I compiled dillo on Solaris, UltraSparc too (alyazs solaris 2.6, gcc > 3.3) You might add this to the compatibility list too. So we have: Solaris 2.6, gcc 3.3, Sparc v8 processor (=32bit) Solaris 2.6, gcc 3.3, UltraSparc (64bit?) What SunOS do they report? Cheers Jorge.-

May 10, 2004

[Dillo-dev]BUG#522

by Jorge Arellano Cid

Hi, Can anyone reproduce BUG#522? 522 Impact: soft error At: run time Type: crash Comments: Url=>http://www.rti-zone.org/dillo/Html.testsuite/jorge/c2.html< Gdk-ERROR **: BadValue (integer parameter out of range for operation) serial 4689 error_code 2 request_code 45 minor_code 0 HTReproduce: debian unstable WorkedBy: nobody Cheers Jorge.-

May 10, 2004

Re: [Dillo-dev]dillo-0.8.1-pre2.tar.bz2

by Jorge Arellano Cid

Riccardo, > Someone is in the search for good news? I have none. > > > Riccardo Mottola wrote: > > Program received signal SIGILL, Illegal instruction. > > 0x0 in ?? () from /usr/local/build/dillo-0.8.1-pre2/src/dillo > > > > I think this is a GTK related bug. I compiled a small program (gcolor) > that uses gtk and it dies the same way! > I have gtk 1.2.10 patched with Jorge's func_data type patch. > I never used gtk except for dillo... > > Now, maybe I know why the idea of a Motif port or widget independent > port is getting into my head again. Oh the fears of GTK! It's not GTK, but AIX. Just google search for the problem you have. Frankly, you're in the best position to solve it because you have the AIX machine at hand. If you're not a developer, try asking an experienced AIX developer that has had the same problem. As for the testing on Solaris, please send me the machine/OS SPEC to include it in the compatibility list. Cheers Jorge.-

May 10, 2004

Re: [Dillo-dev]dillo-0.8.1-pre2.tar.bz2

by Riccardo Mottola

Someone is in the search for good news? I have none. Riccardo Mottola wrote: > Program received signal SIGILL, Illegal instruction. > 0x0 in ?? () from /usr/local/build/dillo-0.8.1-pre2/src/dillo > I think this is a GTK related bug. I compiled a small program (gcolor) that uses gtk and it dies the same way! I have gtk 1.2.10 patched with Jorge's func_data type patch. I never used gtk except for dillo... Now, maybe I know why the idea of a Motif port or widget independent port is getting into my head again. Oh the fears of GTK! -Riccardo

May 10, 2004

Re: [Dillo-dev]dillo-0.8.1-pre2.tar.bz2

by Riccardo Mottola

Jorge Arellano Cid wrote: > Any use of the browser serves, specially testing the new > download feature and multiple windows at the same time. I have compiled and run pre3 on a Solaris 2.6 sparcstation 32 bit. I browsed around, opened multiple windows and it seems to behave fine. I used this browser test from the iCab people (a light browser for MacOS): http://www.icab.de/test.html and seen that dillo fails quite trhough those tests. The I tried compiling on AIX again, pre2. (gdb) run Starting program: /usr/local/build/dillo-0.8.1-pre2/src/dillo Program received signal SIGILL, Illegal instruction. 0x0 in ?? () from /usr/local/build/dillo-0.8.1-pre2/src/dillo the interesting is that I was working on an exported display, without having set the DISPLAY variable. So X apps couldn't possibly start and should output % xlogo Error: Can't open display: This means dillo si failing really early on AIX. These warnings may not be essential, but they may be worth looking: dpid.c: In function `init_srs_socket': dpid.c:409: warning: implicit declaration of function `bzero' downloads.c:179: warning: implicit declaration of function `bzero' I still get those errors: main.c: In function `start_filter_plugin': main.c:47: warning: passing arg 3 of `naccept' from incompatible pointer type but they shouldn't be fatal, AIX must be pricky about socket types and I get that waring with other programs too. socket.h defines: extern "C" int naccept(int, struct sockaddr *, size_t *); and types.h says: types.h:typedef unsigned long size_t; configure reports checking for gethostbyname... yes checking for setsockopt... yes checking for socklen_t... int Cheers, Riccardo

May 10, 2004

Re: [Dillo-dev]dillo-0.8.1-pre2.tar.bz2

by Riccardo Mottola

Jorge Arellano Cid wrote: > > > Any use of the browser serves, specially testing the new > download feature and multiple windows at the same time. I tested it on OpenBSD/sparc and I browsed all the evening without apparent problems, i didn't stress it further though. tomorrow I will try Solaris again and maybe give AIX a new kick. But AIX is beginning to be a black sheep here :) Maybe I test it on NetBSD/68k too if I can... I'll let you know if any problems appear on some platform -Riccardo

May 9, 2004

Re: [Dillo-dev]dillo-0.8.1-pre2.tar.bz2

by Jorge Arellano Cid

On Sun, 9 May 2004, Johannes Hofmann wrote: > Hi, > > dillo-0.8.1-pre2.tar.bz2 works nice here on DragonFly-BSD. The new > handling of unknown MIME types is really a great addition. Good! > Just one little thing: When canceling from the save dialog, the > stop-button stays clickable. Shouldn't it get greyed out? Yes it should; Fixed and commited. Patch: diff -pru dillo/src/cache.c dillo-0.8.0/src/cache.c --- dillo/src/cache.c 2004-05-08 20:31:37.000000000 -0400 +++ dillo-0.8.0/src/cache.c 2004-05-09 14:24:18.000000000 -0400 @@ -827,6 +827,7 @@ static void Cache_process_queue(CacheDat if (st == -1 && ClientWeb->flags & WEB_RootUrl) { /* Unhandled MIME type, prepare a download offer... */ AbortEntry = TRUE; + a_Interface_remove_client(Client_bw, Client->Key); Cache_client_dequeue(Client, NULLKey); --i; /* Keep the index value in the next iteration */ continue; Cheers Jorge.-

May 9, 2004

Re: [Dillo-dev]dillo-0.8.1-pre2.tar.bz2

by Johannes Hofmann

Hi, dillo-0.8.1-pre2.tar.bz2 works nice here on DragonFly-BSD. The new handling of unknown MIME types is really a great addition. Just one little thing: When canceling from the save dialog, the stop-button stays clickable. Shouldn't it get greyed out? Cheers, Johannes On Sat, May 08, 2004 at 08:29:01PM -0400, Jorge Arellano Cid wrote: > > Hi there! > > It took a long time, but finally, dillo-0.8.1-pre2.tar.bz2 is > ready for download. > > The problem was that the patch for the problem of left-clicking > an unhandled MIME type involved changes, inside the cache module, > that were not trivial. > > I pondered the situation carefully trying to decide whether to > make the patch and delay the next release, or leave it for 0.8.2. > After studying the situation and developing a patch, important > changes were made in the cache (for instance all the cached URLs > use new code now, and the main scheduler was also changed, and > the posibility of deleting an active URL-transfer was made > possible). > > After all that, it only remained to offer a download dialog for > the aborted transfer, and as the patch was already major, I went > ahead and the result was one of those improvements you can't > leave out. > > What does it do? well, now you can left-click on any URL; if it > happens to be of an unhandled MIME type, the transfer is aborted, > and a download dialog appears to offer the possibility of saving > the resource locally. Simple and clean. Now you can click > carelessly on those fake-download links from SF until you reach > the real source ;). > > The tradeoff: the possibility of labelling this release as > "beta stable" is not as clear as before. This tarball requires > plenty of testing, so please download it and give it a hard time! > > Any use of the browser serves, specially testing the new > download feature and multiple windows at the same time. > > Get it from: > > http://www.dillo.org/download/dillo-0.8.1-pre2.tar.bz2 > > and report back to dillo-dev. > > Cheers > Jorge.- > > > PS: Kudos are also welcome! ;) > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 9, 2004

[Dillo-dev]dillo-0.8.1-pre2.tar.bz2

by Jorge Arellano Cid

Hi there! It took a long time, but finally, dillo-0.8.1-pre2.tar.bz2 is ready for download. The problem was that the patch for the problem of left-clicking an unhandled MIME type involved changes, inside the cache module, that were not trivial. I pondered the situation carefully trying to decide whether to make the patch and delay the next release, or leave it for 0.8.2. After studying the situation and developing a patch, important changes were made in the cache (for instance all the cached URLs use new code now, and the main scheduler was also changed, and the posibility of deleting an active URL-transfer was made possible). After all that, it only remained to offer a download dialog for the aborted transfer, and as the patch was already major, I went ahead and the result was one of those improvements you can't leave out. What does it do? well, now you can left-click on any URL; if it happens to be of an unhandled MIME type, the transfer is aborted, and a download dialog appears to offer the possibility of saving the resource locally. Simple and clean. Now you can click carelessly on those fake-download links from SF until you reach the real source ;). The tradeoff: the possibility of labelling this release as "beta stable" is not as clear as before. This tarball requires plenty of testing, so please download it and give it a hard time! Any use of the browser serves, specially testing the new download feature and multiple windows at the same time. Get it from: http://www.dillo.org/download/dillo-0.8.1-pre2.tar.bz2 and report back to dillo-dev. Cheers Jorge.- PS: Kudos are also welcome! ;)

May 9, 2004