due to excessive spam, email form has been removed. instead use handwritten photo of email address:

There is no warranty for this product you use it entirely at your own risk, if you only write to ram: files and your machine is not connected to other computers then usage will be pretty safe but no guarantee of this is given. A.F.P.L Ghostscript is unconnected with GNU Ghostscript!

PHOTOS: making a titchy A6 booklet from a chapter of a document using the pamphlets feature. I use this feature for documents I am not sure about OR if there isnt much printer paper left. Here are commands for doing this, somedoc.pdf is the document and the booklet is physical pages 97 to 158 (pages 110 and 111 in the last photo are in fact physical pages 128 and 129 for this document):

makedir somedrive:temp_pamphlet
gs:bin/pamphlet somedoc.pdf 97 158 somedrive:temp_pamphlet/temp
execute ram:script1
execute ram:script2

This creates 3 PS documents in somedrive:temp_pamphlet/ which are temp_0.ps, temp_1.ps and temp_2.ps.

You then print temp_0.ps via gs, this does one side of the pages. Now depending on the printer you print the other sides by printing either temp_1.ps or temp_2.ps. You have to reinsert the pages the right way. You need to reverse the order of these pages and that gives you the pages in the first photo above. You then cut that column of pages in half, put one half above the other and go to the second photo. There is a lot of technique involved, the novels feature tends to be better quality as you dont have to cut the pages.

You need the 22nd May 2007 core and binary archives for this as the system has been enhanced as of 22nd May 2007 (today).

gs:lib/pdf2ps.amiga "" gs:examples/tiger.eps ram:tiger.ps
gs:lib/pdf2ps.amiga "" gs:examples/escher.ps ram:escher.ps
gs:lib/pdf2ps.amiga "" gs:examples/annots.pdf ram:annots.ps
c:join ram:tiger.ps ram:escher.ps ram:annots.ps as ram:various.ps
set GSFUNCTION T ; local variables so other shells can do other things.
set GSTHUMBNAIL 3
gs:lib/pdf2ps.amiga "" ram:various.ps ram:thumbnails.ps
unset GSTHUMBNAIL ; remove the settings so other things can be done,
unset GSFUNCTION
gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE -r300 ram:various.ps

Useful Amiga links		www.ann.lu	www.amiga.com	Martin Blom's Linux-x-Amiga cross compilers
www.amiga.org		AmigaWorld.net	x86-AROS boot CD

          __________________
PS ----->|                  |---> print->|-->Turboprint: max 16777216 colours 24 bit
         |   This port of   |            |-->AmigaOS: max 4096 colours 12 bit
PDF ---->| Ghostscript 8.54 |            |-->inbuilt GS drivers (eg Samsung ML-4500)
         |                  |            |-->ijs (ixemul only)
         |                  |
         |                  |---> view->|-->6 Cyber viewers eg WB truecolor 24 bit
         |                  |           |-->6 AGA viewers eg 262144 colour HAM
         |                  |
         |__________________|---> convert->|-->jpeg
                                           |-->png
                                           |-->fax
                                           |-->bmp
                                           |-->PS
                                           |-->PDF
                                           |-->etc!

1. A fairly major fixing of Florian Zeillers GS510 turboprint device to make it fully compliant with GS8 onwards. To maximise the future of this device I split it up into 3 devices in line with other GS devices such as jpeg and png. My own viewers are also split into 3 devices. Florian's original device only understands Turboprint 7, whereas I have fixed it to understand Turboprint 3,4,5,6,7
2. Totally writing from scratch brand new viewers for both graphics cards and AGA. For AGA my work allows you to view PS in HAM8 , and for graphics cards to view PS in 24 bit colour eg on depth 24, 16 or 15 screens. I have written 6 different Cyber viewers and 6 different AGA viewers.
3. Totally written from scratch are 3 methods for printing via AmigaOS printer including 12 bit 4096 colour printing.
4. I fully debugged the printer driver for the Samsung ML-4500 600dpi b/w laser printer. (my own printer), at £75 its a real bargain. This is present as -sDEVICE=samsung_gdi. This driver isnt yet ported to GS854 though is in GS813.

INSTALLATION

A FULL NEW INSTALL IS REQUIRED FOR GS870: YOU CANNOT REUSE GS854, GS850, GS8 or GS813'S INSTALLS

Downloads

• gs870core.lha cross platform part of the program, 15th October 2009
• gsfonts.lha Fonts necessary to run GS.
• gs870noixemul.lha 68020 no-fpu noixemul binary of GPL Ghostscript 8.70, current upload: 15th October 2009, suitable for Morphos
• gs870ixemul.lha 68020 no-fpu ixemul binary of GPL Ghostscript 8.70, alternative to gs870noixemul.lha has a few more features. current upload: 15th October 2009,
• icon_scripts.lha point and click icon script interface to GS80.

Decompressions

STARTUP SUMMARY

This now can be done via the icon script startup, eg by double clicking it. The icon script install needs to be done first which just sets the env variable gs870 to the install directory.

ASSIGNS:

• GS870:
• GS:
• GSFonts:
• gscache:
• Ghostscript: assign for Turboprint PS:

SETTING UP gs: FOR script use

Put in the startup:

This is needed for the AmigaOS scripts in gs:lib and gs:bin to function,

GS870:

GSFonts:

GS870 etc can share fonts with GS850, via:
eg.

gscache:

STACK

USAGE:

• Turboprint usage
• AmigaOS printer usage
• Graphics card viewers (Cyber) usage
• Classic A1200 + A4000 AGA viewer usage
• Viewer usage tips
• Inbuilt Ghostscript printer drivers
• Convert PS and PDF to jpeg
• Further GS870 things
• Everything!
• Help function

setenv whooshzoomstep 1.05
setenv whooshzoomsubstep 1.01

Left-Shift+Up-Arrow	=> speed up zoom by a factor of 1.005 per key press
Left-Shift+Down-Arrow	=> slow down zoom by factor of 1.005
Left-Shift+Right-Arrow	=> speed up keyboard scroll by 1 pixel per key press
Left-Shift+Left-Arrow	=> slow down keyboard scroll by 1 pixel per key press

Right SHIFT		1
CAPSLOCK		2
CONTROL			3
Left ALT		4
Right ALT		5
Left Amiga		6
Right Amiga		7

setenv whooshqualifier 2

setenv whooshbeep 0

c:version gs

setenv whooshquiet 1

set whooshw 1 

set whooshinterleave 0 ; => non interleaved BitMaps

set whooshviewx 100 ; will restrict viewer window 
                    ; to width 100 pixels
set whooshviewy 200 ; will restrict viewer window 
                    ; to height 200 pixels

setenv whooshscreen magic_number

set whooshscreen magic_number 

HELP FUNCTION

GRAPHICS CARD VIEWERS USAGE

24 BIT RGB CYBER WB VIEWER

24 BIT RGB CYBER CUSTOM SCREEN VIEWER

256 SHADES OF GRAY CYBER WB VIEWER

256 SHADES OF GRAY CYBER CUSTOM SCREEN VIEWER

RAPID RENDER 1 BIT B/W CYBER WB VIEWER

RAPID RENDER 1 BIT B/W CYBER CUSTOM SCREEN VIEWER

CLASSIC A1200 + A4000 AGA VIEWER USAGE

• HAM8 Custom screen viewer
• 216 colour Custom screen viewer
• 256 shades of gray AGA custom screen viewer
• Rapid 1 bit b/w AGA custom screen viewer
• Colour WB AGA window viewer
• Rapid render 1 bit b/w WB AGA window viewer

HAM8 CUSTOM SCREEN AGA VIEWER

216 COLOUR CUSTOM SCREEN AGA VIEWER

256 SHADES OF GRAY CUSTOM SCREEN AGA VIEWER

RAPID RENDER RAPID VIEW 1 bit b/w CUSTOM SCREEN AGA VIEWER

COLOUR WB AGA WINDOW VIEWER

RAPID RENDER 1 BIT B/W WB AGA WINDOW VIEWER

THE GS> PROMPT

HOW TO USE THE VIEWER

• Normal Scroll
• Automatic Scrolling
• Naive Zoom in
• Hacked proper Zoom in

NORMAL VIEWER SCROLL

AUTOMATIC VIEWER SCROLL

NAIVE VIEWER ZOOM

HACKED PROPER ZOOM VIEWING

VIEWER USAGE TIPS

INBUILT GHOSTSCRIPT PRINTER DRIVERS

TURBOPRINT USAGE

ICC colour profiles

Background of the problem

Methodology of using ICC colour profile files

ICC program downloads

Speed optimised conversion between ICC profiles

Using colour profiles with GS

Background of the problem

If you take a photo with a digital camera, that is a jpeg. You view that on your monitor as an onscreen image A. Now you print that with your printer on 75g/m2 paper and get a printed image B. You print again on 160g/m2 paper and get a printed image C.

We have 3 images now from the same jpeg: A, B, C

And we have a problem: the colours are different in each image!

Also if we use paper by a different manufacturer we also get different colours. Printer paper is in fact not white but ALWAYS has a tint, as can be proven by holding the paper next to a white screen on a monitor. There is equipment which will measure this tint!

Each image on its own looks kind of correct, but the different images just do not agree on many colours.

If you use a 35mm scanner you get an even worse problem that each brand of film has different biases. The scanner has a fixed interpretation of colours, but a Fuji scan is biassed to green (or blue?) and Kodak to red (IIRC).

Basically each medium and each machine has a different bias.

What is needed is a way to counteract the biasses so that ALL devices and media agree on each colour, at least as long as a colour isnt beyond the limits of the machine eg a monochrome printer just cannot express green but you would want it to agree with a monitor on grey scale images.

ICC colour profiles are THE industry established way to do this and is based on work that goes back to at least 1931. The ICC standard is backed by a huge amount of major companies including Microsoft, Adobe, HP, Polaroid, Eastman Kodak, NEC, etc.

A device such as a monitor, camera, scanner, printer uses its own private coordinates which we will refer to as RGB for the typical case where there are 3 coordinates for each pixel which quantify how much red, green and blue. Without colour profiles RGB is the RGB your monitor uses.

And usually each coordinate will be an 8 bit unsigned integer 0, 1, 2, ... 255. But the same RGB coordinates eg R=50, G=100, B=150 will look different on different devices.

A printer typically has 4 cartridges Cyan, Magenta, Yellow and blacK. CMYK, but the driver typically works with an RGB image, eg the bitmap of a jpeg. The driver then converts the RGB coordinates into CMYK, but we regard the driver as being part of the hardware! Some printers have 6 cartridges but the extra 2 are light magenta and light cyan, which is an optimised form of CMYK.

Thus the device coordinates could be other things than RGB but RGB is the usual, even when the low level hardware eg ink powder is CMYK. I only look here at RGB with 8 bit components as that is already way beyond mainstream printers which are 1 bit per component.

Usually a digital camera and a monitor will agree, but unfortunately other devices dont agree on the same RGB values. And eg a Samsung camera produces different colours from a Sony.

What the ICC colour profile does is measure the absolute colours produced by the device's RGB interpretation, by measuring a set of sample RGB values and then interpolating the measurements for the unmeasured values.

By measuring absolute colours relative to an absolute illumination we can now convert RGB coordinates from one device to another and preserve colours.

One form of absolute measure of colour is CIEXYZ, which uses 3 ABSOLUTE coordinates X, Y and Z. These coordinates correspond to the nerve impulses of the RGB cones of an average observer multiplied by a 3x3 matrix so that one coordinate is the brightness.

Basically the eye is regarded as a device and CIEXYZ maps the device RGB to the eyes coordinates which means CIEXYZ is LITERALLY the colour seen by the eye. The measurement itself is done by machine. Because it models the eye's response, CIEXYZ deals with the problem of "metamerism" where different colours look the same: eg R + G looks like Y.

When you view Y the R and G cones of the eye respond, this means that the perception of colour is not absolute and is ambiguous. Hardware also has its own ambiguity, eg different RGB values can look the same on the monitor or when printed.

digital cameras, jpegs and monitors TEND to use a standardised icc colour profile called sRGB. This is why there tends to be no problem when using these. But once you get more adventurous you run into the problem of colour incoherence between devices. The sRGB profile on Windows XP is stored at somewhere like:

C:\WINDOWS\system32\spool\drivers\color\sRGB.icc

and you will find plenty of other icc colour profiles in the same directory, HOWEVER just one profile is relevant to a particular plan. Use the wrong profile and you have garbage. A profile is NOT some choice for you but is decided by the hardwares biases. ie you cannot just go and use any profile! The above Windows directory can contain a lot of colour profiles, but typically none are relevant to you other than sRGB.icc.

ICC colour profiles are ????.icc or ????.icm, thus you can search for them on another OS if you have an Amiga emulator using c:list from a shell thus:

c:list some_directory all files pat=#?.ic(m|c) lformat=%p%n

With this sRGB profile for instance R=255, G=0, B=0 has XYZ coordinates 0.4124 0.2126 0.0193

if you use a 35mm scanner on Windows this will create an uncompressed tiff file where the bitmap uses the scanners hardware specific RGB coordinates and embeds an icc colour profile which counteracts the biasses of both the scanner and the scanned film brand. ie if you scanned a Fuji and a Kodak film of the same image the profile converts the 2 bitmaps to the same colours as the original scene.

Another way to look at it is that RGB images are in fact palette images, where the RGB coordinates are the palette colour and the ICC colour profile is the palette to what your eyes see.

In the early days computers used fixed palettes, then the A500 used retargettable palettes. Then computers used truecolour and palettes became obsolete. But today palettes are used again, and these are ultrasophisticated palletes. Creating perfect imagery.

OK

Methodology of using ICC colour profile files

Thus to convert images between devices so that the colours agree you need an icc colour profile for each device.

When you buy hardware, search the Windows CD for the hardware for files #?.icc and #?.icm in case they have supplied ready made colour profiles. For scanning 35mm, colour profiles are very expensive and you have to rely on ready made ones. eg if you scan a film from 1950 you can hardly calibrate that today!

For printers there are companies who will create an ICC profile for your printer for 15 pounds. You download say a tiff file with sample colours, print this without colour correction, post it to them and they will email you a colour profile file.

You will need a colour profile for each brand of paper you intend to print with, and each brand of ink in case you decide to use cheaper imitation inks.

I do NOT address here the problem of obtaining the ICC custom profiles, you will have to get those either from the hardware's CD or from profiling companies. Or you can find them on Apples and Windows. In fact I cannot create ICC colour profiles as that is a HARDWARE problem and I only look at software problems. Do a google search for "custom ICC profile" to get your printer software calibrated.

For jpegs and tiffs without profiles, the sRGB.icc profile will usually work. Tiff embeds profiles, but libtiff doesnt interpret the profile in any way, software which views the tiff may or may not utilise the profile. To guarantee the colours look alright you need to manually remap the tiff to the sRGB profile using the programs here.

ICC program downloads

The download of my own programs is icc_programs_fpu_201011190012.lha, icc_programs_68k_nofpu_20101107.lha, and you also need the programs of libtiff libtiff3.8.2.lha. icc_programs_fpu_201011190012.lha can be just decompressed and used without any install. libtiff3.8.2.lha needs to be decompressed and you need to assign tiff: to the directory. If you use Geekgadgets you can decompress it to gg: and you must also assign tiff: to gg:

For Morphos you need the nofpu version.

All the programs when run without args will echo usage info.

Each program dealing with jpegs uses libjpeg and each program dealing with tiffs uses libtiff, and each program dealing with ICC colour profiles uses icclib.

The programs work via my own intermediate simplified bitmap format which I call .bitmap. To work with an image such as jpeg or tiff you need to convert that to a .bitmap file. The .bitmap format is very straightforward: it begins with the string "bitmap", followed by a space char, followed by the bitmap pixel width written in ascii decimal eg 123 or 000123 etc, followed by a space followed by the bitmap pixel height in ascii decimal, followed by a space followed by the rgb bytes.

I have now also implemented a CMYK form of .bitmap's, and my software will automatically process between RGB and CMYK bitmaps. This is necessary for using CMYK ICC profiles and to have a CMYK profile made for a printer.

All my ICC programs will echo usage info if run without args, the usage info does improve with time, so you should occasionally find the usage info from the program itself and not from here.

The ICC programs here may not be redistributed in any way without my permission.

For example if you want to work on a jpeg xyz.jpg, you need to convert it to xyz.bitmap thus:

jpeg_to_bitmap xyz.jpg xyz.bitmap

If you want to work on a tiff file xyz.tif then you convert it to abc.bitmap thus:

tiff_to_bitmap xyz.tif abc.bitmap

if the tiff file has an embedded icc profile this will be output to abc.icc and the program will echo this action. And if the tiff file has dpi info, this will be output to abc.dpi

For instance say you have a 35mm scanner which outputs tiff files with embedded profiles and you want to view the tiff on an sRGB monitor using a jpeg viewer which doesnt deal with colour profiles AND you want to print the image with a printer with colour profile printer.icc

First:

tiff_to_bitmap xyz.tif abc.bitmap

This creates abc.bitmap and abc.icc

Now you need to remap this bitmap with profile abc.icc to sRGB

bitmap_icc_icc_cached abc.bitmap abc.icc abc_sRGB.bitmap sRGB.icc p p cache_directory

cache_directory is a directory initially empty, which gradually fills with cache info. It needs to be on a volume with a lot of free space.

You will need to obtain sRGB.icc from someone with Windows as explained above.

Here the p p args are the "rendering intents", p = perceptual, a = absolute, s = saturation, r = relative, P = absolute perceptual, S = absolute saturation. These are IDENTICAL to the options you see on Windows XP printer drivers!

The best options seem to be p p and r r. Usually you should use p p for everything unless you have a good reason not to!

The first rendering intent is that for converting the input image to XYZ, and the second intent is that for converting the absolute XYZ to the second device.

Its best to use perceptual or relative for everything ie p p or r r.

abc_sRGB.bitmap is now the same bitmap relative to the sRGB colour profile. Thus if you now convert this to jpeg it will view with the correct colours:

bitmap_to_jpeg abc_sRGB.bitmap abc_sRGB.jpg 1

The last arg is a scaling factor which usually is 1. Higher numbers are just to counteract jpeg artefacts. But now I use tiff files instead which dont have artefacts. ie if you set the last arg to 2, it will double each pixel to 2 x 2, and these are then subject to jpeg artefacts.

if you view abc_sRGB.jpg with ANY jpeg viewer it will now have the correct colours, IDENTICAL to the colours you see on Photoshop. In fact I use Photoshop to verify if I have coded correctly! As Photoshop is DEFINITIVE on the ICC idea. ICC is THE Photoshop methodology for commercial imaging.

However had we converted abc.bitmap to abc.jpg instead that would have wrong colours. Often that would look ok, but if you compared it to Photoshop you would realize why you need ICC.

To convert to jpg for viewing you must always convert to sRGB first using sRGB.icc

To convert abc.jpg to the printer's profile we need:

bitmap_icc_icc_cached abc.bitmap abc.icc abc_printer.bitmap printer.icc p p ongoing_cache

abc_printer.bitmap is now the bitmap for the printer's profile.

We can convert this to an lzw compressed tiff file with embedded icc profile printer.icc thus:

bitmap_to_tiff abc_printer.bitmap abc_printer.tif printer.icc

Tiff doesnt change the supplied bitmap in any way, but saves also an optional embedded profile for nonstandard colour interpretation eg scanned 35mm

Alternatively we can convert the sRGB bitmap to a tiff without embedded profile thus:

bitmap_to_tiff abc_sRGB.bitmap abc_sRGB.tif

bitmap_to_tiff has an optional 3rd arg which is the optional .icc file, if there is no .icc file the tiff file will be viewed relative to sRGB, which will produce the wrong colours if the image is in fact relative to some other profile. And you can also give a .dpi file, as output by tiff_to_bitmap.

But whether or not a profile is embedded, the bitmap is IDENTICAL. Programs such as Photoshop will display the tiff via the profile: change the profile and the picture changes but the bitmap is unchanged.

This is done because any change of the bitmap will usually lose information, thus the scanner hardware bitmap remains unchanged. In particular you could change the profile later. This is why the tiff format is very useful for quality image processing.

Now if your printer.icc was calibrated by printing a tiff without colour profile, then in fact if we convert abc_printer.bitmap to tiff without profile it will print with correct colours:

bitmap_to_tiff abc_printer.bitmap abc_printer2.tif

if you view abc_printer2.tif it will look wrong, however it will print correctly with full colour correction

These programs also allow you to say convert jpeg to tiff eg to convert xyz.jpg to xyz.tif

jpeg_to_bitmap xyz.jpg xyz.bitmap
bitmap_to_tiff xyz.bitmap xyz.tif

And you can lzw compress an uncompressed tiff with embedded profile thus:

tiff_to_bitmap xyz_uncompressed.tif xyz_uncompressed.bitmap
bitmap_to_tif xyz_uncompressed.bitmap xyz_compressed.tif xyz_uncompressed.icc LZW

Other attributes such as resolution will be lost, but on Photoshop both images will look identical.

If the tiff file has resolution data:

tiff_to_bitmap xyz.tif xyz.bitmap
bitmap_to_tiff xyz.bitmap xyz.tif xyz.icc xyz.dpi LZW

Note that if you have a profile aware tiff viewer, when you view abc_printer.tif it will in fact have the right colours, subject to the limits of the devices.

The embedded printer.icc profile is used by the viewer to render the image relative to sRGB.

jpegs sometimes have embedded ICC profiles, these dont seem to be dealt with by libjpeg. I have written a program called get_profile in the above download which will extract embedded profiles from jpeg files. You can use this to extract the ICC profile from a jpeg with embedded ICC profile thus:

get_profile infile.jpg out.icc

If there is no embedded profile it will tell you this. Thus you can use it also to determine if a jpeg has an embedded profile.

This now will NOT extract profiles from .tif's but WILL extract large embedded profiles from jpegs. To extract profiles from .tif's use the following command:

tiff_to_bitmap xyz.tif xyz.bitmap db

This will extract JUST the ICC profile if any as xyz.icc, with the last arg, d==.dpi not output, b==.bitmap not output.

Without that arg, all 3 will be output if relevant.

OK

Speed optimised conversion between profiles

The original version used a program called bitmap_icc_icc to colour convert, but this could be extremely slow. The new version is bitmap_icc_icc_cached which is much faster and will cache the conversion data of all profile conversions you use.

NOTE: this optimisation requires 48M of free memory to function. Thus if you just have a 16M machine then you cannot use this. Amiga Forever seems to default to a mere 16M, you need to reconfigure AF to 500M which is tricky to do.

OK

Using colour profiles with GS

The above programs deal with bitmaps directly eg jpegs and tiffs. To deal with PS and PDFs you need to convert these to bitmaps. Now jpegs are a lossy format, thus it is better to convert to tiff.

The tiff programs I have written are compatible with gs -sDEVICE=tiff24nc

For instance if you wanted to print tiger.eps relative to a colour profile printer.icc with a 600dpi printer setting:

gs:bin/gs -sDEVICE=tiff24nc -r600 -dBATCH -dNOPAUSE -sOutputFile=tiger.tif tiger.eps
tiff_to_bitmap tiger.tif tiger.bitmap
bitmap_icc_icc_cached tiger.bitmap sRGB.icc tiger_print.bitmap printer.icc p p ongoing_cache

And now convert tiger_print.bitmap to whatever bitmap format the printing software uses.

In the download there are also some libtiff utilities, including a program to convert tiff to PDF and another to convert tiff to PS as well as BMP etc. Run a prog without args and it will echo usage info. Thus you can convert tiger_print.bitmap to PDF thus:

bitmap_to_tiff tiger_print.bitmap tiger_print.tif
tiff:bin/tiff2pdf -o tiger_print.pdf -u i -x 600 -y 600 tiger_print.tif  

Here the -u i -x 600 -y 600 args mean xres=600dpi and yres=600dpi

If you want to convert many pages to PDF, you need to convert them to PS using tiff2ps, and then concatenate the PS pages, and then use the GS framework to convert that to PDF.

With the programs you can convert say jpeg to PDF, by converting the jpeg to .bitmap, then the .bitmap to .tif, then the .tif to .pdf

tiff:bin contains other useful conversion programs eg to convert between tiff and .bmp .gif and other things.

OK

TURBOPREFS COMMAND LINE

You may of course put eg -sDEVICE=tp1 if you want to do fast low colour printouts,

SETTING UP PS: FOR TURBOPRINT USE

MORPHOS users: CLICK for Turboprint GS510 things: http://www.irseesoft.de/ghostscript (:24.mar.2004.1050pm)

Morphos users: CLICK for extra magic required to make PS: function. :apparently "just drop the gs-handler in L: and place the PS mount file in devs:dosdrivers."

:Note that Turbo GS510 only understands Turboprint 7, whereas in my ports the Turboprint devices understand Turboprint 3,4,5,6,7: required careful surgery, I believe in backward and forward and sideways compatibility! If I didnt you wouldnt be able to use this port eg on Morphos or OS4 or on early A1200's,

Setting up PS: consists of 3 parts: handler + mountlist + assign:

1. The handler: you need to recycle the GS510/l/gs-handler thus:

makedir GS870:bin/l
copy GS510/l/gs-handler GS870:bin/l ; IYSWIM!

2. The mountlist: recycle the GS510 DEVS: mount file, to DEVS: not sure what the mountlist is called,

3. The assign: C. Driscoll tells me that Ghostscript: needs to be assigned in such a way that you get Ghostscript:l/gs-handler, thus you need eg:

assign Ghostscript: GS870:bin  ; startup each time you boot,

The Ghostscript: assign is only relevant to PS:, its not a GS870 thing but a PS: thing. C. Driscoll also says you can if you wish edit the mountlist to say L:gs-handler, however that gs-handler has Ghostscript: and Ghostscript:GS embedded in the code, so even if you edit the mountlist you will continue getting the Ghostscript: requester.

So the path of least resistance seems to be to leave the mountlist unchanged and follow steps 1, 2 and 3!

How to quit the viewer early

The viewer will only quit early if you type control-C in a shell WHEN there is no viewer window present. As you have to act fast to do this, there is a trick way to do it without having to rush:

while the viewer window is open, press space in the shell (or IconX shell) which launched the viewer. Now close the viewer window. Now type control-C in the shell (or IconX) window. Press return and the program should quit.

24 BIT RGB TURBOPRINTING

:all on one line, the -dFirstPage and -dLastPage tricks are only available for pdf docs, not for ps docs. annots.pdf is in GS870:examples/

256 SHADES OF GRAY TURBOPRINTING

Please note: for GS8 you have to use -sDEVICE=tp8g, with GS854 you can use either -sDEVICE=tp8 or -sDEVICE=tp8g

With GS854 the name has been changed to be easier to remember.

:all on one line, the -dFirstPage and -dLastPage tricks are only available for pdf docs, not for ps docs. annots.pdf is in GS870:examples/

RAPID 1 BIT B/W TURBOPRINTING

:all on one line, the -dFirstPage and -dLastPage tricks are only available for pdf docs, not for ps docs. annots.pdf is in GS870:examples/
This produces the fastest render, its good for text only documents. Its also good if the document only has solid regions of black on a white background (no grays or colours).
If the document has lots of delicate colours or gray then use tp24 or tp8

AmigaOS point and click icons

Download icon_scripts.lha, this presents icons for a point and click approach.

The following info is also in the archive.

make sure that your startup has:

assign gs: gs870:

The interface is via the visible icons only, the other scripts are auxiliary and not to be directly called.

double click the "view" icon and you get a requester for what document to view, that is then viewed.

double click convert_to_jpg and you input a ps or pdf document which is then converted to jpg in ram: eg if you select gs:examples/annots.pdf you get ram:annots1.jpg, ram:annots2.jpg ...

double click convert_to_pdf and you select a document to convert to a pdf in ram:

multi_convert_to_pdf allows you to multiselect from the requester which documents to convert. After conversion the documents are moved to the selected completion directory. DONT try this on gs:examples as it will move the examples out! This hasnt been fully tested, so please make a backup or test from ram.

you can customise these scripts to do other things.

they function via c:iconx it is possible you may need c:xicon instead for some systems.

AMIGAOS PRINTER USAGE

• 12 bit 4096 colour AmigaOS printing
• 256 shades of gray AmigaOS printing
• rapid render 1 bit b/w AmigaOS printing

12 BIT 4096 COLOUR AMIGAOS PRINTING

256 SHADES OF GRAY AMIGAOS PRINTING

NOTE: With GS8 you have to use -sDEVICE=whooshg, whereas with GS854 onwards you can use either -sDEVICE=whoosh8 or -sDEVICE=whooshg

RAPID RENDER 1 BIT B/W COLOUR AMIGAOS PRINTING

CONVERT PS AND PDF TO JPEG

It would do this at 100% quality because of the -dJPEGQ=100 switch. If you want 10% quality you use -dJPEGQ=10 instead etc.

NOTE that 100% quality is NOT the same as lossless jpeg as the latter is commercial and discouraged by the opensource community, instead if you want lossless images use -sDEVICE=png which is a free open standard (I hope!).
-sDEVICE=jpeg is useful for interfacing with web-browsers as jpegs can be viewed via browsers.
So you can make a PS page available for a browser by converting it to jpeg via -sDEVICE=jpeg and then linking to this in the html.

General info about the command line: all Ghostscript arguments such as -dJPEGQ are CASE SENSITIVE ie -dJPEGQ=20 is GOOD, but -djpegq=20 is WRONG and -DJPEGQ=20 is WRONG. Also the order of the args MATTERS, Ghostscript processes the arguments left to right, some orderings are good and some are not! The above presentation of arguments is correct and other presentations are correct. This is different from a lot of Unix programs where arguments can be presented in any order.

I find its best to put the device as the first arg and right at the end to put the output file followed by the input files:

gs -sDEVICE=????? ...... -sOutputFile=???? infile1 infile2 infile3

From left to right the args of the jpeg example are:

1. first gs:bin/gs is the path to the Ghostscript binary, on *nix probably just gs ok

2. -sDEVICE=jpeg is the jpeg device ie convert documents to jpeg, for list of devices: gs:bin/gs -h ok

3. -r150 is the resolution in dpi (dots per inch, ie pixels per 2.54cm, computer monitor is approx -r100), ok

4. -dJPEGQ=100 is a device specific argument specific to -sDEVICE=jpeg explained above, ok

5. -dNOPAUSE means Ghostscript shouldnt pause annoyingly between pages, ALWAYS do this ok

6. -dBATCH means Ghostscript should exit on completion, ALWAYS do this ok

7. -sOutputFile=some_path/somefile%d means the output file, ok

8. %d means create an output file for each page substituting %d by the pagenumber. ok

9. And lastly are presented a list of PS or PDF files to convert. ok

Note that this website is about the 68k-AmigaOS Ghostscript binary available from this webpage, however various info will apply to all Ghostscripts. Many things are only applicable to this specific version of Ghostscript, namely things I coded myself. Today most people use 68k-AmigaOS in emulated form, eg for PC's there is a commercial product called "Amiga Forever" which is an Amiga emulator for PCs. Via that people with PCs can use this port. There is also an excellent free Amiga Emulator for PCs called WinUAE but you need to supply the ROM image and system disk images. People also can use the binary here via the AmigaOne (A1) and Morphos on Pegasos which are both PPC versions of AmigaOS with integrated 68k-AmigaOS emulators. There is also the AROS reimplementation of AmigaOS for PCs, I dont know if they have a 68k-emulator yet, I think that is one of their projects. I did a version of the program for AROS some years ago but many features have been implemented since then and I havent done any further builds for AROS.
2006.8.1: someone has pointed out that the original command I gave created a 72dpi jpeg which was a bit low res. So I've modified the shell command above to give the res, here at -r150, you can use any other number eg -r100 or -r300 etc.

USE GHOSTSCRIPT AS A TYPEWRITER!

topic originally from Thursday 8th May 2003 1115pm

For typing with GS you need some language layer otherwise its a real pain, thus use my own language layer: type.ps.

The problem is that GS uses a coordinate system with the wrong origin + wrong axes directions wrong measure etc. Thus to make it user friendly use the above file.

All commands beginning with Upper case initial letter are my own commands, so if you look inside the above file anything beginning with lower case is an inbuilt PS command eg show is the inbuilt PS command for printing text.

Begin by calling gs as usual with the above file as input, eg

gs -sDEVICE=whoosh24 -dNOPAUSE -r30 type.ps

This will take you immediately to the GS> prompt.

Now try this:

GS> (Hello world!)show
GS> (this is a test)show
GS> Newline
GS> 255 255 0 Square
GS> (see a yellow square?)show
GS> 0 255 255 Square 
GS> Newline (:cyan square)show
GS> Newline
GS> /NimbusSanL-Regu Font
GS> (:new font being set)show
GS> 5 Fontsize /NimbusSanL-Regu Font
GS> Newline
GS> (Big 5cm!)show
GS> Newline
GS> 1 Fontsize /NimbusSanL-Regu Font
GS> (smaller font!, see gs8data:fontmap.gs)show
GS> Newline
GS> (for all available fonts)show
GS> Print

You can do this also for any GS device, whenever you enter Print it will print the current stuff to the printer or other device.

gs -sDEVICE=anydevice -dNOPAUSE type.ps

This can also be done from a pre-made file, eg:

gs_000 -sDEVICE=somedevice type.ps

Then at the GS> prompt type:

GS> (typetest) run Where the file typetest contains the above commands, this makes life a lot easier to debug the PS file. You can also add your own language layer to extend type.ps.

You can do all this directly with PS but its a lot of work as eg the units of measurement are 1/72 inch,

Also PS does rgb colours with floating point values between 0 and 1 for each component. type.ps retargets this to the traditional computer 0-255 values!

type.ps keeps track of vertical position on the page, the Newline procedure resets the position to the start of the next line.

By using my type.ps layer file, you have user friendly usage of GS for text using all GS fonts in gs8data:fontmap.gs and any other ps fonts.

Thus you can write a letter with commercial quality printout just armed with GS and type.ps

Handwritten Postscript generally requires debugging eg one line may collide with another or run off the edge. eg the above example had some bugs, now removed!

Also with each page printed everything gets reset, thus my Print procedure reinitializes the page each time, otherwise when you try a second page it will be just blank!

Really using the GS> prompt is just like using the BASIC language on eg a BBC computer of yester-year.

A procedure for automatically doing newlines would be

/Line {show Newline} def,

you could feed this new procedure in at the GS> and immediately start using it.

USE GHOSTSCRIPT AS A CALCULATOR:

gs_000

To multiply eg 12.3 x 13.8:

GS> 12.3 13.8 mul ==

To add use add, likewise use sub, div,

To do (2 + 3)/4:

GS> 2 3 add 4 div ==

GS is a stack machine, if we present it with a number, it pushes it onto the stack. When we present it with an operator eg add it pops the operands from the stack, applies the operator and pushes the answer onto the stack. To pop + view the top thing on the stack you type ==. So eg to add 1 2 3 4 5 we could type:

GS> 1 2 3 4 5 add add add add == If the GS prompt says eg GS> < 4 > that means there are 4 unpopped things on the stack. Its useful for debugging.

FURTHER GS8 THINGS

EVERYTHING!

COMMENTS

• PS vs HTML!
• 3 or 4 ways to print

3 or 4 WAYS TO PRINT

1. Turboprint
   If your printer is supported by Turboprint then this is the recommended path
2. Inbuilt Ghostscript printer drivers.
   My printer Samsung ML-4500 b/w 600dpi laser is supported by neither Turboprint nor AmigaOS. This means the only way to print with it on an Amiga is via Ghostscript, this is actually how this port begun. I had to download the Ghostscript c-source driver from a Linux site, then spend a week or 2 debugging it finally I could print! This is the samsung_gdi driver in the device list.
3. AmigaOS printer driver
   If your printer has an AmigaOS driver (many dont) then this is another method.
4. ijs
   Available in the ixemul recompile which isnt uploaded yet, (needs a lot of explaining how to set things up for ixemul). -sDEVICE=ijs is an impenetrably complicated method. Its clever but usage is near impossible to understand, I've made some 3 attempts to understand it and given up. Anyway this method allows you to download and use external drivers from the internet and use them with GS8. I think Hewlett-Packard are involved with the concept :I think ijs is one of those a-bit-too-clever ideas! If you get too clever with computers you end up with something which is too difficult to use, L-unix anybody??

PS VS HTML

• PS is absolute.
• HTML is relative.

1. 1. HTML render is fast,
2. 2. Links!: HTML is interactive via its links PS is not.

THE AGA BLITTER BUGS PROBLEM

PROBLEMS?

1. Study http://www.whoosh777.com/fix.html, download the latest version of the program if any
2. If the problem persists email me:

THE AGA SetRGB32CM() BUG PROBLEM

ENV VARIABLES REFERENCE

Miscellaneous downloads

When gs encounters an error it tells you the file position, however what you really want is the line number, so there is now a small program to convert file position to line number in the binary download.

Example usage:

gs:bin/pos_to_line examples/tiger.eps 1000

:would tell you the line number of file position 1000 in tiger.eps,

To get usage info type:

gs:bin/pos_to_line

or

gs:bin/pos_to_line ?

gs:bin/pos_to_line examples/tiger.eps 1000 1200

:would print out all text from file position 1000 to 2000 and then tell you the line number of file position 1000 in tiger.eps, eg when I tried it, it does:

/_i currentflat def
/i {dup 0 eq {pop _i} if setflat} bdef
/j /setlinejoin ldef
/J /setlinecap ldef
/M /setmiterlimit ldef
/w /setlinewidth ldef
% path construction operators
/_R {.25 sub round

LINENO = 30

Michael Merkel's GS8GUI

Michael Merkel who was one of the original betatesters for the Turboprint part of the port has written a GUI frontend for the ports of GS I have done.

Its an independent project and this is the URL.

Printing Billboards

This requires the 11th May 2007 binary archive or later.

The current core download as of today (17th July 2005) now contains pdf2ps.amiga.

Lets say you want to convert gs:examples/annots.pdf page 2 to 3 x magnification billboard:

Here is how you would do it just to view the parts. To actually print the frames you need to edit gs:bin/view1 and uncomment eg the turboprint command: a row by row column of frames will then be generated by your printer starting with the lowest row and working left to right. You then cut the right + top edges of each frame and glue consecutive frames together. In the "billboard" command below, the first argument is args in "" for GS: we filter out just page 2 here, the next arg is the document, then is the magnification factor: here its 3, then a script file which will be generated (output) ram:script0, then a temporary filename prefix here hd:temp, scratch files hd:temp#? will be generated by the mechanism, then a script file you supply which will view/print the resulting PS files: gs:bin/view1 (ready made one), then the horizontal overlap factor: here its 4 meaning each consecutive horizontal page overlaps with 1/4 of its predecssor. Lastly the vertical overlap factor here 8: vertically frames overlap by 1/8.

:if there are gaps between consecutive frames reduce these 2 parameters till consecutive frames match with absolute precision: should be pixel perfect.

If you run gs:bin/billboard without args it will give you usage info, x0 and y0 define the overlap factors of 1/x0 and 1/y0.

Note that if you dont filter out one page via -dFirstPage and -dLastPage you will get a billboard for every page of the document using a square mile of paper: BEWARE!

(A)
delete hd:temp#?
gs:bin/billboard "-dFirstPage=2 -dLastPage=2" gs:examples/annots.pdf 3 ram:script0 hd:temp gs:bin/view1 4 8
; :all on one line,
; ie without paths its:
;; billboard "-dFirstPage=2 -dLastPage=2" annots.pdf 3 script0 temp gs:bin/view1 4 8
execute ram:script0
In gs:bin/view1 you can uncomment a line to print the billboard via Turboprint. You can also comment out the line that deletes the images after printing.
You can use this system to generate huge photograph images from an a4 printer: combining the resulting a4 sub-images will be quite a lot of effort.

Printing Novels

This requires the 11th May 2007 binary archive or later.

This puts 2 PDF document pages per physical page side in such a way that when you print on both sides you can column up the pages, fold in half and obtain the correctly numbered pages of a novel. For example a 9 page document is prints as:
(1)[ 2 : . ]
(3)[ 4 : 9 ]
(5)[ 6 : 7 ](8)

As with pamphlets you can use the novel feature several times and then combine these into a tome.

Example: say you want to put pages 90 to 210 of doc.pdf into a novel.

This system ONLY functions for pdf's. To do this with a PS document you need to convert it to PDF first via GS:lib/ps2pdf.amiga which is Ghostscript's PDF distiller script.

Here is how you now convert pages 90 to 210 of doc.pdf to 2 x 1 x 2 novel. You need a temporary file prefix eg hd:temp or ram:temp (if you have lots of memory). The temp file prefix hd:temp, 90 and 210 are then entered into the following commands. WARNING: all files with prefix hd:temp will be deleted at the start!

(A)
delete hd:temp#?
gs:bin/novel doc.pdf 90 210 hd:temp
execute ram:script1
execute ram:script2
gs -sDEVICE=???? ?????? hd:temp_0.ps
;WAIT FOR PAPER TO COOL DOWN, EG WAVE PAPER IN THE AIR.
;NOW REINSERT PRINTOUT,
;IF IN FORWARDS ORDER UNCOMMENT THIS:
;gs -sDEVICE=???? ?????? hd:temp_1.ps
;IF IN REVERSE ORDER UNCOMMENT THIS:
;gs -sDEVICE=???? ?????? hd:temp_2.ps
;if unsure whether hd:temp_1.ps or hd:temp_2.ps then view the first
;page of say hd:temp_1.ps with the -sDEVICE=whoosh24 viewer and
;see if it matches the first page to be printed. If it matches now
;print hd:temp_1.ps else print hd:temp_2.ps. Stick a note on the
;printer saying which option to use.

If you run gs:bin/novel with too few args eg no args it will give you usage info.

The above commands will generate hd:temp_0.ps, hd:temp_1.ps and hd:temp_2.ps these are 3 PS files. First print hd:temp_0.ps with GS. This generates the upper faces of the novel. Once printed you have to re-insert these into the printer. If these are in forwards order now print hd:temp_1.ps and if in reverse order print hd:temp_2.ps. Make sure the pages arent upside down!

This will print the lower faces on the same pages.

IMPORTANT: make sure to wait till the pages have cooled down before reinserting. Otherwise the printer will lose its grip and the printout could be wrongly positioned.

Experiment with say 20 pages of a document. If you only want one of forwards or reverse ordering of the second print then comment out the appropriate line of gs:bin/script3n

My printer has 2 output schemes which create opposite out-tray orderings of the print.

When both sides are printed you may need to do a final reversing of page order. I probably need to improve the scheme sometime so that a final reversing isnt necessary.

If you arent sure, instead of printing view temp_0.ps, temp_1.ps and temp_2.ps with whoosh24 and note the page numbering, then figure out from this how to do the reinsertion.

You can create commercial quality booklets with this scheme.

Printing Pamphlets and Books

This requires the 11th May 2007 binary archive or later.

This puts 4 pages per page side in such a way that if you cut the pages in half horizontally, place one half column above/below the other and remove one possibly blank page at the top, staple together you get a pamphlet with correctly sequenced page numbers.

For example the first printout of a 30 page document will have the following page number layout:
2
10 23

Later in phase 2 of the procedure under the 2 will be 1, under the 10 9, under 23 24, and nothing under the empty subframe. ("Notes" candidate!)

The second printout will look like:
4 29
12 21

Later under 4 + 29 + 12 + 21 will be 3 + 30 + 11 + 22 respectively. You dont want to have to do this by hand as its really painful!

BTW I've been thinking about this idea ever since GS8, but couldnt see how to do it then when looking at something Christoph Poelzl asked I suddenly made a breakthrough.

There is quite a bit of puzzle element to the procedure, eg when I first tried it one side was upside down, then when I got it the right way round I was looking at the wrong side of the page, things only make sense if you look at the correct side!

You can also publish your own book by dividing the book into pamphlets and then stitching the pamphlets together into a book.

The pamphlet scheme has some sort of physical limit for convenient browsing, to create a tome you need lots of pamphlets. I think the professionals stitch with string and dont use staples. Staples are for amateurs like me. The problem with staples is though they look bright and shiny today in 10 years time they will have corroded. That shiny lustre will have flaked off causing a health hazard.

Example: say you want to put pages 90 to 210 of doc.pdf into a pamphlet. You can determine the page count of a document via the number GS -sDEVICE=whoosh24 says when you view the document. You can make a tome by splitting the document into several pamphlets.

This system ONLY functions for pdf's. To do this with a PS document you need to convert it to PDF first via GS:lib/ps2pdf.amiga which is Ghostscript's PDF distiller script.

Here is how you now convert pages 90 to 210 of doc.pdf to 2 x 2 x 2 pamphlet. You need a temporary file prefix eg hd:temp or ram:temp if you have enough ram. The temp file prefix hd:temp and 90 and 210 are then entered into the following commands. WARNING: all files with prefix hd:temp will be deleted at the start!

(A)
delete hd:temp#?
gs:bin/pamphlet doc.pdf 90 210 hd:temp
execute ram:script1
execute ram:script2
gs -sDEVICE=???? ?????? hd:temp_0.ps
;WAIT FOR PAPER TO COOL DOWN, EG WAVE PAPER IN THE AIR.
;NOW REINSERT PRINTOUT.
;IF IN FORWARDS ORDER UNCOMMENT THIS:
;gs -sDEVICE=???? ?????? hd:temp_1.ps
;IF IN REVERSE ORDER UNCOMMENT THIS:
;gs -sDEVICE=???? ?????? hd:temp_2.ps
;if unsure whether hd:temp_1.ps or hd:temp_2.ps then view the first
;page of say hd:temp_1.ps with the -sDEVICE=whoosh24 viewer and
;see if it matches the first page to be printed. If it matches now
;print hd:temp_1.ps else print hd:temp_2.ps. Stick a note on the
;printer saying which option to use.

If you run gs:bin/pamphlet with too few args eg no args it will give you usage info.

The above commands will generate hd:temp_0.ps hd:temp_1.ps and hd:temp_2.ps these are 3 PS files. First print hd:temp_0.ps with GS. This generates the upper faces of the pamphlet. Once printed you have to re-insert these into the printer. If the reinsertion is in forwards order you now print hd:temp_1.ps and if in reverse order hd:temp_2.ps.

The first time you try this everything will go wrong.

The second print prints the lower faces on the same pages.

IMPORTANT: make sure to wait till the pages have cooled down before reinserting. Otherwise the printer will lose its grip and the printout could be wrongly positioned.

If you comment out one of the 2 commands in gs:bin/script3 you can make only one of the 2 possibilities of forwards versus reverse happen.

My printer has 2 output schemes which create opposite out-tray orderings of the print: I move a lever up or down, if the lever is down the pages leave the printer to the floor (unlimited capacity) and when its up they accumulate within the printer. :both schemes are stacks but one is a face down stack and the other a face up stack.

This scheme is complicated but thats because the problem itself is geometrically quite complicated.

Creating pamphlets is very satisfying.

2 sided printout of Books

This requires the 11th May 2007 binary archive or later.

This takes an input PDF document doc.pdf, and outputs 3 PS documents hd:temp_0.ps, hd:temp_1.ps and hd:temp_2.ps.

The odd pages are in hd:temp_0.ps and the even pages plus maybe a parity synchronising blank page in hd:temp_1.ps as well as in hd:temp_2.ps. hd:temp_1.ps contains the even pages in ascending order and hd:temp_2.ps in descending order.

So you print hd:temp_0.ps then reinsert the pages and print either hd:temp_1.ps or hd:temp_2.ps to get a 2 sided printout.

(You can convert these 2 PS files to PDF via GS:lib/ps2pdf.amiga, :this script is self documenting)

Example: say you want to print pages 90 to 210 of doc.pdf thus, Note you can find the number of pages in a PDF document by running GS -sDEVICE=whoosh24 and noting the number at the start.

This system ONLY functions for pdf's. To do this with a PS document you need to convert it to PDF first via GS:lib/ps2pdf.amiga which is Ghostscript's PDF distiller script.

Here is how you now convert pages 90 to 210 of doc.pdf to 2 x 1 x 1 book format. You will need to supply the first and last pages 90 and 210 as shown in the example below. You also need a temporary file prefix eg hd:temp. (I use ram:temp). The temp file prefix hd:temp and 90 and 210 are then entered into the following commands. WARNING: all files with prefix hd:temp will be deleted at the start!

(A)
delete hd:temp#?
gs:bin/book doc.pdf 90 210 hd:temp
execute ram:script1
execute ram:script2
gs -sDEVICE=???? ?????? hd:temp_0.ps
;WAIT FOR PAPER TO COOL DOWN, EG WAVE PAPER IN THE AIR.
;ALSO GOOD IDEA TO FLATTEN THE PAPER.
;NOW REINSERT PRINTOUT, IF IN FORWARDS ORDER UNCOMMENT THIS:
;gs -sDEVICE=???? ?????? hd:temp_1.ps
;IF IN REVERSE ORDER UNCOMMENT THIS:
;gs -sDEVICE=???? ?????? hd:temp_2.ps
;if unsure whether hd:temp_1.ps or hd:temp_2.ps then view the first
;page of say hd:temp_1.ps with the -sDEVICE=whoosh24 viewer and
;see if it matches the first page to be printed. If it matches now
;print hd:temp_1.ps else print hd:temp_2.ps. Stick a note on the
;printer saying which option to use.

If you run gs:bin/book with too few args eg no args it will give you usage info.

The above commands will generate hd:temp_0.ps, hd:temp_1.ps and hd:temp_2.ps these are 3 PS files. First print hd:temp_0.ps with GS. This generates the odd numbered pages. Once printed you have to re-insert these into the printer, if they are in forwards order print hd:temp_1.ps and if in reverse order print hd:temp_2.ps

According to the number of pages there may be 1 synchronising blank page.

IMPORTANT: make sure to wait till the pages have cooled down before reinserting. Otherwise the printer will lose its grip and the printout could be wrongly positioned.

If you know you only need either forwards or reverse order you can comment out the appropriate line in gs:bin/script3b

Printing and viewing thumbnails

This requires the 22nd July 2005 binary or later.

Say you want to view/print doc.pdf in 4 x 4 thumbnails:
set GSFUNCTION T
set GSTHUMBNAIL 4
gs:lib/pdf2ps.amiga "" doc.pdf doc_thumbnails.ps
unset GSTHUMBNAIL
unset GSFUNCTION

This will generate doc_thumbnails.ps with 4 x 4 thumbnails, ie 16 pages per page.
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16

Pages 17, 18 etc will be thumbnailed to the next page etc, and you can have any number of pages eg 3 or 101.

eg you can store the 6 pages of GS:examples/annots.pdf on one 3 x 3 thumbnail page!

Printing and viewing in landscape

This requires the 15th July 2005 binary or later. Usage has changed since 14th July.

In response to a request by Christoph Poelzl I've customised GS854 onwards so it now can print in landscape.

You need the current binary.

To print/view in landscape say annots.pdf,
set GSFUNCTION L
pdf2ps.amiga "" annots.pdf annots_landscape.ps
unset GSFUNCTION

This creates a landscape PS file eg annots_landscape.ps eg view it at low res:
gs -sDEVICE=whoosh24 -r50 -dBATCH -dNOPAUSE annots_landscape.ps

Converting problematic True Type fonts to PS fonts

WIARD Thomas (thomas dot wiard at radiofrance dot com) contacted me with the following problem which is about embedding problematic true type fonts in a document as PS fonts.

Various true type fonts (Trebuchet TimesNewRoman CourierNew and Arial) converted to PS fonts via ttf2pt13 from aminet and embedded in a document via Wordworth7 were not rendering "-". The "-" was being rendered with the default undefined symbol which is a square.

We established that the problem was not with GS.

Using nonembedded fonts rendered the - but didnt look the way intended.

The fonts needed to be converted to PS to use on Wordworth7 and to be embedded to preserve the look of the document eg when used with GS.

All attempts to do this were not rendering the "-" for all the fonts, some attempts rendered the "-" for some of the fonts.

Eventually the following method was found by WIARD Thomas which is entirely via AmigaOS:

1) convert the .TTF font with 'ttf2pt1 -a -b' command into the .PFB file format
2) launch TypeSmith 2.5 software
3) import the .PFB file
4) at the question : "the font has a custom encoding. Load with TypeSmith encoding ?" reply YES
5) export the .PFB file
6) choose the parameter : encoding type - TypeSmith encoding

and then the .PFB file is correct !

Converting PDF and PS to ascii

Someone asked me how you do this, I've converted the ps2ascii script to AmigaOS for this. You use GS:lib/ps2ascii_amiga which is in the core download since 26th June 2005

Example:

Converting ascii to PS

You need A2ps.

I use it to print ascii on my printer.

Deblurring pdf and ps photos

To deblur a photo in a ps or pdf file, you first need to increase the blurring a few times via b p b p ... and then use the deblur function s a few times eg s p s p.

The deblur function used directly isnt so good it works better by first increasing the blur factor. If you increase the blurring first and then deblur as explained above the effect is quite impressive.

Double sided printing

How do you print on both sides of the pages?

Here is the brute force way! Its only for pdf documents.

Say the device is tp24 and you want to print doc.pdf, you need to run 2 scripts:

First find out how many pages eg via:

gs -sDEVICE=whoosh24 doc.pdf

gs will say how many pages, exit via control-C to the shell.

Then run:

When this completes, take the column of pages, re-enter them into the printer thinking very carefully about the geometry of what you are doing.

Depending on how your printer outputs things you now either print pages 2,4,6,... or pages 100, 98, 96, .... 2 by the same technique.

There are 4 things that can go wrong: upside down, wrong numbering, wrong synch, wrong side (double superposed),

My printer can output 2 different ways so both possibilities can apply.

When I use this technique I use a c program to generate the script for me. The program is gs_scripter. You run it thus:

gs_scripter 100 1


This will create a script file ram:script which goes from the first number to the second number in steps of 2:

somescript 100
somescript 98
somescript 96
somescript 94
...

You then create somescript to call gs to print out exactly one page by the -dFirstPage=10 -dLastPage=10 trick. This trick is only available for pdf. To do this for ps you have to convert the ps doc to pdf via gs and then use this trick.

If anyone knows a better way to do this please contact me.

Simplified usage: requester scripts and aliases

As typical usage of GS requires 3 standard arguments and a filepath it makes sense to do this via a script or to use an alias.

Put the following line in s:shell-startup

alias g "gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE []"

Now to run gs all you do is from the shell press g space tab on King-con, This gives you a requester where you enter the document via the mouse. And gs now views that document!

g space tab click click click enter

You can also enter the above alias in the shell directly:

alias g "gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE []"
g ram:xyz.pdf

will then view ram:xyz.pdf. The square brackets is how aliases do arguments.

That is much faster than a gui, you just press 3 keys, g, space and then tab. Make sure to install King-Con. I've been told that the VNC shell can also do this but I never managed that myself.

You can also go via a shell script. If you give this an icon you can run it from the WB. To do file requesters in shell scripts you need eg:

c:requestfile title "enter PS or PDF file to view:" > env:tempname

and to access the filename $tempname eg:

gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE "$tempname"

These 2 tricks (c:requestfile and $tempname) are essential for shell scripts to communicate with file requesters.

For a script you need to set the stack or it can malfunction, eg the following script does things correctly:

stack 500000
c:requestfile title "enter PS or PDF file to view:"  > env:tempname
gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE "$tempname"

Viewing page 1 of annots.pdf

Over the months a number of people have emailed me saying that page 1 of examples/annots.pdf is missing some colour boxes which are supposed to be there.

:someone has explained to me how to view/print annots.pdf correctly: you need -dPrinted=false eg:

GS:bin/gs -sDEVICE=whoosh24 -dPrinted=false GS854:examples/annots.pdf

GS:bin/gs -sDEVICE=tp24 -dPrinted=false GS854:examples/annots.pdf

-dPrinted=false only affects PDF files and is some technical PDF thing,

GS now has this info within the annots.pdf document!

USER CONTRIBUTIONS

C.Driscoll has sent me an Arexx script for converting FinalWriter open documents to PDF

Here is further FW script he sent me: FW2PDF.lha (updated for Wide orientation by Cary Driscoll, 26th June 2005).

Ernest Unrau contacted me and send some Adobe Illustrator scripts he has made which he finds useful: Unrau.lha.

CREDITS

Jan-Erik Karlsson

for explaining how to use Geekgadgets in particular gcc2.95.3-4

Paul Sadlik

for feedback on Turboprint and the Cyber viewers

Tony Mulvihill

for feedback that Turboprinting was functioning correctly

Daniel Rangel

for verifying that the Cyber custom screen viewers were functioning

Richard de Rivaz

for various feedback earlier on

Jörgen Danielsson

for being the first tester

C Driscoll

for explaining about PS:

various other people are mentioned on the website

============== OTHER PORTS ===============================

I have now done various new ports:

68k hosted cross compiler gcc-3.3.1 for x86-AROS, a port to 68k AmigaOS host of the existing Linux hosted AROS gcc-3.3.1. I have successfully used this to port GS854 to x86-AROS.

Currently I am working on GS854 in a low key way: it is essentially a completed project although there will always be ongoing small improvements

Now that I have a faster machine (2.6GHz Intel Celeron WinUAE OS3.9) I am attempting other ports. Trying to gradually move my work to x86-AROS. My system is now based on WinUAE which I think is better than a real A1200 in most respects.

I am also working on various nonport projects, 68k but should recompile to any CPU. My policy is generally to not talk or announce stuff until its done.

I find that porting is a very inefficient way of doing things: in the time it takes me to fix some obscure port problem I could have written a major subsystem of my own work. All my 68k work only uses OS3.0, this way I maximise my potential user base to everything including AROS,

Another annoying thing about cross-platform ports is the Unix API, the AmigaOS API is a real joy in comparison. Armed with the RKMs you can breeze through major work in a way which is just not possible via the cross platform path. There is also something inherently fun and pragmatic about 68k AmigaOS. My A500's ROM was 1/2 Meg, a "small" version of Linux is 50meg (compressed?): the Amiga was never ashamed to be small,

Fun OSes lead to fun programs,

POSIX THREADS FOR 68k Amigas PORTED, includes some example threaded programs to try out on 68k Amigas. (updated: wed.25.feb.2004.night),

NEW ANNOUNCEMENT: STAND-ALONE AMIGA 68020 IXEMUL RPM4.0 HAS BEEN PORTED (this is the full port *EXCEPT* no database support, "rpm --install xyz.rpm" is fully functioning which is the useful thing. reliable version of ixemul.library included in the download)

Crucial File updates

New idea showing file updates that *must* be downloaded,

Sun.28.mar.2004.1145pm: TP_PS_files.lha for Morphos people,

OK!!

tiff_to_bitmap photo.tif photo.bitmap 
	; this also outputs photo.icc the embedded profile (if any)
bitmap_icc_icc photo.bitmap photo.icc photo_printer.bitmap printer.icc p p
	; this will create photo_printer.bitmap, p = perceptual rendering intent
bitmap_to_jpeg photo_printer.bitmap photo_printer.jpg 1
	; creates photo_printer.jpg
print_jpeg photo_printer.jpg

	; this will print with the correct colours on the Rey 160g paper

tiff_to_bitmap photo.tif photo.bitmap 
	; this also outputs photo.icc the embedded profile
bitmap_icc_icc photo.bitmap photo.icc photo_monitor.bitmap sRGB.icc p p
	; this will create photo_monitor.bitmap, p = perceptual rendering intent
bitmap_to_jpeg photo_monitor.bitmap photo_monitor.jpg 1
	; creates photo_monitor.jpg
some_jpeg_viewer photo_monitor.jpg

	; this will view with the correct colours on a typical monitor

start_file temp
	; creates temporary file temp
bitmap_icc_icc temp sRGB.icc monitor_to_printer_cache printer.icc p p
	; creates cached conversion, could take 20 minutes on WinUAE

delete temp

jpeg_to_bitmap photo1.jpg temp.bitmap
bitmap_cached temp.bitmap temp_printer.bitmap monitor_to_printer_cache
	; creates temp_printer.bitmap, EXTREMELY fast on WinUAE, eg 7 seconds.
bitmap_to_jpeg temp_printer.bitmap temp_printer.jpg 1
print_jpeg temp_printer.jpg
	; first photo is printed

jpeg_to_bitmap photo2.jpg temp.bitmap
bitmap_cached temp.bitmap temp_printer.bitmap monitor_to_printer_cache
bitmap_to_jpeg temp_printer.bitmap temp_printer.jpg 1
print_jpeg temp_printer.jpg
	; second photo is printed

....

jpeg_to_bitmap photo10.jpg temp.bitmap
bitmap_cached temp.bitmap temp_printer.bitmap monitor_to_printer_cache
bitmap_to_jpeg temp_printer.bitmap temp_printer.jpg 1
print_jpeg temp_printer.jpg
	; tenth photo is printed


delete temp.bitmap temp_printer.bitmap temp_printer.jpg
	; remove temporary files

   alc1900 alc2000 alc4000 alc4100 alc8500 alc8600 alc9100 ap3250 appledmp
   atx23 atx24 atx38 bit bitcmyk bitrgb bj10e bj10v bj10vh bj200 bjc600
   bjc800 bjc880j bjccmyk bjccolor bjcgray bjcmono bmp16 bmp16m bmp256
   bmp32b bmpgray bmpmono bmpsep1 bmpsep8 cdeskjet cdj1600 cdj500 cdj550
   cdj670 cdj850 cdj880 cdj890 cdj970 cdjcolor cdjmono cdnj500 cfax chp2200
   cljet5 cljet5c cljet5pr coslw2p coslwxl cp50 declj250 deskjet devicen
   dj505j djet500 djet500c dl2100 dnj650c epl2050 epl2050p epl2120 epl2500
   epl2750 epl5800 epl5900 epl6100 epl6200 eplcolor eplmono eps9high eps9mid
   epson epsonc epswrite escp escpage faxg3 faxg32d faxg4 fmlbp fmpr fs600
   gdi hl1240 hl1250 hl7x0 hpdj1120c hpdj310 hpdj320 hpdj340 hpdj400 hpdj500
   hpdj500c hpdj510 hpdj520 hpdj540 hpdj550c hpdj560c hpdj600 hpdj660c
   hpdj670c hpdj680c hpdj690c hpdj850c hpdj855c hpdj870c hpdj890c hpdjplus
   hpdjportable ibmpro ijs imagen iwhi iwlo iwlq jetp3852 jj100 jpeg
   jpeggray la50 la70 la75 la75plus laserjet lbp310 lbp320 lbp8 lex2050
   lex3200 lex5700 lex7000 lips2p lips3 lips4 lips4v lj250 lj3100sw lj4dith
   lj4dithp lj5gray lj5mono ljet2p ljet3 ljet3d ljet4 ljet4d ljet4pjl
   ljetplus ln03 lp1800 lp1900 lp2000 lp2200 lp2400 lp2500 lp2563 lp3000c
   lp7500 lp7700 lp7900 lp8000 lp8000c lp8100 lp8200c lp8300c lp8300f
   lp8400f lp8500c lp8600 lp8600f lp8700 lp8800c lp8900 lp9000b lp9000c
   lp9100 lp9200b lp9200c lp9300 lp9400 lp9500c lp9600 lp9600s lp9800c
   lps4500 lps6500 lq850 lx5000 lxm3200 lxm5700m m8510 md1xMono md2k md50Eco
   md50Mono md5k mj500c mj6000c mj700v2c mj8000c ml600 necp6 npdl nullpage
   oce9050 oki182 oki4w okiibm paintjet pbm pbmraw pcl3 pcx16 pcx24b pcx256
   pcxcmyk pcxgray pcxmono pdfwrite pgm pgmraw pgnm pgnmraw photoex picty180
   pj pjetxl pjxl pjxl300 pkm pkmraw pksm pksmraw png16 png16m png256 png48
   pngalpha pnggray pngmono pnm pnmraw ppm ppmraw pr1000 pr1000_4 pr150
   pr201 ps2write psdcmyk psdrgb psgray psmono psrgb pswrite pxlcolor
   pxlmono r4081 rinkj rpdl samsung_gdi samsunggdi sj48 spotcmyk st800
   stcolor svg t4693d2 t4693d4 t4693d8 tek4696 tiff12nc tiff24nc tiff32nc
   tiffcrle tiffg3 tiffg32d tiffg4 tiffgray tifflzw tiffpack tiffsep tp1
   tp24 tp8 tp8g txtwrite uniprint whoosh1 whoosh24 whoosh8 whooshg xcf xes

bj10v	 Canon BubbleJet BJ10v/BJ15v (japanese)
bj10vh	 Canon BubbleJet BJ10v/BJ15v/BJ35v (japanese)
bjc880j	 Canon Color BubbleJet BJC-880J (japanese)
       bjccolor Canon BJC-250, BJC-250ex, BJC-1000, ... Floyd-Steinberg
                dithering
       bjccmyk  Canon BJC-250, BJC-250ex, BJC-1000, ... GhostScript
         standard dithering
       bjcgray  Canon BJC-250, BJC-250ex, BJC-1000, ... Grayscale mode
       bjcmono  Canon BJC-250, BJC-250ex, BJC-1000, ... Monochrome mode
       cdj1600  HP DeskJet 1600
       cdj670   HP DeskJet 670
       cdj850   HP DeskJet 850
       cdj880   HP DeskJet 880
       cdj890   HP DeskJet 890
       cdj970   HP DeskJet 970
cdnj500  HP DesignJet 500
chp2200  HP Business Inkjet 2200
       dl2100   DEC DL2100
dmprt	 dot matrix printer driver for Ghostscript (it can use 
	 dviprt printer config files, japanese)
escpage  Epson ESC/Page driver for Ghostscript (japanese)
fmpr	 Fujitsu FMPR (japanese)
fmlbp	 Fujitsu FMLBP2xx Page Printer (japanese)
gdi	 Samsung's old driver for their SmartGDI laser printers:
	 ML-4500, ML-2xx, ML-1xxx, ML-5080, ML-6040, ... and
	 Lexmark E210, same as "samsunggdi"
       hl1240   Brother HL-1240 and compatible 600-dpi PCL-5 printers
       hl1250   Brother HL-1250 and compatible 1200x600-dpi PCL-5 printers
hpdj1120c HP DeskJet 1120 ("pcl3" driver)
hpdj310  HP DeskJet 310 ("pcl3" driver)
hpdj320  HP DeskJet 320 ("pcl3" driver)
hpdj340  HP DeskJet 340 ("pcl3" driver)
hpdj400  HP DeskJet 400 ("pcl3" driver)
hpdj500  HP DeskJet 500 ("pcl3" driver)
hpdj500c HP DeskJet 500c ("pcl3" driver)
hpdj510  HP DeskJet 510 ("pcl3" driver)
hpdj520  HP DeskJet 520 ("pcl3" driver)
hpdj540  HP DeskJet 540 ("pcl3" driver)
hpdj550c HP DeskJet 550c ("pcl3" driver)
hpdj560c HP DeskJet 560c ("pcl3" driver)
hpdj600  HP DeskJet 600 ("pcl3" driver)
hpdj660c HP DeskJet 660c ("pcl3" driver)
hpdj670c HP DeskJet 670c ("pcl3" driver)
hpdj680c HP DeskJet 680c ("pcl3" driver)
hpdj690c HP DeskJet 690c ("pcl3" driver)
hpdj850c HP DeskJet 850c ("pcl3" driver)
hpdj855c HP DeskJet 855c ("pcl3" driver)
hpdj870c HP DeskJet 870c ("pcl3" driver)
hpdj890c HP DeskJet 890c ("pcl3" driver)
hpdjplus HP DeskJet Plus ("pcl3" driver)
hpdjportable HP DeskJet Portable ("pcl3" driver)
jj100    Star JJ-100 (japanese)
       la50     DEC LA50
       la70     DEC LA70
       la75     DEC LA75
       la75plus DEC LA75+
lbp310	 Canon LBP-310 (japanese)
lbp320	 Canon LBP-320 Pro/LBP-350 (japanese)
       lex2050  Lexmark 2050
       lex3200  Lexmark 3200
       lex5700  Lexmark 5700
       lex7000  Lexmark 7000, Lexmark IJ900, Compaq A900, Z51
lips2p	 Canon LIPS-II+ (japanese)
lips4v	 Canon LIPS IV vector mode driver
lips4	 Canon LIPS IV raster mode driver
       ln03     DEC LN03
lx5000   Lexmark 5000
       lxm3200  Lexmark 3200, Z31, Z12
md1xMono Alps MD-1000/1300/1500 (monochrome mode, japanese)
md2k	 Alps MD-2000/2010/4000/1000/1300/1500
md50Mono Alps MD-5000, Oki DP-5000 (monochrome mode, japanese)
md50Eco	 Alps MD-5000, Oki DP-5000 (economy mode, japanese)
md5k	 Alps MD-5000, Oki DP-5000
mj500c	 Epson Stylus Color IIs, 200, 1500 (japanese)
mj700v2c Epson Stylus, Epson MachJet (japanese)
mj6000c	 Epson Stylus Color 400, 800, 1520 (japanese)
mj8000c	 Epson Stylus Color 3000 (japanese)
ml600	 Okidata Microline 600CL/620CL (japanese)
npdl     NEC MultiWriter, PC-PR1000/2000 (japanese)
       oki4w    Okidata OkiPage 4w+
opvp	 Gluecode for Vector Driver API
pcl3     PCL-3(+) printers: Many, especially older HP inkjets,
	 non-HP inkjets as Sharp AJ, Xerox DocuPrint, ...
pr1000	 NEC PC-PR 1000 (japanese)
pr1000_4 NEC PC-PR 1000/4 (japanese)
pr150	 NEC PC-PR 150 (japanese)
pr201	 NEC PC-PR 201 (japanese)
rpdl     Ricoh RPDL I/II/III/IV drver for Ghostscript (japanese)
samsunggdi Samsung's old driver for their SmartGDI laser printers:
	 ML-4500, ML-2xx, ML-1xxx, ML-5080, ML-6040, ... and
	 Lexmark E210, same as "gdi"
       xes      Xerox XES (2700, 3700, 4045, etc.)

mag16	 MAG file format (from Red Hat's japanese driver pack)
mag256	 MAG file format (from Red Hat's japanese driver pack)

uniprint/: Some additional .upp files

United States 37  15.9% 
Germany 36  15.5% 
United Kingdom 20  8.6% 
Israel 18  7.8% 
Canada 15  6.5% 
Poland 15  6.5% 
France 14  6.0% 
Italy 13  5.6% 
Russian Federation 9  3.9% 
Switzerland 9  3.9%
Ireland 7  3.0% 
Spain 6  2.6% 
Australia 5  2.2% 
Sweden 5  2.2% 
Netherlands 4  1.7% 
Norway 3  1.3% 

version gs:bin/gs

|<-
->|

7 8 9
4   6
1 2 3 

stack 500000

; NOTE: pattern used here as acceptpattern doesnt function on all systems

RequestFile title "multiselect documents to view" pattern "#?.(eps|ps)" multiselect drawer gs:examples > env:temp

multisplit env:temp ram:script gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE -r100

execute ram:script

displaybeep

stack 1000000

Beginning work on Ghostscript 8.60 for 68k-AmigaOS

If I run into problems I will attempt an earlier version instead.

First thing I am doing is moving the project development to flash disk, instead of hard disk. That allows me to develop from any machine.

930am: making gradual progress. WinUAE seems much slower when a flash drive is connected even if you dont access the flash drive, so I probably will revert to HD again.

330pm: I have made reasonable progress since 930am but a lot left to do.

8pm: I think I can probably complete the port of GS860 by Monday, there have been problems but it has been less problematic than gs854. To speed up the development I think I will only do a 68020-nofpu build. Doing 2 builds just delays everything. 68020-nofpu builds run on all systems and are fine. I have been making various improvements to the build which should speed up future builds. I have also been enhancing the install.

I now keep the project on a flash drive but build in ram: which was the coding paradigm used with the A500: copy everything to ram: and work from there.

============= 27th Feb 2008 ================

I am planning to begin on the next port of GS on Friday, I will take tomorrow off from computing and begin on Friday. I have completed what I was working on with the language. Just making a few improvements.

I have written some batch conversion point and click icon scripts, one script converts an entire directory to another directory and then moves the converted files. The other script allows you to multiselect files to convert from a file requester. After conversion the documents are moved to another directory.

Someone has been trying these on their system but there is a problem with one of the scripts, trying to resolve that. On my system the scripts function fine. Everything done just with AmigaOS scripts, no MUI or AREXX used. I will upload them once the problems are resolved.

============= 22nd Feb 2008 ================

I have had some feedback on the point and click icons. AmigaOS icon scripts are a very powerful paradigm. They allow you to use the Workbench as a GUI, where the buttons are icons.

I was asked about output to know when a script is complete.

I have written a small utility for this, I thought there was a program in C: for this but it appears to be only available at the OS level.

At the end of a script if you put displaybeep this will produce a sound when the script is complete. You can select alternative sounds via "Sys:Prefs/Sound". All the program does is to call the intuition.library OS call DisplayBeep(). You can run it via the icon also: displaybeep.info. The source for it is displaybeep.c

That way you dont need to keep looking at the computer waiting for it to complete and can get on with other things. An interrupt concept!

One other thing: you can move an icon to the Workbench also just by moving it with the mouse instead of selecting "Leave out" from the WB menu. The fastest way to return it to the directory is via the WB menu "Put away". If you forget which directory the icon is from, you can find that by left clicking the icon and then right selecting Icons--information from the Workbench menu. That gives the full path.

Because there are so many alternative usage paradigms sometimes some of them get forgotten. Often the most effective way to do things is with AmigaOS scripts, c:list is especially good.

Also with the point and click icons, there are TWO stacks, one is the stack you see in Icons--information, and the other is the stack within the script. I think the Icons--information stack is the stack for c:iconx the default tool, and the stack within the scripts is for gs.

The easiest way to customise the icon scripts is to copy them to ram by moving the icon with the mouse. Then rename via the menu: Icons--Rename and then customise the script: left click the script icon then press left-shift down and simultaneously double click the icon of a text editor eg Sys:Tools/Memacs. If you left click the text editor icon first then left shift double click the script icon that also functions. At the end move the new customised icon back to the directory.

Copying the icon via Workbench menu Icons--copy doesnt function on 68k-OS3.9 if the filename is long: overflow problem. If the filename is short then its ok and you then select rename.

Next port likely to begin in February (2008)

Things are progressing much faster now with my language and compiler project, as a result I have drastically improved the estimated timeline for the compiler project. It was the previous phase of work which took much longer than expected.

I want to complete the compiler subtopic I am working on just now which relates to some tricky implementation problems, have at least one day of holiday from ALL computing and then will begin working on the next Ghostscript port.

Some complicating factors: I may be away from the internet while working on the port which could delay making the work available.

I cannot guarantee to succeed at the port, it is a port attempt.

Fortunately I have WinUAE on a laptop so I can take the project with me.

============= 19th Feb 2008 ================

I have completed an initial version of a major component of my compiler project. I have been working towards this since mid November 2007. It is one of the most difficult subprojects of the work I am doing. This is now running fine on 68k-AmigaOS, the initial compiler is a 68k-AmigaOS hosted cross compiler.

A lot of cool features of the new language are already functioning correctly. If I give the compiler example programs it processes them detecting many errors. But there is no code generation yet.

This should bring forward the timeline for working on Ghostscript.

start in February: 30% probable.

start in Feb or March: 80% probable.

I now have 2 computers on my desk with UAE, a laptop and my tower system with a HUGE landscape a3 size monitor!

The monitor is 1680 x 1050, but I use it at a mere 1024 x 768 as that is the highest res that Memacs accepts. They should do a 68k-AmigaOS 3.10 and resolve some of the annoying bugs and make it UAE compatible. I think a LOT of people would buy 68k-AmigaOS 3.10.

H and P where are you?

============= 13th Feb 2008 ================

I have enhanced the point and click icons:

The viewer script now views to fill the width of the Workbench. That is the optimal way to read a document as you only need to scroll downwards.

The convert_to_jpg now converts with maximum quality.

I have also given the directory an icon to make it easier to try out.

You can customise the start directory of the view icon, the current icon starts at gs854:examples but you can change that to wherever you want the viewer to look for documents.

If you single click any of the icons and from the Workbench menu via the right mouse button select "Icons--Leave out" then the icon appears directly on the Workbench. You can then directly double click the icon when you want to view without going via directories. This is a standard AmigaOS paradigm, which anyone who had an A1200 or earlier will know.

The point and click icons are several standard ideas combined to create a very convenient reconfigurable interface.

This is the new download.

============= 10th Feb 2008 ================

I have created some AmigaOS icons for a point and click approach, eg an icon "view" where you double click, select document and it views. An icon "convert_to_jpg" where you select a document and it is converted to jpegs in ram:. And an icon "convert_to_pdf" where you select a PS document to convert to pdf in ram:

For convert_to_pdf, you will need

assign c: gs854:bin add

in the startup,

This assign is now part of the startup assigns instructions

The download and documentation are here.

============= 3rd Feb 2008 ================

Further to 27th Jan, March is starting to look more likely.

I am starting to make better progress now with my language coding, some of the problems had been very tricky eg dealing with circular type definitions eg the equivalent of:

struct a { struct b b ; struct c c ; } ;
struct b { struct a a ; struct c c ; } ;
struct c { struct b b ; struct a a ; } ;

struct x { struct y *y ; struct x *x ; } ;
struct y { struct x x ; struct y *y ; } ;

struct z { struct z a ; struct z b ; } ;

Here x, y are ok but a, b, c, z arent. All are circularly defined, it takes some work in software to determine well-definition the problem is that to evaluate a you recurse to evaluating b and c, but b recurses back to a: the problem is that a is in the middle of being evaluated. In a way it is a meta level problem.

Because of the better progress it looks like I can bring the timeline for the GS work sooner.

New probabilities:

Begin in March: 60 percent probable.

Begin in Feb: 30 percent probable.

Begin in Jan: 0 percent probable.

Sometimes I get asked about putting zoom buttons on the viewer. The reason I havent done that is because it is MUCH FASTER to use the keyboard. On the Amiga when you click a window it becomes the ACTIVE window and it OWNS the keyboard. Any key you press on the keyboard goes to that window. That gives you more than 50 HARDWARE buttons.

If you look at the keyboard you will see 4 arrow buttons, you can hit one of those VERY FAST, but to move the mouse to a screen button is very time consuming first you move the mouse near the button then it takes some effort to manoeuvre the mouse to the exact place.

Now to the right of the arrow keys you will see:

789
456
123

Those allow you to move very fast around an image in 8 directions and 5 recentres. That means the arrow keys and digits give you 13 HARDWARE controls of the viewers. There are further keys also which are shown when the viewer starts. To put all those on screen will eat up A LOT OF SPACE. A lot of CLUTTER.

The hand is much faster than the mouse. And if you press a wrong key a window appears to tell you the keyboard controls.

I want all the space to be for the page being viewed, I dont want some HUGE control panel and a tiny image. Instead the controls ARE ALL HARDWARE LEVEL, keyboard and mouse. No onscreen controls which MAXIMISES the viewspace. This is a design principle.

I have some financial software and it has 2 ways for moving a share to a portfolio: either the menu or a keyboard shortcut. The keyboard is almost instant but the menu is nerve grating. But it has been known since the earliest home computers that the keyboard is the best way to control a computer.

With the image itself there are no scroll gadgets, MUCH MORE DIRECT scrolling by clicking and dragging the image. Scroll gadgets eat up screen space and are inconvenient as you have to move 2 gadgets, first you move y then you move x. Click and drag is the most direct way you move BOTH x and y directly.

Today all the Windows programs are starting to use this same concept, but I implemented that in 2003. Even Google Earth uses this idea where you click and drag the planet. I think Java now has this concept built into their design.

But via AmigaOS my viewers give you a super efficient implementation of the mechanism. Just move the mouse to anywhere on the image. Press the left button down and move the mouse without releasing the button and the image will move with the mouse. Release the left button when the image is where you want. This phenomenon is called "click and drag", which means moving the mouse with the left button pressed. AmigaOS uses the idea for moving an icon to a directory. That is called "drag and drop". Click and drag, drag and drop. Some of the PC programs show a hand which grabs the image, but some dont change the image. Not changing the image is better as the tip of the mouse defines where the mouse is.

Personally I want speed and efficiency and not pretty gimmicks, XP programs go OTT with gratuitous imagery eg reflections etc!

The viewers use more of a game paradigm, when you play a computer game you use the mouse or joystick directly, it would be silly to press buttons in a game eg to press a left button to move left! My idea was you play with the image directly. Its a question of paradigm, 3 different paradigms: keyboard, gadgets, menus. Some people have touch screens more efficient than the mouse. I think the arrow keys and 1,2,3,4,5,6,7,8,9 controls are unforgettable. The text window at the start reminds you of all the controls.

I have just bought a huge 22 inch TFT, 1680 x 1050. Less than half the price of my 1024 x 768 monitor from years ago. I thought my laptop 1280 x 800 was big, but this is hugely bigger. I set WinUAE to this res, and tried the viewers. I wasnt sure what would happen! In fact it was alright, 47cm x 30cm view. At 500 dpi there wasnt enough memory for the zoom facility. You can get even bigger monitors but they are very expensive. Java on XP runs into efficiency problems with such a big size. A cool thing about huge screens is you can have lots of windows in full view simultaneously. Looking at webpages at 1680 x 1050 is really cool.

Someone requested that I allow the caller to set the position of the viewer. He is working on some unusual meta level ideas connecting up different programs simultaneously. That is on my todo list.

============= 27th Jan 2008 ================

Further to the timeline given on 7th Nov 2007, I will probably start attempting the next port in March or April 2008 keeping to the given timeline. I havent got too much done this month. The more precise timeline is that I will BEGIN the work very probably in March or April and will allocate AT LEAST 3 weeks. Provided the work is progressing I would go beyond 3 weeks if necessary. This next port is going to be more difficult than earlier ones.

If I make plenty of progress with my language project in February then I will start in March, but I cannot guarantee that. It is possible but is a problem mainly of motivation.

Begin by 30th April: 98 percent probable.

Begin by 24th March: 40 percent probable.

Begin by 21st February: 10 percent probable.

Begin by 31st January: 0.5 percent probable.

The realistically optimistic start point will be approx 24th March 2008 But there is no guarantee at all of that. Anyway March would be an improvement of the timeline by 1 month. The pessimistic start point would be approx 21st April 2008. OTOH February is just about within the realms of possibility but unlikely.

============= 20th November 2007 =================

Someone emailed me about a topic I wrote about from 2003! I had completely forgotten about it and it is something worth trying out so I have reinstated it here.

It is about using GS as a typewriter, where you directly enter text interactively, either to the GS viewer window or to a printer.

You need to download type.ps and then an example usage is:

gs -sDEVICE=whoosh24 -r30 -dNOPAUSE type.ps
GS> Newline
GS> (Hello world!)show
GS> 255 255 0 Square
GS> 255 0 0 Square
GS> Newline
GS> 0 0 255 Square
GS> 0 255 0 Square
GS> Print
GS> quit

For the full explanation see here.

You should be able to print directly to Turboprint the same way eg:

gs -sDEVICE=tp24 -dNOPAUSE type.ps

GS> Newline
GS> (Hello printer!)show
GS> Newline
GS> 255 0 0 Square
GS> 255 255 0 Square
GS> 0 0 255 Square
GS> Print
GS> quit

Dont give any res as that is set at Turboprefs, for the viewer you need to give a lower res otherwise it wont all be visible. The fontsize and font can be changed, see the explanation on that.

============= 7th November 2007 =================

To be definite I think I will attempt the next port of Ghostscript within the first 4 months of 2008. I will reduce that timeline if I can.

I recently decided to shelve implementing C/C++ and instead develop my own language. This is proving a good decision as I am progressing much quicker. So I may be able to work on Ghostscript sooner than previously thought. I will continue to implement C at some future point probably AFTER the OS is complete.

The change of plan is because I realised that implementing C++ will probably take 4 x as long as developing and implementing a new language AND I had no plans to use C++ just to implement C++. I will continue the implementation of C eventually as I need that for meta reasons. Anyway its all to do with time: going via my own language will buy me a lot of time. I dont want my various projects to take a second longer than necessary.

The problem with things like C++ is that you can get drawn into them and implement them just because its a challenge. which is what was happening. But the challenge for me is the OS, which I began in early 2006 so it is almost 2 years of work now and I have achieved a huge amount of progress eg I have completed a 64 bit x86 multiprocessor kernel and am progressing towards my own 64 bit compiler of my own language for that. The language is now mostly designed and I am beginning the second major phase of implementation work today. (I am implementing it before the design is complete as language design always goes on forever, eg C is still being worked on today)

I always prefer to work on new ideas, C is from 1978 and C++ I think is 1985, 22 years ago. They are still working on the design of C today 29 years from the original version!

============= 30th October 2007 =================

When I reach an appropriate completion point with my various projects I will attempt a new port of 68k-AmigaOS Ghostscript. My aim is to complete my various projects within 2008, I dont know for sure I can but that is the wish.

I think a new Ghostscript port attempt will be in 2008, as I have just November left this year for programming. They have been making too many changes to GS recently, so I will probably attempt the earliest stable version after 854.

This is a transition problem, the next version will probably be less recent in time. The version after that should be more recent.

Although I am developing my own projects I will continue supporting 68k-AmigaOS. Generally speaking I like pioneering works, eg the Amiga 500 and old C. I like things created out of necessity also like OS3.0. The bad guys have won but the early stuff is always the best. OS 1.2 kix linux.

AFAIAC GS854 gives me all I need, but I will continue beyond that,

Were it not for all the changes I would attempt the most recent stable version, but there are problems ahead so I need to be conservative.

No idea what is happening in the amiga scene now, last I heard Acer had bought up Gateway (I never liked Gateway). Big fish eats medium sized fish. Anyway I write this update on MicroEMACS V2.1 on WinUAE 68k-AmigaOS 3.9 on a rather cool dual core laptop (not as fast as my tower).

============= 16th September 2007 =================

Someone emailed me saying QNX realtime is now opensource. I should point out some theory: a realtime OS is one where ALL OS actions are time-guaranteed. Each and every thing you can do in a realtime OS has a time guarantee. eg if you write a script you can guarantee that it will complete say in 0.5 seconds.

But time guarantees can only be done by limiting EVERYTHING. You have to limit the number of tasks, limit the number of files, limit the sizes of files etc. A realtime OS will typically use fixed size tables for all OS resources. That is the only robust way to timeguarantee things. This has 2 advantages: the OS is much simpler to implement and much faster. But there is a MAJOR DISADVANTAGE: EVERYTHING IS LIMITED. You may be able to reconfigure the limits but high limits will be very wasteful of resources and will lead to wasteful guarantees. eg if you limit to 100 tasks and there is 1G then you have to preallocate 10M per task. That way a task will start really quickly as the limited memory it needs is already there waiting. But it limits the memory per task to 10M. Now 10M is enough for most things, but once in a blue moon a program wants 500M.

The time guarantee for say a script is calculated by adding the time guarantees for each step, and multiplying by say the size of a loop etc. But that can only be done if you limit the size of a loop.

So an OS such as AmigaOS or Unix where NOTHING is limited is much more sophisticated but there is no timeguarantee. It is vastly more flexible but not quite as fast. Usually realtime OS's are for safety critical use eg factories, nuclear power plants, etc where you need to guarantee response time to an emergency.

The net effect is that a realtime OS reacts superfast ie it reacts in realtime, it reacts immediately to problems. But that is done by keeping everything small, ie cheating. To the untrained eye it can look very impressive.

When commercial wares go free that usually means abandonware, I suspect Linux are eating into QNX's customer base and going opensource is a last ditch attempt out. Todays machines being so much faster I think realtime is less relevant. Safety critical things are probably better via human operators, who keep an eye on things and press a red button. You dont need realtime, you can just set up a dedicated mechanism for each safety critical thing. eg setup a temperature controlled power off switch. That is much more robust than going through an OS. NEVER RELY ON COMPUTERS! A fuse is an excellent example of a realtime mechanism which doesnt use computers. The fuse reacts immediately to excess current.

BTW AMD CPUs have a disclaimer that they mustnt be used for safety critical things. So strictly speaking you cannot use AMD for realtime.

I think realtime isnt much use to AmigaOS, the only way forwards for AmigaOS is to create a brand new system like I am doing with my own OS and then to host the classic system above that. integrating the classic system is a bad idea as it will constrain the new system. Hosting itself is a special form of integration, but it avoids constraints. But this means the classic system is orthogonal to the host system. Which means you may as well host the classic system above ANY system. But then are you moving forwards? The answer is yes if the new system furthers the successful ideas of the old system. But to create a new system you dont need to go via Amiga.

My own OS project is my own response to the systems I have used: AmigaOS, Unix and Windows XP. Working on my own OS I am getting major work done, I am realising everything I ever wanted to do in computing. I have already completed more things than I can count, and it is all geared to the newest x86 PCs you see in the shops including ironically the Gateway ones. So it is the longest run of success I have ever achieved. The day I bought an x86 machine my luck changed from lose-lose to win-win. I am not denying what the Amiga is but am doing what I want to do. I dont know where the Amiga is going or why but I accept AmigaOS up to and including 68k-AmigaOS 3.9. Up to 3.9 it all makes sense. Some people like and want the things they are doing. It really depends on your frame of reference. If they are doing what you want then you should support their work.

============= 5th September 2007 =================

Someone emailed saying the photos on this page are too big AFA the time it takes. However I need them like that for reasons of psychology as it is the Microsoft philosophy of pushing everything to the limit unnecessarily.

If you are on dialup, ALWAYS switch off picture loading as that eats up a lot of time even if the pictures are small. I know that both IBrowse and AWeb allow pictures to be switched off. Trying this just now on IBrowse, I selected from the menu:

Preferences -- image loading -- none

And this webpage loaded literally in 2 seconds on slow broadband, with no pictures just unfilled rectangles for where the pictures should be.

As pictures can be switched off on both the main Amiga browsers I will leave them as they are. As mentioned above if you are on dialup you will save a lot of time and money by switching off pictures altogether. On some websites on some buttons the button action is written IN the image. For this situation just load the individual button image individually:

With IBrowse it is done thus: move the mouse above the picture, then press right mouse button and select "Load image". That individual picture is loaded.

If you have configured to a different language then reconfigure temporarily to english for the above actions.

============= 30th July 2007 =================

The next version of GS looks like it will be tricky, they are making a lot of changes attempting to unify GS with Linux. GS is thus getting full endorsement from Linux which will probably be a good thing as long as they dont make too many changes.

I will work on that further in the future, as before it will be for 68k-AmigaOS.

If you use Michael Merkel's GUI for GS854 email him and say which variant of AmigaOS you use so he gets an idea of what the user base is.

For 68k-GS854 the user base is about 1300 people, half of whom use the 68020-nofpu build and half use the 68020-fpu build.

I hope someone does UAE for my own OS eventually that way we can use this port from there. My OS will supply a full 64 bit x86 virtual machine, so it will be ideal both for UAE and for hosted x86 AmigaOS. That virtual machine is already implemented but no API yet and no graphics, various functionality not implemented but it does function already eg the videos on the other webpage. The text there is to a non virtual shared 1980 screen. The most difficult part of the problem is already done.

I am thinking of implementing C++ instead of C for the next phase of my compiler project. The compiler would then compile BOTH C and C++. The preprocessor is already implemented 68k-AmigaOS hosted, and I will begin the C++ compiler as soon as the current OS subproject has stabilised, again initially 68k-AmigaOS hosted.

I found that Geekgadgets C++ does in fact function, g++, however eg try-catch doesnt function.

============= 17th July 2007 =================

Michael Merkel's redone external GUI for GS854 is here. Contact him for any feedback as that is his project.

I should point out that Unix/Linux people wont like my OS project either as I am also trying to go beyond where Unix reached. Unix hasnt changed much since the 1970s and Linux is merely an unofficial version of Unix.

The reason AmigaOS is still popular is because external projects modernised it: cybergraphics modernised the obsolete interleaved bitmaps to modern gfx cards and Turboprint modernised the printing. Those 2 projects allowed AmigaOS to continue to outdo Windows and Linux. And MUI modernised the windowing. MUI is 10 years ahead of XP. My GS854 viewers in fact dont use MUI but use low level AmigaOS gfx and intuition functionality. Geekgadgets modernised the development side by catching up with Unix. External projects have also kept the Amiga compatible with PC hardware eg USB. Amiga didnt do that, external people did.

My OS project is just modernisation completely externally, AmigaOS itself was a challenge to Apple, Unix and PCs of that time. AmigaOS is a bit like the concorde aircraft, a very modern idea: supersonic superfast airtravel between europe and the US but they didnt further the idea. Now some aeroplane company could create a new supersonic aircraft. But to continue with concorde is to be stuck with 1970s constraints. The hovercraft is another example. Nobody stopped concorde from being continued, they have only themselves to blame. Now the helicopter invention was continued and is a major success story.

I want to make a career from programming and that wont happen with AmigaOS. I need a user base which is 10000 x as big as AmigaOS's current user base. Amiga just are NOT going to deliver that user base: they COULD by going x86 but they WONT! Its too late anyway as I already have a 64 bit multiprocessor pre emptive kernel. I am creating a system sufficiently ambitious to be worth programming for, the way the A500 was.

I think PPC itself is highly influenced by MIPS, almost identical asm, according to wiki MIPS was 1985 and PPC 1991. So similar that gcc's PPC is a customisation of gcc's MIPS. eg MIPS has 32 registers r0 to r31 and r0 is hardwired to 0. MIPS does the instruction after a branch. The original MIPS had 32 bit instructions with 3 registers. Is it a coincidence that PPC does all these things? x86 is much better for moving from 32 bit to 64 bit as little endian memory extends fields leftwards, whereas big endian extends fields rightwards which is the wrong direction.

============= 4th July 2007 =================

Michael Merkel has been enhancing his GUI, not completely sure what his plan is.

At the top of the webpage I mention about my OS project, I have almost got 64 bit x86 multiprocessor pre-emptive multitasking functioning. I know some people wont like what I am doing, but the ideas that Amiga started MUST be continued and brought to x86. The current Amiga variants official and unofficial are just NOT challenging Windows. The Amiga is the most asynchronous OS I have used, its windowing architecture is much better than Linux and XP.

The thing is the classic Amiga was for the 68000 in 1986 and we are 21 years later. Vista is geared to 64 bit multiprocessor x86 machines eg my laptop here is Vista "capable" and has a dual 64 bit cpu the AMD Turion X2. The Amiga architecture even now outdoes Linux and XP but it really needs to be totally redone in order to fully eclipse Windows.

With this microkernel I am completing, a completely modern AmigaOS COULD be done. Now I cannot do that myself as AmigaOS is proprietory, but if someone wanted to they can do that above my system. I am making this system according to my own ideas on things. The only way to modernise AmigaOS is to do something equivalent to what I have done. What I am doing is inspired by the best of both AmigaOS and Unix. All developers agree that the perfect world is somewhere in between the Amiga and Unix. The problem with SOME of the current Amiga projects is they are just copying Linux on everything. That is NOT the answer. Linux is just a revamped 1970's architecture.

The Amiga is the most usable and the most programmable OS ever. But Unix is probably the most sophisticated OS ever, Unix is from around 1978 and C was invented in order to do Unix. The problem with Unix is it is so unusable. Geekgadgets on AmigaOS is essentially an emulation layer of Unix hence "ixemul" ie Unix emulation. I do a lot of things with Geekgadgets which in a way is itself something in between Unix and AmigaOS.

The problem is the Amiga user base have an almost religious belief in the Amiga when in fact the interesting thing about the Amiga is not the specifics but the philosophy of the machine. It is like different countries make fighter planes but all fighter planes are the same philosophy. It is the concepts and philosophy which need to continue not necessarily the product. The problem with Windows is it looks like an Amiga but is the exact opposite philosophy: the Amiga empowers whereas Windows is a disempowerment philosophy. If I make enough money with my OS I think I will buy up AmigaOS and have it modernised to x86.

According to my webstats there are about 1300 users of my GS854 port. That confirms the theory that there are a few thousand people in the scene. Now if I look at February 1994's Amiga Format magazine their ABC (Audit Bureau of Circulation) says 140299 readers jan to jun 1993. I have heard it said that about 2 million A1200's got sold. So the Amiga 1200 despite all its problems was probably 100 to 1000 times as big a scene. The Amiga ideas should be reaching a much wider audience. And the people in charge IGNORE the majority of users who DEMAND x86. Well I am implementing EVERYTHING I have heard requested in forums. If you want to make a career in computing you need to support projects which listen to the users and create systems worth investing time on and aim for a large user base. The Amiga is a company which has been bought up by another company Gateway and you need to explain to me why Gateway dont have A1's in their shops! In fact my OS will run on the Gateway 64 bit x86 PCs I see in the supermarket. (I am not criticising them but just pointing out a contradiction).

It will probably be more than a year before my project completes, I hope to complete before the end of 2009. But the microkernel is ALMOST complete and I could sell that if I wanted.

Two videos are here a video of multiprocessor multitasking on a 2-cpu system and on a 1-cpu system. On a 1-cpu system it is the same as uniprocessor multitasking. Read the info to understand the video better as multiprocessor multitasking is quite different. You can tell how many cpus you have by looking carefully at the text output of the demo. It has taken me 1.5 years to reach this point and the code will run on up to 256 cpus: x86 is limited to a maximum of 256 cpus. It is completely my own design and it is 100% asm.

Someone told me I wont win any Oscars for those videos!

I think we have to stop thinking in terms of brand names but in terms of developers. If you keep the brand name but completely change the developers then it is a completely different project. Things may get better or worse or different. Examples of things getting better was components of AmigaOS being redone in C from BCPL and asm. You can judge a project by seeing what users say in forums. If most users are disappointed or angry then it is a bad project.

Progress comes from new projects starting out of frustration with existing projects. Sometimes people will remove popular features and a new project may try to reintroduce the features. It is the developers that matter not the brand name. Amiga's OS really is Sassenrath who created exec. But Sassenrath left the scene a long time ago and today is involved with REBOL (IIRC).

Note that XP was completely inadequate for 64 bit multiprocessors which is why there is a brand new version of Windows: Vista. In fact 64 bit x86 was designed by AMD according to Microsofts wishlist. Most XP users dont want to switch because XP is mature and they have invested in a lot of apps. XP is comparable to OS3.9. So even something as recent as XP cannot cope with the Gateway PCs you see in the supermarket.

I had the good fortune of starting my project a year before Vista was released. But compelling reasons for going x86 were known 2 years ago. AmigaOS users have been demanding x86 for at least 4 years if not 6, go read amiga.org which is the most barometric of the forums. Apple also I think have changed drastically a number of times. To go beyond OS3.9 AmigaOS has to change drastically. My OS is the required change and has the advantage of escaping all the contractual trickery. Gateway are basically sitting on the rights to AmigaOS. Which is why the Amiga is turning into a VW-enthusiast computer.

I remember some Amiga magazine celebrating Gateways purchase of the Amiga. That magazine doesnt exist today! For backwards compatibility there are 2 paths, use external emulation eg UAE for 68k binaries OR have a hosted native classic AmigaOS so programs can be ported. Integrated emulation is a BAD idea as it integrates all the problems. WinUAE is proven to be the best backwards compatibility path.

I have so many indispensible programs on the Amiga that I will probably be using 68k-AmigaOS 3.9 for at least another 5 years. example programs other than GS!: PGPGoesMUI, YAM, Gui-FTP, Memacs. I use all 4 almost daily. I also have numerous utilities of my own, sometimes I create temporary utilities: I write a utility to do something very specific and discard it afterwards. I use the Amiga where it is better than the alternatives, I dont use it for some retro reason. The Amiga user experience is much better than Linux or XP.

============= 11th-12th June 2007 =================

Mathias has completed the GUI work he was doing, Michael Merkel is enhancing that and merging it with his original GS8GUI work. It is called GSGUI now to avoid referencing version numbers, possibly it may get renamed further.

The code looks good, I havent tried Michael's enhancements yet.

============= 5th June 2007 =================

I think Mathias is currently working on the GUI.

Someone emailed about the screenshots taking long to render, however if you use IBrowse or Internet Explorer the text part of this webpage is rendered first then the images are gradually rendered. So you can use the webpage fully before the images are rendered.

I need to have those images for presentational reasons, I now go for maximum use of technology which is the Microsoft idea. I urge anyone who uses the internet to get broadband. you can switch off rendering on IBrowse via the menu sequence: (preferences)(image loading)(none). Individual images can then be loaded by right clicking on the image rectangle and selecting (load image).

If you use dialup you should do ALL WEBSURFING WITH IMAGE LOADING SWITCHED OFF, as all images cost time and money. Images are only if you use broadband. If a button has the writing on the button then load that image individually.

The irony is that broadband is much cheaper than dial up, broadband here is about 20 quid a month, which is about 66 pence per day ie about 1 euro. That is 24 hour access and 8x the speed of dialup. So if it takes you 20 minutes to download a file with dialup at 1.5p per minute that costs you 30p. But with the broadband it will take 2.5 minutes and cost you 0.115p. 20 minutes + 30p versus 2.5 minutes + 0.115p. In fact you can get it cheaper and faster than that but you need a BT phone line.

To switch off images on Internet Explorer menu deselect: (tools)(internet options)(advanced)(Multimedia)(Show pictures). To display an individual image right click on the image and select (show picture).

Tip: if you use computers always reconfigure to the US + english eg www.google.us is better than www.google.co.uk as it has the highest volume of traffic. If you go to www.google.com that always redirects to the local google which you want to avoid. Localisation isolates.

============= 26th May 2007 =================

Mathias PARNAUDEAU is currently doing a C version of Michael Merkel's GS8GUI, he can be contacted at: mathias dot p at wanadoo dot fr, (x dot y at z represents x.y@z).

I will make some changes to the program useful for that, some technical improvements.

============= 22nd May 2007 =================

Jinxes and gremlins! I decided to download and install directly GS854 and create a pamphlet from that. Ran into many problems, so the upload wasnt quite synchronised with the setup I have here. Each problem I resolved another would manifest. Eventually the pamphlet created.

I think the problem is now resolved, so you need to download and decompress the core and binary archives again. eg I found that the core archive didnt have the amiga specific scripts. I have improved the pamphlets, books, novels and billboards features so that now all scripts are called via "execute" and not directly as running scripts directly on WinUAE tends to malfunction as it keeps losing the script s flag from files.

Anyway there are photos now near the top of the webpage of the pamphlets feature. Strictly speaking it is not a pamphlet but an A6 booklet created from A4 prints with 4 pages on each side.

If you run into any problems at all with any of the features email me as it is too time consuming for me to test out absolutely everything.

Someone emailed me about viewer speed, the viewers currently use a resolution of 126dpi, which is higher than necessary so you can speed the viewers up considerably by changing the res. to 100dpi which is the res of a high res TFT: 1280pixels/13inches==98.5dpi. That will speed the viewers up by 59%, using 72dpi will make the viewers 3x as fast.

A lot of people will have fast machines eg I use 300dpi for the viewers all the time but you need plenty of memory and speed for that. To speed up printing use lower resolutions, most printers have several resolutions the lower ones are for faster printing. There is a tradeoff between time and quality.

Each computer is different, each printer is different, each document is different, each processing of the document is different, so there are many problems that emerge. Speed can be one problem, getting a faster computer wont necessarily make any difference as the problem ultimately is the printer as that is physical with ink, printers are literally manufacturing equipment. This project has generally tried to deal with the problems I have encountered using GS.

I found I incorrectly said the pamphlets are A5 documents in fact they are A6, that is now corrected. pamphlets=A6, novels=A5, Books=A4.

============= 13th May 2007 =================

I have uploaded a further photo, this time of the landscape feature. That feature is mainly for printing documents which are done the wrong way. It is a PS level rotation of 90° and NOT a graphic rotation. I havent implemented a graphic rotation as documents arent meant to be rotated: a document should be correct as-is. Rotation is a printer problem. If you really want to rotate a page it is better just to print the page and then rotate the A4 page with your hands, or make a paper aeroplane.

With any software project there is a danger of digression where you start implementing things which really should be done in a different project: the thing to do is to precisely define the project and avoid things outside of the definition. Good definition is essential for an effective project. I have digressed a bit with this project but I try to keep the digression under control.

The definition of this project is really to make stable versions of AFPL Ghostscript available on 68k-AmigaOS 3.x with quality viewing and printing. With the focus now on systems with gfx cards and lots of memory. Furthermore to deal with the problems encountered with downloaded documents.

eg in the above photos you will see there is about 330 + 8 MB free in a 512MB system, so the viewer is utilising about 174MB for the bitmaps. As you can see I am using an indulgent 300dpi res which is low res laser printer res. Via emulation 68k is regarded as hardware independent virtual asm which coincidentally runs on real 68k hardware! Many viewer features are only available for gfx cards. Most users will run the program emulated, the photos above are ALL above the WinUAE emulator. The photos are of a virtual classic 68020 + fpu Amiga ??00 3.? with gfx card. The advantage of this is the program is fully available to more people. I have probably printed 4000 pages of documentation using it above WinUAE and can vouch that it is faster than necessary, rendering another page every few seconds, whereas the printer takes maybe 30 seconds per page. So 68k-GS854 will whizz through a document and exit, and then the next 30 minutes is the printer catching up from the cached parallel port. For example it takes 19 seconds to render Annots.pdf for my 600dpi printer, which is about 3 seconds per page and that is with an internet intensive download program running in the background. I'll time it again later when the background program completes and I'll time it on my Sempron 2800+ tower as that is much faster than this laptop. Also the viewers achieve real time graphics on WinUAE. So I personally believe that native builds arent necessary, 10 years ago probably emulation was unacceptably slow but not today. Full page photo images will always be slow as that is some 400MB of bitmap.

later: tried it just now, the tower takes 14 seconds to generate the 6 pages of annots.pdf at 600dpi for my printer. Printing takes exactly 2 minutes, total time= 2:14, so rendering:printing==14:120 ie rendering is 14/134 = 10%, the bottleneck is the printer not the emulation. 600 pages would therefore take 1400 seconds to render = 23 minutes and 200 minutes to print = 3 hours 20 minutes.

Anyway the idea is 68k-GS854 is MEANT TO BE EMULATED and MEANT TO BE GOOD EMULATED, if it isnt there is something wrong with your emulator and you should try and get E-UAE for your system. AFAIK E-UAE is even being done for Apples (but not apricots or acorns), remember that ALL webpages arent even emulated they are INTERPRETED, and everyone thinks they are good.

All printers are ultimately portrait, so landscape documents are always a nuisance hence the landscape feature. Thumbnails are a way of overviewing a document: it allows you to directly see how a document is structured, eg the photo above of annots.pdf thumbnails gives an overview of the entire document. Novels are for handy (convenient) printouts and are my preferred way of printing documentation, the photo at the top being quite typical. Some documents the fonts are too small in "novel" format, for those I use the books format. The pamphlets feature is an even smaller version of the novels feature which fits 4 correctly numbered pages on each side of a physical page. The pamphlets feature is useful for printing very large doubtful documents. That way you get 8 pages per physical page, which means 104 pages via 13 A4 pages. Some people like very small imagery, so may well prefer the pamphlets feature: you would need a high res printer as well. Alternatively 2 x 2 thumbnails gives you sequentially numbered pages of the same size.

============= 11th May 2007 =================

830pm: I found the novels, pamphlets, books and billboards features had references to gs850. This has now been corrected. I hadnt noticed this earlier as I usually have gs850 and gs854 installed. You need to download the binary archive again if you plan to use any of these features. The gs binary is unchanged but many other things have been changed.

At the top of the webpage I have uploaded a photo of the novel feature. One further correction: the documentation said you have to copy pdf2ps.amiga to gs854data:, it is in fact already there. So I have corrected that.

Via a better camera I have uploaded a better photo of the GS854 viewer at the top of the webpage. I have also uploaded a photo of the thumbnails feature. In the photo I have made thumbnails of tiger.eps, escher.ps, and annots.pdf from gs854:examples. By following the instructions I gave on this webpage I found the instructions to be not quite correct, that has now been corrected. Thumbnails were the 44th set of new features I implemented.

I use WinUAE at 800 x 600 resolution on a 1280 x 800 x86 laptop, that isnt the highest res. but I find it the best for ascii fixed width fonts, the ones I use being AmigaOS default topaz 11 which at 800 x 600 I find to be unbeatable. I use those fonts for *everything*. In the photos you can see the 800 x 600 topaz 11 fonts in use. I prefer fixed width fonts as they have alignment power that variable width fonts lack.

I suppose thumbnails isnt the most accurate description of the feature, it is more of a tiling feature, with one page per tile.

============= 12th April 2007 =================

I would like to draw your attention to the new features summary. That lists all new features since GS8, many of which never got documented elsewhere. Some new features are also described in the text window when you run the viewer.

Someone contacted me who has an ECS 68k machine with OS3 without gfx card. Some of the info on the webpage which refers to AGA machines probably applies to such a machine. I asked him to try out the AGA WB viewer as that probably is the best one for such a machine. No idea if that will function as the code was written for either AGA or cybergraphics machines.

The more recent gfx features are only for cybergraphics 68020 compatible machines.

People sometimes ask me about GUIs, the GUI of the viewers is the keyboard and the mouse! ie its a hardware GUI, eg you can move 1/2 a page in all 8 directions by pressing the keys:

7 8 9
4   6
1 2 3

That was a neat suggestion from someone in Sweden, he also suggested that 5 should recentre the image. All of which I implemented. That is features no. 39 and no. 42 on 23rd feb and 26th jun 2005 in the new features summary.

Hardware GUIs are an ancient concept and the ultimate way to control a machine, the ultimate h/w GUI is the joystick. IIRC Nintendo dont use a mouse they use a wii! PROOF that h/w GUIs are the fastest way to do things. The fastest way to quit XP is alt-f4, and to quit WinUAE also alt-f4.

If you ever try the x86 gfx card demos try pressing w as that gives you the wire frame version of the demo.

The reason my viewers dont have an on-screen GUI is because on-screen GUIs eat too much viewspace, a typical on-screen GUI eats 30% of the height. I want a BIG picture, NOT a big control panel.

Another very useful feature in the new features summary is no. 43: convert documents to landscape format. That rotates a document by 90° at the PS level. You need that if you have an a4 printer and you download an a4 landscape document as an a4 landscape document requires an a3 printer.

============= 4th April 2007 =================

For printing schemes such as "novel" I found a trick to determine which of the 2 documents to use for printing the reverse sides. As I can never remember which of the two it is. The trick is to select say hd:temp_1.ps and view the first page of that with -sDEVICE=whoosh24 and compare that to the page which would have been printed. If it matches that page then hd:temp_1.ps is the correct one and if it doesnt match, use hd:temp_2.ps. (depends on the printer and the mechanical config of the printer eg my printer here can be configured either way: print to floor or print upright).

And then stick a note on the printer saying which option it is as a note anywhere else will get lost.

I have put this info into each scheme's documentation.

============= 18th March 2007 =================

I've put my first attempt at a screenshot at the top of the webpage.

It looks 100 x better than that, its just this camera refuses to take a clear picture.

There is a screenshot and video of my OS DMA HD code and mouse + keyboard events being echoed on my os web page.

the camera is clear for videos, blurry for snapshots. I'll replace the above picture by one more illustrative of the program's features.

============= 14th January 2007 =================

AFPL Ghostscript 8.54 for 68k-AmigaOS released!

I havent made any announces as it is too much stress, so please announce the release on my behalf, use these links: this announce, installation instructions, topic index,

the announce can be terse such as: "68k-AmigaOS AFPL Ghostscript 8.54 released" with just the above links given. Further info via the topic index here.

1220pm: the 68020-fpu-O2 binary is now uploaded, possibly better for real 68k machines.

Fonts can be shared between the 2 installs via:

assign gs854fonts: gs850fonts:

This is the current version of the program, I had been waiting to see if a brand new version would appear but timed-out waiting. Version number ports such as this are very stressful as any number of changes could have happened and there is no guarantee that the port will complete.

I am buying a laptop now so I can work on things at any time. I have never seen 68k AmigaOS on a laptop so that will be a new experience. (via UAE). I'm not keen on laptops but as a practical matter it seems a good idea to get one. What would be useful is if someone created a laptop tower say 3 x as high as a laptop so you could build your own system.

2007-feb-16: I have a laptop now which is really cool, it is slower but more advanced than my tower system. Also I have fully ported my OS project to the laptop. No project updates and no response to emails as I had to use a very expensive internet service.

having said that, laptop keyboards + slider mice are totally and utterly useless. Working with the laptop hardware is VERY interesting. I tried WinUAE from the laptop in an aeroplane miles above the english channel which was supercool. mobile phones are a bit passé when you have a laptop. Someone needs to figure a way to connect laptops to the mobile phone system, that would be better than wireless modems.

Work on the OS is now accelerating as I have got so much already implemented.

============= 12th January 2007 =================

3am: much left to do but I am ahead of envisioned schedule,

If anyone is in contact with Peer Richter please ask him to email me, I can attempt a build which will deal with the font problem he asked me about years ago. If Tony Pascoal is reading this, I'll try to deal with one of the questions you keep asking about. I'll only tell you which question if successful. While working on this port I had an idea how to do it,

1030pm: that idea looks trickier than I thought, so I have to postpone it till later. I am continuing with the main work and think I can probably complete by midnight Wednesday.

============= 11th January 2007 ==================

650pm: progress continues towards AFPL Ghostscript 8.54, there are a lot of changes since 8.50, should be a good version

============= 10th January 2007 ==================

230pm: I am making gradual progress with the port of AFPL Ghostscript 8.54. There is a long way to go yet. I have a time-window of about 10 days within which I want to complete the work.

9pm: I've completed one of the more stressful parts of the port. There is further stress ahead.

============= 9th January 2007 ==================

1130pm: well GS8.54 it is then! I'll start tomorrow.

============= 8th January 2007 ==================

I still havent received the info I requested. If I dont hear anything by the end of tomorrow I will probably start work on 8.54 first thing on Wednesday (health permitting).

============= 7th January 2007 ==================

I've just returned from my holiday. As mentioned in the previous info update I am evaluating which version of GS to do next. I am awaiting some info by email to base the decision on. That info may need further clarification which could delay things by some further days. As soon as I have the info I need I will make the decision. If I dont get any further info beyond what I know just now then I will work on GS8.54. I hope I can make a decision by approximately next Sunday. I have various real world commitments ahead which will get in the way of programming but I will start on the work and then continue as and when time allows. I may be forced to buy a laptop to get more done sooner. If an interesting version of GS is imminent then I would wait for that.

============= 2nd December 2006 ================

I wont be doing any computing from next week till January 2007. If you email me there will be no reply until Jan 2007. In January I will evaluate which version of GS to do a new port for. If a new version of GS is imminent at that time I will wait for that via a timeout otherwise I will work on the most recent stable version which will be at least 8.54.

I say that just in case the next version was to be in say mid February, then it would be better to wait till then: I will make a timelined decision in January. If it is less certain than that I would ask people to email me whether I should wait or not. If the next version wasnt a super stable one I would immediately begin work on 8.54 in January. WHERE do I draw the line? Answer: I dont know but I know WHEN I will draw the line which will be in January!

If someone gave you 10000 what would you spend it on? You can only decide that at the time you get the 10000. First get the money THEN decide. If you will get the money in January, decide in January AFTER the money has cleared in your bank account.

============= 22nd November 2006 ===================

The C pre-processor mentioned below is complete. It needs a lot of testing but all the basics seem fine. It makes use of the early phases of the compiler project. It contains various enhancements versus standard C pre processing which I will document later on. My aim was to attempt completing this by the end of this month, so I am 8 days ahead of schedule.

============= 31st October 2006 ===================

Info on aliases and shell scripts for simplified usage of GS has been moved to here. Moving to earlier pages can only be done from outside GS because of the way Ghostscript has been designed so you need to use Michael Merkel's GUI interface for that.

Anyone who wants to try out my C pre-processor email me and I'll send a binary after #define is implemented. The C pre-processor part of my C compiler project is universal so can be used for any OS. The binary I will send is 68k-AmigaOS hosted. Today I will be working on macro expansion. Languages such as Modula dont use a pre-processor and are generally much cleaner than C. C was invented in the 1970s to make Unix portable. C is the heart of Unix. The Amiga was designed around C eg the classic Amiga's hardware registers form a C struct called struct Custom defined in hardware/custom.h.

9th November 915pm: #define is now implemented. I havent tried it out yet. I've done enough for today so I will probably try it out tomorrow.

1015pm: suddenly realised I forgot to implement ## expansion. I'll start on that tomorrow. At the moment the ## will remain unexpanded.

10th November 4pm: #define is now ready to be compiled and tried out. 630pm: various bugs which I am working on.

My C compiler will probably be free but wont be made available early except maybe in demo form.

============= 23rd September 2006 ===================

I have completed 2 major subprojects of my x86 OS project, a central low level kernel component and the second phase of the compiler project. Those are probably the 2 most difficult subprojects of the entire project. The kernel component was done entirely in x86 asm which was particularly severe. The compiler project is done entirely in C. I now have enough stuff implemented to do really interesting things.

AFPL Ghostscript centrally is at version 8.54. So version drift is just at 4 (8.54-8.50==0.04). For 2006 I mainly have October and November for my projects and I need to allocate at least 2 weeks for a GS attempt. I also need to take a holiday in what remains of the summer.

What I have decided is to begin on a new GS port by the end of January 2007 at the latest. As 8.54 has been around some time that probably means they are working towards a major version. So it is worth waiting, I want to avoid blowing time on minor versions. October and November tend to pass by very quickly, December and early January are too cold to do anything useful, so before you know it, it will be mid January 2007.

============ 9th August - 6th September 2006 ================

By some error the 68020-nofpu and 68060-fpu builds of 6th August were both 68020-fpu builds. Correct builds were done on 9th August. If you arent sure, c:version will tell you what each build is. As I have macros which automatically generate the version string correctly.

I think its only worth doing a 68020-nofpu and a 68020-fpu build. The 68020-nofpu build is the only build guaranteed to run on all systems. 68020-fpu builds are known to be problematic on PPC, they are fine on 68k systems and WinUAE.

Sometimes people ask me about speed, on WinUAE on an AMD Sempron 2800+ GS850 takes a few seconds per page both for viewing and for my 600dpi laser printer. With the printer the bottleneck is the printer, GS850 generates the binaries very quickly but then XP's buffered parallel port takes ages to actually print the pages. You can print via GS850 and Turboprint on WinUAE.

IMO GS850 generates pages faster than they can be read or printed. So it doesnt need further speed.

To get best performance from GS850 you need to process pages in batches eg:

gs850:bin/gs -sDEVICE=some_device -dFirstPage=1 -dLastPage=100 -dBATCH -dNOPAUSE xyz.pdf

If you process pages 1 at a time the performance isnt so good as GS850 has to do a full initialisation per page.

The -dFirstPage= and -dLastPage= options are only available for pdf's. To do this for PS files you need to convert the PS files to pdf first via gs850:lib/ps2pdf.full.amiga or via gs850:lib/ps2pdf.amiga Both these scripts contain usage info within the script comments. I converted these 2 scripts to AmigaOS scripts from the Unix versions.

These 2 args are not necessary if you want to process the entire document for either PS or PDF.

============ 6th August 2006 ================

I've done 3 new builds of 68k-GS850. These contain a few small changes,

I've redone the 68020-no-fpu build as well as 68020-fpu and 68060-fpu builds. If you use Morphos then ONLY USE the 68020-no-fpu build as fpu builds cause problems on Morphos.

I did the fpu builds as someone with a 68060-PPC machine requested this,

The new viewers at very high resolutions can malfunction, if this happens its quite harmless but you should do a hard reboot ie reboot by switching the power off and then on again and use a lower resolution next time. Such malfunction seems to be caused by an OS3.9 bug where huge memory allocations which fail dont return error.

My current plan is still to port GS9 when that is released.

It is possible that apart from the version info that 68060 and 68020 builds are identical. I will try and determine this.

============ 1st August 2006 ================

Someone has pointed out to me that the command line I gave for converting PS and PDF to jpegs creates low res jpegs at 72dpi. So I've modified the info, you need to give eg -r150 as a further arg to get better jpegs. :I've put this info in the documentation here.

I've been also asked to create an fpu build. So I will generate a 68020-fpu build. There is one obscure enhancement I also need to make to the recent improvements.

I will probably also do a 68060-fpu build as well, feedback in the past says 68060 builds have no advantage over 68020 builds. I'll do one so you can verify this.

I need to make the obscure enhancement first before doing the alternative builds, in total it will take some time, so I'll try and complete this by next Monday.

============ 19th June 2006 ================

I am taking a break now from the GS850 work. Make sure to read the updates from the 14th of June to the 18th, as a lot of new material is there. One of the reasons I made so much progress was my mind was fresh and I found the topics very interesting. If you look at a software topic for too long you stop making progress: I am reaching that point now so need to take a break.

Once I feel sufficiently rested I will do some further tidying up. There are some further features that I may implement: I have some ideas I want to try out where I am not sure what the effect will be. Also I need to create documentation for the new features on this webpage: for the moment the documentation is the updates 14th to 18th.

comment: if you want a photographically accurate view of a document page, and have plenty of memory you can run GS850 -sDEVICE=whoosh24 with -r400, eg:

gs850:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE -dFirstPage=20 -r400 xyz.pdf

then on each page press h twice. Although there is a bit of blurring this looks like a photograph of a lazer printed page. Remember that a lazer print of the same page has at least 36 x as many pixels. Blurring is the only way to achieve the same look with 1/36 of the info. You can then also zoom in up to 400dpi without loss of visual info. If you dont have enough memory then experiment to find the highest res which succeeds. On WinUAE on the Sempron machine here 400dpi on a typical document takes 7 seconds to render the first page and then 3 seconds per subsequent page which seems quite acceptable. The full image being 3400 x 4400 pixels.

============ 18th June 2006 ================

1pm: Redownload yesterdays binary as an improved binary is now available. Reread yesterdays info as I added some useful further info there today: eg on how to deblur photos in pdf and ps files, the s function on its own isnt enough.

The new binary no longer has a limit of 16 million pixels for the fast zoom out. If the image is too big you get a warning and may get some artefacts when the image is 5 x 5 pixels or less.

The fast zoom out algorithm is only available for images up to 18916 x 18916 pixels.

Pop up windows no longer vanish automatically, press return when you've read the info.

============ 17th June 2006 ================

Further enhancements of 68k-AFPL-Ghostscript-8.50 for download!

Download the new binary of 68020 no-fpu AFPL Ghostscript 8.50. (updated 1pm 18th June 2006)

Further enhancements to the download of 14th June 2006:

(a list of the key commands appears at the start of the first page when viewing, and also if you press eg space at any time)

With all the new viewer features you can press 'p' to make the change permanent, and as before 'u' to undo.

A new viewer feature to make text more delicate: press m, I had to invent some jargon for this which I call "maximum-alias". It is a customisation of the existing anti-aliasing but with the difference that averaged pixels are removed. This avoids blurring.

Press w for the opposite of m which is "minimum-alias", as both start with 'm' the w is an upside down m. w makes fonts more coarse, you can use it instead of m if you have bright text on a dark background. w makes bright text delicate and dark text coarse, it is the dual of m.

Press b for blurring. What this actually does is replace each pixel by the average of the 9 surrounding pixels, ie the 3 x 3 square with our pixel in the middle. People wonder whether averaging is a way to anti alias, I didnt know whether it was until I implemented this. The answer is it isnt any good as it is too blurry. Ironically the useful thing that blurring does is allow deblurring of photos in ps and pdf files: see later, you need to use b to blur a few times till the pixels "disappear" and then to deblur perhaps twice via the s function described next.

As an experiment press s for sharpen. This is sort of the opposite of blurring. It is just an experiment and is just a naïve deblurring. Proper deblurring I think requires a lot of theory.

You can see the effect of deblurring by first pressing eg b p b p b p to blur 3x and now press s to deblur. You will see the image becomes sharper. However if you recurse the results arent too good.

The averaged zoom out of the 14th is now much faster especially as the image becomes smaller. This was achieved by a lot of tricks. It is very memory hungry and eg here it allows me to zoom out on a 400dpi image reasonably quickly on a 512MB WinUAE system.

Feature (A) mentioned yesterday is the blurring feature. The speed ups of the zoom out are actually much better than the idea (B) mentioned on the 14th.

I remembered this time to remove the GNU debug info from the binary, which makes the size more acceptable.

The new viewer features only become visible on zoom-out if you press p. So eg to try out blurring when zoomed out you press: b p.

If you keep recursing maximum-alias many times you can get extraterrestrial text! (m p m p m p m p m p ...., and zoom in close, it does depend though on the input page).

Try out the sharpen feature on the pictures on the later pages of gs850:examples/annots.pdf.

If you want to deblur a photo in a pdf you have to use a trick. If you try s directly the effect isnt too good. However ironically if you first increase the blurring a few times via b p b p .. and now deblur a few times eg s p s p you get excellent deblurring with the new image better than the original blurred pixelly picture. I tried this out on a newspaper cover pdf I downloaded. What it is, is that the s function is ideal for something created via the blurring function applied a few times. I have put this info in the index.

The fast zoom out only functions for images with less than 16 million pixels. So if your image is bigger than this the zoom out will be slow: try a slightly lower res. This limit is plenty for current monitors (4000 x 4000), eg I viewed a newspaper page at 400dpi which was too slow but at 250dpi it was fast. If you visit websites of newspapers they sometimes make pdf's of past editions available or pdf's of cover pages. A4 at 400dpi is fine (15.47 million pixels), but a newspaper at 400dpi is too big, 250dpi fine.

The slow zoom out initially is actually fast because of optimisations, but it becomes too slow as you zoom out too much. The new algorithm OTOH accelerates as you zoom out. For the next build I will put an error message if the image was too big. The really neat thing about the enhanced zoom out is that even when the image is the size of a matchbox it still looks photographically authentic. And at playing card size you can read the article titles. I keep thinking it looks just like XP wares.

I think I can remove the 16 million pixel limitation by allowing artefacts when the image is just a few pixels wide. eg 64 million pixels could have artefacts when the image is 2 x 2 pixels.

============ 16th June 2006 ================

Feature (A) mentioned yesterday is now written but not checked or tested yet. I realised today a way to make zoom out much faster. I will see if I can implement this for the next upload, depends how tricky the coding becomes.

4am: I've implemented (A). I'll explain what it is when the upload is ready. I didnt know what (A) would actually look like, now that it is implemented I know what the effect is.

============ 15th June 2006 ================

I am currently implementing the feature (A) mentioned yesterday. There are a number of other image transformation features I want to implement and then I'll make an upload.

============ 14th June 2006 ================

Improved version of 68k-AFPL-Ghostscript-8.50 released!

Download a new version of 68020 no-fpu AFPL Ghostscript 8.50. This is sort of a BETA. It contains many enhancements to the viewers (only available for machines with gfx cards and lots of memory):

Zoom-out now uses colour-averaging, as you zoom out ALL input pixels are used to compute the output pixels via averages. This means the visual information is always fully correct. This makes a big difference to the image quality. It leads to smoother zoom out images. The original algorithm is still there for comparison by setting env variable whooshbms to 1. To test this out try viewing at 100dpi or lower as that increases the frames per second.

Optional anti-aliasing is now available for the initial magnification or higher (zoom-in). If you zoom-out there is no anti-aliasing. ie if you press r then that is the original magnification. That and higher magnifications are "zoom in" and have anti-aliasing available, lower magnifications are "zoom out" and dont use anti-aliasing as those are more pictorial than textual, the colour-averaging being instead a form of anti-aliasing.

The zoom-out colour-averaging is a more satisfactory work as anti-aliasing is one of those impossible subjective problems.

To try the anti-aliasing just press a for a.nti-alias at the original or higher magnifications. Press u for u.ndo to revert the image to the original un-anti-aliased image. Anti-aliasing is optional because it is debatable whether anti-aliasing is a good idea: un-anti-aliased text has maximum contrast.

The anti-aliasing only happens on the underlying image so if you zoom in and alternately press a and u you can see what happens to the pixels.

As everyone now has plenty of memory I have increased the default resolution of the viewers to 126dpi. If you use a classic machine then change this to a lower setting eg 84, via -r84 on the command line. Previously the default setting was 84 which allows a full page to be rendered with just 2mb chipram. Unfortunately that can lead to badly rendered e characters.

The frames per second of zoom out depends on the resolution. If you want it to be more impressive eg for non text pages then decrease the res to eg 100dpi. Or set whooshw to 1.

These new features are ONLY available for the whoosh24 viewer and ONLY for cybergraphics machines. You also need plenty of memory: for an a4 page at Z dpi you need 300 x Z x Z bytes. So eg at 100dpi you need a 3MB buffer. 200dpi would require a 12MB buffer, 300dpi a 27MB buffer etc. Note also that 200dpi will be 4 x as slow as 100dpi, 300dpi 9 x as slow as 100dpi etc.

If you want to try colour-averaging anti-aliasing then render at double res and then press h in the viewer: this idea is easier to do from the outside. (no need to press a as that isnt for zoom-out).

I have enhanced the text output of the program a bit so it now outputs some things to a new window instead of to the shell. So eg in the viewer if you press v a window pops up telling you the current resolution and physical pagenumber etc.

As said above this is a beta, so there could be problems. The zoom out is "science" the anti-aliasing is "art".

130pm: I forgot to remove the GNU debug things from the binary. This is now done, so if you downloaded before 130pm re-download again.

----%%%%%%%%% info from here onwards not uploaded yet %%%%%%%%%%%---------

430pm: I am implementing some further viewer document enhancers. The problem that happens with GS850's fonts is they are automatically generated, that leads to unforeseeable glitches. My anti-alias scheme attempts reverting this via aesthetic principles. Now AmigaOS's topaz fonts are hand generated so though not anti-aliased they look fine.

I am looking now at a scheme to enhance the fonts without anti-aliasing, the idea is to refine the fonts without blurring.

One other thing if the dot of an i is 1 pixel the current upload averages that, I will change that in order to preserve contrast.

6pm: I have created a variant of the anti-aliasing scheme which makes text more delicate without blurring. It is a modified version of the existing anti-aliasing algorithm. As there is a duality between background colour and foreground colour I have a converse scheme which makes fonts less delicate. The duality is that if you make the foreground colour more delicate you make the background colour more coarse. So eg black text on white background requires the other function from white text on black background.

Although not intended for images I tried both schemes on tiger.eps and the results are very interesting if you recurse a few times: each colour region starts to change shape. (I press eg m p m p m p m p ... )

You can now make the output images permanent by pressing p (p.ermanent), this means you can eg recursively anti-alias to see what happens.

I have also prevented 1 pixel dots of i's getting antialiased away. An i without a dot is an iota.

There is one other image transformation feature I want to implement, I want to implement that before making an upload. Its a feature which will be really interesting to recurse. (A)

I'll be watching the Germany vs Poland world cup match tonight so wont be coding then! (it looks like the top teams dont make a full effort until later in the tournament)

850pm: its half time during the match, 0-0 so far. While watching I realised a really obscure improvement to the main viewer, I'll say what it is if I manage to implement it. (B) Just before the match I tried out the code for making text delicate and located a very subtle glitch in the main algorithm so after the match I will correct that: it was a break in the lower part of a right ) symbol: not a true break but a break by averaged pixels. I want the line of input pixels to be unbroken as a design constraint. later: I see this glitch isnt in the current upload but occured since then, the original code was correct on this. (C)

I think antialiasing in general is a very deep problem. Here I am not looking at the general problem but mainly the problem of text rendered by GS850.

1230am: a careful study of (B) shows the idea isnt feasible to implement. The idea I had was sound its just that the info I need is too intractable to obtain. AFA (C) goes I found a different improvement which does affect the current upload. I havent begun on (A) and I've run out of time. I'll begin on (A) tomorrow.

Recursing the code to make text delicate creates extraterrestrial imagery on some document pages!

============ 13th June 2006 ================

I'm not completely convinced by the concept of antialiased text. The problem is it creates blurring which causes eyestrain as you keep trying to focus your eyes, eg if you look away from the monitor at reality everything is infinite res and sharp. Un-antialiased text is fine, stop complaining.

You are supposed to be thinking about the information presented not the rendering there-of. The best computer fonts I know of are the AmigaOS topaz fonts. Unantialiased imagery is part of the fun of the computer experience.

Remember to view at 100dpi as that is computer monitor res. Best thing is to view the image, then zoom-in via the up-arrow till the magnification is just right, then press v, look on the shell for the current x and y res and round that to the nearest integer. eg here on a document it says xres == 149.990624 so that means I should view that document at 150dpi, so I need to run GS850 with -r150. Usually xres==yres, but you can set them to be different at the cost of aspect. The whooshw env variable makes the viewer view so the page exactly fits the width of the monitor.

Having said that I will implement one or another anti-aliasing scheme, each way I've looked at has disadvantages. If you want a visually perfect image you should print the page. The real problem is that monitor resolution is too low: the only way to get authentic imagery is via blurring.

Schemes which look impressive close up make almost no difference at normal magnification.

One scheme I tried made the image so blurry that you will go mad if you look at it for too long. I think that is one thing I dont like about XP, the image is too blurry. If you use XP backdrops on WinUAE via Prefs they look much better on WinUAE due to lack of antialiasing.

Much more successful as an idea is the averaged zoom in, eg if you zoom out from an un-antialiased page it always looks correct.

6pm: I think I have an antialiasing scheme now which is reasonable.

Although this antialiasing is only intended for text I tried viewing tiger.eps just now and it does that correctly. It creates in between colours.

midnight: I've made several improvements to the anti aliasing. I think it is now sufficiently good to make available. I've run out of time just now but I'll try and get the new work uploaded by Thursday. I need to test the antialiasing on further documents and recheck the code.

It looks more impressive if you zoom in on the pixels. I've implemented an undo facility so you can switch between the original pixels and the new pixels.

============ 12th June 2006 ================

7pm: I am coding now a first attempt at antialiasing.

Last thing last night I did a full build of 68020-no-fpu O2 optimised GS850 as it currently stands.

The averaging-zoom-out is now acceptably fast, possibly 2x as slow as the original zoom. With this there is now no pixel-dancing as you zoom-out. The image also has the look of images on Windows XP, so XP must be using such techniques for some things at least (not everything).

This new zoom-out now uses a more efficient rendering pathway, this allows it to catch up vs the original system.

It should be particularly good for photos. If you zoom out now on the tiger the tiger's whiskers dont fragment.

Now when you zoom out to the point where the entire image is 1 pixel that 1 pixel is the average colour of the entire input image. So if the input image is say 70MB it is an average of that. The averaging is total which means the full info is always there. I could speed things up by skipping pixels but as I can do a total average reasonably fast I wont. If you skip pixels that could lead to visually incorrect imagery.

You see that the full info is there as you zoom out: the image is always visually correct. And it looks like a printout from a printer except a bit blurry in places.

Anyway I'm continuing now with the anti-aliasing coding,

830pm: The coding is progressing well, dont know if I can complete this tonight.

145am: The first version of anti-aliasing is now functioning. It needs further improvement. I think I have to do a lot of further experimenting. Anyway it is functioning correctly. I need to improve the heuristics. Have been trying it out on some x86 documentation.

The anti-aliasing happens fairly fast. The zoom-in doesnt do any further processing, this means I can zoom in first then press a on the keyboard and see pixel by pixel what has happened. Doing this I see it isnt quite right: subjectively speaking.

============ 11th June 2006 ================

4pm: I am reactivating the GS850 project this afternoon, 4 days ahead of the promised timeline. First thing is to backup everything just in case things go wrong. I then have to survey the state of the project as there is several weeks of work beyond the current binary on this webpage.

A subset of the new work is good but most of it needs to be undone. An interesting thing I did achieve was a legacy problem Peer Richter found where incorrectly defined fonts were being filled in but no problem on GS510. The problem was with the fonts not with GS, entirely by chance I found a way to make GS850 revert to the GS510 behaviour on this. That requires a different build of GS850.

The GS850 work will be done in parallel to my other projects. To prevent any project eating all my time I now always work on more than one project: management of time-risk.

Once the project is coherent again I will begin working on the anti-aliasing. I have an initial algorithm now designed to try out. The anti-aliasing is the interesting part of the new work but other organisational gruntwork needs to be done first.

645pm: well I'm progressing now on the work. I've decided I'll make various other improvements as well. As I wrote my own bitmap rescaling I am looking at enhancing that for reductions by replacing the current naïve rescaling by averaged rescaling. That will be slower but should produce better colours.

Note that averaged rescaling wasnt feasible for classic AmigaOS as that used a palette scheme.

Looks like I can do averaging in the x-direction without major changes, I will see if I can do averaging in both directions which will be better. But only if it doesnt require total rewriting of the code.

BTW that will produce naïve antialiasing by zoom out. Anyway this change will produce averaged-colour zoom-out. For my anti-aliasing code I want something more sophisticated than just averaging as averaging will just blur the image.

It will definitely be quite a bit slower as the entire page needs to be sampled, I need to find how much slower. Naïve rescaling only has to sample relevant pixels which makes it very fast. Do you want speed or do you want colour quality?

All the new features will just be for the truecolour viewers, I could do them for the greyscale viewers but I think on modern machines you should just use the truecolour viewers.

9pm: Well I have implemented + debugged the averaging zoom-out, and it takes a 2D average which is the best approach. It is absolutely fantastic. I have run the original viewer side by side with the new viewer, viewing tiger.eps and the new viewer always looks completely correct as you zoom out, it looks like a photo at all times.

The only catch is that it is a lot slower, perhaps 2 or 3 frames per second. I think I can definitely speed it up considerably but I have to study the code carefully.

I think my planned anti aliasing should help with tiger.eps as well for when you zoom in.

I have tried viewing some x86 documentation at 200dpi then pressing h (zoom out by 2x) to get averaged antialiasing of 100dpi. This looks just like a laser printed page, the only problem is it is a bit blurry in many places. The problem with averaging anti aliasing is it blurs thin lines. It also blurs edges. My planned antialiasing will avoid the blurring problem by maintaining sharp contrasts.

1045pm: I am working on making the averaging zoom out faster. I think I have found a way to do it which doesnt require major changes. Not sure I can complete this tonight, I'll see how far I can get.

145am: I have now a fast version of averaging zoom out. At least it is fast on this Sempron machine. I tried an 800dpi page to then press h 3 x for 8 x zoom out: For this the averaging zoom out was slow as 800dpi is almost 200MB of bitmap. (greyscale could be better for very high res as it reduces the memory footprint by 3x ) Also the 800dpi averaged down to 100dpi isnt really any better than 400dpi averaged down.

I am almost ready to implement my first anti-aliasing algorithm that will produce much clearer imagery. The build I am looking at is an unoptimised 68020-fpu build. For general downloads 68020-nofpu builds are better as the fpu builds dont run on Morphos.

============ 8th June 2006 ================

I will soon reactivate the project, by 15th June at the latest as said in the previous update.

I will attempt implementing antialiasing for the viewers in response to Tony Pascoal's requests.

It looks like quite an interesting problem, interesting in a visual way, however before I can begin on it I have to do a lot of tidying up of the project.

Anti aliasing should greatly enhance the viewers (I hope).

I will also attempt to port GS9 as and when they release it. Versions near GS9 on either side wont be as interesting as GS9. Centrally they are at GS8.54, its a good sign that the numbers are changing slowly as that means the product is very mature.

Right now I am working on a lot of x86 hardware problems as well as software projects. All the development done on WinUAE. I think I have printed more than 5000 pages of x86 documentation with my GS850 port eg yesterday I printed yet another document on x86 hardware, 20 pages of interesting hardware info.

============ 27th May 2006 ================

I am making a study now of creating antialiasing for the whoosh24 and possibly whoosh8 viewers, this is in response to requests by Tony Pascoal.

There are 2 general ways to do antialiasing, the better way is to integrate antialiasing into eg the font definition. Unfortunately that is way beyond the scope of this project. For my OS project I will try and do integrated antialiasing for the OS fonts but for the GS project it is beyond the scope of the project. Something which is fine for one project is not fine for another project, its a problem of decision sequencing. The problem here is that font antialiasing is a specification or definition problem and not an implementation problem.

So instead the antialiasing will be done in a workaround way. Workaround antialiasing is a complicated and ill defined problem. eg someone might create a document explaining antialiasing and give examples of images that need antialiasing: you DONT want the rendering to anti-alias the examples as they are meant to be bad!

That is similar to the problem of giving examples of spelling mistakes, you DONT want a spell checker to correct that!

Anyway I have an initial antialiasing scheme designed to try out.

Note also that integrated font anti aliasing would be much much faster than workaround anti aliasing.

I will reactivate the GS850 coding temporarily by 15th June 2006, first I will need to do some tidying up. And I cannot restart the coding immediately as it is just 1 thread in the tapestry of my life. When the coding has been restarted and the tidying done and other changes done, then I will code and try out the initial scheme, anti-aliasing is to some extent subjective and in fact is only necessary because monitors have such low resolution. If they can increase the resolution of monitors by 6x then anti-aliasing will be obsolete.

Anti aliasing is just a legacy artefact, unfortunately monitors havent evolved their way out of the legacy swamp. Note that if monitor resolution is increased 6x then graphics will become 36x slower.

The anti-aliasing I am designing is geared to fonts and curve based 2 colour graphics: that is exactly the type of pages you find in typical documents eg x86 documentation. Where you have b/w pages with text and curve based diagrams. General purpose antialiasing wont help at all as it will just blur very low res text.

Studying the problem and designing a scheme I can do now, but the coding cannot be begun yet.

============ 23rd April 2006 ==============

The 68k-GS850 project will continue indefinitely. I'm just very very busy with the OS project. But when the time is right I'll reactivate the GS work. I will always have and use 68k-AmigaOS and 68k-GS.

The 68k-GS project is at a very mature point so I can keep the pan boiling at low heat. I have some GS things I want to implement for my own use, and when I reactivate the project I will work on those.

The only way to work on many projects is to be very efficient with time, once a project has matured you have to then reduce the time invested.

I dont just work on projects to while away time but I code for a purpose. Once the purpose is attained the point of focus needs to move to a new project. For me personally 68k-GS has attained its purpose of allowing me to do customised prints and viewing of PS and PDF files. The "novel" and "landscape" and other such schemes were things I'd wanted right from the start but it took a long time before I could see how to implement them.

I use the "novel" scheme all the time, it saves me a lot of ink and paper and IMO is the best way to present documentation. What I usually do is print each chapter of a PDF as a "novel" booklet. I staple the booklet with a long arm stapler. I use the whoosh24 scheme to plan the printout, usually the first thing is to determine the last page of the contents and print the contents out as a booklet. I then note on the contents booklet which chapters I've printed out and what the physical pages are.

============ 8th April 2006 ==============

Click for further info on my OS project. See the day before yesterday and yesterday.

============ 7th April 2006 ==============

Further info regarding my operating system project I mentioned yesterday.

I will probably also move things concerning the project to another web page.

With something like AmigaOS there are 2 ways forwards, you can either (a) try and develop the system further or (b) you can create a completely new system which coexists with the original system. The problem with the former approach which I think OS4 are taking is that there are limiting constraints from 1986 when the original designers thought that the 68000 series would go on to infinity. x86 is Aesop's tortoise and 68k is the hare. You have to then try and workaround the legacy design constraints. This you can do but it can complicate everything for everyone.

OS4 and Morphos have gone for 68k binary compatibility eg they can run my 68k-gs850 port from their system shell or workbench. They can do that as they have integrated 68k-emulators. UAE is fundamentally unintegrated so it will run 68k-gs850 eg thats what I do but only from its standalone space. UAE only emulates the hardware, the OS is by the Amiga company. UAE is not an OS it is virtual hardware implementing the hardware reference manual and the Motorola 68k manuals. It doesnt reference or implement the RKMs. It has some integration eg the filesystems are integrated with XP. UAE is a hardware layer.

Integrated emulators are different from unintegrated ones because integrated emulators are above the OS and act through the OS whereas unintegrated emulators are below the OS. Integrated emulators dont use a ROM, they use the actual OS. The advantage of unintegrated emulators is they can run above any OS, the disadvantage is they are unintegrated.

AROS took an interesting path in they implemented a hosted AmigaOS above x86-Linux. 68k programs need to be rebuilt and then will run x86 native. eg I rebuilt my 68k-gs850 port and it does run correctly, they dont have Turboprint but you can eg use the whoosh24 68k-gs850 viewer.

AmigaOS could take the hosted native path, you then get x86-native AmigaOS but hosted above another OS such as Linux or XP. That's a good medium term strategy, you get people on all hosts to use your system and you only go for source-compatibility. The same x86 binaries will run on all x86 hosts, and the same PPC binaries will run on all PPC hosts. So you get partial binary compatibility: cpu level binary compatibility. Classic 68k programs wont run, but that creates a market for you to write your own versions of those programs. If it rains a lot instead of complaining make money by selling umbrellas.

If they use the same h/w conventions as AROS then the same binaries will run on both systems. eg my x86-native-AROS-gs850 port on this page would then run on x86-native-AmigaOS.

The PC universe is different from the Amiga universe in that they have gone for clone-compatibility. And it has paid off handsomely. Everyone is successful.

AmigaOS has run away from the clones whereas x86 have run with the clones, eg you can run ATi Radeon's Chimp and butterfly demo on an Nvidia gfx card on an AMD or run it on an ATi card on an Intel, it looks better on the ATi.

It was a major turning point in x86-history when Bill Gates decided to run with the clones and IBM ran away and joined forces with Motorola and Apple. Microsoft overtook IBM as a company. IBM were running in the wrong direction along the track: clockwise, easy to overtake! History has many lessons.

Running with the clones means the best developers win, whereas running away means you have to rely on loyalty, and most computer users have limited loyalty. If you cant beat them join them. AROS can hardly sue AmigaOS for using their h/w conventions, they will probably be flattered.

Now I am creating a brand new system without any reference to any other OS. x86-native AmigaOS could definitely be run above my system and I am designing the architecture so that emulators and hosted OS's will run as fast as they would hitting the h/w directly. Hosted OS's do hit the CPU directly, and you can code in x86-asm "mov eax,ebx", "push ecx", and gfx can hit the h/w directly: gfx h/w is just ram (a lot of the time).

Its just an external HAL vs an internal HAL. Same difference.

You wont in general be able to hit the MMU directly as that brings in security problems, but target user progs should also not hit the MMU directly as that brings in target OS security problems, so you just redirect user MMU ops twice instead of once.

host-hw------host-os---target-os---target-user-prog :indirect

host-cpu---------------------------target-user-prog :direct cpu

host-gfx-hw------------target-os---target-user-prog :direct os-gfx

host-gfx-hw------------------------target-user-prog :direct user-gfx

host-gfx-hw--host-os---target-os---target-user-prog :indirect gfx

:hosted OS's are native in many respects, its only hosted emulators which arent native, all emulators arent native. Actually modern x86 CPUs are emulated as x86 is emulated by a RISC core. I think a lot of people think hosted OS's are slow, they arent.

AFAIK AROS began hosted only and then later they achieved native.

Its not that AmigaOS could be hosted, its already been done by AROS. AmigaOS has some catching up to do with AROS. As I said: run with the clones.

I've already coded and run and debugged many boot experiments in x86 asm. I boot from a floppy. I have 2 PC's, I code on WinUAE, assemble on XP via FASM, and then boot the floppy from the other PC. Everything so far is in asm, however x86 assemblers are quite sophisticated, by using a lot of macros its not that much more difficult than coding in C. FASM asm has structs, and typechecking at the operand size level.

Anything you can do in C you can do in x86 asm though you dont have many registers: eax, ebx, ecx, edx, esi, edi. Things get complicated if you run out of registers. But I've developed mitigating techniques. You have to write the code differently from how you would code it in C. Its not like 68k where you have d0,d1,d2,d3,d4,d5,d6,d7,a0,a1,a2,a3,a4,a5,a6. Some things can only be done with ecx, some only with ebx, some only with eax and edx. Eg for division, the numerator is always (2^32 * edx + eax), the division goes to eax and the modulo to edx with a flag set if the answer is too big.

So to divide ecx by ebx with the answer to esi:

  push eax
  push edx
  mov edx,0
  mov eax,ecx
  div ebx
  mov esi,eax
  pop edx
  pop eax

(:A)

Its not like some CPUs where its just 1 asm op. eg with RISC the equivalent would probably just be "div r2,r3,r4". With 68k to divide d2 by d3 with result to d4 its probably:

  move.l d2,d4
  divu.l d3,d4

You can do (A) via a macro:

macro  mydiv32 quotient32*,numerator32*,denominator32*
	{
	push eax
	push edx
	mov edx,0
	mov eax,numerator32
	div denominator32
	mov quotient32,eax
	pop edx
	pop eax
	}

and invoke it thus:

  mydiv32 esi,ecx,ebx

FASM macros are clever so you could even make the macro do the division directly if quotient32 happens to be eax.

IMO the 68030+MMU was the best CPU ever from the programmers POV. No other CPU compares for convenience. People who say PPC and 68k are better than x86 are right, the strength of x86 is they workaround the malarchitecture with a lot of force. x86 is a deeply flawed specification but the implementation is first class.

Its going to be some time before I even have a mouse pointer. The first steps are the slowest and most difficult. I have 4 system-bootstrap phases already coded and debugged. And I have debugged the initialisation code of various system components. I have run into some BIOS limitation with accessing the floppy drive so I am currently working around that via an extra phase. I've written code to probe the PCI bus which functions correctly, though I havent succeeded yet coding the h/w located by the query. I need to work on a lot of other things before I can attempt any further PCI coding.

If there are any bugs with my boot code the machine tends to reset. I've probably spent days with jmp bugs, jmp is very tricky. Boot code is generally very jumpy, the whole system will fail because of some trivial error eg some bit wasnt set or you were executing 16 bit code when you should have been executing the 32 bit version of the identical code.

My code is quite safe though as its only accessing the floppy disk, and its only reading the drive. Its when you start writing to drives that you have to be very careful and use a scratch drive.

Modern PCs are just huge Amiga 500s, thats the way I look at them.

Anyway AFA AmigaOS is concerned, I think the best way to move an OS is to host it. To create a new OS you really need to create it native otherwise you'll be influenced too much by the host architecture. What you do then is internally host the OS. Then you can move the hosted part to an external host. Lastly you can replace the external host by your own version. OS's are very large viruses.

x86-AROS really is the defining example of this methodology, they reimplemented AmigaOS above a Linux host, and then implemented their own host to get x86-native-AROS. and I think they are working on a Windows host.

Through layering you can have PPC-native binaries which will run on both Morphos and OS4. The guys at Morphos and OS4 will not approve but it can be done. that's a project.

Noone likes being cloned, but if you cannot stop a clone its better to be inter compatible. With x86 everyone wins who accepts the existence of their clones, going even further its a good idea to clone your clones. Learn from what your clones are doing, Intel does that. From the user POV, clones maintain pressure on companies preventing complacency. Apple and Amiga were very complacent as they had no opponents. Their only opponents were at a great distance from x86 and Windows. Today AROS is progressing at such a rate that AmigaOS is under pressure and the only way out is to copy AROS.

I'm not waiting, I'm constructing my own way out.

The absence of clones was bad for the Amiga because the central company could do anything they wanted and we the users could do nothing about it. AROS + Amithlon + WinUAE are basically clones pushing through a contradictory belief that x86 is the way to go. Microsoft also has no competition, but they cooperate with all hardware clones. I for one will be competing against Windows. There are so many ways to outdo Windows, a whole bookful.

============ 6th April 2006 ==============

I'm creating my own operating system now. It is an x86 native operating system. It will be super-modern and I have already completed various initial stages, enough to know that I can complete the whole project though its going to take a LOT of work.

My filesystem project will supply the filesystem for the project. My filesystem will be integrated into my OS. All other private projects I've been working on will also be integrated into the system.

The 68k GS project will continue unchanged as its unlikely that GS will build on my OS as I'm making a total departure from *nix. The AROS port of GS will also continue.

The OS is being cross developed on 68k AmigaOS on WinUAE. This is a long term project and I intend to compete against Linux and Windows. I'm implementing the ideas I've been saying for quite some time that AmigaOS should do.

x86-native AmigaOS could be implemented above my project the same way Morphos implements AmigaOS above the Quark kernel. However that is not for me to decide: I wont do a unilateral reimplementation of AmigaOS. I could but I wont, I'm not into reimplementation and emulation.

Big endian x86-AmigaOS could also be implemented above my project.

Various components of my project can be ported just like that to say 68k AmigaOS as I do that anyway to test them out.

Unlike some projects I am not hostile to AmigaOS, I think everyone who wants to become a programmer MUST familiarise themselves with classic 68k AmigaOS as it is the best example of how things should be done. There are only 2 classic operating systems: 68k-AmigaOS and Unix. Unix is clever but very painful, 68k-AmigaOS is the only sophisticated OS which is fun.

I am not copying AmigaOS in any way however I do want to achieve the same objectives that AmigaOS achieved: directness, ease of use, high programmability, (who doesnt!).

This is something that should have been done in 1995, Microsoft have had too easy a ride and Linux can never challenge Microsoft as they are caged within the framework of Unix.

The advantage of doing it today is that x86 hardware is just at the point of becoming interesting, and AMD are pushing through good architecture. Today Intel copies AMD's designs. The 68030 MMU is still better than even the latest x86 MMUs. The 68030 MMU allows pages from 256 bytes to 32K with early out at all levels. x86 MMUs only allow pages of 4K or 2MB or 4MB, and only allow early out at the second last level: that's how they achieve 2MB and 4MB pages. 4K/entry_size * 4K == 2MB or 4MB. The x86 MMU is similar to the 68030MMU but less flexible.

The 68030MMU is a dream machine. eg the 68030MMU can emulate an x86 MMU but not vice versa.

Even today AmigaOS can still compete against Windows, the thing is I cannot do their work for them. I know what needs to be done and I know how to do it. I can stand around for years wishing and hoping they make some obvious decisions or I can make those decisions myself.

From my POV its better for me just to get on and create my own system. Otherwise another 5 years will go by and it will be 2011 and there will be no observable change. In those 5 years I could implement a fully featured OS. I've already got most of a filesystem implemented within 1.5 years, so I can definitely implement an entire OS in 5 years.

The guys who created AmigaOS in the first place werent happy with Apple and Unix and they created their own system the way they thought it should be done. They created a 4096 colour pre-emptive multitasking computer when Apple was unitasking monochrome and MS was a unitasking 80 x 25 text screen with flashing cursor and Unix just had voluntary multitasking in the kernel.

============ 3rd Apr 2006 ==========

I'm making good progress with my other projects, enough so that I've restarted my FS project. Once I've made enough further progress I'll schedule time for some 68k-GS things.

At the moment I'm learning and experimenting with x86 hardware. This requires huge amounts of documentation printouts: which I do with my GS850 port. As an example there was a 230 page document on cross platform h/w info which I wasnt sure was useful. So I printed it in double sided "pamphlet" form via my pamphlet extension of GS850. So instead of 230 pages it was now just 230/8 == 29 small pages. I then cut this with a scissors, not very carefully! It was too many pages to staple, I then flicked through to locate any useful things. There were just a few pages of interest.

So instead of wasting half a ream of paper, I just wasted a twentieth. It also gives you a 4x saving of ink.

The pamphlet scheme is the best way to deal with bloated reference documents. If a chapter looks really interesting then print it full size. With obscure computer documents you'll often only be interested in say 2 chapters out of 10.

With double sided printing you have to wait for the paper to cool down. I think hot paper causes problems with the toner and you can get creases in the paper. So after printing the first side, remove the paper from the printer and leave it for 1/2 hour before doing the reverse side.

A different approach is to use the whoosh24 viewer to study the index of a document. Find eg a chapter that looks interesting. Use trial and error with whoosh24 to determine the physical pages of the document. And eg you can start reading the chapter with whoosh24 to see if it is worth printing. You then can print that eg in novel format eg:

8> gs850:bin/novel   ; to get the usage info


Usage:

gs850:bin/novel pdf_document first_page last_page temp_file

8> makedir hd:temp_dir 
8> gs850:bin/novel docs:xyz.pdf 103 150 hd:temp_dir/xyz_

8> protect ram:script#? +s
8> ram:script1  ; typically takes a lot of time,
8> ram:script2
8> gs -sDEVICE=somedevice -dBATCH -dNOPAUSE -sOutputFile=par: hd:temp_dir/xyz__0.ps
; WAIT HALF HOUR FOR FIRST SIDE TO COOL DOWN.
8> gs -sDEVICE=somedevice -dBATCH -dNOPAUSE -sOutputFile=par: hd:temp_dir/xyz__2.ps
; some printer configs you print xyz__1.ps instead, depends on the paper transport geometry.
; you may need to reverse the second printout. You now eg staple the column into a 
; novel sized publication. 60 pagenumbers will staple without problem: 15 A4 pages.
; I bought a long arm stapler from the shop Staples, it is by Rexel and has a 10 inch reach.
; if you printout a 1000 pagenumbers (250 x A4) it will be impossible to staple.
; so you need to plan.

For documents I like I often use novel format unless the font is too small.

If you want to do this for a PS document, you need to convert it to PDF first via gs850:lib/ps2pdf.amiga or gs850:lib/ps2pdf.full.amiga which call gs850. Read these 2 conversion scripts for usage info in the comments.

The novel and pamphlet schemes will save you a lot of money in paper and ink as well as save a lot of storage space.

If you want to put a huge amount of info on 1 page use the thumbnails scheme, probably more useful for pictures.

You can also combine schemes eg convert to thumbnails, convert thumbnails to pdf, and then convert pdf to novel: put 512 pages onto 2 x A4 with 8x8 thumbnails, you'll need a very high res printer and a microscope!

You can merge PS documents via c:join, I think do this with documents which have the same pagesizes. Then you can convert these to pdf, then eg convert to thumbnails.

============ Wed 8th Mar 2006 ==========

I've been asked about what I'll do next with this project. The only thing I can promise is that when GS9 is centrally released I will try and start on a 68k AmigaOS port within 3 months of hearing that. I say 3 months because maybe I will be on holiday or in the middle of something else. I will of course try and start a lot sooner perhaps 2-3 weeks, but I cannot promise that.

Centrally AFPL GS is now at GS853, that was released in November 2005 so I think I shouldnt target it as they will probably soon release maybe GS854. If it was a major release then I would.

Going by the past I think probably they will release GS854, then GS855 and then GS9. Major versions such as GS8, GS850, GS9 are the best as they tend to be super stable. GS853 contains new features but some of the new features are beta. With major releases AFPL try and stabilise everything. Stability is much more important than currency eg GS8 is better than GS813.

To be quite frank I think GS850 does everything one can want. I have printed 1000s of pages of downloaded pdf documentation with it. If you keep enhancing a program you eventually reach the point of absurdity. IMHO GS, WinUAE, gcc and a lot of GNU have already reached the point of absurdity: they already do more than you can ever want. Actually sometimes programs get worse if they have too many enhancements.

========== Fri 27th Jan 2006 ==========

At the moment I'm working on a whole series of programming projects. When I originally ported GS8 I was actually in the middle of a project, I needed to print out the PPC manuals and that was beyond my Star LC10 dot matrix printer. So I bought a b/w laser printer, but it wouldnt print via the Amiga, but there was a GS driver. People on www.amiga.com told me that the way to print was via GS. That eventually led to me attempting to port GS8. My port attempt received a lot of criticism: no gfx card support and no Turboprint support. 5 months later and I had addressed all the major criticisms. Beyond that over the months I gradually dealt with all the feedback, many things are here. As you can see there are 47 improvements since the release of GS8.

GS8 led to me looking at open source in general and I worked on more open source projects than I care to remember, however none with the depth of GS. Eventually I became a bit disillusioned with open source, so I decided that beyond GS I wouldnt be involved with open source except where it is absolutely necessary eg I've dabbled with gcc eg porting AROS's Linux hosted gcc to 68k host which is somewhere on this website!

I eventually got converted to the idea of x86 AmigaOS, and use WinUAE. I took an interest in x86-native-AROS, as they seemed to have hit the nail on the head as far as strategy for AmigaOS. I've now more or less left AROS and am working instead on my own private programming projects. I've taken the cue from AROS and am trying to learn x86 programming and am progressing, gradually, as x86 is a severe system.

I've restarted in the last few weeks the project I stopped in order to port GS8 way back whenever it was. So I am working now on a multitude of projects, all my own projects and none are in the public domain. eg I've just managed to reorganise the memory subsystem of my FS project so that I can reuse it in other projects. My memory subsystem has a debug option which does total tracking of memory allowing me to rapidly locate memory bugs. All my projects are developed on 68k AmigaOS WinUAE, but done portably so I could transfer them almost anywhere.

I use 68k-GS850 to do all my printing and the "novel" etc schemes I created are very useful for dealing with huge printouts. So because I am myself a user of the program I will try and generally keep the program up to date.

============ Tue 10th Jan 2006 ==========

Wanting to print out a chapter of some documentation in "novel" format, ie 2 pages per physical page and on both sides correctly numbered I decided to follow my instructions on this webpage. I found a bug in the instructions which I've corrected, the 3rd line said "ram:temp" when it should have said "hd:temp". The error happened because I usually use ram:temp. Although printing in novel format sounds scary if you follow the instructions it is straightforward. The scariness is in creating the mechanism not in using it. At the very end you may need to reverse the order of the column of double sided prints. I probably need to improve the scheme sometime so that a final reversing isnt necessary.

At the moment all my time is learning about x86 hardware, its very interesting but takes a lot of effort to understand. I learnt that the Pentium from 1993 can do 2 instructions per clock cycle, the P6 from 1995 can do 3. As soon as I've made some further progress I'll resume work on the FS project, which currently is a 68k project though I want to get it to run on x86 as well by hitting the x86 hardware directly outside of Windoze which is why I'm learning about x86.

I'm printing lots of documents with 68k-gs850 and it is coping with the documents just fine, so I dont see any urgency in a new port. I use the whoosh24 viewers to locate which pages to print, no point printing an entire document if I only need say 3 chapters out of 12. Eventually I will do a new 68k port of GS. I will have to also port the novels + pamphlet etc schemes forward as well as those are changes to the central source, and those facilities are only available on my port of GS850.

My view is that programs should do what they're supposed to do and you get on and use them. I dont subscribe to the idea of neverending version improvements. AFPL GS centrally seems to have stabilised as really they've done everything that possibly can be done. This is a good state of affairs, the last thing you want is people pretending to be busy!

============ Friday 2nd December 2005 ==========

I havent left!

At the moment all my time is on my filesystem project. I'm just finishing off towards the next filesystem prototype. Eventually I will do a new forwards port of GS850.

============ Monday 12th September 2005 ========

in response to requests I spent maybe 2 weeks attempting a port to Morphos. Porting to Morphos looks very very difficult and has so far been unsuccessful. :I can build the binary, but all fonts do not get rendered, and turboprint doesnt function at all.

The problem is very deeply situated. So if you use Morphos please use the 68020-nofpu binary from this webpage as that functions fully correctly and does everything documented on this webpage.

In attempting to port to MOS, I found how to workaround a problem that Peer Richter told me a long time ago. Fonts from long ago dont all conform to the current specification. The workaround allows documents with such fonts to be rendered correctly: if you have a letter O, this is defined by an inner curve and an outer curve. The problem fonts have both curves going in the same direction and rely on parity to decide which points are rendered: doubly rendered points are not rendered. Correct fonts have the 2 curves going in opposite directions. So the modern specification renders the problem fonts O as a disk. The 2 schemes apparently are incompatible, GS510 rendered fonts incorrectly by parity, GS850 renders correctly. I have found how to make GS850 render "incorrectly" for compatibility with GS510 and early fonts.

:the binary with the workaround hasnt yet been uploaded yet, it needs a bit of further coding and I'll then upload it.

I will continue attempting a port to MOS, but only as a background activity as its starting to eat too much time and there's no guarantee of success.

Right now all my time is on my FS project. I'll schedule some time ASAP to complete the problem font workaround.

============ Sunday 24th July 2005 =========

Temporarily at least I have bought 70Mb of extra webspace, so all archives are now in .lha format as I now have enough webspace. Previously I had less than 1Mb free.

If anyone tries out any of the new features within the next two weeks please email me to say how it went.

============ Friday 22nd July 2005 =========

5pm: I've now improved the usage of the pamphlet scheme. Its now simpler and better. Also improved are the book and novel schemes.

With all 3 schemes you no longer need to supply page_count and offset but instead supply first-page and last-page. With the pamphlet scheme you now cut the column in half and then just place one half above/below the other half. Previously you had to alternate pages from the 2 halves which was a pain. also the new scheme creates less unused pages within the book: when you place the one half column above the other at the top there may be a fully unused half page you need to remove. The total amount of paper used is the same, but the amount used within the book is less by one half page in half the possible circumstances.

Furthermore with all 3 schemes for the reinserted print the schemes all create both the forwards version which is hd:temp_1.ps and the reverse page numbering version which is hd:temp_2.ps.

As the usage has changed I've changed the names of the relevant auxiliary programs, they are now "book", "novel", "pamphlet" replacing "book1", "novel2" and "pamphlet4" this will avoid wrong usage.

The instructions for these 3 schemes have been changed accordingly.

The usage of these 3 schemes is now much easier to remember:
auxiliary_program document first_page last_page temp_file_prefix
execute ram:script1
execute ram:script2
gs -sDEVICE=tp24 -dBATCH -dNOPAUSE hd:temp_0.ps
gs -sDEVICE=tp24 -dBATCH -dNOPAUSE hd:temp_1.ps ; FORWARDS REINSERTION
OR
gs -sDEVICE=tp24 -dBATCH -dNOPAUSE hd:temp_2.ps ; REVERSE REINSERTION

2 bug fixes: when I first implemented them the thumbnail and pamphlet schemes both functioned. But when implementing later features I rearranged that code and it now malfunctioned.

Thumbnail and pamphlet are now functioning correctly again.

I'll retest all the other recent features in case any bugs are there too.

============ Thursday 21st July 2005 =========

In response to a request I've created one further feature: BOOKS.

This will take a pdf document say doc.pdf and output 2 ps documents, say hd:temp_0.ps and hd:temp_1.ps.

hd:temp_0.ps will contain the odd numbered pages and hd:temp_1.ps the even numbered pages. That way you can print the odd numbered pages, reinsert the paper and then print the even numbered ones getting a double sided printout. If there are an odd number of pages there will be one extra blank even page to prevent the numbering getting out of synch. Also you can choose whether the even numbered pages are in reverse order.

I've made a slight change to the recent pamphlets and novels features so they now output hd:temp_0.ps and hd:temp_1.ps, this is just for future compatibility.

============ Monday 18th July 2005 =========

11pm: I've had some feedback that a full install of GS850 led to crashes, I recently modified gs850core.lha to include pdf2ps.amiga and this may have decompressed incorrectly: ISTR that although I generate the archives with Geekgadgets that Geekgadgets doesnt decompress them properly, whereas I think OS3.9's Unarc does decompress properly.

I've regenerated the archive again, luckily I backed up the archive before decompressing it, if anyone runs into probs with the new install contact me ASAP so I can try and correct this.

I've done a full fresh install to ram: of the current downloads and tried out the billboard feature with the just the whoosh24 viewer enabled and everything functioned fine. So I think the downloads are all clean now.

On my system script flags all seem to be lost from the downloads, so you will need to do
protect xyz +rwds

on each script file that the shell says isnt a script file, eg gs850data:pdf2ps.amiga,

Try out all features directly from the shell before using non shell approaches as the shell will give informative error messages.

Earlier progress report: I've enhanced the BILLBOARDS feature mentioned yesterday:

The feature now only displays the precise image to be cut out,

BEWARE: GS850 devices have their own margins, so the overlap factor needs to be bigger than the margin: this means you need to use the smallest two numbers (4 and 8 in the billboards documentation). On my printer 4 and 8 are fine, the smallest allowed value is 2 where each image overlaps with half of its predecessor. If on your printer there are gaps between frames you need to reduce these 2 parameters.

So 2 will function, 3 should function and 4 probably will function:
assign c: gs854:bin gs854:lib add
billboard "-dFirstPage=3 -dLastPage=3" doc.pdf 10 script0 temp gs850:bin/view1 2 2
execute script0

:is the wasteful command using 2 everywhere that always will function. Although not mentioned in these commands all the work is done by GS854.

I've tried this out with tiger.eps and consecutive frame boundaries match with total precision. This will reduce the effort of reassembling the frames into a bigger image. In fact you only need to cut along 2 edges: the right edge and the upper edge: the remaining overlap then allows vertically and horizontally consecutive frames to be glued together.

BUGFIX: in yesterdays upload I found there was a bug with the height, I'd wrongly used the width instead of the height in one place in the code. This has been corrected.

============ Sunday 17th July 2005 =========

I've implemented one further feature in GS850: BILLBOARDS.

The idea of billboards is to create a large picture made of many pages joined together. This is how they make billboards, I've seen them do it: they have lots of paper rectangles they glue to the billboard creating the advertisement. :from a distance you dont see the joins between the rectangles.

With my implementation you specify a magnification eg 3 and horizontal and vertical overlap factors as there are gaps between consecutive images.

Please read the progress reports since the 15th for the various other recent new features implemented.

Billboards is the most difficult of the new features to use, second most difficult is pamphlets, then novels, thumbnails and landscape are the most straightforward to use.

IMO novels are the most useful of these new features.

thumbnails IMO are good for planning huge printouts. eg for the 1200 page document I mentioned, my plan is to print maybe the first 80 pages as 4 x 4 thumbnails on 5 sides of 3 a4 pages and then plan how to do the full printout via several novel printouts.

============ Saturday 16th July 2005 =========

8pm: with the novel and pamphlet schemes mentioned today and yesterday, note that script4 is quite time consuming, you can monitor progress of the mechanisms via "list hd:temp#?" where hd:temp is the temp file prefix of either scheme. Pages are generated in an erratic order. One other thought, with really huge documents eg there is a 1200 page document I want to print out a good idea is to subdivide it into "volumes" of a few chapters where each volume (group of chapters) is done as another pamphlet/novel volume. In particular with the novel scheme you can then create a series of booklets covering the whole document. A 1200 page document would be 1200/4==300 a4 pages with the novel scheme, a booklet of 30 a4 pages seems feasible so maybe that could be 10 booklets.

I've customised GS850 so it now does NOVELS.

This fits 2 document pages per physical page side, so if you doubly print the pages they reassemble into a novel.

It is similar yet different to the pamphlet scheme mentioned in yesterdays progress report.

IMO this is the most useful way to print documents: firstly there is no cutting involved, secondly the page size seems right approx the size of a novel page via A4, and thirdly it allows 4 pages per page which is economical. eg a 100 page document will take 25 A4's.

For pamphlets and novels you need to download pdf2ps.amiga and copy it to GS850Data:

For both the pamphlet and novel scheme I've changed the default to be the same as on my printer to simplify creating the upload, so now the default is to reinsert the pages in reverse order. Just copy script3_normal and script3n_normal to script3 and script3n respectively in gs850:bin if you want to reinsert in the same order.

For both schemes also make sure to wait till the paper has cooled down before reinserting otherwise the printer may lose its grip.

As an example of the NOVEL feature if you print a 9 page document this way, you get numbers:
[2 . : . 1][4 9 : . 3 ][ 6 7 : 8 5]

:putting the 9 pages onto both sides of 3 a4 pages, you then column up these pages fold in half and staple or stitch into a novel.

I've tried this out just now and it really looks like a booklet that accompanies a commercial product.

============ Friday 15th July 2005 =========

I've customised GS850 so it now does THUMBNAILS, PAMPHLETS, and LANDSCAPE.

:available for all printers and viewers.

I mentioned landscape yesterday, I've changed the way its invoked so read the above link even if you've tried yesterday's binary.

Thumbnails allows you to have eg 4, 9, 16, 25 ... pages printed on one page, eg if you specify a thumbnail factor of 3 you get 9 pages on one page arranged thus:
1 2 3
4 5 6
7 8 9
10 11 12
13 14 15
16 17 18

The pamphlets feature will print 4 pages on each side of a page, if you cut these along the horizontal bisector the resulting cut pages can be placed in a column and stapled or stitched into a brochure.

eg for a 30 page brochure the first page will have on one side:
2
4 29

and on the other side:
. 1
30 3

you then cut 4 29 from 2 ., and 30 3 from . 1 on the other side of 29 is 30 and on the other side of 2 is 1,

The second page has on one side:
6 27
8 25

and on the other:
28 5
26 7

You can then stitch together lots of pamphlets into a book, and thereby join the home publishing revolution!

Turn the most fearsome documents into dinky pamphlets.

I've always wanted to implement these features but couldnt see how to do it, after studying Christoph Poelzl's request for landscape I realised the right way to do it.

As soon as I have some time I'll implement a 2 x 1 brochure where you have 2 pages on each side. This will probably be more useful than the 2 x 2 brochure just implemented.

The great thing about the pamphlet idea is that say a 100 page document will fit on 13 pages, greatly reducing wastage and cost.

A 1000 page document will fit in just 125 pages.

============ Thursday 14th July 2005 =========

In response to a request by Christoph Poelzl I've customised GS850 so it now can print in landscape.

Other techniques for doing landscape dont seem to function.

You need the new binary and pdf2ps.amiga.

To print/view in landscape say annots.pdf,
assign c: gs850:bin add
set GSLANDSCAPE 1
pdf2ps.amiga "" annots.pdf annots_landscape.ps

This creates a landscape PS file eg annots_landscape.ps eg view it at low res and see that its rotated by 90°:
gs -sDEVICE=whoosh24 -r50 -dBATCH -dNOPAUSE annots_landscape.ps

============ Monday 27th June 2005 =========

There was a bug in yesterdays new binary, the normal scrolling wasnt functioning, have corrected this.

download the GS850 binary again

I've checked and the scrolling is now fine as is the new reverse scrolling.

============ Sunday 26th June 2005 =========

In chronological order:

Someone requested that with the viewers I make 5 recentre the image and also that scrolling is in the reverse directions:

There is a new env variable "whooshreverse" which if nonzero makes the scroll directions the reverse. download the new GS850 binary with this

Someone asked about whether FW2PDF.lha can be made to deal with "Wide" orientation. I contacted Cary Driscoll, who has improved FW2PDF.lha (FinalWriter to PDF) for this.

Someone else asked various questions one of which I've found the answer to: how do you extract ascii from PDF or PS. I've customised ps2ascii to do this, use GS850:lib/ps2ascii_amiga by downloading gs850core.lha for this: updated today.

He also asked how to conveniently do double sided printing, I've given an explanation for a brute force way to do double sided printing. I tried -dDuplex but that doesnt do it. See the above link for a shell utility I've written for this.

Ernest Unrau contacted me and sent some Adobe Illustrator scripts he has made which he finds useful: Unrau.lha.

Right now all my time is taken up with my filesystem project, where I'm making rapid progress.

============ Monday 9th May 2005 ===========

I've found the answer to the C question I asked on the 6th, I got the answer from SASC6.50's documentation. The question is really "how do you do a directory scan in standard C?",

Answer code fragment:

#include <sys/dir.h>

DIR *dfd = 0 ;
struct dirent *dptr = 0 ;

dfd = opendir( "ram:" ) ;
if( dfd==0 )exit( 20 ) ;

while( 1 )
	{
	dptr = readdir( dfd ) ;
	if( dptr==0 )break ;
	printf( "%s\n" , dptr->d_name ) ;
	}
closedir( dfd ) ;

I need this info to do a portable version of copy_directory_to_my_fs.

============ Friday 6th May 2005 ===========

C Question: (Answered on 9th May!)

can anyone tell me how you do recursive directory scans with standard C?

I know how to do it with dos.library but not via the standard C api.

Regarding unsupported printers: Although a printer may appear to be unsupported on AmigaOS there may in fact be a GS driver out there. Far eastern printer companies such as Epson and Samsung will often have a GS driver lurking somewhere on the internet, probably beyond the reach of Google. So dont give up and run into the arms of Windows XP.

Eg I saw an interesting cheap colour laser printer and have located a GS driver and am looking into this specific printer. When buying a laser printer see if it can do A3 as that allows posters + landscape a4 and also find out how much ram it has. Low ram will prevent renders which wont fit: ie heavy duty images cannot be rendered if there isnt enough ram in the printer. Of the printers you can afford buy the one with the most ram. Dont believe the pages per minute number as actual printing is much slower. pages per minute appears to mean empty pages per minute. A heavily rendered page is much slower.

If you have seen an interesting printer which isnt supported by Turboprint contact me and I will try and locate a GS driver to build into GS850. Turboprint drivers tend to create higher fidelity images than manufacturers drivers as Turboprint has very advanced dithering + colour correction. But if there is no Turboprint driver you should use a manufacturer's GS driver instead.

============ Sunday 1st May 2005 ===========

A few changes made to the homepage, I've moved the external links away from the top otherwise people will leave before visiting!

I've also put a link to my filesystem project which is where I'm spending all my time now: major work underway creating a very advanced fully 64 bit filesystem. I've already got an unintegrated + synchronous fully 64 bit filesystem up and running on 68k eg WinUAE. Later I will make it asynchronous: one thing at a time.

I have some major further internal changes to the filesystem before I intend to start benchmarking it. My filesystem does not use dos.library.

The fact this web-page has been silent is a good sign as it means things are good as they are. As and when it seems appropriate I will reawaken the project. So its currently hibernating and GS850 seems a good release. The GS850 project is living happily ever after as story books say!

============ Thursday 24th February 2005 ===========

I've put some new links to various external Amiga websites at the top of this web-page. GS850 is in the ALD database, but I need to put some further info there sometime soon. If anyone can send me link banners for any of the URL's I will put the banner. The banner needs to be similar in size to a text link as this website is mainly ascii based.

I've received some in depth feedback on using 68k GS850 on Pegasos II (G4@1000MHz) with MorphOS 1.4.3, everything seems to be running smoothly, I may try and upload this info.

============ Wednesday 23rd February 2005 ===========

(some new info (342am) at the end of this update)

Note on emails: if you email me make sure to mention either GS850 or AmigaOS in the subject line, because I get so much junk mail that if the subject line is not familiar I delete the email.

I've been working on various GS850 things, for AROS and cybergraphics 68k the viewers now use my own rescaling code. I got feedback that control-C could crash the program. I think I have this now fixed and GS850 now cleanly exits on control-C, control-C needs to be done in the shell window and not in the viewer window.

The control-C problem was because in earlier GS's my code on exitting would make an internal call which AFPL have changed in an incompatible way without any explanation of how to use the replacement. Anyway by experimenting I have found a replacement mechanism.

Someone emailed requesting for + and - in the viewers to be alternative ways to zoom in + out. I have implemented this, also implemented are: 1, 2, 3, 4, 6, 7, 8, 9 will now move the viewer 1/2 a window in each of the 8 directions so you can move quickly around an image. You can enter these new keyboard commands either from the main keyboard or from the "calculator" keys: the idea being to use the calculator keys. The letter c will give the framecount on the shell. Later I will try and give 5 a function but it will take some study of my code to make 5 do what I want, so for now 5 doesnt do anything.

Initially I made the digits move the image exactly 1 windows distance but there was a lack of visual continuity.

The new downloads are 68k_binary_archive and x86_binary_archive.

Decompress the archive for your system to GS850:,

All new functionality is always explained in cumulative reverse chrononlogical order in this part of the website

I have various new ideas for the port but need to wait till I have a convenient time window.

342am:

If you have a fast machine with lots of memory, you can render a page at say 600dpi, and then by zooming out you retain image quality,

gs -sDEVICE=whoosh24 -r600 -dBATCH -dNOPAUSE tiger.eps

(gs here is GS850:bin/gs and tiger.eps is GS850:examples/tiger.eps)

:check the shell output to verify that the full image was rendered, if it wasnt then try a lower resolution,

with the new numeric key commands you can whizz across the image at great speed,

============ Tuesday 1st February 2005 ===========

Continuing from a question by Castellen on amiga.org Cary Driscoll has sent me a further Final Writer script, FW2PDF.lha.

Also Georg Steger has fixed an x86-AROS graphics bug in BitMapScale( ), I havent yet tried this out but he says there is a huge increase of speed with the x86-AROS GS850 viewers.

============ Friday 28th January 2005 ============

730pm: I have managed to port now the Samsung printer driver mentioned in yesterday's update. I had to rebuild the entire program from scratch, which took about 2 hours 20 minutes on WinUAE on a 2.6GHz Intel Celeron. So the GS850 port now fully supercedes my earlier GS813 port.

============ Thursday 27th January 2005 ============

AFPL Ghostscript 8.50 released today for 68020 AmigaOS and i386 AROS!

The AmigaOS version is nofpu-68020, the AROS version is i386 both builds selected for maximum compatibility.

8.50 is a major release version of AFPL Ghostscript and contains a lot of new rendering code not present in any earlier Ghostscripts resulting in improved image quality. eg GS8.50 contains new rendering code that optimises font quality at very low resolutions. The quality of line curves within images also looks improved. The program also appears to be faster than earlier Ghostscripts.

Please replace the GS813 fonts by the new gs850fonts.lha, as I got feedback of a problem from Cary Driscoll. The problem has been resolved by regenerating the entire fontset from scratch as I had lost track of how the GS813 fontset had been generated. The replacement fonts can also be used for eg GS813 and GS8.

There is just one omission from this build: I havent managed to build in the driver for my Samsung printer. I will try and build it in eventually. So GS813 is still needed for that specific purpose.

============ Wednesday 19th January 2005 130am ============

I am progressing with the port to GS850, I have run into several problems already and it is quite time consuming despite the faster machine. At the moment there is a problem with the driver for my printer as it calls a macro and AFPL have decided to add an extra argument, the original macro used a default argument which is no longer defined. So I'm trying to get around this discrepancy.

============ Monday 17th January 2005 445pm ============

I've just completed my computer holiday and have found AFPL Ghostscript 8.50 was released centrally on 11th December 2004.

So I am beginning now to port GS813 forwards to GS850. GS850 is a very stable build and meant for general release. So if you relook at the previous info updates below you will see I was right to wait for GS8.5x.

First I will do a 68020 no fpu build as this will run everywhere. Later I will attempt a sideways port of GS850 to x86-AROS.

============ Monday 8th November 2004 midnight =========

I have been told that the stable AFPL Ghostscript 8.5x will be out quite soon, maybe even this month. So I have decided that I will wait till this is released and then port it to 68k. I have allocated up to 4 weeks for this work.

Usually I dont do much computing in December, so if AFPL GS8.5x is released at the end of November my port attempt should begin by approx mid January 2005. The first week of January is usually nightmarishly cold so I'm usually too busy shivering to do anything but babble incoherently at that time of year.

I think now it is best to port on a "movable" basis: allocate a certain amount of time eg 3 weeks but not allocate when!

I certainly have the time to port GS8.32 right now, but GS8.32 is a 3rd beta towards GS8.5x and GS8.32 has known critical bugs such as which the AFPL people are working on right now. So it would be an error to port GS832.

By porting GS8.5x, 68k will be bang up to date for many months, also Morphos and x86-aros versions should follow: but the first priority will be to port the 68k version. The Morphos version will probably only run on very recent Pegasos II's.

============ Sunday 7th November 2004 10pm =========

10pm: Things get complicated, I was about to begin on porting Ghostscript 8.15 when I noticed that it is GPL and not AFPL. Yet it supercedes Ghostscript 8.14 which is AFPL. This is slightly annoying as I dont really want to partake in GPL. Trying to change license is too complicated and I am not too keen on GPL.

So I am trying to find out when AFPL Ghostscript 8.5x is planned, if this is quite soon I may wait till it is out and port that. If it isnt for some time then I will now port AFPL Ghostscript 8.32 the 3rd beta towards 8.5x. This would contradict some of my intentions mentioned recently, where I said I wanted to target GS's which have been out for a healthy amount of time. But AFAICS the most recent stable AFPL GS is 8.14 which seems too nonrecent, and GPL 8.15 is said to fix bugs in 8.14,

Conclusion: my plans are changed now to either GS8.32 now or wait a bit and port GS8.5x very soon after it is released: this could be in January though.

It seems there are 3 different GS's, AFPL, GPL and GNU,

============ Saturday 6th November 2004 sunset =========

I should have read the small print!

ok, further to what I said on 31st Oct below:

I have decided to begin porting AFPL Ghostscript 8.15 to 68k AmigaOS, and it seems I probably shouldnt have ported 8.13, no harm that I ported it but I probably shouldnt have, this is why:

Timeline: 
29th August:  version 8.31 2nd beta, 
23rd Sep:     version 8.15 first release of 8.1x, STABLE,
26th October: version 8.32 3rd beta towards 8.5x,

So it seems that 8.13, 8.31, 8.32 are only for internal purposes, thus the only *correct* port to do now is 8.15, and after 8.15 the next *correct* version would be 8.5x. As you can see 8.15 though numerically less than 8.31 was released *after* it,

The current 8.13 is fine, but I was somehow aware that 8.00 was a better program in its own right: eg 8.00 was better behaved on Morphos than 8.13. So it seems that there was a basis to this perception. I wonder how many other Ghostscript ports shouldnt have been done!

Trust me when I say this: only *stable* releases should be targetted, stability is much more important than currency. Stable releases always have an undefinable extra something (zhe ne se kwa?), hmmm... maybe what they have is definable and is stability! (zhe se kwa??)

Try and download to storage *all* archives related to 8.13 on this webpage as 8.13 will be removed once 8.15 is ready: as there isnt enough webspace for both versions. In particular download the x86-aros version of 8.13 ASAP eg now, if x86-aros interests you in any way, because after 68k 8.15 is completed there will be a time interval with *no* x86-aros Ghostscript on this page.

============ Sunday 31st October 2004 midnight =========

midnight: further to what it says in the "sunset" update below, I will say on this webpage which version I decide to target, right at the outset. The work will firstly be on a new 68k GS version (68020 fpu and 68020 nofpu). After the 68k version is complete I will then port the 68k version sideways to x86-AROS. The priority is on the 68k version, and the main time window for the work will be 6th Nov to 30th Nov 2004.

sunset (6pm): Approximately 1 week into November I will begin new work on Ghostscript, I will probably try and target the most recent stable version of GS rather than the most recent version. So if the newest version has been around for say 1 week I wont target it, and if the version before that wasnt around too long I wont target that. The reason for this unusual approach is that some versions of GS can have problems, so the assumption is that a version which has been around for a long time must have been a particularly good version.

So eg GS8 was a particularly stable version, and GS813 was soon superceded by GS814 which I think was around for quite a long time. So GS814 would have been a better choice than GS813.

I have absolutely no idea how long the port will take, but I hope it could be done within two weeks.