On Fri, 8 Nov 2002, Tim Wegner wrote:
I don't think defining fRAc is that urgent. I would rather do any temporary thing to store data, and when we are clear what we want to store, then define fRAc.
Using the gIFx chunk would be an easy temporary solution. Does anything besides Fractint read Fractint's extention block now?
items with new names. At one time my thought was to define the notion of "subchunk" within fRAc, and support PNG's philosophy that way. That is, do define a number of never-changing subchunks such as "corners".
A real simple way to proceed at first is to write something like a PAR into a comment field or application-specific chunk. Since fRAc has been reserved, I really want to do it right. Originally I imagined that fRAc would be application-independent. That may be a pipe dream.
Here's what I'm thinking right now... Some of the data about a fractal we need to present in such a way that it will be of use by other fractal programs; This would be the public fRAc chunk. And then some data is of no use by anything but Fractint, that could be stored in a private block, and ignored by everyone else without harm. If done right then PNGs generated by other fractal programs could be useful to fractint, of course. I'm wondering about a good way to record what the type of fractal is or it's formula without having a huge table of arbitrary types as fractint has now. We could store the fractal type as a parsable formula string, then anyone who needed to know it would have to decode a structured grammer, which is a bit more work. The formular parser in Fractint does this now. (This would also only apply to iterated functions in {C:z} and not weird stuff like line systems) Indefinite precision numbers would also need to be represented somehow. Not everything would need to be included in every file (like the 3-D stuff) How close does the public chunk description of the fractal need to match in order for other people to make use of it? (continue calulations or zoom from there or whatever) The sub-chunking is probabily the best way to handle storing all of this. It's rather like how everyone else does file formats there days (ID3v2, RealMedia, PNG) And it's much better than XML for this :P