Personal info for ajv
This person is currently certified at Journeyer level.Name: Andrew van der Stock
Homepage: http://www.greebo.net
Notes: Lead developer on pnm2ppa
Recent diary entries for ajv:
Hi everyone!I'm the currently anointed pnm2ppa maintainer, and I'd like to get it in as real Ghostscript driver. But as some of you know there's a few things we need that Ghostscript doesn't yet do.
Raph and I had a great conversation earlier this year at my LCA speakers' BBQ, and now's the time for me to follow through and start the process.
In the meantime, HP finally released the drivers they mentioned in one of the many e-mails we had with them.
The paraphrased form of nearly all these e-mails is:
pnm2ppa project: can we have the specs for our printers? We don't want to break them* HP: No. They contain color matching IP which cost HP millions in R&D. pnm2ppa: we don't want color matching stuff, we do not want to break our printers, and it'd be nice to know when the printer was out of paper or had a paper jam. HP: tough.
* pnm2ppa printers are REALLY dumb. It's possible to send raw garbage to them that will permanently kill them. Blinkenlichter von der Hölle.
Anyway, most recently I mailed the HP project manager of the new inkjet drivers with the repeated offer of wishing to work with them to port our drivers to their architecture, but have received no response.
Moving forward, printing devices like ours need lots of host based help. At the very least, we need:
* cleaning helpers (it's possible to dump the windows sequences to them, but...) * calibration helpers (we've written one that works) * persistent calibration storage (we use /etc/pnm2ppa.conf) * persistent color map storage, not all pen heads are the same * A method to not temporarily need > 100 MB per page * A method to not receive > 100 MB per page in raw image data via a pipe (the context switches alone kill performance)
We solved some of these problems, but some of them are only fixable by being in-process, and that process being cognizant of our needs.
We need banding support (this is to maintain a small memory footprint), which we emulate by handling small chunks of the pnm input image. Also, we could really speed up if we could stash a little more information so we can do the stepped printing technique that HP uses in their Windows drivers. This is a simple process. In pass L-R, the color inks are fired. The page is shifted down roughly 1/2 the print head (normal mode), and then the R-L pass fires the black head on the top half and the color head on the bottom half. This avoids smearing and liquid ink pools and speeds up printing considerably, whilst removing most banding artifacts for near zero cost in head speed. Trapping causes the above to be not quite what I've mentioned, but for practical purposes, it's close enough.
Lastly, the ability to pick among many decent dithers on the fly based upon content. We implement about three at the moment, but once chosen, the entire job is done using it. We cannot easily tell the difference between text and graphics. GDI does this by having "text" bounding boxes, where no dithering is done. This speeds up rendering and printing, and allows the text to look amazingly sharp.
Looking forward to participating. I develop on NetBSD/alpha, and can compile on x86 Linux and Win32.
This person has certified others as follows:
- ajv certified ajv as Journeyer
Others have certified this person as follows:
- ajv certified ajv as Journeyer
- raph certified ajv as Journeyer
- Jan certified ajv as Journeyer
- Mike certified ajv as Apprentice
- tschingsy certified ajv as Journeyer
[ Certification disabled because you're not logged in. ]