[Files] AFPL Ghostscript 8.13 ported to i686-AROS | ANN.lu |
Posted on 01-Jun-2004 01:40 GMT by whoosh | 8 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 articleSorted by date, most recent at bottom |
Comment 1 | Joe "Floid" Kanowitz | | 01-Jun-2004 02:56 GMT |
Comment 2 | Anonymous | | 01-Jun-2004 08:17 GMT |
|
AFPL Ghostscript 8.13 ported to i686-AROS : Comment 3 of 8 | ANN.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, |
|
List of all comments to this article (continued) |
|
- User Menu
-
- About ANN archives
- The ANN archives is powered by #AmigaZeux. It was updated daily (news last: 22-Oct-2004; comments last: 18-May-2005).
ANN.lu was created, previously owned and maintained by Christian Kemp, www.ckemp.com.
- Contribute
- Not possible at this time!
- Search ANN archives
- Advanced search
- Hosting
- ANN.lu was hosted by Dreamhost. Sign up through this link, mention "ckemp" as referrer and he will get a 10% commission on any account you purchase.
Please show your appreciation for any past, present and future work on ANN.lu by making a contribution via PayPal.
|