I have put in /n/sources/contrib/lucio/pub/npng.c a PNG renderer that
uses the Open Source libpng library: <http://www.libpng.org/pub/png/>.
There is also a man page (npng.1) that roughly describes its behaviour
but is not (yet) totally accurate; I'm going to try to catch up with
the inaccuracies in the next few hours.

Its most significant feature is that it can render 24-bit and even
48-bit PNG images and that it can convert, seemingly successfully,
colour pictures to grey-scale.  On the other hand, much discussion
with Russ Cox has not yet convinced me that there isn't an error
outside of my code that causes α-blending to break.  As a result I
have defaulted (as documented) the behaviour of npng to strip the
α-channel and I'm hoping that someone else will inspect the pertinent
code and help me correct its behaviour.  Strangely, grey-scale
operation does not seem to be affected.

There are a couple of less fundamental issues that I would also
appreciate comments on, they are described in the BUGS section of the
man page.  Ideally, npng ought to be a plug-in replacement for png(1),
but there are inconsistencies that may or may not be addressable.
Comments in this regard will also be readily accepted.

I have at the same time submitted patches to those APE headers
(/sys/include/ape/*.h) that provide non-Posix/ANSI enhancements to
make them somewhat easier to use, but very much in a Unix-oriented
fashion, almost certainly diverging from conventional Plan 9 practice.

These changes are mandatory to be able to build npng, but not for the
libpng and zlib libraries that are its prerequisites.  Complete
library distributions, with mkfiles, for the most recent versions of
zlib and libpng as well as mkpublib, required by these mkfiles as
</sys/src/pub/mkpublib, are also available in
/n/sources/contrib/lucio/pub.  The directory mirrors /sys/src/pub
which is my convention for Open Source and possibly other
APE-dependent ports and tries to resemble /sys/src/cmd as closely as I
can manage.  I haven't yet decided whether to strip these directories
of irrelevant branches (libpng/ada comes to mind) or keep them for
consistency.  Perhaps they ought to be strictly in CVS format (but
then one may need subversion and other options), export or work
directory, but that is not up everyone's alley.

Suggestions welcome, other than attempts at imitating what Boyd may
have said under the circumstances, I reserve the right to guess that
for myself.

Ideally, I'd like to migrate all APE projects to /sys/src/pub (gs,
awk?, cvs, etc.) and thus draw a more accurate boundary between
strictly native applications and APE-dependent ones (the name
/sys/src/ape is already reserved for the APE system itself).
/sys/src/ape/cmd ought to shed a couple of entries in favour of
/sys/src/pub, but that is not exactly a crucial issue.  I'll probably
release the latest diff, expr, gmake, patch, pax, pdksh and sed in
this new home, as soon as I need them.

I've also added /sys/man/^(1 3 5 6)^pub locations for the man pages
from Open Source projects, even though these are not in exact
synchronisation with how Plan 9 interprets the section number.

I make no apology for flaunting Plan 9 conventions (I'm specifically
referring to the inclusion of prerequisite header files within other
header files, I clearly recall Rob Pike's argument against doing
this).

My long-term goal is to create an environment that makes it as easy as
possible to port Open Source projects to native Plan 9.  I must
confess that it is not yet clear to me how this will be achieved, I
think it is a tangential but convergent approach to what Russ Cox is
doing with P9P.  Any suggestions on how best to blend these efforts
are also welcome.

To return to npng, libpng and zlib, it has been easy, almost trivial
to shoehorn the libraries into APE, once a mkfile was constructed.
Originally I started with a distribution that had been "./configure"ed
on NetBSD, but it turned out to add no value whatsoever to my efforts
(now that I think about it, it may have helped to produce a "plan 9"
object directory, I'll look into that).  I have tested these libraries
as widely as possible and npng was the offshoot of such testing.  Any
errors should ideally be reported to me.

I could use some advice on how best to tweak these libraries to remove
completely their dependence on APE.  Both of them make trivial use of
<stdio.h> and more or less allow it to be replaced by a native
offering, but I haven't been able to make the necessary adjustments.
Anybody interested in such a development is welcome to contact me on
or off list(*).  It is non-trivial, as the dependence on Posix
features increases as one gets higher on the ladder and jpeg, gd, tiff
and geotiff all need to be able to interface successfully to such
modified libraries and, ideally, in turn be free of APE dependencies
themselves.

Error handling in libpng has also not received due attention, here I'm
very much on a limb, not knowing how to implement it.

(*) My mailer will filter out messages from unregistered senders to a
separate folder which I then inspect more or less regularly.
Contacting me on this list will allow me to register new senders.