[Foomatic] Driver maintainers?

Stian Sletner stian at sletner.com
Wed Oct 13 03:30:22 PDT 2004


* At 2004-10-13T01:20-0400, Grant Taylor wrote:
: 
| Hmm.  There used to be a spot of overview text and a simple picture
| somewhere, but I think it was in the HOWTO, which died long ago.
| 
| For now there is the cups quickstart page, which is written for users,
| and some user pointers through the printer and driver database pages.
| Much of the rest is developer or distributor focused.
| 
| A secondary problem is that every distribution is slightly, or even
| grossly, different.  I've been doing this for 12 years now and this
| problem just keeps getting *worse*, not better.

Yes, this is a problem, but perhaps with a wiki approach, many of the
variants could be covered by various people eventually.  I don't know
that it is such a good idea to have a lot of developer- or
distributor-centric information floating around on the website.
Certainly, in-depth documentation should be available, but not in your
face.

But this will quickly turn into nit-picking and guesswork.  I fear the
complexity of the issues may not be well-suited for the type of
hand-holding I dream of.  Maybe there is no way for the information on
linuxprinting.org to be presented that gives a clear impression of how
things fit together.  Maybe I'm just annoyed that the situation is more
complicated than I wanted it to be.  Maybe I should have bought a book.

| We do have a wiki system, after a fashion.  Every printer database
| page has a segment of "user comments" in the middle that anybody can
| edit.  It only supports text, with no markup, but for this purpose
| that would just be complexity in search of a problem.

At an earlier visit, I considered adding something, but what I really
wanted to change was the "works Perfectly" status. :)  Now that I'm
starting to understand what a PPD file is, and where Ghostscript fits
in, and such, the database does begin to make more sense.

| I also have a program to wikify all the prose pages on the rest of the
| site.  For the moment, however, I'm still trying to recover from the
| last experiment - a volunteer who collected data from forum traffic.
| That resulted in dozens of unfindable pages detailing assorted random
| facts that should have just gone into the database.  Took me days of
| work to sort out in the end.
| 
| What I'd like to do is prune out at least half of the non-database
| content, leaving behind a core set of several key documents built from
| Kurt+Till content (which is generally quite comprehensive) but
| translated/edited from the current Germanesque style into something a
| bit more approachable size-wise.  Then wikify those, and see what
| happens.
| 
| Do you think that's a useful plan, or should I target my efforts
| elsewhere?

Sounds good, but great care should be taken when linking this together
with the database and the rest of the site.  One thing is having all the
information available, another is to present it such that it gives a
natural path of learning (for those who are digging around the site),
attempting to answer the questions as they invariably come up, perhaps
keeping a short intro to each concept apart from the deeper
documentation, etc.

| Do you mean from an aesthetic standpoint, or a in terms of
| participation?  I could do a face-lift easily enough, but I can't
| really make people participate.

Not aesthetics, really.  It has more to do with usability, how it's all
stitched together.  In what format the communication happens, the
perceived "distance" between various fora, the threshold for
participation and the level of comfort with which such participation
takes place.  The facilities for being a useful contributor (this is
where wiki shines, obviously) are important, as well as the feeling that
your contributions are in fact useful (they're not stuffed away in some
remote corner (unless they deserve it)).  Many subtle issues here, I
imagine.  Just my personal feelings, though -- I may be talking out of
my ass.

| Oh, skip CUPS and Foomatic; they're impossible to diagnose, even for
| someone like me (you don't want to know how long it took me to get my
| mother's new Epson to work properly).  Run your driver directly by
| hand and see if it works that way.

This gives me no amount of joy to hear.  The problem was of course that
I didn't feel confident that the same things happen if I try to step
into the middle of the chain of events, as it were.

| You can find how to invoke ghostscript with your driver, at least the
| way Foomatic is configured to do, on the "Execution Details" page
| linked from http://www.linuxprinting.org/show_driver.cgi?driver=ljet2p
| See also the man page for gs, and "gs -help", and the proper gs docs
| that are probably installed in /usr/share/doc/gs-mumble/ or the like.
| 
| Offhand it looks like the thing is plugging in an A4 imagable area
| that, if broken, could cause your problem.  So you could just vary the
| A4 size numbers to test that.
| 
| Similarly, try using the normal resolution and pagesize options from
| "man gs" or the regular gs documentation, and see if that fixes it.
| 
| If none of the above fixes it, then we look at the code a bit more.

All right.  I think I might have explained the problem clumsily.  What
seems to happen isn't that something is left out, or scaled wrong, but
rather that the whole thing is shifted upwards.  I took a picture of a
CUPS test page to avoid all confusion:

http://home.powertech.no/sletner/testpage.jpg

The line at the bottom is supposed to be even further down, and there
should be a similar one at the top (actually it's supposed to be a box,
I don't know why it cuts off the sides, but that's no big deal.)  I get
the impression here that the A4 measurements are right, not least
because the width and horizontal balancing seem correct.  Furthermore, I
tried using gs's built-in sense of A4:

stian:~$ cat /usr/share/cups/data/testprint.ps|gs -q -dBATCH \
-dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ljet2p -sPAGESIZE=a4 \
-sOutputFile=- -|perl -p -0033 -e 's/^&l\d+[aA]/$&/; ' >a4-1.pcl
stian:~$ file a4-1.pcl 
a4-1.pcl: HP PCL printer data - A4 page size
stian:~$ lp <a4-1.pcl 
request id is hplj-4 (1 file(s))

And got the same result.  (I couldn't get the -s "..." directives from
the execution page to work, "Error: /invalidfileaccess in
--.outputpage--", but I assume it would be the same.)

| Assuming that you are indeed using the ljet2p driver, it's part of the
| Ghostscript source distribution.
| 
| The ljet2p driver is in fact composed of a core of shared PCL driver
| code plus assorted other modules.  The exect set of gdev*.c files is
| defined in the file "devs.mak" (unless they finally evaporated the old
| *mak system entirely in gs version 7 or 8).

Something tells me I'll be headed in this direction soon, armed with a
PCL specification and a distinct sense of pessimism.

-- 
Stian Sletner




More information about the Printing-foomatic mailing list