Z-DOC/PalmPilot

Z-DOC / PalmPilot ZDOC is a GPLised industry standard DOC file format viewer/editor with a few extras. It is released only under the terms of the GNU GPL. Please read the files GPL.TXT and ZDOC.TXT for a full description and terms of the GPL as well as an introduction to ZDOC.

The ZFile initiative is now starting once sufficient hardware is available. For more details click here.

You can download ZDOC from the ZDOC Programmers page by clicking .

You can read the ZDOC manual from the ZDOC Manual page by clicking .

ZDOC FAQ :-

This is a list of frequently asked questions about ZDOC. It should cover most queries, but mail me if you have any others. RTFM before mailing me -- i dont have a lot of time to answer a billion queries. They arent in any specific order -- just dumped in when i recv queries.

[0.0] How fast do you release ZDOC versions ?

[0.0] Varies -- depending on my mood and how much time I have. It usually takes a week between version upgrades when I have access to a machine for a minimum of 8hrs/day and no other work. This will slow down or stop to one version every month or so when i cross a decent threshold of features.

[0.1] You dont have access to a machine ?

[0.1] I dont have any machine with the exception of my PalmPro. No PC/Unix machine. I get access thru public terminals where i've installed the GNU SDK. I dont have a great deal of cash to afford a decent laptop.

[0.2] How stable is ZDOC ?

[0.2] As stable as I could make it. It doesnt crash under the 2.0 debug ROM which is supposed to include lots of checks. As I spent a year programming on a Irix platform i've dealt with a lot x/motif memory leaks. As a result my memory handling routines should be stabler than most other ppls. I cant guarantee anything though. Its not as thoroughly tested as some of my other software and you use it at your own risk. As a general rule of thumb try to open files which are less than 250K and do not open them unless you have at least 2 times the file length in free RAM. i.e. if youre editing a 100K file make sure you have 200K free ram in your pilot. (Check it via the memory utility). This is normal for any DOC app, not just ZDOC. DOC apps consume RAM faster than any other apps. [[Note that
this does not apply to betas/alphas/test releases..theyre as buggy as hell.]]

[0.3] What about bugs ?

[0.3] What about them ? (heh.) I've weeded out most of em. If you find any try and fix it yourself (the code is GPLised) and mail the thing to me with all possible details of it -- i'll whack it up soon, or modify/improve it to fit in all versions of ZDOC. If i release a special test version then just mail me the bug and i'll try and fix it immediately. this applies for test versions only [ e.g. 5.x.x c ] all versions with a c extension are test releases.

[0.4] Is there a seperate programmers page for ZDOC ?

[0.4] Yup. Try this one.

[0.5] I've put a really groovy must have thingy into ZDOC. How do i release it ?

[0.5] Mail it to me with express instructions including where it fits and what it does. Mail me the version of ZDOC used (must be the most release version i.e. no alpha/beta) and i'll put it up with your name (if you would like your name there).

[0.6] Can i send you encrypted mail ? Your PGP key is on your site.

[0.6] NO. Not regarding ZDOC. I allow/use encryption for confidential mails only. Mailing me encrypted junk gets you onto my kill filter ASAP.

[0.7] I lost my data !! ZDOC wiped my system !! it crashed..etc..etc.

[0.7] Restore from hotsync. mail me OS version, what you did, what files you worked on, what files you had loaded and what versions they were, all file/database sizes. I'll try and work on it to remove the bug, but no guarantees are made. Youre using this program at your own risk. I *do* have *some* motivation to remove total loss bugs (if any occur -- ive not seen it happen yet) since i use ZDOC extensively myself. (and no.. i dont take the advice from [0.2] seriously either. i routinely use it in low memory situations, but ive never lost anything uptil now -- on the other hand i DO keep hotsyncing at every oppurtunity)

[0.8] Does ZDOC work with/compatible with any other DOC readers/writers ?

[0.8] I've always kept a freeware DOC reader on my system. Usually its Aportis DOC Mobile edition or the freeware DOC reader from Aportis. They cause no problems and ZDOC can handle bookmarks easily (i.e. right now it just ignores them).

[0.9] Why dyou keep a freeware reader on your system ?

[0.9] Just in case (heh). Acutally i prefer to work with readonly mode readers rather than a reader/writer such as ZDOC for browsing files. Its safer. For editing files I just use ZDOC. Note that ZDOC Ver2.x or below open files in ReadOnly mode and are as safe (or safer) than Aportis readers since Aportis readers add bookmarks which means they write to the file. ZDOC 2.x or below DO NOT write to the file. After Ver2.x it does...since i use Ver3.x and above this doesnt apply to me. Note that Ver4.0.5a and beyond now write to the file only when you press the save command...otherwise they open the file in readonly mode.

[1.0] How stable is the code ?

[1.0] Very. ive not seriously broken it til now. It uses PalmOS 2.x API calls only to allocate/deallocate memory and no funny stuff. It should be compatible with PalmOS 3.x too..although i dont have a palm iii so i guess i'll wait til i find someone who tries it on one.

[1.1] Are you registered with 3COM ?

[1.1] I'll try to get ZDOC PalmOS certified..no guarantees on this. I've registered ZDOC's AppId with 3COM -- it's ZURK. I've also Gremlin tested each version of ZDOC and ensured that it runs on both 2.0 and 3.0 debug ROMs. Note that the test versions of ZDOC are not gremlin tested fully..usually they are put through 1000 or so cycles and not the 1-2 million recommended. I'LL ONLY RELEASE FULL VERSIONS WHEN THEY PASS THROUGH 1 MILLION CYCLES.

[1.2] Im a newbie programmer...i wanna learn ! Cant find anything -- help !

[1.2] Mail me -- i usually help if im not too busy. it takes a while but i'll get around to replying. Note that i only help ppl who work on GPLed code and use GCC. If you use any other development engine/develop commercial/shareware code -- forget it. Mail me your website, the location of GPLised code that you have contributed to the general public and any apps (with code). If i like what i see and i think you have potential i'll reply. Very newbie newbies who havent done anything but are prepared to show intent to develop GPLised apps are also welcome. I must have your website tho, and you must be using GCC.

[1.3] How come you havent put your real name on your site ?

[1.3] I believe in my freedom to remain anonymous. That and it makes me a lot tougher to sue. As such i dont put any real names/addresses up. I guard my privacy VERY carefully. And no, i wont give it to you if you ask me either. You may email me of course. My email address is functional (zurk@geocities.com).

[1.4] Have you written/going to write any other pilot software besides ZDOC ?

[1.4] dunno. will see.

[1.5] I want ##spiffy feature #999## in ZDOC. How do i do that ?

[1.5] Mail me your specs for #999 and i'll include it if i think it interesting. otherwise i'll delete the mail. get off your lazy backside and do it yourself before mailiing me...unless youre a total newbie.

[1.6] Why does ZDOC work on only 4K at a time ?

[1.6] Until i feel a HELLUVA lot more comfortable working with big chunks of data on a palmpilot, thats the way it stays. 4K is nice neat and simple. And theres no problem about the OS suddenly freaking out due to too much RAM consumption. Anyone want to patch ZDOC to work with over 4K at a time ? mail me
and try it out..if i feel its stable ill put it into the full versions.

[1.7] Does it work with PalmOS 1.x ?

[1.7] NO. thats been confirmed. Check the mail below :-

Here's the scoop, I just downloaded version 4.0.5a (which according to you is the
new version) and tried it in CoPilot (I've had to remove the RAM file everytime
following a crash anyway so I was already doing that). It caused an application error
when I clicked on the open button and closed CoPilot. I went ahead and
downloaded it to my pilot and it still hangs on the info window when the open button
is clicked. However, this version does not generate the MemoryMgr.c invalid handle
error so I was able to remove it without the hard reset :) (BTW when I mentioned
that in CoPilot it was locking up, I meant it was generating an application error and
closing out).

Jonathan Beach
CMHC Systems
Systems Support Engineer

[1.8] DOC files...what are they ? where can i get info for them from ?

[1.8] Although Aportis has not formally released the DOC specification to the general public, heres a mail that might help :-
The database layout is pretty simple:

- record 0 is a header which contains the following:
      - a short int (2 bytes) containing the file version
        (1 = uncompressed records, 2 = compressed records)
      - a short int containing something unknown and unimportant
      - a long int (4 bytes) giving the total *uncompressed* length of
        the text
      - a short int giving the count of text records
      - a short int giving the *uncompressed* size of each text record
        (default 4096)
      - a short int containing something unknown and unimportant

      readers may add a bit more to this record the first time they
      open the file, but only the above needs to be there when it is
      created.

- records 1 - n (where n is the number of text records) each contain
    a block of text of a fixed size, normally 4096 bytes. That is
    4096 bytes *before* compression -- the actual size of the record
    will be somewhat less, because it contains the compressed data.
    However, since the uncompressed size of each record is known, it
    is easy to seek to any particular point in the file and uncompress
    one record at a time using a fixed-size buffer.

- records n+1 to the end are bookmarks. Each one contains a 16-byte
string (null terminated, but always takes the full 16 byte area)
followed by a long int giving the seek position of the bookmark.

The compression algorithm is too complicated for me to describe here
(as such things go it's rather simple, but it is still easier to show
with code :) so your best bet is to look at the code.

> I managed to get some make doc samples for unix and could
> probably reverse engineer them, but its irritating when the DOC standard
> is supposed to be an "open industry wide standard" (according to the
> author of PilotDOC). I did find a few msgs which commented on the
> Micro$oft style takeover of pilotdoc by aportis but nothing else.
> Any help would be appreciated as i plan to create a few DOC apps over the
> next month or so (GPLised of course).

If you are working with Unix, I urge you to check out my package
called "PalmPython". I don't know if you ever use Python, but even if
you don't you ought to give it a look because I did some pretty
extensive Doc-making stuff. (I also have a simple XML-to-Doc
converter that uses it.) Python is fairly easy to read even if you've
never used it before, provided you understand basic OOP etc.

In particular, PalmPython contains a snippet of C code to do Doc
compression and decompression, which you can probably use elsewhere.
(It's two functions and a Python-API wrapper.) If you actually *use*
PalmPython, it contains code for reading and writing Docs as file-like
streams, complete with automatic compression and reader-style
bookmark-setting (the latter of which none of the other Doc-makers do,
even on other platforms).

PalmPython is GPLed, so do with it what you will. (If you actually
use it for anything, please let me know, send patches and
compatibility reports, etc.)

PalmPython is available at
http://www.io.com/~rob/cq/
along with its companion XMLDoc. As I said, even if you don't use
Python, you might want to read the source and copy bits of _Doc.c.
By the way, when you mention creating "a few Doc apps", do you
perchance mean a reader? The world desperately needs an open-source
Doc reader on the Pilot -- I would do it myself, but I have made so
many failed attempts at decent Pilot programming it's not funny, and I
have thus decided to stick to the desktop side. If you are
considering doing one, please take this as a hearty endorsement of the
idea :-)

--Rob

--
Rob Tillotson N9MTB

[1.85] Have you got any info on DOC derivates (i.e. PDB format?)

[1.85] Heres an email which may help you :
(Note that i have been sent this email anonymously, and this is posted for informational/interoperability purposes ONLY.
Personally i think PDB's are a sucky attempt at monopolising DOC space (or polluting it)..the DOC format could handle
all this shit with straightforward HTML markups without the need for all this proprietary garbage but some companies just dont
play nice..*sigh*)

Anonymous <remailer@anon.xg.nu>
Comments: This message did not originate from the Sender address above.
It was remailed automatically by anonymizing remailer software.
Please report problems or inappropriate use to the
remailer administrator at <abuse@anon.xg.nu>.
To: zurk@geocities.com
Subject: Peanut DOC Format
Peanut Reader Document format

Reverse-engineered by Setec Astronomy
-------------------------------------

   This document describes the PDB format created by the Peanut press MakeBook
   java program. This program only generates unprotected books, so this is the
   only kind of books documented. Reverse-engineering results are to be used for
   interoperability (compatibility) purposes only, ie the ability of creating
   and viewing Peanut press documents outside of the Peanut press company
   proprietary software domain. This is necessary for competition and thus for
   consumers of electronic litterature.

   During the work we found that large parts of Pat Beirnies MakeDoc program had
   been used. That is why, for example, the compression method is exactly the
   same. The main difference from standard DOCs is that pagination is handled by
   the creator program, which makes it more complex: you have to calculate where
   pages start and put in pointers to be used by the reader program. As text
   styling is reset on each new page, your program must also parse styling tags
   and place a default style for each new page in the pointer records.

The structure of the PDB is quite straight forward:

   1. An AppInfo-like PeanutRec0 before the actual data
   2. Scrambled Records containing the actual text in Peanut Markup Language
   3. Page pointer record(s) for small font
   4. Page pointer record(s) for large font
   5. Chapters pointer records relative to the page pointer records

IMPLEMENTATION
--------------

   Words and DWords are big-endian (ie most significant byte comes first)
   your routies that read or write PDB files must always handle this. This is
   the Motorola 68k-style by the way, as opposed to the Intel x86 style. For
   details on endianess, see the FAQ for graphic files formats at:
   http://www.faqs.org/faqs/graphics/fileformats-faq/part4/

   The DOC compression used in Pilot DOCs is described by Pat Beirnie at:
   http://cr945328-a.flfrd1.on.wave.home.com/Programming/PilotDoc.htm
   There is an implememtation in C (txt2pdbdoc) by Paul J Lucas at:
   http://www.best.com/~pjl/software.html

For C users the following goes:

   typedef unsigned char Byte;
   typedef unsigned long DWord;
   typedef unsigned short Word;

   PeanutRec0
   1 record
   ----------
   Offset Name Type Size Content
   0x00 wPacking Word 2 2 (= Packed? 1 = unpacked?)
   0x02 wUndef Word 2 Verified garbage (*)
   0x04 dwUndef DWord 4 Verified garbage (*)
   0x08 wRecno0 Word 2 Number of records in main story
   0x0A wRecno1 Word 2 # records used by small font page
   pointers
   0x0C wPagno1 Word 2 # pages used in small font mode
   0x0E wUndef Word 2 Verified garbage (*)
   0x10 cUndef char 8 Verified garbage (*)
   0x18 wRecno2 Word 2 # records used by large font page
   pointers
   0x1A wPagno2 Word 2 # pages used in large font mode
   0x1C wUndef Word 2 Verified garbage (*)
   0x1E cUndef char 80 Verified garbage (*)
   0x6E wRecno3 Word 2 Number of chapter records
   0x70 wRecno3x Word 2 Number of chapter records (again)
   0x72 wUndef Word 2 Verified garbage (*)

Sum size: 116 bytes

   (*) VERFIED GARBAGE -- these fields are filled with random numbers by
   the MakeBook program from Peanut press. Note that this program is
   most likely not the same as the program used for generating commercial
   books, and a wild guess is that these fields are used for password
   (ie Credit Card number) information one way or another, and that this
   is probably invoked by changing the word at offset 0 to something else
   than 2. I haven't had the opportunity to analyze any commercial books
   from Peanut press so we cannot say.

   Scrambled story records
   wRecno0 records
   ---------------
   Contains packed and scrambled story chunks in Peanut Markup language
   the chunks are 0x1000 or 4096 bytes maximum as in regular DOCs. All
   surplus carriage returns are removed from the markup file, just the
   double LF:s (0x0A) marking paragraph break is left intact. Any ASCII
   below 0x0A or above 0x7F is removed from the file. ASCII characters
   above 0x7F have to be escaped as described in the Peanut Markup
   Language definition.

   The scramble algorithm is to XOR the record with 0xA5 after packing.
   To scramble: 1) Pack the record using DOC compression,
   2) XOR it with 0xA5
   To descramble: 1) XOR it with 0xA5,
   2) Unpack using DOC compression

Sum size: varies

   Page pointer records for small font:
   wRecno1 records
   ---------------
   Each chunk in this record is 14 bytes, each pointing out where to
   retrieve a page. Pages are arranged sequentially, starting at 0x0000.
   Each chunk tells you where to find this particular page. (+)

   Array of 14 byte chunks
   Offset Name Type Size Content
   0x00 wPage Word 2 Page number
   0x02 wRecord Word 2 Record number (?)
   0x04 wOffset Word 2 Offset
   0x06 dwOffset DWord 4 Offset (long)
   0x0A wFont Word 2 Default font for this page (-)
   0x0C wStyle Word 2 Default style for this page (*)

Sum size: wPagno1 * 14 bytes

   Page pointer records for large font:
   wRecno2 records
   ---------------
   Each chunk in this record is 14 bytes, each pointing out where to
   retrieve a page. Pages are arranged sequentially, starting at 0x0000.
   Each chunk tells you where to find this particular page. (+)

Sum size: wPagno2 * 14 bytes

   Chapter Records:
   wRecno3 records
   ---------------
   wPoffS and wPoffL can be multiplied by 14 to get a pointer into the page
   offsets for small and large fonts above. Used for skipping into a certain
   chapter.

   Offset Name Type Size Content
   0x00 wPoffS Word 2 Page offset in small font mode
   0x02 wPoffL Word 2 Page offset in large font mode
   0x04 cChapter char n Chapter Name String XOR:ed with 0xA5
   n+1 bTerm Byte 1 String Zero Terminator (not XOR:ed)

Sum size n+6 bytes

   (-) The "default font" value is:
   0x0000 Normal font
   0x0001 Bold font
   0x0002 Large font

   (+) You obviously need to know what width and height the different
   characters have in order to calculate the page space needed. The lines
   will wrap as soon as the line length > 160 points. To calculate the
   line space used, add character widths as you move along the line (of coure
   you must leave out control characters!) you must also add an additional 4
   points on each side of the line (=8 points per line) for indented regions.

These are the character widths relative to their palm pilot ASCII code,
with index 0x00 .. 0xFF:

   CharacterWidthSmallFont[] = {
   0, 5, 5, 5, 5, 5, 5, 5, 5, 2, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
   5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 2, 2, 4, 8, 6, 8, 7, 2,
   4, 4, 6, 6, 3, 4, 2, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 2, 3,
   6, 6, 6, 5, 8, 5, 5, 5, 6, 4, 4, 6, 6, 2, 4, 6, 5, 8, 6, 7,
   5, 7, 5, 5, 6, 6, 6, 8, 6, 6, 6, 3, 5, 3, 6, 4, 3, 5, 5, 4,
   5, 5, 4, 5, 5, 2, 3, 5, 2, 8, 5, 5, 5, 5, 4, 4, 4, 5, 5, 6,
   6, 6, 4, 4, 2, 4, 7, 5, 5, 5, 3, 8, 5, 6, 6, 6, 4, 11, 5, 4,
   8, 10, 10, 10, 10, 3, 3, 5, 5, 4, 4, 7, 7, 10, 4, 4, 8, 8, 8, 6,
   2, 2, 6, 6, 8, 6, 2, 5, 4, 8, 5, 6, 6, 4, 8, 6, 5, 6, 4, 4,
   3, 5, 6, 2, 4, 2, 5, 6, 8, 8, 8, 5, 5, 5, 5, 5, 5, 5, 7, 5,
   4, 4, 4, 4, 3, 2, 3, 3, 7, 6, 7, 7, 7, 7, 7, 5, 8, 6, 6, 6,
   6, 6, 6, 6, 5, 5, 5, 5, 5, 5, 8, 4, 5, 5, 5, 5, 2, 2, 3, 3,
   5, 5, 5, 5, 5, 5, 5, 6, 7, 5, 5, 5, 5, 6, 5, 6
   }

   CharacterWidthBoldFont[] = {
   0, 5, 5, 5, 5, 5, 5, 5, 5, 2, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
   5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 2, 3, 6, 10, 6, 13, 9, 3,
   5, 5, 6, 6, 3, 5, 3, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 3, 3,
   6, 6, 6, 6, 10, 7, 7, 6, 7, 5, 5, 8, 8, 3, 5, 7, 6, 10, 7, 8,
   7, 8, 8, 6, 7, 7, 8, 11, 7, 7, 7, 4, 6, 4, 6, 5, 4, 6, 6, 5,
   6, 6, 5, 6, 6, 3, 4, 6, 3, 9, 6, 6, 6, 6, 5, 5, 6, 6, 6, 9,
   6, 6, 5, 5, 3, 5, 7, 5, 6, 5, 3, 9, 5, 6, 5, 5, 4, 17, 6, 5,
   10, 10, 10, 10, 10, 3, 3, 5, 5, 4, 4, 6, 7, 10, 5, 5, 10, 10, 8, 7,
   2, 3, 6, 7, 8, 7, 3, 6, 4, 8, 6, 8, 6, 5, 8, 6, 5, 6, 4, 4,
   4, 6, 7, 2, 4, 2, 6, 8, 9, 9, 9, 6, 7, 7, 7, 7, 7, 7, 9, 6,
   5, 5, 5, 5, 3, 3, 3, 3, 8, 7, 8, 8, 8, 8, 8, 6, 8, 7, 7, 7,
   7, 7, 7, 8, 6, 6, 6, 6, 6, 6, 9, 5, 6, 6, 6, 6, 3, 3, 3, 3,
   6, 6, 6, 6, 6, 6, 6, 7, 8, 6, 6, 6, 6, 6, 6, 6
   }

   CharacterWidthLargeFont[] = {
   0, 5, 5, 5, 5, 5, 5, 5, 5, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
   5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 2, 4, 9, 6, 11, 8, 2,
   4, 4, 6, 8, 3, 4, 2, 5, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 2, 3,
   7, 7, 7, 5, 11, 9, 6, 7, 7, 6, 6, 8, 7, 3, 4, 7, 5, 10, 7, 8,
   6, 8, 6, 5, 6, 7, 7, 11, 7, 6, 5, 3, 5, 3, 6, 6, 3, 6, 7, 6,
   7, 7, 4, 7, 6, 3, 3, 6, 2, 10, 7, 7, 7, 7, 4, 5, 4, 7, 6, 10,
   6, 7, 6, 4, 2, 4, 7, 5, 7, 5, 3, 7, 5, 10, 6, 6, 4, 13, 5, 4,
   9, 10, 10, 10, 10, 3, 3, 5, 5, 5, 6, 12, 7, 11, 5, 4, 12, 10, 8, 8,
   4, 2, 6, 6, 8, 8, 2, 6, 4, 10, 5, 7, 7, 4, 10, 4, 5, 6, 5, 4,
   3, 6, 6, 2, 4, 3, 5, 7, 8, 8, 8, 5, 9, 9, 9, 9, 9, 9, 9, 7,
   6, 6, 6, 6, 3, 2, 3, 3, 8, 7, 8, 8, 8, 8, 8, 6, 8, 7, 7, 7,
   7, 6, 6, 6, 6, 6, 6, 6, 6, 6, 11, 6, 7, 7, 7, 7, 3, 2, 3, 3,
   6, 7, 7, 7, 7, 7, 7, 6, 7, 7, 7, 7, 7, 7, 6, 7
   }

   When line length exceeds 160 points, that triggers a line break. Line
   breaks appear after spaces (0x20), dashes (0x2D) and underscores (0x5F).
   Small and bold font is 11 pixels high, while the large font is 14 pixels
   high. When a page is > 148 pixels high, it will be broken and a new page
   starts. So you have to program one or two adding routines here. Also note
   that the Page Pointers for small and large fonts must be calculated under
   respective presumption: that that font is the "default" or "normal" font.

   (*) The style is the internal format used by the peanut reader for
   translating the Peanut Markup language into a Style Word where the
   bits signify the style options:

   Bit mask: Style:
   0x8000 Italics
   0x4000 Underlined
   0x2000 Indented
   0x1000 Overstrike
   0x0800 Invisible
   0x0002 Right justified
   0x0001 Centered

   Right justification and centering occurs exclusive with normal
   (left) justification, so the possible low bit values are 00,
   01 and 10. Boldface is not a style, rather a special font. (See
   "default font" above.)

   This documentation is free; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version. See: ftp://prep.ai.mit.edu/pub/gnu/COPYING

Peanut Press and Peanut Reader are probably trademarks of Peanut Press.

[1.9] ZDOC crashed/machine reset ! It also left a database called ZRAM on my machine..what do i do ?

[1.9] Erase off the ZRAM database. Its a temporary database of no importance. Be aware that if ZDOC
crashes while saving, and you have a lot of important work that should be saved/you have no backup of
that work, ZRAM will contain the record which should have been saved. ZRAM contains just one record,
record 0, with a text version of the field that ZDOC is currently working on. It serves as a backup.

[2.0] Whats the tiny symbol displayed on the top right hand corner when i save to a compressed file ?

[2.0] Thatrs a replacement for the ugly status messages. A small arrow pointing downwards is displayed on
the top right hand corner when ZDOC is ready for user input. A small star symbol is displayed when it is
busy (usually compressing and saving text)..its equivalent to the arrow/hourglass figure in windoze.

Note: if anyone doesnt want their mails etc posted up i'll be glad to remove em. mail me.
All copyrights are acknowledged.
<-EOF->