[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    [9fans] tiff(1) for page(1)
From:       lucio () proxima ! alt ! za
Date:       2008-03-28 19:17:18
Message-ID: 5d599c7abe2b9a0625e06c573b2edb10 () proxima ! alt ! za
[Download RAW message or body]

I have borrowed much of jpg(1) to produce a similar tiff(1) that I
successfully integrated with page(1) (more or less: it disobeys the
injunction:

/*
 * N.B. These commands need to read stdin if %a is replaced
 * with an empty string.
 */

and I don't think I can sensibly address that aspect).

There are many sample TIFF images it can't render, I need to
understand the TIFF library better before being able to comment or,
preferably, fix these problems.

One problem this mailing list may be able to assist me with involves
producing image files.  I can successfully generate RGB24 (also
labelled CMAP8 within jpg(1) - three colour channels, no alpha) files
from RGBV images, but any attempts at dumping what look like perfectly
reasonable RGBA32 images that happen to be the "natural" format
delivered by libtiff, results in, apparently, blank images or, in the
one FAX instance I used for testing, at best some blue text where it
ought to be black.  This would be using -9 or -c and making RGBA32 the
default target format.

Displaying the generated RGBA32 images (allocimage(), loadimage())
works just fine for RGBA32 and, to the extent that I tested things,
even for the monochrome, colour-mapped and three-colour formats, I'm
not sure that I have successfully covered all the jpg(1) options.

I borrowed code from /sys/src/cmd/jpg/^(torgbv totruecolor) quite
liberally so tiff(1) can display or write to stdout all the jpg(1)
output formats I manged to grasp, but I cannot find a valid,
functional example of writing an RGBA32 "frame buffer" to stdout.  The
temptation now is to display the image and writeimage(2) the produced
structure, but that abuses a window, while using the memdraw(2)
facilities is not readily available until someone actually ports
memdraw(2) to APE (I think I already did this, but I didn't want to go
off on yet another tangent, I've been hacking at this way too long
already).  Even with memdraw(2), I think the approach -
allocmemimage(), loadmemimage(), writememimage() - would seem at best
inelegant.

Anyone who wants to improve this tiff(2), please let me know; give or
take the need for the libtiff library, it is pretty much a standalone
application, anything I borrowed from /sys/src/cmd/jpg/ I incorporated
into the source rather than attempt to link to an alien directory.  I
changed enough in an attempt to simplify things to the point I could
understand them that the relationship will be hard to maintain.  But
having the code more or less self-contained seems like a good thing in
this instance.  At 929 lines, it is tempting (but futile) to include
it in this message.

++L

PS: Sorry if the above is a bit rambling, there were so many different
code paths, options and possibilities, it's been very hard for me to
keep track of all the issues.  I'm hoping the source will speak for
itself.


[prev in list] [next in list] [prev in thread] [next in thread]