System 6 Browser Development Opinions

[II2II]

Another option is to setup a machine that will host PPP or SLIP connections.

But there is plenty of ethernet hardware for system 6 Macs. The most obvious one is a NuBus card in a modular Mac, but I'm fairly certain that a few of the SCSI to ethernet bridges worked under System 6.

At any rate, even with a compact you're better off than I. I don't own a Mac anymore. Still, I'm talking about what I wished for back in the day.

 

[porter]

Plugins on a 68000 macintosh running 6.0.8 are really crippled. You either do code resources with their limitations or else require the use of ASLM.

The only architecture that would have made sense is the CTB, but CTB works from terminals and streams and this is stretching things.

For example you could make a web-page renderer as a terminal tool, hence to change browser/renderer you change terminal tool. But this doesn't map well for clicking on links or button pushing.

I suggest a clean open source minimal browser, do one job and do it well.

MacTCP at one end, application in the middle, QuickDraw on the other.

 

[luddite]

I have a MacIP solution, which runs on NetBSD and Linux, shouldn't be a problem to get going on Darwin.
So either using AsantePrint or LocalTalk bridge on another mac with both LocalTalk and Ethernet would solve that.

This gives me an idea that's... off-topic

 

[CaryMG]

Whoever makes a System6 browser shall be the first beneficiary in my will.

Of the features you mention, I'd like ta see ....

* Image Support

* Can DownLoad Files

In my completely layman's opinion I think having different fonts would overly tax an already "struggling", if you will, piece of software -- lol -- and

just using either Chicago or Palatino would be fine as far as fonts go and would be that much less for the browser to hafta do.

:b&w:

 

[luddite]

In my completely layman's opinion I think having different fonts would overly tax an already "struggling", if you will, piece of software...

I suspect image support would be much more of a resource issue than fonts (assuming the browser stick to one font each for serif, sans-serif and monospaced)...

[also a layman's opiniion]

 

[porter]

It would be best to avoid the images as

(a) each graphics requires another HTTP transaction to download and will look crap on 512x384 monochrome, especially when most of the web is assuming minimum of colour with 800x600.

( B) fonts should be used, but limited to supporting the headers "h1", "h2" etc originally defined levels, not the custom font stuff.

 

[II2II]

With respect to fonts, those should be handled by the Macintosh's Toolbox. So, relatively speaking, they would be easier to implement.

With respect to image support, most images are compressed. That would add a definite load to the CPU. Since a lot of pages have a lot of images, the browser would probably be unbearably slow if the images were rendered inline. (I seem to recall a discussion a number of years back where a moderate sized JPEG would take minutes to render on an Apple IIgs. Now the CPU on a Mac is considerably faster, but not that much faster! Also, modern compression schemes usually place the compression ratio ahead of decompression time, since the CPU is cheaper than the bandwidth. So I'm *guessing* that formats like PNG would be slower to decompress than JPEG.)

There is also the issue of library support. Even if you could obtain a library that decompresses JPEG files under System 6, it may not handle the most recent variations. I doubt that anyone has ported a library for stuff like PNG to System 6.

So I'm afraid that image support will be fairly challenging.

Probably the best thing to do is look at what word processors of the era were able to render, and how well and how quickly they did it. Factor in stuff like HTML being harder to parse than a binary format, particularly for layout (content shouldn't be too bad), and embedded data being more complex (e.g. images). Then factor in your own programming skills. That will give you a rough idea of what capabilities should or shouldn't be included.

 

[porter]

With respect to fonts, those should be handled by the Macintosh's Toolbox. So, relatively speaking, they would be easier to implement.

There are two parts to the font issue...

The first is, as originally defined HTML defined abstract font typing for body and header, it was left to the renderer to define what looked best.

Later versions of HTML have pages specifying actual font types by name, which did not necessarily map well to what was installed on the system.

 

[II2II]

True. I'm inclined to say go with the former and neglect the latter. Then again, I'm the type of person who believes that document structure is more important than the eye candy.

The other option is to create a list of font mappings. Back in my naughty days I'd say something like use Arial, but have Helvetica as a backup. Now System 6 doesn't have either by default, but it can recognise both fonts as proportional, sans serif then select something appropriate. Of course it won't cover the case when a dork of a website designer decided not to have a common font as a backup, but c'est le vie.

 

[benjgvps]

Well, I just looked at this page with page style turned off ... it's not all that different, just a lot plainer and a bit messier. It gives me an idea of what I could perhaps expect from a very basic System 6 browser. Party like it's 1993!

Try looking at it from Lynx... it's fairly horrible, but can be used it you're determined. I think that's a better approximation of a minimal System 6 browser.

Links is a great browser, if that is made for 68k, it would be perfect.

 

[porter]

Okay, I need some guidance with some HTML parsing...

I am very happy about parsing XML, the rules are very consistent.

However HTML is another pile of poo when people shove javascript in it which contains < and > characters.

Surely these should have been escaped with "&lt" etc?

Eg

.....

My problem is I see the "

What is the correct way to detect the end of java script in a manner that does not require me to parse javascript?

I basically want to end up with a TEXT node with the javascript under an ELEMENT named "script".

 

[blackbird]

1- Doesn't bomb when you quit

2- Plain text layout

3- Can download files

4- Forms

5- Beyond plain text layout (ie, bold, font sizes, etc)

6- Image Support

 

[porter]

1- Doesn't bomb when you quit 2- Plain text layout

3- Can download files

4- Forms

5- Beyond plain text layout (ie, bold, font sizes, etc)

6- Image Support

I'm putting something together that will do everything except 6.

My excuse being I am targetting monochrome 512x384, so 99% of todays embedded images will look awful.

The image support will be supported by item 3. You will be able to happily download images as files (or you could scowl while doing it).

Thinks, would need a "Content-Type" to TYPE/CREATOR mapper.

 

[II2II]

My excuse being I am targetting monochrome 512x384, so 99% of todays embedded images will look awful.

Of course, I gave other reasons for not supporting images. But I just had to comment that I think that colour images resampled as 1 bpp looks pretty cool on the Mac. I forget the name of the algorithm that Apple used, but it does a good job. (Particularly compared to dithering algorithms that I encountered in my 386/486 days, which used a regular rectangular arrangement for the dithered pixels.)

 

[tomlee59]

There are many halftoning algorithms, ranging from simple-but-crummy, to complex-but-less-crummy. Floyd-Steinberg seems to be very popular on the Mac (and elsewhere), as it seems to balance complexity with quality in some reasonable fashion. That's probably the algorithm you're thinking of.

 

[II2II]

That Floyd-Steinberg name sounds familiar. And I think it's pretty cool how a black and white (not even monochrome!) image can look so good. It ranks right up there with those old teletype reproductions of photographs (i.e. the ones with over-typed letters).

 

[tomlee59]

I remember the halftoned tiger image that lived on one of the early Hypercard stack examples. It rendered quite nicely on a compact Mac screen, as well as on the early Imagewriters. Now why can't the Wall Street Journal do as well?

 

[porter]

Okay whizzes, what am I supposed to do with the HTML garbage?

....	
	{for blog_item in blogs}

......

returned from http://www.guardian.co.uk

I'm discarding comments and scripts, but how is this supposed to be handled? All I can think of is if you read an element and after the element name you find something that is not

/

>

whitespace

then junk everything until the > character.

Ideas?

 

[luddite]

That seems logical to me. Offhand I can't think of a situation where that would fail.

 

[Charlieman]

How are you proposing to handle verbose sites within 1MB RAM? A lot of bloggers, just picking on them as an example, have pages which contain greater than 1MB of text data. By parsing that text, you can immediately throw away a lot of the advanced headers, CSS related data etc but you are still going to end up with a lot of data to buffer, process and finally present.