May 2004 - Dillo-dev - lists.mailman3.com

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