- 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