Much of the information here is covered elsewhere in the web pages and documentation. However, since there is so much information (and it may not be optimally organized), here are a few answers to Frequently Asked Questions about Newt's Cape:
As described on the main web page, Newt's Cape is a tool to create Newton books from HTML documents. It provides much of the functionality of a web browser and a book tool like Apple's Newton Press. Since you can embed NewtonScript objects and methods, it's also a form/application development environment (and dessert topping and floor wax...).
To get started look at the documentation (described below).
Newt's Cape runs on all models (MP100, MP110, MP120, MP130, MP2K, MP2100, eMate,...); however, some functionality is only available on newer systems. It may work on OMP (pre-1.3), though I have not been able to test this.
Web access requires NOS 2.x, Newton Internet Enabler(NIE) NIE and adequate system resources (i.e., heap and store); on MP120, web access "works" if you freeze other apps, access small pages and graphics, and don't mind waiting. On NOS 1.x, you can "browse" (non-real-time) via an email client or serially from your desktop.
You can access HTML documents from the Notepad, Inbox, other applications like Paperback, Personal Media, and Newtworks, your desktop (via serial or ADSP), and the web.
In the web-based version, you can download text files, Newton packages or any kind of file via http: protocol (assuming a helperApp is registered to handle that MIME type).
Newt's Cape supports the HTML 2.0 standard, along with selected HTML 3.2 features. In particular, it supports graphics, tables, forms. It does not implement frames, JavaScript, Java applets or JPEGs. Check the index to see if/how Newt's Cape handles your favorite tag.
Newt's Cape does a reasonable job of formatting and laying out documents, but it is not as "forgiving" as other browsers. As documents become more complex, use sloppier syntax, and are formatted for particular browsers or large screens, "your mileage may vary". In particular, the following can cause problems: nested tables, table cells with large fixed widths/right alignment, NAME targets with empty ranges.
Newt's Cape can display (animated) web GIFs in black and white, or 4- or 16-grays on 2.1; it does not currently transfer or convert JPEGs. You can include Newton bitmaps and PICTs in documents, provided by other applications (e.g., HexPaint) or from soups (e.g., converted from PICT/GIF/BMP by Newt's Cape Graphic Converter (NCGC) and transferred via Sloup). By the way, you can lay out graphics horizontally by using tables.
For 1.x, you can specify URLs via relative link of the form SRC="soupname/graphicname". In a Sloup file (e.g., created with NCGC), the first line before the ! contains the soupname; the first line of data (usually the 3rd line of file) contains the graphic name in the first field; make sure there are tabs (and not just spaces on the line). So, if the soupname were "mygraphics" and the graphicname were "somepict.gif", you could reference this in HTML as: <IMG SRC="mygraphics/somepict.gif" ALT="a picture">. You can verify that the graphic correctly transferred by installing the BitSound application; select the soupname and then select the graphicname.
Newt's Cape does not convert .wav or other web sound formats (opportunity for 3rd party helper app?). You can access sounds from the Newton ROM, or transferred from the desktop via Sloup. (Also use BitSound to play sounds).
There is a separation between the Newt's Cape "control panel" (for commands) and a book "container" (for content). There are a lot of features supported. So, yes, this can be confusing. (If Newt's Cape were just a 2.x web browser, it could be simpler.)
The control panel was kept small so that it could work on older MessagePads and also be used while other applications were visible. The commands are organized more like the menus in desktop web browsers. It might have been possible to add these commands instead to the book menu bar (like the History, Back and Forward buttons) except that the API is different on each MessagePad, and not well-documented or reliable.
Since a powerful book reader is built-in to every Newton, the book was used as a document container, and package as a distribution medium for published documents. Although the book implementation and API varies somewhat across models and is largely undocumented, it is a fairly reliable and flexible way to format and navigate information. We have investigated viewing documents in Newtworks (on 2.1), e.g., Save Book to NewtWorks though it lacks some important capabilities for layout and embedded form objects; we will continue to look at this and other alternate document models as they become available and viable (and registrations continue).
Error reporting occurs via dialogs, the status area, for 1.x serial via the terminal emulator, and in the book itself. This should be made more complete/consistent. Version 1.5 replaces many of the flashing dialog boxes.
Apple has investigated how the Newton can support the Java OS, runtime and language, and how this might complement, integrate with or replace the Newton OS, runtime and NewtonScript language. Newt's Cape currently ignores Java applets. However, if an APPLET tag references a Newton package, it is possible to download, install (Newt's Cape asks first), and run it within a screen area (examples).
JavaScript is a dynamic scripting language (similar to the Java language in name only). Newt's Cape currently ignores JavaScript -- though it would be possible to map a sizeable subset of the language into NewtonScript and Newt's Cape document objects. However, if certain META tags contain NewtonScript expressions, they can be used to access built-in graphics, sounds or other objects, or open a Newton application (Styles) or run a NewtonScript method when a URL or Submit button is tapped (examples). By default, the NewtonScript option is initially off; if you are accessing your own pages (or trusted sites on the web), you may wish to set it to Compile.
Newt's Cape supports proxy servers (e.g., for corporate firewalls), user and proxy authentication (basic name and password), and cookies. It does not support SSL (secure socket layer) for encrypted commerce. Newt's Cape is primarily a HTTP/1.0 client (though it supports a few 1.1 features).
In addition to sheer size, complexity of the tag markup can also use more heap. On 1.x MessagePads, you might be able to process a 20-30K (source) document -- more if the document is not displayed but saved directly as a package. On 2.x, much of a document object is placed in temporary storage rather than heap -- enabling much larger documents to be browsed; and of course, if your MessagePad has more heap, you can view larger documents. See Size Constraints.
This assumes you have a compatible version of NewtPack installed (available to registered users). If you are creating a series of books, you can uncheck the "Standalone book pkg?" option to save ~25K per book (this would require your user to have Newt's Cape Lite (or regular) installed). Your final package can also take less space if you turn on the package compression option. You can save separate "chapters" as packages, and then combine them later into a superbook. You can maximize heap by closing (or freezing) other applications, and by disconnecting any communications.
The following are rough estimates, to be updated by user reports. On OMP, the limit would probably be ~30-40K for a book package. For other systems, you would need available store at least 2x the final package size, and enough heap for NewtPack to keep track of objects as they're saved. For 1.3, ~80-100K package should be possible; for 2.x, ~400-500K packages should be possible.