On Wed, 17 Oct 2007, Franz Korntner wrote:
Thanks for your contribution -- comments below.
In the meantime I noticed that my contribution was incomplete as I missed out
the riscos subdirectory. I work under linux and have no access to riscos
running platform. The full patch netsurf-1.1a4.patch.gz is some odd 10000
lines and I have made a selection of interesting changes in
netsurf-1.1a4.fixes.gz which might possibly be considered as bugfixes. [the
a4 is my internal version number].
I currently don't have time to look at your patch (it'll probably be next
week when I get time), but 10000 lines is most likely too big to evaluate
in one go. Is there any possibility that you could break it up into more
manageable chunks?
Finally I constructed autoconf/automake templates as I require certain
functionality not delivered by the supplied makefile. I suggest you include
these files so that package/distribution builders can choose which system to
use.
Are you suggesting that the existing build system be replaced? If so,
that's a non-starter as it's highly unlikely that autotools will ever work
on RISC OS.
For the same reasons I suggest you include precompiled versions of
lemon/re2c generated files.
Currently, these are available from
http://netsurf.strcprstskrzkrk.co.uk/developer/ -- they're recreated
automatically as needed. The CSS parser is due for a major overhaul at
some point in the relatively near future. I currently have no idea whether
this will have an impact on the use of lemon/re2c.
At the moment I'm analyzing the rendering coordinate system, the numeric
operations on it, the mixed use of int's and floats, the knowledge that a FPU
is absent, and the propagation of rounding errors. It gives interesting
reading and I see possibilities to extremely minimize FP operations in the
rendering engine in exchange for maximized accuracy.
This sounds good and I look forward to seeing the results of your efforts.
The current layout engine cannot cope with the document changing.
There's also no DOM support to speak of. John Mark Bell has recently
been writing a new HTML parser and a DOM library that should hopefully
be complete with a few months. That would make JavaScript somewhat
easier.
Good to know.
I have a good feeling that DOM functionality can easily be injected in the
current HTML parser.
That depends; whilst libxml already produces a tree which is fairly
close to the W3C DOM, its HTML parser is particularly non-robust to
real-world web content. Additionally, its architecture is not suited to
handling injection of data into the document source stream (as required by
certain scripting methods -- namely document.write()).
I am looking for a small footprint package and get unnervy with the
foresight of the introduction of a complete and/or standalone DOM
component. This might make things easier.
I'm not sure I understand this. Are you saying that a standalone DOM
component is a good thing or not? Note that a standalone HTML parser and
core DOM implementation is likely to be smaller than a binary of libxml.
Note that both the HTML parser and DOM implementation will be standalone
libraries.
We've looked at several JavaScript libraries in the past. The choices
are narrow when you have the requirements that it be linkable to C,
compilable on RISC OS, and have a GPL2-compatible licence. Performance
is also an issue: Many users of NetSurf use it on machines with CPUs
less than 500MHz, and with no FPU.
Ok. i'll also take that into account. I'm leaning more towards seamonkey as
it seems that it can be made lightweight.
The two libraries I currently favour are SpiderMonkey (which is what I
think you meant, not SeaMonkey ;) and libsee. However, JavaScript work is
someway down the line, so a decision on this hasn't happened yet.
Cheers,
John.
