[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Future directions for browsers in emacspeak
everthing you say is correct.
My own thinking on this was to try to get one of the
emacs/firefox integration bits working -- people claim to have
and then send it to Firefox for evaluation -- it's a plugin to
aid debugging. The advantage from an emacspeak perspective is
that those plugins then allow ou to walk the DOM of the document
you're looking at, so we could essentially get exactly what
you're suggesting; namely, let Firefox do the heavy lifting of
handling badly formed HTML and giving us a reasonable DOM to work
with, and Emacspeak/emacs doing the speech interaction.
To date I've not succeeded in getting any of those plugins to
you'll find the ones I found.
I'll also admit to not having spent too much time trying to get
them to work.
So if you have the time and the energy, that's where i'd suggest
starting; once we have one of those beasts running predictably
the rest should be fun to build.
>>>>> "Lukas" == Lukas Loehrer <email@example.com> writes:
Lukas> Sorry for hijacking the thread, but this has been
Lukas> bugging me for some time. I wonder if neither w3m nor
Lukas> w3 are the way to go for the future. Both of these
Lukas> browser try to render the web page visually which is
Lukas> really a waste of effort for people who cannot read
Lukas> the screen. It occured to me that a web browser for
Lukas> blind people is really just a fancy way to navigate
Lukas> the DOM of the page at hand, so one is more interested
Lukas> in the logical structure of the document than in one
Lukas> possible visual representation provided by thos
Lukas> I like the w3m way of having an external process do
Lukas> most of the work, so emacs is not blocked. I first
Lukas> thought one could write a program using libtidy to get
Lukas> the dom of web pages. While this solution would be
Lukas> rather easy to implement using existing bindings to
Lukas> libtidy for example from python, it would not give us
Lukas> Tim mentions are becoming more and more important.
Lukas> So, it seems that a real browser engine like khtml or
Lukas> gecko has to be employed. I mean not the part that
Lukas> does the rendering but only thos parts that fetch the
Lukas> page and manage the DOM. Good bindings for a friendly
Lukas> language like python, perl or ruby would be very
Lukas> helpful in such an project.
Lukas> The external program could then offer a simple
Lukas> interface that could be wrapped from emacspeak, in
Lukas> order to navigate the page.
Lukas> The above is just a kind of brain dump, not an outline
Lukas> for a real project. I am not suggesting that anyone
Lukas> (except maybe myself) gets to work on this
Lukas> tomorrow. Still, I would be very interested in input
Lukas> on the general direction proposed above.
Lukas> Best regards, Lukas
Lukas> Tim Cross writes ("w3m and reading www pages with
Lukas> multiple collumns"):
>> Hi Paul,
>> I actually find both w3 and w3m are useful. For some
>> pages, w3 does a nice job and you get a very nice
>> intergration with emacspeak. In other situations, w3m is
>> better. Depending on your distribution, it can be a little
>> time consuming to install w3. Debian has it as a package
>> and it is reasonably up to date. However, you really need
>> the latest w3 CVS version to get the best result.
>> While it is not an ideal situation, at least with both
>> browsers, we get a reasonable coverage. I think part of
>> the problem is that development of w3 stalled a few years
>> back and now with w3m, there is even less motivation for
>> others to contribute to w3. From an emacs perspective, I
>> think there is more potential for better integration with
>> w3, but w3m has some advantages with respect to speed and
>> the rendering of pages.
>> It will be interesting to see what happens in the future
>> considering the growth in use of Ajax. Some experimental
>> w3, but I don't know about w3m.
Lukas> To unsubscribe from the emacspeak list or change your
Lukas> address on the emacspeak list send mail to
Lukas> "firstname.lastname@example.org" with a subject of
Lukas> "unsubscribe" or "help"
AIM: emacspeak GTalk: email@example.com
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "firstname.lastname@example.org" with a
subject of "unsubscribe" or "help"
Emacspeak Files |
Unsubscribe | Search