HTML document browser ?
Erik Naggum
:
| I'm sorry if this is the wrong group but I couldnt find a group related
| to HyTime Markup Language.
Not quite the wrong group, but HTML does not stand for HyTime Markup
Language. Actually, HyTime is an International Standard (ISO 10744) whose
full name is "Information Technology -- Hypermedia/Time-based Structuring
Language (HyTime)", and is an application of SGML, while HTML is the
"Hypertext Markup Language" or somesuch, and comes out of the World Wide
Web project out of CERN.
Your question would probably be answered more completely in
comp.infosystems.www, to which I have directed follow-ups.
| Anyway,since HTML is related to SGML, here goes: does someone know of a
| read-only browser for HTML documents ? What I need is something in PD
| or shareware that takes a HTML doc ( extension .html ) and presents it
| in a window; if a link is activated, the viewer forks to present this
| new document or presents it in the same window. This browser would be
| similar to the XMosaic product from NCSA but without all the bells and
| whistles.
|
| Does anybody know where I can ftp such a thing ? Does it even exist ?
Best regards,
</Erik>
--
Erik Naggum <er...@naggum.no> <SG...@ifi.uio.no> ISO 8879 SGML
Chairman, SGML SIGhyper <SGML.S...@ifi.uio.no> ISO 10744 HyTime
"Memento, terrigena. Memento, vita brevis." ISO 10646 UCS
Marc Andreessen
writes:
Anyway,since HTML is related to SGML, here goes: does someone know
of a read-only browser for HTML documents ? What I need is
something in PD or shareware that takes a HTML doc ( extension
.html ) and presents it in a window; if a link is activated, the
viewer forks to present this new document or presents it in the
same window.
You just pretty much described NCSA Mosaic (ftp to ftp.ncsa.uiuc.edu
in /Mosaic).
This browser would be similar to the XMosaic product
from NCSA but without all the bells and whistles.
Ah. Well, you could place masking tape over where the menubar shows
up on the screen...
Marc
--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
ma...@ncsa.uiuc.edu
HALLAM-BAKER Phillip
|>In article <1993Jun22....@psg.com> mval...@draco.lnec.pt ()
|>writes:
|>
|> Anyway,since HTML is related to SGML, here goes: does someone know
|> of a read-only browser for HTML documents ? What I need is
|> something in PD or shareware that takes a HTML doc ( extension
|> .html ) and presents it in a window; if a link is activated, the
|> viewer forks to present this new document or presents it in the
|> same window.
|>
|>You just pretty much described NCSA Mosaic (ftp to ftp.ncsa.uiuc.edu
|>in /Mosaic).
|>
|> This browser would be similar to the XMosaic product
|> from NCSA but without all the bells and whistles.
|>
|>Ah. Well, you could place masking tape over where the menubar shows
|>up on the screen...
Actually such a mode would be quite usefull. Say I was presenting some
docs and didn't want the user to bounce off into the web by mistake and
not know where they were.
Also would like to have the full space on the screen without the bits at the
top and botton. They take up valuable space for text, especially when using
eXcursions on the PC on a small screen,
Phill
Frank Teusink
|>|> This browser would be similar to the XMosaic product
|>|> from NCSA but without all the bells and whistles.
|>|>
|>|>Ah. Well, you could place masking tape over where the menubar shows
|>|>up on the screen...
|
|>Actually such a mode would be quite usefull. Say I was presenting some
|>docs and didn't want the user to bounce off into the web by mistake and
|>not know where they were.
I agree. I am also looking for a simple HTML browser running under MS-DOS
(MS-Windows), without all this www stuff (-; oops, maybe I'm in the wrong
newsgroup ;-)
Frank Teusink
Paul De Bra
on systems with no or a very slow internet connection.
I would advocate a visual distinction between 'local' links and links
going off into the network (hhtp, gopher, etc. links), so the user can
be aware he/she's going to leave the current hyperdocument.
I would also advocate including the help files with the x-mosaic source,
so clicking the help button doesn't tie up the network, and so a
non-networked system could also have a functional help button.
Paul.
Edward Vielmetti
: X-Mosaic is indeed a fine HTML document browser, but can hardly be used
: on systems with no or a very slow internet connection.
I'm using NCSA Mosaic on the slow end of a SLIP line; while it is
slow to connect to and download large remote files, I take that as
a flaw of the network link and not Mosaic itself.
It would be useful to have more clues, tho, as to the size of remote
documents. The "file://host.domain.org" set of URLs based on FTP
could provide more detail, assuming that you can parse the ls output
and display it in some sensible way. Note that "gopher" doesn't
return any file size information at all, and so you may have a hard
time predicting how slow those links will be to traverse.
We need to get the Mosaic developers a nice slow modem connection
to help them design it (just like Gopher was built in part on a 2400
baud line).
--Ed
Brook Conner
Paul> X-Mosaic is indeed a fine HTML document browser, but can hardly be used
Paul> on systems with no or a very slow internet connection.
Paul> I would advocate a visual distinction between 'local' links and links
Paul> going off into the network (hhtp, gopher, etc. links), so the user can
Paul> be aware he/she's going to leave the current hyperdocument.
I'd disagree here. One of the things I like so much about XMosaic is
that you don't know locations and don't _need_ _to_.
If you really want a local-only browser for HTML documents, write one.
The HTML widget XMosaic uses is well-documented (albeit in the web).
I whipped up a local-only browser in about an hour (to get an idea of
how hard an editor would be to make): read a filename off of the
command line, read in the file, give the resulting char* to the HTML
widget, et voila! Add a callback for following links, pop up dialogs
for things that aren't local files ("Can't access URL
blahblah:/internet.far.away") and you're all set.
Paul> I would also advocate including the help files with the x-mosaic source,
Paul> so clicking the help button doesn't tie up the network, and so a
Paul> non-networked system could also have a functional help button.
That's a reasonably good suggestion, but how did you get XMosaic in
the first place if you didn't have an Internet connection?
Better perhaps might be a tar file in the ftp directory: xmosaic-doc.tar.Z
Brook
--
Klacktoveedsedstene
William M. Perry
Well, I've been experimenting with the Win-Emacs 1.00.05 (not sure
of the version #, but its close), which is a lucid emacs clone for
Windows (actually, its a complete implementation, just based on an
xwindows emulation DLL). Just on a lark I decided to try and run my
WWW browser in it. Worked with 1 change (had to add ".ht" to the
list of hypertext extensions), which took about 5 seconds.
My browser is written entirely in elisp, so its completely
portable. :) I'd say the Lucid version would have to be the best
looking of them all (it supports fonts/highlighting in epoch, emacs19,
and lucid, graphics in epoch). Full menu support etc in lucid and
emacs19.
The Lucid Emacs for windows can be ftp'd from netcom.com in
/pub/pearl - be warned though - it requires the Xwindows DLL that is
proprietary. (It pops up a warning after its been idle for so long
about how you are supposed to buy it, etc). So unless you are
planning to buy the DLL (or want to write one on your own), this
probably won't be for you.
You can ftp my emacs browser from cs.indiana.edu in /pub/elisp/w3.
Main files are in w3.tar.z, extras (ange-ftp, gopher mode, etc) are in
extras.tar.z.
BTW: My browser will run inside normal emacs also, so you should be
able to use it with Oemacs, Demacs, etc.
And if for some reason you don't like emacs (heathen), then you
should probably take a look at Cello. (Not sure of the ftp address,
but it was posted here within the last 3 or 4 days). Just don't put
in any links to outside your local machine, and your users won't be
able to wander off (unless they know enough to type in a valid url, at
which point they _should_ be let wander :)
Hope this helps,
Bill Perry
Guido van Rossum
>I'd disagree here. One of the things I like so much about XMosaic is
>that you don't know locations and don't _need_ _to_.
Maybe you have been living in well-connected place long enough to
forget how slow file transfers can be. I haven't, yet. When the
difference between retrieving a (more-or-less) local document and a
remote document is in the order of half a minute or more, you
certainly need to know (an estimate of) the location in order to guess
whether it will be worthwile to wait for the data. Mosaic is still
useful under these circumstances: at many places in Europe, access to
pages stored at CERN may be fast but pages stored anywhere in the US
may be slow.
BTW, if you open the "Window History" dialog, you can see the URL's of
the anchors in the document, which can help estimating the distance...
--Guido van Rossum, CWI, Amsterdam <Guido.va...@cwi.nl>
Nathan Torkington
the host, decide how far away it is, and colour the anchor
accordingly, from hot red (local file, click on me!) to cold blue
(five satellites, a 2400baud modem connection and horse ride away).
You have your mission, Marc, should you choose to accept it ;)
Nat
Marc Andreessen
gn...@kauri.vuw.ac.nz (Nathan Torkington) writes:
Actually, that's not too far off from what we're already planning to
do (someday)... mouse tracking in the HTML widget -- pass the pointer
over a hyperlink and get a status readout showing you the destination
URL and any other info we can divine.
If anyone wants to donate ping-dependent code like Nat suggests,
though, we'll be happy to take a look at it and then turn our noses up
at it :-).
William M. Perry
>do (someday)... mouse tracking in the HTML widget -- pass the pointer
>over a hyperlink and get a status readout showing you the destination
>URL and any other info we can divine.
One thing that would be nice in Xmosaic is some way to see the URL
under the cursor. (Or is there already a way to do this (other than
getting the entire document source?)
Is this feasible with the current HTML widget?
-Bill Perry
A. Bryan Curnutt
>
>That's a reasonably good suggestion, but how did you get XMosaic in
>the first place if you didn't have an Internet connection?
I got mine from either DEC's ftpmail, or by asking the UUNET operator
to ftp it for me and uucp it to my machine -- I forget which. That was
before I found out that you need to be on the Internet in order to
read the documentation...
I _really_ like the idea of having documentation available, whether
it's in a separate tar file or no.
--
Bryan Curnutt Stoner Associates, Inc.
bryan%uhu...@uunet.uu.net (713)626-9568 voice (713)622-7832 fax
Dave Whittington
OK
>The HTML widget XMosaic uses is well-documented (albeit in the web).
.
.
.
>blahblah:/internet.far.away") and you're all set.
This is fine if you have Motif, but is there an HTML Athena widget
out there.
Dave
Marc Andreessen
OK
>The HTML widget XMosaic uses is well-documented (albeit in the web).
.
.
.
>blahblah:/internet.far.away") and you're all set.
This is fine if you have Motif, but is there an HTML Athena widget
out there.
Boy, are you in luck. Mosaic's HTML widget was designed to work just
fine without Motif -- in fact, it was developed completely separately
from Mosaic's Motif-based user interface and the test programs were
raw Xt -- and subsequent modifications as Mosaic has evolved have
continued this independence. It won't be difficult to pick it up and
plop it into an Athena application.
Marc Andreessen
de...@wsinis07.info.win.tue.nl (Paul De Bra) writes:
X-Mosaic is indeed a fine HTML document browser, but can hardly be used
on systems with no or a very slow internet connection.
I assume this is largely because Mosaic currently indiscriminately
pulls over inlined images without checking with the user first in such
a situation -- right? We're considering an option to have inlined
images show up as (small, built-in) iconic anchors that reference the
images as external images, which would ameliorate this.
I would advocate a visual distinction between 'local' links and links
going off into the network (hhtp, gopher, etc. links), so the user can
be aware he/she's going to leave the current hyperdocument.
On the list...
I would also advocate including the help files with the x-mosaic source,
so clicking the help button doesn't tie up the network, and so a
non-networked system could also have a functional help button.
Also on the list.
Chees,
Nathan Torkington
> Boy, are you in luck. Mosaic's HTML widget was designed to work just
> fine without Motif -- in fact, it was developed completely separately
> from Mosaic's Motif-based user interface and the test programs were
> raw Xt -- and subsequent modifications as Mosaic has evolved have
> continued this independence. It won't be difficult to pick it up and
> plop it into an Athena application.
I'll second this -- I wrote a pre-pre version 0.1 HTML editor a while
ago, and I used the Athena text widget for text entry, and bound ^L to
refresh the HTML widget underneath. The HTML widget did its job
perfectly, though there were some weirdnesses with Athena packing (I
think) to get over.
Nat
Chris Johnson
> d...@cs.brown.edu (Brook Conner) writes:
>
> >I'd disagree here. One of the things I like so much about XMosaic is
> >that you don't know locations and don't _need_ _to_.
>
> Maybe you have been living in well-connected place long enough to
> forget how slow file transfers can be. I haven't, yet. When the
> difference between retrieving a (more-or-less) local document and a
> remote document is in the order of half a minute or more, you
> certainly need to know (an estimate of) the location in order to guess
> whether it will be worthwile to wait for the data.
half a minute? I think you are living well :-)
when I were a lad, we lived in a cardboard box and waited 12 hours for a batch run every time we changed a line in the program... :-)
when there are megabytes in some pictures, getting them to Australia takes many
many minutes... when performance of the net makes this much quantitative
difference, there is a real qualitative difference to the feel of the tool.
Try looking at the ANU BioInformatics links, for example, from a distance, to
get something of the feel of working from this end of the world.
(//life.anu.edu.au:80)
Transparency is a worthy goal, but functional transparency is only half the
story. We must try to get near-transparency of performance eventually... which may mean more attention to local caching and alternative sources, with in-built mirroring.
In the current state of the art and the network bandwidths around the world
the feedback to the (naive ?) user could be given by an indication of how
long/how big/how far is the next link, with a threshold value that would ask
the user to confirm the fetch. I would compare this with database retrieval
interfaces: how big is the set you have selected tells you whether you really
want to display it or to refine your query a bit more first.)
---
Chris Johnson phone: +61 6 249 2624 or 282 1993 (h)
Dept of Computer Science in Australia (06) 249 2624
Australian National University AARNet,Internet: c...@cs.anu.edu.au
Canberra, ACT 0200 fax: +61 6 249 0010
Thomas Dettmer
>In article <2070uh$1...@wsinis07.info.win.tue.nl>
>de...@wsinis07.info.win.tue.nl (Paul De Bra) writes:
>
> I would advocate a visual distinction between 'local' links and links
> going off into the network (hhtp, gopher, etc. links), so the user can
> be aware he/she's going to leave the current hyperdocument.
>
>On the list...
>
seems to be[come] a long list :-). The visual distinction is a good idea,
put I'd suggest (additionally) some command (double click, right mouse
button or even pull down) to show the link or href value. I know it can be
done scrolling throug the HTML source, but with lenghty documents this is
far away from comfortable. Especially for me, because I'll try to use
automaticly generated HTML which has no user oriented newline formatting.
only to expand the list..:-)
tom
--
det...@ls1.informatik.uni-dortmund.de
phone: +49-231 755 6464, FAX: +49-231 755 6555
Thomas Dettmer, Dortmund University, Computer Science I
Post Box 50 05 00, W-4600 Dortmund 50, Germany
mval...@draco.lnec.pt
Hi:
I'm the original poster of the HTML browser request.
Just thought I should justify it.
The organization where I work is not intending to access
WWW. We're building a multimedia documental database and had
to decide on a hypertext format. Since we have to use standards
when possible we decided to use HTML ( with it being based on
SGML ).
We dont need access to remote files, FTP, WAIS, gopher, etc.
We just need a browser for HTML docs.
Of course I tough of modifying xmosaic, cutting out parts that
I dont need, basically using the HTML widget. I just tought I
could get it easy :-) and save time for more important work.
I already requested that the poster who said had done this to
make his work available to others, if possible.
C U!
By(e)
Mario Valente
Steven Grimm
>when there are megabytes in some pictures, getting them to Australia takes many
>many minutes...
You don't have to be in Australia; our net link runs over a wimpy V.32bis
modem connection, which means looking at anything with graphics is a slow
process indeed. What would be neat would be a progress meter of some sort
(which would appear after X seconds of elapsed time) and, more importantly,
an "ABORT" button I can press when I accidentally jump into a 10-megabyte
MPEG file!
An option for compressed file transmission might be worth looking into as
well. That'll become increasingly necessary as people start accessing the
Web from their cellular-modem-equipped PDAs and palmtops.
-Steve
frans van hoesel
: You don't have to be in Australia; our net link runs over a wimpy V.32bis
: modem connection, which means looking at anything with graphics is a slow
: process indeed. What would be neat would be a progress meter of some sort
: (which would appear after X seconds of elapsed time) and, more importantly,
: an "ABORT" button I can press when I accidentally jump into a 10-megabyte
: MPEG file!
You can always send xmosaic a kill -USR1 to abort a transfer, but you are
right I miss that button very much!
_________________________________________________________________________
frans van hoesel Phone (fax/voice/data)
hoe...@chem.rug.nl +31.50.127033
Scientific programmer 'every day is a good day'
_________________________________________________________________________
HALLAM-BAKER Phillip
|> X-Mosaic is indeed a fine HTML document browser, but can hardly be used
|> on systems with no or a very slow internet connection.
|>
|>I assume this is largely because Mosaic currently indiscriminately
|>pulls over inlined images without checking with the user first in such
|>a situation -- right? We're considering an option to have inlined
|>images show up as (small, built-in) iconic anchors that reference the
|>images as external images, which would ameliorate this.
I see a need for being able to bind a number of resources up together in a
file. For example take my CMS server daemon (soon for release.. wait damit!).
This allows you to view a CMS library direct. Now it would be very neat to
be able to put icons into the document to indicate things such as the status
of the file - the way the DEC CMS X interface does. As it is I have to
write stuff out such as No Concurrent Replacements, History Enabled etc,
this takes a lot of space up and dilutes the information density. I can see
cases in which I would want to use a palette of 20 odd icons up to 1000
times in a single document. The data volume would be minute, 32 bytes per
icon. But the benefit would be high.
Currently I am looking at ways of using MIME for this purpose. Essentially I
want to bind the icons into the document to build a multipart document and then
configure anchors into the multipart of the document. This essentially means
that in a multipart MIME document the content-ID headers of each part have to
be considered as anchors in some way.
Phill Hallam-Baker
Brook Conner
Mario> The organization where I work is not intending to access
Mario> WWW. We're building a multimedia documental database and had
Mario> to decide on a hypertext format. Since we have to use standards
Mario> when possible we decided to use HTML ( with it being based on
Mario> SGML ).
Mario> We dont need access to remote files, FTP, WAIS, gopher, etc.
Mario> We just need a browser for HTML docs.
XMosaic works fine for local only stuff, you know. It's just that it
has all that "other stuff" in there too. Perhaps the binary is too
large for your taste. Relinking against dynamic libraries solves that
handily (the binary ends up being maybe a sixth the size)
Mario> Of course I tough of modifying xmosaic, cutting out parts that
Mario> I dont need, basically using the HTML widget. I just tought I
Mario> could get it easy :-) and save time for more important work.
Having thumbed through the XMosaic source, while it is competently
written, I'd hate to try to "rip stuff out," especially on the scale
you're talking about.
Starting from scratch using the HTML widget would be much easier.....
Mario> I already requested that the poster who said had done this to
Mario> make his work available to others, if possible.
That would be me. As I told Mario in email, you don't want the code,
at least not yet. It shows html docs fine, but doesn't follow _any_
links. Really it was an experiment (an _encouraging_ experiment) to
see how much work it would be to pull in the HTML widget to an HTML
editor (answer: not much).
Since I've had a couple of requests for the interesting code, I'll
post it here.
// Open a file named by the char * f. I get this from the command
// line, but you could get it from a dialog box.
ifstream funk(f);
// Find out how big the file is
int fd = funk.rdbuf()->fd();
struct stat buf;
fstat(fd, &buf);
// Read the file into a big-enough string.
file = new char[buf.st_size+1];
funk.read(file, buf.st_size+1);
// Make a couple of widgets -- a scrolled one in case the document
// is long
Widget scrolled = XtVaCreateManagedWidget("scrolled",
xmScrolledWindowWidgetClass, par,
XmNscrollingPolicy, XmAUTOMATIC,
XmNwidth, 500,
XmNheight, 600,
0);
(void) XtVaCreateManagedWidget("htmlViewer", htmlWidgetClass, scrolled,
WbNtext, file,
XmNresizePolicy, XmRESIZE_ANY,
WbNautoSize, True,
XmNwidth, 500,
0);
See? No tricks. Add a callback to the htmlViewer to follow links,
and you're off and running.
Brook
(Or maybe I just think this is obvious because I use C++ and Motif all
the time, even teach it)
--
Klacktoveedsedstene
Michael Witbrock
indication/perfo.. Steven Gr...@spud.Hyperi (776)
> An option for compressed file transmission might be worth looking into as
> well. That'll become increasingly necessary as people start accessing the
> Web from their cellular-modem-equipped PDAs and palmtops.
Not necessarily. High speed modems do hardware file compression.
Compressing files prior to sending via to such modems can increase
overall transmission time. I imagine that most little computers will
have this kind of modem.
Rich Brandwein
In article <20emb0...@fbi-news.Informatik.Uni-Dortmund.DE>, det...@jupiter.informatik.uni-dortmund.de (Thomas Dettmer) writes:
|> >Also on the list.
|> seems to be[come] a long list :-). The visual distinction is a good idea,
|> put I'd suggest (additionally) some command (double click, right mouse
|> button or even pull down) to show the link or href value. I know it can be
|> done scrolling throug the HTML source, but with lenghty documents this is
|> far away from comfortable. Especially for me, because I'll try to use
|> automaticly generated HTML which has no user oriented newline formatting.
|>
In fact, Cello (the MS Windows browser) seems to let you find the
reference by clicking the right mouse button over a highlighted
reference.
--
Rich Brandwein
AT&T Bell Laboratories Internet: rich.br...@att.com
Room 2G-523 Crawfords Corner Road Phone: +1(908)949-2135
Holmdel, NJ 07733-3030 Facsimile: +1(908)949-3210
Joseph C Wang
>In fact, Cello (the MS Windows browser) seems to let you find the
>reference by clicking the right mouse button over a highlighted
>reference.
tkWWW lets you do that also.
William M. Perry
As does the W3 browser I have written in emacs. We all must be way
ahead of xmosaic. :)
I posted this suggestion a while back (last week sometime), but I
never saw any followup.
Marc: would it be possible to add this to xmosaic? (Pop up a small
x window when pressing mouse button 3, removing window when let go of
mouse?) Is this possible with the way the HTML widget is written? (I
have never looked at the code for it personally).
Thanks,
Bill P.
Steven Grimm
>Not necessarily. High speed modems do hardware file compression.
My (admittedly ad-hoc) tests show that they don't do very _good_ compression,
though. Slightly worse than the UNIX "compress" program, and nowhere near
as good as "gzip". Since uncompressing is relatively cheap compared to
compressing, it still might be reasonable to store compressed files on the
server and have the clients uncompress on the fly.
On the other hand, perhaps building better compression into modems would be
a more worthwhile pursuit.
-Steve
D. Ilstrup
>(Or maybe I just think this is obvious because I use C++ and Motif all
>the time, even teach it)
>
>--
>Klacktoveedsedstene
I have it on good authority that listening to Charlie Parker helps to
subconsciously imbue the listener with a tendency to utilize appropriate
metaphors and techniques in the modification of X-based internet software.
Just so you all know ;)
-Dave