29-Mar-2024 13:19 GMT.
UNDER CONSTRUCTION
[Files] AFPL Ghostscript 8.13 ported to i686-AROSANN.lu
Posted on 01-Jun-2004 01:40 GMT by whoosh8 comments
View flat
View list
I have recompiled my 68k AFPL Ghostscript 8.13 port to i686-AROS. Outside of the viewers everything appears to be functioning, and within the viewers just the truecolour WB viewer for PS and PDF is functioning. revisit http://www.whoosh777.pwp.blueyonder.co.uk This port was done using my recent port to 68k host of the x86-AROS gcc-3.3.1, so the one port was used to port the other port.

Of the 6 viewer options just the most useful one functions!

With the truecolour WB viewer the colours and image are completely correct, and the viewer is very responsive.

Possibly the other viewers dont function because of endianess, so I will look into this possibility,

The 5 non functioning viewers just produce either an empty window or a window with correct image but wrong colours.

As Turboprint hasnt been ported to x86-AROS, the Turboprint devices cannot currently be used but are compiled in,

The port is a very clean port, the few hitches which occured were quite painless. There were no missing API calls at the linker stage,

I will next be attempting ports of AFPL Ghostscript 8.13 to other AmigaOS variants,

:these other ports will be attempted first before trying to fix the 5 non functioning viewers of this port.

The port takes 3.5 hours to build on WinUAE and the resulting binary is 3.2mb,

List of all comments to this article
Sorted by date, most recent at bottom
Comment 1Joe "Floid" Kanowitz01-Jun-2004 02:56 GMT
Comment 2Anonymous01-Jun-2004 08:17 GMT
AFPL Ghostscript 8.13 ported to i686-AROS : Comment 3 of 8ANN.lu
Posted by whoosh on 01-Jun-2004 22:46 GMT
In reply to Comment 1 (Joe "Floid" Kanowitz):
@Joe "Floid" Kanowitz

/*
Nice!

I suppose GSView (or some other sane 'viewer') may be the real solution to
any zooming annoyances, unless it isn't...
*/

I've run out of time with regards this particular project area for
GSView or any other variants of the concept,

my time will now be channelled to other programming projects,
GS itself will continue getting time but it will be very carefully
measured

so the Ghostscript project now is maintainance and porting only,
ie fixing bugs, bringing forwards the version number, and
bringing the code to new OS hosts,

in the end I decided that the way my port currently does things is
sufficiently adequate,

right now the program does a lot, it could do even more but its more
trouble than its worth,

the useful thing about Ghostscript is that it is an all rounder,
and also it is self contained,

my real interests are in writing original code from the ground up,
that way there are no license issues and I *own* the IP in its entirety,
I can also control and understand the work in its entirety, which is
usually not possible with open source,

with open source you blow months of time battling with nightmare
frameworks, open source is completely designed to be impenetrable
and unenlightening

ie open source is usually only truly open towards the compiler, not towards the
human(s),

/*
Could an 'interactive' output device be a possible hack
(output being only the area requested, at a given scaling, everything else
rendered to the bit-bucket), or can rendering rely on actual pixels in whatever
the output data structure is, making that a wrong tree?
*/

GS operates in terms of horizontal bands, so only horizontal bands that
intersect with the actual render get computed,

you can also put vertical barriers, the problem I ran into is that
the GS internal API doesnt seem to provide a way to revisit the same page at a
different resolution with different vertical and horizontal boundary,

so I could only see how to visit each page once, each page can have a
totally different resolution and positioning etc, but you cannot
re-render that page in a different way: you can only move on to the
next page,

GS is designed from the POV of printers rather than of viewers,
so my viewers operate by pretending to be a printer device,

my viewer only computes a local subset of the full image,
something like 2 x the viewer window size,
so if you shrink the window rendering will speed up quite drastically,

eg halve the viewer window and rendering will speed up 4 x ,

ie its a virtual image, the parts beyond the window mostly dont exist
until you try to look at them, this is to reduce the time and memory usage,

This time I got the license requirements done correctly
before making the announce,

I will now be attempting ports to some other AmigaOS variants,
Jump...
#6 Joe "Floid" Kanowitz
TopPrevious commentNext commentbottom
List of all comments to this article (continued)
Comment 4whoosh01-Jun-2004 23:04 GMT
Comment 5justnotbill02-Jun-2004 06:51 GMT
Comment 6Joe "Floid" Kanowitz02-Jun-2004 13:27 GMT
Comment 7whoosh02-Jun-2004 16:48 GMT
Comment 8whoosh03-Jun-2004 20:17 GMT
Back to Top