- - Add support to the help compiler for generating postscript / PDF /
HTML output.
- - Add support for inlined images in help browser (initially present
only in PS/PDF/HTML versions)
Image Computation
- -----------------
- - Provide anti-aliasing support directly (requires deep color)
- - Synchronous Orbits Iteration
Image I/O
- ---------
- - Provide PNG support for both 8-bit and deeper video modes; handle
gamma correction properly on output
Platform Support
- ----------------
- - Create "fractint GUI API" that abstracts out fractint's ideas of
dialogs, text boxes, number boxes, keyboard navigation of dialogs,
etc., so that ports to other windowing systems are more readily
accomplished from the same body of source code a la xfractint/fractint
as opposed to the completely native port of winfract (which lags);
this will abstract out the interface from the computation engine,
which enhances portablity (something fractint sorely lacks) to other
platforms and also makes it easy to reuse fractint's compute engine.
- - Support for generalizing the assembly code to other architectures
such as 68k, MIPS, etc., by segregating assembly code into
architecture specific directories and integrating xfractint C
emulation of assembly routines for all other architectures.
- - Support "video modes" by name/number/capability rather than by
function key assignment. Since video modes vary by platform, and
even on the same platform they can vary from user to user, a way of
specifying the video mode in terms of its capability is needed.
Something like video=x-res/y-res/depth, i.e. video=640/480/8. In a
windowed environment, the video "mode" is used to guide window size,
palette emulation, etc.
Platform Support: DOS
- ---------------------
- - Eliminate overlays / move to 32-bit flat address space DOS protected
mode app (gives up 286 support)
- - Option for displaying dialogs and text screens in graphics video
mode with image save/restore; eliminates switching back and forth
from text mode to graphics mode, saving wear and tear on monitors
- - port code to DOS version of "fractint GUI API"
- - Improve performance of native DOS 3D driver
- - Compute an image larger than the screen resolution and allow panning
through the larger image by the screen.
Platform Support: Win95/NT
- --------------------------
- - Win32 port
- - long filename problems?
- - DirectX support?
- - 3D drivers: Direct3D / OpenGL
- - animation support? (AVI, MPEG, etc.)
Platform Support: unix/X
- ------------------------
- - Visual selection assumed root is 8-bit psuedocolor; improve to
select appropriate visual for requested video mode (could be 24-bit
with deep color support)
- - Eliminate use of curses and xterm in favor of native X-based text
windows
- - Fix function key support (probably a free side-effect of previous item)
- - Use Xt for interface components of "fractint GUI API"
- - 3D drivers: OpenGL, PEX, native X
- - Generate /bin/sh scripts instead of MS-DOS bat files for "b" command
- - long filename problems?
Platform Support: Mac/Amiga/BeOS/NeXT/other
- -------------------------------------------
- - Someone needs to do the port! :)
Zoom Box
- --------
- - Use XaoS like techniques to speedup the zoom box and/or initialize
the screen from the zoomed section.
Delivery-Date: Mon, 16 Mar 1998 15:43:22 -0700
Received: from dbank (dbank.ptc.com [199.6.17.9]) by woody (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA27065 for <rthomson@woody>; Mon, 16 Mar 1998 15:43:21 -0700
Received: from poster (poster.ptc.com) by dbank (5.x/SMI-SVR4)
id AA13391; Mon, 16 Mar 1998 15:43:09 -0700
Received: from Erich.Triumf.CA by poster (5.x/SMI-SVR4-NN)
id AA28994; Mon, 16 Mar 1998 17:43:06 -0500
Received: by triumf.ca (MX V4.0-1 VAX) id 187; Mon, 16 Mar 1998 14:34:51 PST
Date: Mon, 16 Mar 1998 14:34:45 PST
From: NOEL_GIFFIN <noel@triumf.ca>
To: rthomson@poster.ptc.com
Message-Id: <009C3471.20A0D478.187@triumf.ca>
Subject: Re: HTML version of fractint docs
Hi Rich,
You wrote:
> Noel, one of the things I've been considering adding to fractint is
> support for HTML output directly from fractint's "help compiler". I
> suspected that you manually created the HTML (probably with the help
> of some simple text processing scripts) from fractint's help files or
> the fractint text documentation. I like the no-nonsense style of your
> web version of the fractint docs. If you have any suggestions or
> know of any 'gotchas' you learned while converting the docs to HTML,
> I'd be happy to hear them. Unlike many fractint 'developer projects',
> this is one I could actually do rather quickly since the help compiler
> is a rather small program and doesn't suffer from all the overlay and
> memory contortions of fractint.
I've certainly had some thoughts about what I would have done
differently had I been starting fresh.
The first thing I would do is establish some sort of perl
script or similar text processor to parse the complete document
and substitute any angle brackets, quote characters, ampersands etc,
with the accepted strings. Anything that means something in html
should be replaced. Do that before you break anything into small files
or add any real html code.
Then I would come up with a mechanism to parse for internal
page references and translate them into an internal url. This would
imply that you have some sort of algorithm established for a file
naming convention. This is also a very good idea on its own. I
broke all the docs up into small files to take the load off the
server, but I named all the docfiles somewhat arbitrarily, so
consiquently I have to make all the links by hand. I don't know
what you should use as a criteria for file breaks. Chapter headings
is to coarse.
I've also set a convention that equations and formulae
get displayed in a different text. I use the <pre> </pre> html
for this. I think it is very useful. I don't know how you could
set up a parser to know what is a formula or an equation unless
you inserted some invisible tag in the docs.
Maybe there is a way with a cgi-script to do all this on the
fly and create an html file from sections of the main document.
Then you could allow the cgi to do searches as well and produce an
index on the search results and allow the user to select a page
from the search results, pass it back to the cgi-script and build
the requested page.
I'm sure that there are a lot more things that I haven't
thought about, and I'll pass them along to you as they occur to me.
I think your idea for fractint to create it's own web docs is a good
idea. Use any images you want off my pages if you think they are
worth adding. Perhaps the little thumbnails of all the fractint
