#
# $Id: History,v 1.29 1996/08/03 21:44:01 heinz Exp $
#

This is the history from the original 1.7 source up to now in chronological
order. Releases follow the changes done. The most recent notes are
at the end of the file.

        - took the original 1.7 sources and added my own fixes.

    2.0 HWG internal

        - SAS/C 6.x compatibility
        - Added 24 bit capabilites. Note that any of the 24 plane ptrs can
          be set to NULL to achieve "partial" rendering of bitplanes. This
          way you can render e.g. a 300 dpi A4 24 bit image one plane
          at a time even on a small machine doing 24 passes. Afterwards you
          could combine the planes on HD to a full image. This seems to be
          easier than rendering clips with a depth of 24 bit.
        - sethalftonephase.
        - integrated Tom Rokicki's fixes.
        - handling of illegal type 3 encodings (well sort of).


    2.1 HWG still not public

        - After a virtual memory restore the current font setup was totally
          messed up, which resulted in a invalidfont error in the best case.
          Worse cases were possible.
          I fixed this by removing a few global (Yuck!) font variables and
          integrating them into the graphics state. As a side effect calls
          to show are now faster.
        - For errstackoverflow and errdictstackoverflow the stacks were not
          cleared as the should be according to Adobe.  The fix for the
          operandstack is complete. For the dictstack and execstack there
          might be still a problem. I currently have no idea how to solve
          multiple stack overflows and the Adobe manual doesn't really tell
          what should happen if the execution stack runs over its limit.
        - For the first time I put it into RCS.

    22  HWG still not public

        - The new local/global VM scheme seems to be working now.
          The dictstack is like in a level 2 implementation now.
          The overhead needed triggers an increase of memory use of about
          80% for all objects. I don't see a way to reduce this if I want
          to keep going to level 2. No idea yet on how to implement a nice
          garbage collection without adding _major_ overhead to object
          handling. At least a restore does a true memory free now.
        - New operators: setglobal, currentglobal, gcheck, scheck,
                         glyphshow, <<, >>, undef, arct,
                         setstrokeadjust, currentstrokeadjust,
                         setbbox.

        - Neither setbbox nor the strokeadjust stuff is tested.
        - The strokeadjust stuff doesn't really do a decent strokeadjust
          currently. It is more of an experiment right now.
        - GlobalFontDirectory is now there, (Shared variant, too).
        - putinterval now deals with packed arrays.
        - execstack now correctly clears the attributes for all copied
          objects.
        - dictionaries conform to level 2 now and expand as needed.
        - undef is implemented. It doesn't reduce the dictionary size. It
          just invalidates the entry. (Note: This is not a typenull!)
        - null is no longer an operator but a constant.
        - The complete system name table according to the adobe reference
          manual appendix F is now implemented.
        - The object types are now numbered according to the red book,
          page 113, table 3.14.
        - Hashing in nametoken() should be a little faster now.
        - clippath will no longer return an empty clipping path. Instead
          it will return a zero area path at (0,0) device space.
        - <~ASCII85~> implemented, not tested.
        - Some speedups in scantoken.
        - Only PaintTypes 0 and 2 are accepted now, not tested.
        - CDevProc handling put in, not tested.
        - added 'a' and '+' modes to file opening, not tested.
        - defineuserobject/undefineuserobject/execuserobject, not tested.
        - filter mechanism in place, eexec runs on top of it now.
          dct, ccittfax, and lzw filters missing, proc and string input not
          tried.
        - Real BlueValues with a zero fractional part are now accepted to
          allow use of broken fonts.
        - /loadfont in init.ps discards garbage on the operand stack left
          by the font.
        - filenameforall implemented. I need this functionality for the
          resource ops. Limited testing.
        - setobjectformat, currentobjectformat implemented. Not tested.
        - error handling should be pretty much level 2 compliant now
          except for "binary" and stackoverflow handling inside the error
          handler itself. Not really tested.
          stackoverflow handling inside the error functions is a nasty one,
          as we don't have Level 2 compliant expanding stacks. This
          actually doesn't matter, as even a "true" level 2 interpreter
          could run out of memory in that situation. It seems to be an
          obscure and undefined case. I handle it my way. At least it
          should not crash.
        - character showing could be a little faster now. Hashing for
          it does not need multiplications anymore. It uses shifts and
          additions.
        - status should handle a string arg now. Not tested.
        - renamefile, deletefile, fileposition, setfileposition
          implemented. Not tested.

    22.3 HWG still not public

        - callextfunc now no longer public. It is nasty stuff anyway.
        - Now the names @vmhwm, @prompts instead of vmhwm, prompts.
        - many internal speedups and simplifications. Don Knuth said that
          "premature optimization is the root of all evil.". This is of
          course true, but I mainly cleaned up quite some code to make
          it more readable to me and "reduced" definitely unneeded type
          sizes. The speedups came as a positive side effect, though they
          are probably not that noticeable with standard PostScript code.
        - imaging and filling now in separate source files. It was all too
          big IMHO.
        - For displays with less than 100 dpi on at least one axis, a
          default halftone frequency of 30 instead of 60 is chosen now.
          This gives at least some halftoning on screen as default which
          makes many pictures look much nicer. I am not sure that this
          conforms to the B&W book where it is said that 60 is returned as
          default, but it gives better results for B.J.User. So what the
          heck ...
        - When grestore behaves like a noop because there is nothing to
          restore, the halftone screens are no longer invalidated.
        - copy is now level 2 compliant for dictionaries. No attribute
          changes anymore for the destination.
        - There was some unlogical code in calclogicaldepth (pun intended)
          which IMHO could have failed under special circumstances. Should
          be safer now.
        - When closing an eexec file, the dictstack is popped only if there
          is sysdict on top of it. Anything else is silently ignored to
          avoid recursion caused by the error handler (which can cause
          files to be closed, too).
        - Implemented a ForceBold mechanism for type 1 fonts. If
          ForceBold is true and a stem would be rendered 1 pixel wide
          because its width is >= 1.3 and < 1.5 it will be thickened to two
          pixels. 1.3 seems to give visually acceptable results. 1.25
          as limit for rounding up looks pretty unreadable already.

    22.4 HWG still not public

        - StdXW and StemSnapX implemented. "Snapping" should work when the
          delta to the actual width is less than 1.0 _pixel_.
        - Implemented FamilyBlues and FamilyOtherBlues.
        - selectfont is now built in and behaves correctly.
        - Major rework of the font machinery to help adding the composite font
          extensions. Now most of the vars needed for rendering are cached
          at setfont time. I trade memory for speed.

    22.5 HWG still not public

        - Moved the ForceBold limit up to 1.4. 1.3 just doesn't look too good.
        - Major rework of the font caching. The font cache size can now be
          changed (needed for setcacheparams) and with a tiny little change
          the efficiency of the font cache has gone up it seems.
        - Implemented setcacheparams, currentcacheparams.

    22.6 HWG still not public

        - Setup internals for the implementation of User Parameters. This causes
          changes to VM handling, font handling, and the interpreter stack setup.
          All other values are currently noops.
        - currentuserparams, setuserparams, setvmthreshold implemented.
          Currently we don't have any garbage collection. So the value you set with
          setvmthreshold does nothing.

    22.7 HWG still not public

        - Somewhere in 22.7 I went to SAS/C 6.51.

    22.8 HWG still not public

        - xshow, yshow, xyshow implemented. Seem to work well.
        - missing flush in error message output added.
        - rectfill, rectclip, rectstroke.
        - half a ton of const keywords added to many functions.
        - setgstate, gstate, currentgstate. Not tested.
        - forall should no longer enumerate read protected keys.
          I am not exactly sure that this is correct behaviour, though.
        - kshow resets the current font after executing the proc if
          necessary.
        - findresource will behave as in a "small memory" situation as
          Adobe names it. That is, it will never fiddle with the VM mode
          even for type 3 fonts, unlike e.g. Display PostScript does
          according to Adobe.
        - moved definefont and undefinefont over to using resource
          primitives. I don't even know right now if it will compile. ;^)
          Uhm, as you see, undefinefont should be available now, too.
        - Implemented @RegisterDiskResource to tell HWGPOST what external
          resources are available.
        - findfont is using resources now, too.
        - init.ps is setting up the disk resources now!
        - eexec should behave like run now. It should automatically close
          the file it creates on EOF _and_ on any other termination! This
          should fix "{eexec} stopped" like constructs which used to leave
          systemdict on the dictionary stack.
        - findfont, definefont, and undefinefont are now defined in terms
          of resource operators as described in the R&W book.
        - ISOLatin1Encoding, StandardEncoding, and findencoding are now
          defined in terms of resource operators as described in the R&W
          book.
        - Split up font handling and show handling even more. Another
          source file postshow.c is now available.

    22.9 HWG still not public

        - minor cosmetic reworks in some publically visible files

    22.10 HWG first public beta release

        - currentcolortransfer returned garbage. Should be fixed now.
        - Internal preparations for setting up color spaces!
        - setcolor implemented. Not tested.
        - setoverprint. Note that this is a no op currently!
        - currentoverprint.
        - created postcolor.c with all the colorspace handling stuff.
        - Family[Other]Blues check still had a bug that showed with the "d"
          of the Times-Italic I have here. Should be fixed now.
        - I commented out the halftonephase ops for now. This will need
          much work _after_ patterns are done. Any halftonephase != 0 will
          probably slow done rendering a lot then.
        - sethalftone, currenthalftone, general halftone dictionary
          support. Not tested at all.
        - This just came to mind. Did I mention that the scanner no longer
          uses the isspace() macro, but truly checks according to the R&W
          book specs for white space? This has been in there for quite some
          time.
        - Added provision for true CMYK rendering into the bitplanes
          instead of RGBW on the fly. This has actually been done
          earlier already, but now it is enabled. Not tested.
        - For the pattern color space, I need a masking feature. So I
          enhanced the device structure to provide for a mask.
        - Big problems with the image ops and handling of the Decode array
          fixed. It wasn't decoded correctly anyway and it wasn't used at
          all for gray scale devices.
        - A missing flush in effect mixed error output and output
          by e.g. =, ==, pstack in an inappropriate way.

    22.11 HWG internal

        - /version should be a string now. Sorry for the inconvenience.
        - curveto with the same start and end point now works as intended.
        - pathforall now copies the path into an internal buffer before
          enumerating it. This way changes to the current path while
          pathforall is active no longer hurt the result.
        - Commented out sethalftone/currenthalftone and setcolor for now.
          They are not fully functional yet, and their presence might
          confuse valid PostScript files.
        - Serious bug in handling of parameters for the image operators
          resulted in errors for 8 bits per sample. Found this by accident
          only. :-(

    22.12 HWG release for NOVA.

        - True halftone phase support is back. It should be general enough
          to be a base for patterns. Rendering of halftone screens is
          slower now than before. I might add a special optimized halftone
          function for standard filling though that runs fast for any x
          shift of 0 or by a multiple of 8 pixels.
        - Fixed a bug that could possibly mess up halftoning for very
          small vertical rendering. Never noticed this though.
        - Added deviceinfo to make /processcolors in statusdict easier.
          processcolors has been added, too (In init.ps!). Why I did this
          now? I just got news about /processcolors and before I forget
          about it, I add it.
        - Bookman-Light showed me a possible problem with eexec decoding.
          Though I think that Bookman-Light actually violates type 1 font
          specs, I added special code to the file handling to work around
          the problem for IBM font style binary encoded eexec portions.
          The above is a euphemism for "hack added to make ugly stuff
          work".

          Note: Anyone complaining about a font not working is required to
                provide me with a legal copy of the font for my own use
                from now on. Argh!

          Sidenote: Bookman-Light 001.003 is buggy according to Adobe. In
                    001.004, the problem is supposedly fixed.

        - Work on Separation/Indexed colorspaces to get all the interfaces
          for patterns set up. Tricky and not yet visible to the user.
          Probably not for a while.
        - To get best performance and memory use for any halftoning or
          patterns, you should have a width of the cell that is a multiple
          of eight device pixels. Any halftone phase other than a multiple
          of eight will slow down cell rendering. Any width other than
          a multiple of eight will (sometimes considerably) increase memory
          use. This is especially important for users of halftone
          dictionaries. The cell will be replicated in x direction until a
          byte aligned width is achieved. So e.g. for a 9 pixel wide cell,
          the actual internal width and memory requirement will be 9 * 8 ==
          72 pixel per line, which can be evenly divied by 8. If I did not
          do it like that, rendering would not take long, but forever.
          Actually it is not a new invention. The default halftone screens
          always did it like that. I used this for halftone screens
          specified via dictionaries only, and I have reason to assume that
          I'll need it for patterns.
        - eexec reworked again. It now uses a destructor to pop the system
          dictionary. The file handling is back to normal. No strange stack
          handling within closing of files anymore. I feel that this is
          good news.
        - Interesting enough, the eexec rework led me to a problem with the
          implementation of resource ops while debugging. Tricky
          manual stack manipulation after a resource op caused an error
          could cause a crash. Should be robust now.
        - setdevparams, currentdevparams. They are dummies that don't do
          very much. setdevparams will always give an error and
          currentdevparams returns an empty dictionary.
        - Reworked halftone validating mechanism in my quest for patterns.
          I made it look more "black box" for the callers which should help
          me a lot in the future. As a side effect a few unnecessary
          invalidations of halftone screens could be removed.
        - Color handling behaves better now, too. Setting a colorspace and
          setting the colors is much cleaner internally now and colors will
          be only set once not twice for every colorspace/color change. Oh
          well. Not exactly true. sethsbcolor will first set the colorspace
          and with that the initial color, and then the requested hsb color
          will be set. That is what you get for using strange stuff.
        - I'll have to design a general bitmap caching scheme within the VM
          handling. This will cover hopefully characters, patterns, and
          forms. Maybe I can even do something about user paths then, but I
          doubt it. While thinking about this and looking at the current
          font cache handling, I could fix a possible hole in font type
          checking and improve VM efficiency with save/restore
          combinations. Strange how things hang together sometimes.
        - For the Pattern color space, the font cache will be ignored. A
          rendering function would be needed that I am not willing to
          design to support rendering of the font cache in any reasonable
          way. So with patterns all characters will be rendered the slow
          way.
        - The interrupt signals will be checked now in '=', '==', and in
          'pstack'. While doing this, I added correct defines for the
          signals to postlib.h. I added defines for the garbage collection
          that does not yet exist, too.
        - Changed style of error display to something supposedly much more
          Adobe like.
        - Changed rounding factors for setstrokeadjust to 0.25, i.e. I use
          the 1/4 method suggested in "PostScript by Example". Should give
          slightly better results. Why didn't I think of that in the first
          place?
        - Interesting enough there was a bug in VM save/restore handling.
          restore would not correctly restore things in all circumstances
          because marking of allocations was off by one.
        - Handling and closing of the currentfile was not exactly "ok". It
          should work better now, and currentfile should never return
          "wrong" file handles. Uhm well, if no file exists, currentfile
          will return %stdin to return something. There is not really a
          concept of an invalid file object.
        - There should no longer be any "hanging" file open calls when an
          error occurs. When a file is closed, it is closed now. No fake
          close handling anymore to keep the interpreter happy. I
          originally missed a paragraph in the R&W book saying how it works
          and messed it up. Now it is done right (I hope).
        - Time for a freeze.

    22.13 HWG internal

        - Threshold halftoning was ... uhm ... totally broken. It should
          work now. This paragraph doesn't tell how much time I spent on it.
          As a positive side effect of the rework, the halftone cache is
          now smarter. Going from black to white shold be as fast now
          as going from white to black when asking for halftones.
        - sethalftone is now available.
        - Still a "typo" in the new error message format corrected.
        - There could still be "hanging" file open calls when the execution
          stack was popped, e.g. on error or quit. Now any files
          encountered while popping the execution stack will be closed.
          This should help a lot.
        - Note: kshow does not create a loop context currently! I'll fix
          this when I am into composite fonts. I'll need to invest some
          thought into this. Colorspaces are still first on my list.
        - BTW, if you guys out there want CIE color spaces, buy a decent
          book on the subject, and send it to me. The R&W book isn't all
          that clear, and afterall it would be nice if I didn't have to
          spend all my money on this. :-) If nothing like this happens, CIE
          color spaces won't come soon.
        - In systemdict you will now find /=string with a length of 128.
        - Added the destructor concept to vm restore handling to make cache
          flushing independent of vm handling.
        - name table handling is now more black box, too. I need all this
          black box handling to implement the new general caching scheme.
          A small change to the hashing in name token seems to have helped
          lookup performance.
        - Added @calluserhook. Not tested yet.

            mark <args> <hookadr> <msgadr> @calluserhook

            ==>

            mark <resargs> <resint>

          ints, reals, bools, or strings may be used as args with a maximum
          number of 8 arguments. The values are put into an array of longs
          that is passed as object address to the hook. For strings two
          slots in the array are used for address and length. On return the
          values of ints, bools, and reals will be copied back into the
          internal PS objects. The called function runs on the context of
          post.library and might need to set up A4 from e.g. hook->h_Data
          to make use of its local near data segment. No assumptions may be
          made about post.library's context! It is private stuff!

          All this should help people needing to interface to external code
          a lot.

        - The new general caching scheme is in place now. While it has more
          overhead than the old font cache, there does not seem to be a
          performance hit as hashing and caching is a little smarter.
        - For blue values any reals are now accepted and converted to
          integers.
        - Some cleanup to the font and show handling for the new caching
          scheme.
        - exit always had a bug. It would look below the lower end of the
          exec stack. One object too much. Ouch.
        - kshow now has a loop context that can be exited via exit. I don't
          have composite fonts yet, sorry.
        - While testing pattern generation, I found that gstate object
          handling was in fact totally broken. The paths were not saved
          correctly. This works now. Otherwise patterns would not work.
        - Patterns seem to work now. Please note that patterns are sort of
          slow to render because there is a lot of work to do for this
          including floating point calculations when a cached pattern is
          imaged onto the page. Patterns are also memory hungry. If you know
          the bounding box in device space (i.e. in pixels of the
          bitplane!), you can estimate how much memory patterns eat. They
          use bitplanes in the size of the bounding box. One mask bitplane
          is always needed and for colored patterns you'll need one
          pattern bitplane per device bitplane. Currently there is no
          setsystemparams call and the maximum amount of bytes for the
          pattern cache is ~60K. As we don't have a garbage collection yet,
          allocated memory for the pattern cache will stay allocated until
          it is either reused or invalidated by a VM restore.
        - Hopefully not too many bugs lurk inside pattern handling. BELIEVE
          ME, PATTERNS ARE TRICKY TO HANDLE!
        - As I said above, drawing characters with patterns does not use
          the font cache and probably never will. It is slower of course
          but it works the same and doesn't add tons of special handling
          to rendering.
        - Corrected a sign bug that messed up 360 degree arcs with arcn.
          This one has been in there since at least 1.7. I found this while
          testing patterns.

    22.14 HWG the pattern freeze.

        - The band rendering operators are now named "@currentband" and
          "@setband". To keep compatibility to old post.library usage, I
          added a kludge to init.ps to define the old names in terms of the
          new names. Using the old names is strongly discouraged, though!
        - Oh well, I forgot to mention that the masking feature contained
          in the struct PSextdevice works and may be used. If it wouldn't
          be working, patterns would not work at all.
        - An interesting comment on the side is that the interpreter source
          is still fairly portable even with those many changes. So if I
          was ever to find a computer with a better OS than the Amiga, I
          could take the interpreter with me. Don't fear anything, though.
          There isn't any better OS around for me as far as I can see.
        - Cleaned up names for extended PSsignalint() flags.
        - Added missing PSerrstr prototype and pattern cache default sizes.

    22.15 HWG

        - Just found a bug when testing the release version. Font caching
          would not work correctly.
        - I totally forgot to mention that XUID's should work for fonts and
          patterns.

    22.16 HWG Pattern Release BETA2

        - resourcestatus did not update the operand stack correctly. So you
          did not get the expected results.
        - Negative setdash offsets should work now and give results that
          make some sense.
        - In some cases there was too much clipping done when rendering
          images. The bug was in there at least since post 1.7.
        - Some PS files are checking /version and replace buggy operators
          depending on this information. Of course HWGPOST does not have
          any bugs, ;^) so I had to rework the "version"/"revision" setup.
          /version is now an arbitrary number (50) and /revision is derived
          from the library version number. For HWGPOST 22.16 it is e.g.
          22016. Suggestions for a better /version choice are welcome.
        - A comment on pattern rendering. Due to the current imaging model,
          a pattern must be cacheable. Patterns that do no fit into the
          pattern cache will cause an error. In addition to this behaviour
          the "MaxPatternItem" user parameter is not checked currently.
        - The image operators had some bugs. The first one had been in
          there since the beginning of time. It caused placement and sizing
          problems with images by one pixel. They were due to a
          misinterpretation of filling rules for image data. This should be
          fixed now. Images are now much more handled like standard fills
          which makes handling them a lot safer and clearer.
          The second bug had been introduced by me when the new rendering
          scheme for patterns was put in. Untransformed images that map to
          the page in a 1:1 scale were not at all rendered. The best one
          could hope for was a gray or white area in the image's size.
          Actually this bug was the major reason to work towards a beta 3
          really soon, because not fixing it would have made the beta 2 for
          e.g. "dvips" applications or faithful bitmap rendering useless.
        - If a disk resource is not registered, the /ResourceFileName entry
          in the implementation dictionary is now checked if available. The
          implications of this feat are staggering. ;^) Transparent
          adaptive resource lookup by checking different paths is now
          possible via /ResourceFileName. This makes for nice font lookup.
          Note that this obviously can't affect resourceforall because
          there is no way for this operator to "guess" where a
          /ResourceFileName implementation would look and what resoure
          names would be appropraiet for filenames found. So resourceforall
          will only return registered resources. I doubt that there is a
          good way to implement a general file search for resourceforall
          that could handle e.g. all the different styles of font names
          possible and all sorts of different directories. While
          directories could be handled via a "path" concept, alias names
          for fonts cannot. They needed to be registered. In this case one
          could register the font directly anyway so there is nothing lost
          by the current implementation. A special HWGPOST feature is that
          /ResourceFileName may return a zero length string. This counts as
          "not available/known". It not only speeds up processing a little
          but provides for a more "natural" error handling.

          Net result is, that findresource might be able to find things
          that resourceforall does not list, if /ResourceFileName is used.

        - For the daring: I put in some code into the image handling to
          support 12 bits per sample. Not tested at all yet. Anything can
          happen.
        - Added rootfont. Until composite font support is done, it will be
          in effect equivalent to currentfont.
        - Nobody ever noticed it before, but the scanner had a limited
          understanding of the "newline" concept when skipping comment
          lines.
        - defineresource sets the /Category entry properly now.
        - While resource file stunts can be played now via
          /ResourceFileName, this alone would be rather cumbersome. An
          internal resource lookup scheme is now implemented that makes
          defining a search path for any type of disk based resource rather
          easy. Resource lookup is now done like this:

            1. When registered use the registered filename. Done.
            2. Check if (%ENV%HWGPOST/PATH_<category>) exists. If so:
                a) Parse this file for prefix/suffix combinations to try
                   on the resource name. If a filename can be generated
                   where the file exists, consider the resource to be
                   found. Use this filename. Done.
            3. Check /ResourceFileName if available. Use any non zero
               length return string as filename. If so, done.
            4. Fail. The resource can't be found if you get this far.

          A demonstration PATH_FONT file to be copied into
          (%ENVARC%HWGPOST) is supplied. Refer to it for further
          information.

          As with /ResourceFileName, there is no support for resourceforall
          because there does not seem to be a way to revert back to
          resource names when scanning directories.
        - As you can see, HWGPOST makes use of environment variables for
          the first time, now. They'll all be in a subdirectory "HWGPOST"
          to keep them in one place.

    22.17 HWG

        - I postponed the beta 3 release to implement resource file
          lookup into resourceforall, too. resourceforall will now check
          the environment variable (%ENV%HWGPOST/PATH_<category>) just like
          findresource. On any resourceforall call, all supplied path
          prefixes and suffixes will be scanned with a PostScript file
          pattern of (*) to enumerate all possible files. Then a list is
          built of all the filenames stripped down by the length of the
          prefix and suffix to give resource names suitable for
          findresource. resourceforall will then continue to work as usual,
          enumerating local and global resources. Then the preregistered
          disk resources will be enumerated and finally the entries in the
          just scanned resource file list.

          This new behaviour has some side effects and consequences. the
          file scan cannot check the contents of the file. So any file
          encountered within the resource path will be listed as available
          resource, whatever it is. So keep your resource directories CLEAN
          and put only resource files there. Otherwise you might confuse
          PostScript programs using resourceforall to do more than just
          enumerating resource names.

          There is no serious duplicate checking while building the file
          list. So if you have the same font file names in different
          directories listed in the path, chances are high that they are
          both listed.

          Another side effect is that resources with a name longer than the
          filesystem supports cannot be listed correctly without
          preregistering them. Consider this example:
          (HelveticaNeue-UltraLightItalic) can be
          (HelveticaNeue-UltraLightItal) to a filesystem, because the
          maximum filename length is exceeded. While preregistering the
          full resource name with the partial filename will solve this
          problem for findresource, the automatic lookup via the path will
          not give usable results. The disk scan will return the incomplete
          filename as resource name.

          So if you use the new path environment variables:

            1. Watch out for filenames that are too long. Preregister those
               resources.
            2. Watch out for non resource files that might get in the way.
            3. If you do need alias names, use filesystem hardlinks to make
               them.

          Of course resourceforall still can't handle any tricks that you
          might want to play via /ResourceFileName. But this shouldn't be a
          limitation and /ResourceFileName stunts should not be necessary
          anymore anyway. I discourage using /ResourceFileName now.

          I put so much "automatic lookup" into the resource mechanism that
          anyone who wants to complain about missing features should have a
          _very_ good reason to bother me.

          NB: Playing these stunts wasn't exactly easy. So if you want to
              do something good for me in return, buy a "Sonata" music font
              as gift and send it to me. I'd have good use for this font.

        - Illegal type 3 encodings that do not use names should work again.

          NB: This violates Adobe specs, and I will not guarantee that
              these illegal encodings continue to be accepted.

    22.18 HWG beta 3 release

    22.19 HWG

        - Changes to the library setup code to make an easy name change to
          e.g. "hwgpost.library" possible.

    22.20 HWG hwgpost.library special release

        - Due to a rather reasonable problem report, I decided to put
          "callextfunc" back in. It is now there as "@callextfunc" in
          disguise with some better setup work for the called function.
          Note that I still discourage any use of this function. Let me
          point again to @calluserhook. See HWGPOSTlib.doc for details.
          This stuff needs to be tested.
        - All the composite font stuff is in now. Rather limited testing.
          Nested composite fonts not tested at all because I don't have any.
          Actually I don't have any composite fonts, just the one I hacked
          up myself for testing. Some FMapTypes tested, some not. I need
          examples and feedback here. I wouldn't mind you guys filling up
          my font library in exchange for giving you these features.

          I still hope to find a Sonata font in my smail eventually, too.

        - rectclip did not do a newpath.
        - execform is now available. Due to memory considerations, no
          caching is currently done.
        - The image operators should finally take files as data sources.
          While this is currently rather slow, at least it seems to
          work quite well. So don't complain. I might eventually get around
          to improve it a lot, but without incentive to do so, not much will
          happen here.
        - There wasn't a chance that the image operators worked with 12 bit.
          Now there is. Note that image rendering is slower now because
          of this. Also a one color image source wasn't working correctly
          with a non gray colorspace. While rendering images takes now
          twice as much memory (8 bytes * pixels per page line), all sample
          mangling problems should be solved now. Also the Indexed color
          space should now be usable with the image operators.
        - Interesting enough it seemed that arrays in global VM could
          potentially still be affected by save/restore combinations. Due
          to changes in the VM system for implementing startjob, this
          should never happen again.
        - The interpreter checks for abort signals now while doing image
          data processing. Helps a lot with stopping unwanted 1MB images
          coming in via files and filters. ;^)
        - Added a UseStdIO option to the post frontend. If you use it, post
          will use its own standard shell console filehandles and pass them
          to the library as standard I/O instead of using the interactive
          window of the screen display. Note that the interactive window
          will still be opened. It won't be used for I/O though.
        - Somewhere along the lines I had changed frontend behaviour to
          open a screen if neither iff, screen, nor printer was specified.
          Now the old behaviour of doing a silent "printer" is back.
          Also using the BW/RGB/CMYK gadgets was broken.
        - =string should behave like in Adobe implementations now.
        - Changed the default prompt to "PS>".
        - Added startjob, PSFLAGJxJOBSERVER. Changed the meaning of
          PSFLAGSAVE.

          The new meaning of flags for PSintstring():

            PSFLAGSTARTJOBSERVER:   force a successful startjob with
                                    a "false" operand before interpreting
                                    the file or string.

            PSFLAGENDJOBSERVER:     force a successful startjob with
                                    a "true" operand after interpreting
                                    the file or string. This works like a
                                    major cleanup.

            PSFLAGSAVE              Do both of the above.

          With PSFLAGSAVE you can easily run many encapsulated jobs. With
          the other two flags you can do multiple calls to PSintstring()
          for one job. You have to use PSFLAGSTARTJOBSERVER on the first
          call and PSFLAGENDJOBSERVER on the last call to PSintstring()
          then. You can't nest this and you should not make any special
          assumptions.

          startjob won't work if the PSFLAGSAVE or PSFLAGSTARTJOBSERVER
          have not been used since the setup or the last PSFLAGENDJOBSERVER
          or PSFLAGSAVE. That is, the current context must support job
          encapsulation.

        - Under rather peculiar circumstances the halftone mechanism failed
          because of a loop check that could be wrong by one. If the
          internal halftone memory needs met in a specific, rather
          complicated way with the HT memory size and the previous memory
          use up to that point, a wrong cache screen was generated. Just
          another variation of the "0 to n" instead of "0 to n-1" problem
          that has been in there since pre 1.7 days.
        - serverdict and exitserver are now built in.
        - statusdict is built in and some of the init.ps statusdict
          operators are built in now, too. Note that this stuff is
          implementation dependent and that I might do what I want with it.
          So you better adhere to Adobe specs and forget about statusdict
          as far as possible.
        - When the first init file is run, the default VM allocation mode
          should be local now for sure. This should make many applications
          a lot safer.
        - user object functions now do better type checking.

    22.21 HWG The "startjob" version

        - Major rework of all stack access code. This will make it easier
          to possibly add dynamic stack sizing and some other internal
          stuff and while it seems totally unrelated it might come in
          handy for a future setpagedevice. As a side effect the library
          seems to be faster for most non rendering operations. These
          changes affected most of the sources though, so they classify as
          ENORMOUS REWORK. It seems right now that I did not break
          anything, but we'll see about that.

    22.22 HWG The "new stack stuff" release

        - rectclip still did not work right. It set the clipping path
          correctly and then just cleaned it out again. Hmpfh.
        - A document created by the Interleaf publisher showed me that
          currentfile must return a literal file object. Since the
          beginning of time it had always returned an executable file
          object. A nice guy from Adobe confirmed this change to be the
          right thing to do.
        - Cleaned out some confusing code in the interpreter loop.
        - Note that the systemparam operators are _very_ rudimentary and
          mostly noops. They are not fully implemented yet and the stuff
          implemented is only to make startjob/exitserver basically
          possible. I plan to fix this for the next public release.
        - Scanning of <~ASCII85~> was broken. Should be working now.
          Implementing the ASCII85 filters still has to wait a little,
          though.
        - If the image operator data sources were prematurely exhausted,
          the operand stack wasn't cleaned up correctly. Tss. Always the
          image operator.
        - Prepared for true 8 bit CMYK handling by adding new bitplane
          pointers. A depth of up to 32 should now be ok. One problem with
          all this depth stuff is, that I can only test gray scale
          rendering with other depths than one with reasonable ease. As my
          A3k is ECS, I can only check on 1 bit per color RGB or CMYK
          displays. As the shading and rendering for multiple colors is
          absolutely identical to the calculations for a one color display,
          this should theoretically not be a problem. If you experience any
          problems with more than 1 bpc and RGB or CMYK displays, _you_
          need to help me. I can't afford to buy an AA machine or a
          graphics card + monitor.
        - Moved path handling and matrix calculations into own source files.
          gstate handling is something really strange. I'll need to clean
          this up for pagedevice handling.
        - Added a debugging command to help all those with strange rendering
          problems: @dumprenderinfo. This command will put out on %stdout
          some information about what any rendering with the current gstate
          values would do to the planes. If you have any rendering problems
          that you can't solve, I will need the output of this command to
          help you!
        - Added some safety checks to color and shade handling that should
          indicate if something goes wrong without hurting performance.
          This is just paranoia though. Nothing actually went wrong yet.
        - Added HWGPOST_DEVB_INVERTOUTPUT. This inverts all shades before
          setting up rendering into bit planes. What does this mean?
          Without this flag a 100% color value (e.g. white) will cause 0
          bits in the planes and 0% color (e.g. black) will cause 1 bits.
          This choice had been made because typically there is less black
          on a page than white, and setting bits is generally more time
          consuming than zeroing out memory. This is kind of ugly though
          for color rendering because one needs to set up an "inverted"
          color table. With the new flag all output shades x are converted
          into "1.0 - x" before they are used for rendering. This in effect
          will cause a negative image where 0% color will cause 0 bits.
          The hacked post frontend got an InvertOutput option to test this.

    22.23 HWG The "better graphics" release

        - If one specified a 0 to 360 degrees arc (a circle), the last
          point generated would be a in effect postitioned in a position >
          360 degrees which was "beyond" the first point. A closepath would
          cause a path segement then working backwards which messed up the
          join at this point because the joining mechanism (correctly) made
          a join for a ~180 degree turnaround. You could notice this for
          stroked full arcs with big linewidths when the arc did not seem
          to be correctly closed. The bug was due to additive rounding
          errors inside arc generation which made it exceed the 360 degree
          limit internally by a rather tiny fraction. Can't happen anymore.
        - The hex and rle filters do a read ahead for EOF now to make
          them work better with image ops. I'll have to implement this
          for filters in general though to be R&W book compliant.
        - I decided to make this available as beta 4 now, even though
          I haven't finished the setsystemparams implementation as I
          originally planned to do. It'll be in the in the beta 5.
          Sorry.

    22.24 HWG beta 4 release

        - I have been working on a datatype for HWGPOST based on an
          idea by Swen K. Stullich. As his code was not usable for me
          at all, I wrote new stuff. The data type handles PS
          recognition via "%!" and renders the picture in B&W. It also
          tries to obey any BoundingBox or Orientation header comment.
        - The library now understands how to handle DOS EPS files with a
          binary header. It will automatically read the PostScript code
          embedded. This is not a performance hit for normal files except
          for the first character read from a file. In fact, true ASCII
          files should be read slightly faster than before now.
          Why this before setsystemparams? To be able to enhance the
          datatype now which seems to have more appeal.
        - The simple HWGPOST datatype knows about DOS EPS files now. It
          will now try to display something even if the [E]PS files did not
          have a showpage. It also has much more robust PS file
          recognition. Thanks to Tony for the push to make this
          better.
        - The library should no longer behave strange if you pass NULL
          filehandles. Note that it was _never_ acceptable to pass NULL
          filehandles to the library for %stdin, %stdout, and %stderr.
          It is still not acceptable. This is only a kludge to make broken
          SW work right.
        - With this entry, I break the magic 1k line History mark.

            "Eine Flasche Sekt!"

        - The internal definefont handling did not allow multiple keys per
          font dictionary as possible in Level 2. Fixed.
        - cvi and cvr are now a little less strict about input. They should
          handle one trailing space now. This is an important change and
          fixes some documents.
        - Added some very heavy magic to fix stone age FreeHand documents
          that break documented Level 2 compatibility. I sure hope I got
          this right. It seems to work though.
        - datatypes.library seems to presort the filetypes in some
          arrogant way without regard to the descriptor files. This
          always messed up handling of the datatype descriptor. I
          could not figure out the exact problem. Annoyed as I was, I
          took the brute force approach and use two descriptor files.
          One for ASCII files, and one for binary files.
        - The datatype no longer has problems with negative values in the
          bounding box comment. It also stops scanning when it finds an
          %%EndComments. It also sets up the color map correctly, so that
          clips out of multiview will now show up in a nice and colorful
          way instead of black.
        - The datatype behaves _much_ better now in low memory
          conditions.
        - The datatype now optionally handles color displays,
          densities and other default sizes. How? Via a new
          environment variable: "ENV:HWGPOST/DATATYPECONFIG"

          The first line of this environment variable is evaluated in
          DOS ReadArgs() style with this template:

              COLORS/K/N,BPC/K/N,XDEN/K/N,YDEN/K/N,DENSITY/K/N,
              DEFWIDTH/K/N,DEFHEIGHT/K/N

            COLORS:     Either 1 or 3. Only B&W or RGB supported!
            BPC:        Bits per color. Anything from 1 to 8. Note
                        that BPC*COLORS must be <= 8 or strange things
                        may happen due to the OS limit of 8 bitplanes.
            XDEN,YDEN:  Densities (dpi). Default is 75 dpi.
            DENSITY:    Convenience operator to set both densities.
            DEFWIDTH,
            DEFHEIGHT:  If no bounding box is specified in the file,
                        these values are used. You need to specify
                        them in units of 1/100 inch though, not in
                        1/72 inch like PostScript likes it. The
                        default values for these parameters will give
                        an A4 like bitmap size.

           This environment variable should do the job for a while.

        - Tricky behaviour change to make library use for programmers
          easier. It has always been permissible to set the kill flag on
          the copypage/showpage callback to abort the interpreter run
          synchronously. showpage will now skip the erasepage if it finds
          the kill flag set. Thus it is possible now to abort the library
          run on a successful showpage without the need to redefine
          showpage or copy the bitmap away into some backup place to save
          it from being erased. Nifty, eh?
        - Even better protection against endless error looping now.
        - Interesting enough the SAS/C 6.51 floor() and ceil()
          implementations in scm881.lib will crash when you pass a 0
          NaN to them. This could happen if someone caused the CTM to
          be a e.g. 0 matrix. Then matrix inversions would give NaN
          results which killed the interpreter immediately due to the
          SAS/C bug. I put in some protection into the most relevant
          floating point calculations to circumvent this problem.
        - The post frontend should accept negative values in the SIZE
          option now.
        - Ouch. Due to the internal changes done for the beta 4, the
          PSsetdevice() interface broke completely. No workaround for
          the beta 4. Fixed now. Sorry.
        - Magic added for default font lookup. If the search for a
          font fails, the interpreter will try to find
          /@DefaultFontName as font. The updated init.ps shows how to
          define a dummy default font. If you like any other font as
          default font, e.g. /Courier, just set /@DefaultFontName to
          /Courier.

    22.25 HWG beta 5 release

        - pathbbox returned garbage for rotated coordinate systems. Why
          didn't anyone (including me!) notice this before? This must have
          been a problem for a long time. This will be the reason for
          a beta 6 to come out RSN.
        - Color values out of range should now be silently adjusted as
          described by the R&W book.
        - The datatype did not compute width and height of the bounding box
          correctly. It does now, though it won't handle "(atend)".
        - The datatype will give an error message now instead of an error
          number.

    22.26 HWG beta 6 release

        - Added PSFLAGRUNSTDIN to make a simple run on the passed input
          filehandle as currentfile possible.
        - The interpreter no longer complains on an empty file with an
          ioerror. it will now simply do nothing if it gets an EOF right
          away.
        - Created the new prtpost-handler for PRTPS:. It should behave
          like a no thrills B&W PostScript printer. Page size and
          densities are taken from the printer gfx prefs. Do not
          forget to set the image dimensions to something other than
          "Ignore"! It is _very_ rudimentary and actually just a hack
          to test a few things. It probably won't work for you.
        - exitserver can now be invoked when there is no job server
          encapsulation active. It used to cause an error.
          I put this in to make (lousy!) fonts invoking it work.
        - It should now be possible to change the stack sizes
          via setuserparams. No dynamic resizing yet!
        - The datatype now uses BestModeID() to suggest a display
          mode. This should hopefully help some users. Actually there
          is more to it. It works like this:

            1. Check the config paramter MODEID in the
               HWGPOST/DATATYPECONFIG environment variable. If it is
               set, take it as hex value for the mode id.

                Example: "MODEID=41000" for the A2024 in 10Hz mode.

            2. If no modeid set yet, try BestModeID()

            3. If no modeid set yet, use the default monitor.

          So even if BestModeID() doesn't do what you want you can
          override it with the MODEID setting.
        - Even when a buggy mathieeedoubbas.library is used, truncate
          should no longer give strange results for 0.
        - Negative arguments for setlinewidth should be ok now.
        - When I put in the composite font machinery I messed up
          glyphshow handling. This is fixed again.
        - The C= math libs have a rounding problem if a 68881 is
          installed. This shows when you start mixing single
          and double precision math. It also conflicts with e.g. the
          SAS 68881 inline code (which is better). If these two are
          used together, e.g. an application using one mode using
          post.library compiled with the other, rounding will not work
          correctly. Again, a similar problem appears if
          mathieeesingbas.library is opened after
          mathieeedoubbas.library. You don't even have to use
          post.library to get rounding errors.:-( I can't do much
          about this in the library. A general fix for the C= libs is
          required.

          Well, I did something about the math I use in the library.
          The actual PostScript interpreter will run in a separate
          process now. When you call PScreateact(), you create an
          interpreter process cloning your task priority. All
          interpreter floating point math is now done in that
          interpreter process which is of course absolutely
          independent. Voil, no more problems with rounding errors!

          Notes:

            1. SAS FPU inline math uses "round to nearest"
            2. C= IEEE libs _currently_ use "direct rounding ==
               towards zero".

          Remember this when choosing the post.library version to use.

          Note that the callbacks like flushfunc, copyfunc or callextfunc
          and/or the Hook will still run on your task context, i.e. while
          they are caused by the interpreter process, they don't use that
          context. Don't ask how tricky it was to implement this without
          violating callback compatibility including error handling.
          PLEASE TEST THIS IN DETAIL!

          Currently, the interpreter process does not install any FP trap
          handling for an FPU. The library should not cause any
          math traps like division by zero. Please tell me if you see
          this as a problem.

          CAVEAT: Invoking a callback like e.g. flushfunc will now result
          in at least two additional task switches and some message
          passing. In effect, this slows down any [flushfunc]
          callback. This can noticably affect interpreter speed. So if
          you don't require flushfunc, set it to NULL for optimal
          performance of the interpreter!

          I wasn't able to check on all the different applications using
          post.library. ALL OF THE ABOVE NEEDS LOTS OF TESTING! NOTE THIS
          WELL!
        - Octal output by e.g. pstack wasn't done correctly. Should be
          fixed now.
        - The optimized rendering function for characters rendered trash to
          the right of a character that fell of the left side of the page.
        - A null type in the Encoding of a font is now taken as
          /.notdef to fix some broken apps.
        - Cleaned up the scanner a little bit. Strings handling should be
          done a little better now. Not that it matters in speed, though.
        - The image operators still did not conform to the R&W book
          with respect to the actual pixels rendered. This should
          be better now. I also found a nasty bug in rendering
          code. Still wondering why it didn't crash all the time.
        - Major rework of floating point handling inside the library. All
          the internal math is now done via single precision
          arithmetic except for some places in clipping and filling
          where double precision is needed due to the nature of the
          calculations involved. With minor changes I could even be
          supporting FFP internally again now without major rework
          of the library. I don't want to move away from IEEE math,
          though. Default is currently either
          mathieeesingbas.library or inline PFU code.
        - I hacked up setbbox to include a slightly larger area
          than the numbers tell us. Some PS files shave it so close
          that the floating point fuzz in lower digits could push
          the bounding box check over the edge for nothing. Note
          that this is only a hack to keep some PS files alive!
        - If /StdHW and /StdVW were present in a type 1 font as
          empty arrays, HWGPOST rejected the font. Now empty arrays
          will be treated as "not present". HWGPOST will also
          ignore anything beyond an end type hunk inside an IBM
          style type 1 file. This fixes fonts like BrushScript
          which, among other things, don't really conform to the
          black book specs. How I hate these hacks around messy fonts.
        - Reworked PRTPS: and my hacked up post frontend a bit.
          Finally they should be able to determine the dump size
          correctly without any need to fiddle with the printergfx
          prefs.
        - Maybe I shouldn't include the PRTPS: handler. It is so
          lousy IMHO and I haven't even really tested it. Oh well.
          I've warned you.
        - Reworked the image operator again. It messed up
          coordinates. I am not sure if it now behaves according to
          the book yet. This will need _some_ amount of testing.
          You say I should be able to tell if it works from the
          algorithm I use? You wish. There is tons of math involved
          and I have to get around the peculiarities of the
          different math options. It is not at all easy to identify
          a problem here! It probably still doesn't work right.
        - With the math change I seem to have messeup clipping and
          stroking. It is dead slow. Hmm. Maybe it is flattenpath.
          I'll have to check that.
        - Reworked tricky parts of all the math again. Single
          precision was not enough for some things, so double
          precision is used now, too. Clipping and filling needs
          double precision in certain places to get line
          intersections correct. It ain't easy...
        - charpath could lead to unwanted results for filled paths.
          This should be fixed now.
        - I messed up stroking when doing all the math changes.
          Fixed.
        - Actually strokepath is a mess internally. It doesn't
          really produce an outline of the stroked path, but a
          sequence of outlines for the individual path elements. It
          needs to be rewritten from scratch to put out a true
          outline. This is not an easy task though.
        - The Separation color space worked backwards for all color
          separations, e.g. (Magenta) made HWGPOST ignore the
          Magenta separation instead of producing it. It
          also didn't affect the shade settings at the right time,
          i.e. it didn't really work at all. Currently, you can
          only use the color separation names if HWGPOST is
          configured for the appropriate color model, i.e. if you
          chose a three gun RGB output on starting up HWGPOST, the
          Cyan, Magenta, Yellow, and Black separations are not
          available. The R&W book is a little confusing here, so I
          am not sure if Separation behaviour is up to specs. it is
          not tested that well anyway.

    22.28 HWG beta 7 release

        - I added automatic Interpreter stackextension to the
          library. The exec, operand, and dictionary stacks should
          now automatically be enlarged whenever new entries are
          needed and no user parameter limits are set. There is an
          upper limit of 30K elements per stack and stacks won't
          shrink automatically! Another step towards Level 2 PS.
        - Ouch. There was a hinting bug in the font code. A
          comparison did not ignore the sign of the values involved
          when it should have done so. This messed up e.g. the
          Baghdad font where characters where literally hinted to
          death.
        - Note that if you use an 68040, you will most likely have
          to install a mathieeesingbas.library patch from Aminet
          for <= OS 3.1. Otherwise HWGPOST will most likely crash
          your machine as it depends on a working
          mathieeesingbas.library since the beta 7 version.
        - Color default halftone angles are now 105 75 90 45. They
          used to be 105 75 95 45 for some reason.
        - There was an oversight within the directory scanning
          functions used internally. Now patterns should be
          processed correctly.
        - Making tricky assumptions about the image operator will
          currently fail. An image might be misplaced by one pixel
          in device space if you try to compensate for exactly this
          in your PS code. This might affect dvips users. Sorry
          about that. I'd need to rewrite image positioning, and
          believe me, I tried once already and failed. This needs
          more research and planning. It'll get there, but not
          right now.

    22.29 HWG internal

        - The global checks for gstate objects were not complete.
          This could mess up VM handling.
        - Each VM allocation needs four bytes more now. What you
          get in return? garbage collection and better vm
          save/restore handling. VMThreshold is 100KB and automatic
          garbage collection is turned on as default. As always,
          I recommend at least OS 3.1 and SetPatch 40.16.
          The garbage collection can be turned off as desribed in
          the R&W book via "-2 vmreclaim".
        - vmreclaim does a rangecheck now.
        - There was a nasty bug in VM management of dictionaries.
          If a dictionary got saved by the VM handler and expanded
          afterwards, the restore operation would not always produce
          what you wanted.
        - name comparisons should be a lot more efficient now.
          This could actually compensate for most of any slowdown
          by the more complex VM handling.
        - A problem in setting up cached names for image handling
          fixed. This could have produced dangerous garbage and
          messed up handling of image dictionaries.
        - All cached VM references should now be handled safely.
          Unreferenced objects should be flushed automatically now.
        - During implementation of the garbage collection quite a
          few VM handling inconsistencies popped up. These should
          be fixed now. The interpreter might be slightly slower
          now when it comes to VM handling. I exchanged speed for
          robustness here.
        - Note that a garbage collection will only happen at
          instruction "boundaries", as during instruction execution
          VM may be in an intermediate, instable state for
          performance reasons. This means that you can still run
          out of memory in certain cases.
        - Note also that vmthreshold is evaluated. This means that
          sometimes rendering will pause for a very little while
          because the garbage collection has been triggered. The
          default value for vmthreshold is now 200000.
          Usually the pause is not caused by the garbage collector
          but by freeing the collected memory.
        - There was a bug in setting up cached names for image
          dictionary handling. This could have produced errors when
          using image dictionaries.
        - I added an operator @setpatterncachemax to be able to
          change the previously fixed upper limit of 60KB per
          pattern for testing VM via a demanding and pattern using
          file. As you can see, this is an internal operator. The
          method to set this might change in the future when I have
          decided on a general way to set parameters.
        - $error will no longer be handled via internally cached
          stuff. Now the dictionary is actually used as you would
          expect it to be. The caching was not safe and could
          result in stale data confusing VM handling.
        - Added =print operator. It behaves like "=" without
          printing a newline. This is to support some Adobe error
          handler code.
        - I reworked init.ps to set up a few more dummy operators
          for statusdict and page sizes. This should help quite a
          few PS files.
        - enumfonts.ps should ignore AFM's now. Those shouldn't have
          been placed into PSFONTS: anyway.
        - There were quite a few subtle problems with
          stop/stopped/run/eexec error handling. These should
          hopefully be fixed now.
        - The interpreter will no longer be caught in an endless
          loop when it encounters objects where the executable
          attribute is meaningless.
        - Resource operators could really take the machine down
          on errors due to a missing variable setup.
        - The interpreter runs on an 8KB stack now.
        - "quit" should behave according to spec now. This means
          that you need "systemdict begin quit" to leave the
          interactive context now.
        - It took me about two weeks and an analysis of a 3MB PS
          file to find a very strange bug in the garbage collection
          concept. Basically it was an oversight which caused
          spurious memory messups. During testing it turned out
          that the time needed for garbage collection is truly not
          that long at all. Most time is needed for actually
          allocating and freeing memory. The pools should help. So
          there shouldn't be much of a negative impact caused by
          the new functionality.
        - Strange enough, while testing with that 3MB file I found
          out that an 040/40 with HWGPOST will process B&W image
          data and render it _a_lot_ faster than an HP4M accepts
          and handles it. Even though some of this may be
          attributed to lousy configuration of my parallel.device
          setup, the HWGPOST image operator can't be all that bad.
          :-)
        - flattenpath had problems with degenerate bezier curves
          where all points were extremely close together. Usually
          this happened on scaling large EPS images very small onto
          the page and showed only on certain math options due to
          rounding differences.
        - At this time, fonts using "exitserver" will most likely
          fail with an invalidrestore error. Most likely this won't
          change in the near future. You should get fixed fonts.
        - The error callbacks of the library were not really
          functional. They should do the job now.

    22.31 HWG beta 8 release

        - Any string passed to the interpreter was in local memory
          with the new VM handling. This could result in
          invalidrestore errors. The string will now be allocated
          in global memory. This should fix SpecialHost of PasTeX
          and dvips.
        - LZWDecode is in there. LZWEncode will be publically
          available wihtout returning an error as soon as someone
          talks to Unisys. The filter should support the PDF
          extensions, even though this has not been tested.
        - I included a general fix for mathieeesingbas.library now.
          MathSingFix should get rid of the 8000000B gurus with
          non-FPU and 68040 systems.
        - Some doc updates like removing many empty lines in this
          document.

    22.32 HWG beta 9 release

        - Added the simple pdfmark operator.
        - awidthshow was broken. It didn't evaluate the special
          char argument due to a wrong function parameter.
        - There was a bug in cache management. Luckily it didn't
          show up at all. A silent bug. Still a bug. Another bug in
          cache management could have shown up with buggy fonts.
        - The show functions will not use the cache for strange
          encodings. This should have been that way all along, but
          the line of code responsible was warped.
        - Some TypeSmith generated type 1 fonts seem to be out
          there which violate the winding rules for font paths.
          This leads to filled characters. Nothing I can do about
          that.

    22.33 HWG beta 10 release

*** EOT ***

