[9fans] anyone attempted to build ghostscript recently?

[Steve Simon]

Thinking of tackeling ghostscript again but failed at the first hurdle,
it needs autotools to build...

Anyone attempted this?

-Steve

[erik quanstrom]

Post by Steve Simon
Thinking of tackeling ghostscript again but failed at the first hurdle,
it needs autotools to build...

oh please do!

one question, though. are there better alternatives than ghostscript
for pdf? ghostscript usually fails for simple documents on my amd64
machine with (to me) inscrutible postscript stack traces. i find that
often ghostscript also fails on linux for the same document, but e.g.
evince does not.

- erik

[Kurt H Maier]

Post by erik quanstrom
one question, though. are there better alternatives than ghostscript

evince is a poppler frontend; poppler's problematic dependencies include
glib and cmake. poppler is descended from xpdf, whose problematic
dependencies are include freetype and motif, although I believe the
actual pdf rendering code doesn't invoke any motif.

khm

[David du Colombier]

Post by Steve Simon
Thinking of tackeling ghostscript again but failed at the first hurdle,
it needs autotools to build...
Anyone attempted this?

Ghostscript 8.53 was already using autotools, but Russ Cox wrote a
mkfile for it when he ported it to Plan 9.
The current mkfile is already able to compile Ghostscript up to 8.63,
with almost no change. However, I'm only using Ghostscript 8.56, since
I wasn't able to run the following releases properly.

You could probably use the current mkfile as a base and expend it.
There are probably changes needed in the code that should be pushed
upstream.

--
David du Colombier

[Steve Simon]

Post by David du Colombier
Russ Cox wrote a
mkfile for it when he ported it to Plan 9.

thanks,

yes I looked at ghostscript a year or two ago but they seem
to have changed their directory layout and modifying the mkfile
was not straightforward.

My need is for postscript to pcl6 for the printer we have, currently I
run ghostscript under linuxemu which works but I I would prefer to have
a working native port.

I will try again.

-Steve

[t***@polynum.com]

Post by Steve Simon
My need is for postscript to pcl6 for the printer we have, currently I
run ghostscript under linuxemu which works but I I would prefer to have
a working native port.

Since I had to try to print to an HP with PCL (in fact, with HPGL
embedded in PCL, with job dispatched by PJL...) I looked for a direct
whatever to HPGL (there was a now nuked program in cups in the
early days) or for whatever to PCL. I have not managed to get a
working ghostscript combination that can be swallowed by the HP
big designjet, so I have read the ghostscript sources and the
cups sources.

Problem: there is a mixing of PJL directly in the drivers (while PJL
should be left outside for what it is: embedding printer jobs---lp
level); cups uses ghostscript mainly to rasterize a PS document and then
to produce PJL and PCL commands to embed this image in a job the PCL
printer can eat.

For the task at end, you might have more success by using the
Ghostscript shipped by Plan9 to create a raw image (à la cups)
and to write the filter to embed this image in PCL commands, and
these in PJL (PCL and PJL are now finally documented by HP).

If you have a network connected printer (or a printer connected to a
bi-directional parallel port) to discover what is supported by the
printer, use PJL (sh(1) example used from an Unix):

------------
#!/bin/sh
#

# lpd status.
#
LPD_OK=0
LPD_ERROR=1
LPD_FATAL=2

PJL_UEL='%-12345X' # Universal Exist Language : sentry

PJL_LANGUAGE_SWITCH='E' # for printers supporting several languages

# If used as a filter for lpd, it has to have "something".
#
cat >/dev/null

# Opening the job.
#
printf '%s' $PJL_UEL

# Ensure we send us something.
#
printf '@PJL USTATUS DEVICE=VERBOSE\n'

# A custom string is echoed because there can be informations sent to
# someone else for something else. This is to now this is linked to our
# request.
#
printf '@PJL ECHO KerGIS requesting config %s\n' "$(date -u '+%F %T')"

# If the printer does not support the category, the answer is:
#
# "?" <CR><LF>
# <FF>
#
# Hence, we ask for everything hoping to have something...

# INFO
#
printf '@PJL INFO ID\n'
printf '@PJL INFO CONFIG\n'
printf '@PJL INFO FILESYS\n'
printf '@PJL INFO MEMORY\n'
printf '@PJL INFO PAGECOUNT\n'
printf '@PJL INFO STATUS\n'
printf '@PJL INFO VARIABLES\n'
printf '@PJL INFO USTATUS\n'

# INQUIRE et DINQUIRE.
#
printf '@PJL INQUIRE PERSONALITY\n'
printf '@PJL INQUIRE RESOLUTION\n'
printf '@PJL INQUIRE RESOURCESAVE\n'

# End of job
#
printf '%s' $PJL_UEL

exit $LPD_OK

[t***@polynum.com]

Post by Steve Simon
Thinking of tackeling ghostscript again but failed at the first hurdle,
it needs autotools to build...

Plan A, create a SmallScript borrowing the rasterizing routines of
METAFONT and not aiming to be a full PostScript interpreter.

Plan B, get rid of PostScript altogether and use TeX and METAFONT and/or
fonts available with the glyphes, and render directly from dvi to pdf,
dvi to raw (image), dvi to pcl; even using virtual fonts to render
approximately fonts not present with glyphes definition for
previsualisation, and using dvips for direct printing to real
PostScript interpreters (with embedded compliant PostScript standard
fonts).

Isn't there a sentence about "wanting a banana, and being forced to
have a Gorilla handing the banana with the whole jungle around"?

[a***@9srv.net]

...and how does that help me read a pre-existing PDF document?

[t***@polynum.com]

Post by a***@9srv.net
...and how does that help me read a pre-existing PDF document?

Reading a pre-existing PDF document does not need ghostscript. PDF
is supposed to be in the dvi class, and predigested rendering. So it
should be easier to "port" a PDF library... except that the existing
ones are C++ and there is an inflation of "interactive" features (that
keep Adobe cutting edge even if the language is documented and royalty
free).

So, reading existing things is one thing. Producing things that we are
unable to render is another one. You may have the obligation of the
former; not the latter. This the sense of my comment.

[Jack Johnson]

Is a PS/PDF library something that might benefit from reconstruction in Go?
Or is it just a spaghetti mess?

[erik quanstrom]

Post by Jack Johnson
Is a PS/PDF library something that might benefit from reconstruction in Go?
Or is it just a spaghetti mess?

go or c, a fresh implementation might be an improvement,
and given the weight of some of the other options, might be
more time-efficient than one would think.

- erik

[pmarin]

What about mupdf? It has few dependecies [1]

http://mupdf.com/doc/
[1] http://git.ghostscript.com/?p=mupdf.git;a=tree;f=thirdparty;hb=HEAD

pmarin.

Post by erik quanstrom

Post by Jack Johnson
Is a PS/PDF library something that might benefit from reconstruction in

Go?

Post by Jack Johnson
Or is it just a spaghetti mess?

go or c, a fresh implementation might be an improvement,
and given the weight of some of the other options, might be
more time-efficient than one would think.
- erik

[Jeff Sickel]

Post by erik quanstrom

Post by Jack Johnson
Is a PS/PDF library something that might benefit from reconstruction in Go?
Or is it just a spaghetti mess?

go or c, a fresh implementation might be an improvement,
and given the weight of some of the other options, might be
more time-efficient than one would think.

There are several somewhat portable pdf rendering libraries
out there. Some with mostly C and a little sprinkling of
C++ (like mupdf.com). If we had a Javascript interpreter
and support or SVG then https://wiki.mozilla.org/PDF.js
might be an option once that group irons out the kinks.

-jas

[t***@polynum.com]

Post by Jack Johnson
Is a PS/PDF library something that might benefit from reconstruction in Go?
Or is it just a spaghetti mess?

Whatever the way (porting existing to Go or writing from scratch), a Go
version would be an improvement against a C++ one with gigabytes
of dependencies. This may be (partly) achievable with a PDF library,
I doubt something like Ghostscript is achievable (and I even wonder if
that makes sense to reimplement a full PostScript interpreter).

The problem is: if this is just to render documents created on Plan9,
a minimum is required, but one could get rid entirely of PostScript or
PDF. If this is to view an external PDF document, or to render an
external PS document, that may use the latest version (for PDF) or a lot
of features (for PS), you're skrewed. But in this case, there are
probably online PDF viewers...

[Aram Hăvărneanu]

Post by t***@polynum.com
But in this case, there are
probably online PDF viewers...

But no Plan 9 browsers.

--
Aram Hăvărneanu

[t***@polynum.com]

Post by Aram Hăvărneanu

Post by t***@polynum.com
But in this case, there are
probably online PDF viewers...

But no Plan 9 browsers.

Yes... But this is also why, concurrently, work has to be done to get
rid of some unnecessities: that documents produced on Plan9 be viewable
on Plan9 with only Plan9 means (external documents are another problem).
And this is why I prefer TeX other *roff: not because of some religious
war; but because TeX is a whole system, including fonts and mean to
make them, and there is a shortest path to full autonomy. (And this is
why kerTeX will still produce DVI, even with extensions, and not
directly PDF.)

What would be fun would be a... PDF to DVI converter (because it will
mean a huge part of "dropping" features---/dev/null is something I can
not do without.)

[erik quanstrom]

Post by t***@polynum.com
Yes... But this is also why, concurrently, work has to be done to get
rid of some unnecessities: that documents produced on Plan9 be viewable
on Plan9 with only Plan9 means (external documents are another problem).

ghostscript already renders plan 9 produced pdf just fine.
so that problem is solved, and there's no need to do anything.

what we need is better access to externally produced documents.

- erik

[Jack Johnson]

Post by erik quanstrom

Post by t***@polynum.com
Yes... But this is also why, concurrently, work has to be done to get
rid of some unnecessities: that documents produced on Plan9 be viewable
on Plan9 with only Plan9 means (external documents are another problem).

ghostscript already renders plan 9 produced pdf just fine.
so that problem is solved, and there's no need to do anything.
what we need is better access to externally produced documents.

So, skipping interactivity, what about a pdf2pdf filter?

-Jack