wavebrowser.html>

21/08/2000...
Fonts in the Browser
The browser can handle any font in a web page as long as there is a matching set of fonts defined in the FontList file and if the fonts are located on the same directory The Wave is launched from.

One thing the browser doesn't handle yet is when more than one font is defined in the same tag such as:

It currently sees this string as one whole name rather than splitting it up into two different names. I'll get to this as soon as I can so that it can check the two different font names to see if one of them is supported.

You'll notice in the "options" menu that there are two new menu items, "font bigger" and "font smaller". They also have a number next to them. By default, font bigger has "(+1)" and font smaller has "(-1)" next to it. This indicates the point size that will be selected when you click on the menu item. These numbers change to let you know which sizes you are currently working with.

Here's how font sizes work. There are 7 point sizes in each font, except for the headline fonts which have 6 sizes. They can range in size from 6 points up to a maximum of 24 points. But in HTML, we don't refer to them using their point sizes. Instead we use a "relative" size, or just refer to them in the order in which they exist in the font file. So, we have two different ways to set the size of a font in the HTML code. We can use a number from 1 through 7, or we can use plus and minus signs to reference a size offset from the "base" size that is chosen by the user. Let me make this a little clearer.

Let's say a font's smallest size is 6. This is called size 1. Then the next larger size in the font is 7 points, this would be size 2. The seventh size might be 18 points, this would be size 7. So, if we wanted to use this 18 point font in our HTML code we would use the following code:

    FONT SIZE=7

Pretty simple, huh? Now, when an HTML file is loaded, it might not have any reference to font sizes at all. So, there has to be a default size that is always used when the size isn't indicated. In The Wave's browser, this is size 3. But by clicking on "font bigger", we can change this to make size 4 be the default size.

So, if our default size is now 4 instead of 3, the browser will automatically use one point size larger than what the HTML code is asking for. If the code says FONT SIZE=5, the browser will use size 6.

Ok, but this still doesn't explain the + and - signs used in the menu. And what about that "+0"?

There's another way to specify a font size in addition to what I've already explained.
Both of the following will produce the same results:

    FONT SIZE=5
    FONT SIZE=+2

Since the default size is 3, if we use "+2" in an HTML file, the browser will add that to 3 and come up with 5. If we click on "font bigger" to change our default to 4, then the browser will use 6 when it sees SIZE=+2.

    FONT SIZE=1   FONT SIZE=-2
    FONT SIZE=2   FONT SIZE=-1
    FONT SIZE=3   FONT SIZE= 0
    FONT SIZE=4   FONT SIZE=+1
    FONT SIZE=5   FONT SIZE=+2
    FONT SIZE=6   FONT SIZE=+3
    FONT SIZE=7   FONT SIZE=+4

When you click on font bigger or font smaller, you are telling the browser to change to a different baseline size. The number that's in between what's currently shown in the menu is the baseline size that's currently being used. Since +1 and -1 are showing by default, the number in between them is +0. In the chart above, this indicates that size 3 would be the current baseline size. If you see the following:

The number in between is +2 and the chart indicates our baseline would be 5. With a baseline of 5, if the HTML code asks for SIZE=-1, the browser will use size 4. That might actually be a point size of 12, depending on the point sizes that are contained in the font that is currently being used.

Here's a speed trick for when you want to increase the font by more than one size at a time. Just click on font bigger, and then hit the STOP key. The browser will stop rendering the page and then just click on font bigger again. This way, you don't have to wait for the page to completely render each time you click on a size change more than once.

Currently, when the browser loads in an HTML file, it loads it entirely into memory (SuperRAM memory). Currently, there is no caching of pages mainly because we haven't had the need yet. All the HTML files we've been reading so far are already on disk. Shortly after I get the browser online, I'll be adding the necessary stuff so we can cache the data to disk.

One of the plans is for The Wave to implement a new filing system just for the HD. You'll be able to use current file systems that work with the HD and the RamLink for caching of data, but this new system will also allow a BIG partition to be used on the HD.

This will finally give us a good reason to have these huge HD mechanisms in our CMD HD's. The only drawback is that the partition will only be usable while The Wave is up and running. But you'll be able to make a partition however big you want it, like 500 megs or 200 megs or whatever. You'll be able to use it to store images, HTML files, or whatever you want.

I'll have utilities for copying data between these big partitions and any of the other devices we currently use.

29/05/2000...
The reason for being able to log into the Internet from the ISP directory on the browser side is that you'll later on also be able to type in a URL in the URL bar and go to a web site. Naturally, this has nothing to do with telnetting. However, the same PPP connection can be used for telnetting and for browsing.

The idea here is that you can be visiting a web site with the browser, and at any time you can go into the terminal and telnet to a telnet site. Then you'll also be able to flip back and forth between them.

Likewise, once I get the ability to have multiple TCP/IP connections going internally, you'll also be able to have more than one browser session and more than one terminal session running at the same time.

While you're waiting for a big download to finish in one, you can be doing something else in another, or whatever.

This multitasking, so to speak, will work with anything that you can do while using a PPP connection. If you're doing a direct dialup to a BBS or a direct dial into a shell account, then only one terminal can run since you only have one phone line.

Getting data to and from Internet sites is all done using IP packets. A packet can be going to or coming from one sit while another is going to or coming from another site. As these packets arrive into our computer, The Wave's IP handler will take care of where they should be routed to internally. In other words, one packet might go to one instance of a terminal while another packet will go to an instance of the browser. Whatever is currently visible on the screen, you'll see just like you do now. In other words, if you're typing into a terminal while connected to a telnet site, the characters you type will be assembled into a packet and sent out to the remote site. Meanwhile, there might be a packet coming in that's intended for a different terminal that you had started and have connected to a different site. This could be almost anything, like maybe you telnetted into your shell account and are downloading a 2meg file or something.

The IRC application will also be able to be a part of this multitasking since the same PPP connection will be used to send and receive packets. Internally, the IP handler will direct the packets where they need to go.

It sounds like we're going to be doing a lot of stuff that will be time consuming for the computer to handle. But if you watch your modem lights, you'll see that the modem has a lot of free time where no data is going out or coming in. That free time will be spent on these multiple IP connections.

This is one reason it's taking me longer to get the browser running on the Internet. I have to get some of this multitasking ability working since we also have a terminal running on the same machine at the same time. I don't have to get the multitasking working completely, but it needs to be able to handle two IP ports to begin with, one for the terminal and one for the browser. Once that's perfected, then I'll begin adding multiple terminals and multiple browsers. Again, this sounds like way too much work for our computer, but remember, we have the SCPU to help with the speed and memory. And most of the time, any extra browsers opened will be sitting there idle anyway.

html,head,title,body,br,p,h1-h6,b,i,u,em,strong, font,code,dfn,kbd,comment,blockquote,bq,hr,center, li,ul,ol,a,table,tr,td,th,var,tt,samp,cite,pre, caption,!--,address

The following attributes are recognized and parsed, but only some of them are actually used at this point:

action,align,alt,bgcolor,border,checked,clear,color, cols,colspan,compact,coords,enctype,face,height,href, id,lowsrc,maxlength,method,multiple,name,noresize, nowrap,rows,rowspan,scrolling,selected,shape,single, size,src,text,topmargin,usemap,valign,value,width, wrap,continue

Of the recognized attributes, the following are actually used by several of the tags:

I considered those attributes the minimum to get started with. Then some of the attributes can have values assigned to them. Anything with numbers or strings is recognized along with the following values:

Actually, part of the frame work is done. In a sense, the current method of displaying the html document in the entire screen is no different than displaying it in a portion of the screen, which would be a frame. The code for displaying on the screen is the same as that which will be used for displaying within individual frames. The scrollbar routines are adjustable to work a scrollbar at any position on the screen and at any height, with any amount of content. So, we can have the ability to scroll any part of the screen. The scrollbar routines I've got now are better than the ones I created for the Dashboard. These new routines will eventually find their way into a new version of the Dashboard.

Scrolling the html document up and down is pretty fast. You can grab the scrollbar and move it up and down as fast as you want, and the page moves just as fast as your mouse does. There's absolutely no lag at all.

21/11/99...
For the past couple of weeks, I've been spending most of the time on the browser that's a part of The Wave. It's getting pretty good at displaying HTML documents. It can now handle all the fonts as well as the various sizes and can display all the text just as the page author planned. (at least as good as is possible, given our lower resolution screens.)

HTML,HEAD,TITLE,BODY,BR,P,H1-H6,B,I,U EM,STRONG,FONT, CODE,DFN,KBD,COMMENT,BLOCKQUOTE,BQ,HR,CENTER,LI,UL,OL, A,TABLE,TR,TD,TH,CAPTION,VAR,TT,SAMP,CITE,PRE

Getting the TABLE (and related TR,TH,and TD tags) working properly has been the toughest part so far. Making a simple table work was not a big deal. What was tough was dealing with pages that had tables nested within other tables.

Dealing with that was like assembling source code for a software program. The browser has to make multiple passes through the HTML document in order to completely render the tables. The size of each cell within a table has to be known before the table can be drawn. When another table is found within a cell of the current table, then that table has to be rendered in order to determine the size of the cell that it resides in.

It was a bit of a mess for a while, but I made it through it all and came up with a pretty good method for rendering these tables. It's done, and it works!

Supporting graphic images will be added soon. Currently, the browser leaves an empty spot where the graphic is supposed to go. The plan is to get a minimum functioning system up and running first, and then all the goodies such as support for GIFs and JPEGs can be added. I also don't see any reason why we can't play audio wav files, either. I could also add a new attribute just for this browser that would allow us to play SID music while accessing a site devoted to Commodores.

This weekend, I'm adding support for the FRAMESET tag. With that added, we'll have pretty much a good minimum system that can access most web sites, unless the site requires Java or Javascript.