Slashdot Mirror

I'm not quite sure where the "BSD licensed CUPS" myth started... The very early beta releases (back in 1999) of CUPS were under the Aladdin Free Public License (you can read about Michael Sweet talking about the AFPL license choice in a comment) , a licence that is more similar to the GPL than to a BSD-esque licence. However, in version 1.0b3, CUPS switched from the AFPL to the GPL and has been distributed under the GPL ever since (and you can read Michael Sweet saying the CUPS API is under the GPL but perhaps this changed later?).

This does not refute your point that Apple did _not_ fork the project closed after they obtained the copyright (CUPS always required copyright assignment so it was always possible for people to negotiate for it to be provided under terms other than the GPL).

EPM, the Easy Package Manager, is Free Software. The support (following best FSF practice) is for pay, $99 per year.

I've been using my own forked version of EPM (to allow users to install anywhere, when non-root) for years.

The reason it hasn't been updated in a long time is that it works very well.

We use EPM (http://www.easysw.com/epm/) from Easy Software. Free, cross platform/distro, buy support if you want to. Works just fine.

OpenPKG seems like an interesting portable packaging framework. I would be interested to hear from people that have had any exeprience with this.

PkgWrite is a perl tool that builds debian and rpm packages from a single spec file. GNU/LGLP with liberal relicensing. I suppose it will not save any dependancy issues for you.

EMP is a commercial solution, offering native packages (debian, redhat, solaris, HPUX etc.) and script-based installs. It costs $99, has a stale web site and I never tried it. But for commercial software, perhaps it can help you.

STOW is a free perl-based fancy package manager that was pushed by IBM at one time.

But at the end of the day, it is not very difficult to prepare debian and rpm package specs, build chrooted building environemnts and support several distros. Users are really happy when they can apt-get install your software, even if it is binary-only and from your own server. If you don't have nasty kernel dependencies, chrooted building environment might be easier than it seems. And you will only ever be sure in the case of binary distribution if you can build and test your package yourself. And if you have users who want graphical installers, you can always trick Loki to install a standard package. Which should be its default behaivour anywyay, IMHO.

Easy Software does pay its employees.

CUPS was developed by Easy software products. They have GPLed it, but they also sell support. (Apple licensed CUPS from them, though I don't know what terms were used)

Nobody wants to contribute software for free that they will then turn around and make a product out of. So you would have to fork the project, and that means you can't easily stay in sink with whatever updates they do make.

the makers of CUPS: the Common Unix Printing System has another product called EPM: Easy Package Management available at http://www.easysw.com/epm/.

EPM is a free UNIX software/file packaging program that generates distribution archives from a list of files.
EPM Can:

* Generate portable script-based distribution packages complete with installation and removal scripts and standard install/uninstall GUIs.
* Generate "native" distributions in AIX, BSD, Debian, HP-UX, IRIX, MacOS X, Red Hat, Slackware, Solaris, and Tru64 UNIX formats.
* Provide a complete, cross-platform software distribution solution for your applications.

____
to the guy marking my comments as -1: why?

The GIMP is not about collating and printing photo albums, and neither is PhotoShop. They can both do it, to be sure, but you should be using something like KAlbum or FLPhoto instead. Both of these and a few others sit in Multimedia, Graphics on my Mandrake 10.1 desktop.

My flPhoto application does all but the last (it does support local printing, of course), available at:

... for both CUPS and HTMLDOC.

... for both CUPS and HTMLDOC.

Here's a fine guide on serial port programming from none other than the guys who brought us the cups printing system:
Serial Programming Guide for POSIX Operating Systems

A lot of FLTK apps are available here. There are quite a few. A good demo of the usefulness of the toolkit is this application.

Another little FLTK applet which I like a lot is xpp.

As an experienced SysAdmin, I'm kinda on the side of your prof. Packages give ease of installation of over many machines and (perhaps most importantly) proper tracking of files that are installed to prevent files from being overwritten, and to allow for uninstalls too. OTOH, building from sources gives you fine tuned control over what gets installed and where, and specific build options.

So, why not have the best of both worlds? Build your own packages! I use EPM to do it and it's a breeze. You can get EPM at:

http://www.easysw.com/epm/

I'm not religious about building everything from scratch, but I like being able to include my own default config files, as well as have control over what gets installed where (I mostly manage Solaris machines, but often build Linux packages too).

As a shameless self-plug here, I recently wrote an article for SysAdmin magazine on packaging with EPM. It's especially handy in multi-platform environments. If you want to see my article check out the Dec. 2003 issue of sysadmin mag:

http://www.samag.com/articles/2003/0312/

Hi,

Hopefully you'll be reading your responses ;-)

1- Anyway, I have a Canon PS A70, I had to recompile gphoto2 and associated bits because it was too new a camera at the time to be in my installed version of gphoto2, but that was easy.

As soon as you have gphoto2 working, flphoto should do you. Excellent GUI.

2- Not supported under Linux, a reflection on Creative, not Linux.

3- NVidia cards work well in 2D with X with the `nv' driver. If you want 3D acceleration and all the other bits you need the binary package from NVidia. No kernel recompile should be necessary.

• Look at their systems and ask what portion of their IT/IS productivity comes from FLOSS and what portion of their overall system productivity comes from FLOSS and contribute accordingly. Examples:
  network department's use of ntop, mrtg, snort
  programmer's use of emacs, ant, jEdit, gcc, etc
  Production Systems: vital functions running via perl
  Add this stuff up roughly and then say, gee we pay 190K for commercial snmp agent licenses, and we would actually be way more screwed if we didn't have perl - and with perl 6 there are some things we could do that we can't now. So let's chuck 125K at the perl 6 effort. And let's send some of the Ultra 20's in the storeroom in the basements to the ntop guys if they want them. Forward $5000 from our corp amazon account to Tobi's for the priceless contribution of mrtg/rrd to the world of network monitoring, without it we would have had a hard time tracking down xyz problem last month - god knows that is nothing compared to the XX millions we spent on Tivoli, Openview and Cisco software. Our most productive programmers use emacs, so send that powered down, 6 CPU Sun E4500 with the faceplate ripped off to the GNU boys. We are going to move one of our most speed sensitive systems to Opteron, so send SuSE $8K and ask that they put us on their early 64bit release list.
  For a big company, these are not even blips on the financial radar.
• Completely subsidize small projects that they find useful. Having worked at a number of big companies, I can tell you that they could pay one area expert person to devote full time to a OS project for less than the cost of one useless junior "business analyst".
  Here is a personal example:
  For doing some on-demand reporting, I needed to check that the bloated, overpriced, under performing Report Server *Achoo* [...hate when that happens, excuse me] that we were using was producing the correct numbers. It took forever to run the reports with this software and the license costs for it cost in the 18K - 38K per CPU range. I used htmldoc to spin a pdf version from a raw query of the data via a sh script sweet, easy, fast - I couldn't get htmldoc to take more than 1 second regardless of how long the report was. The other software took at least 8 minutes to produce the same report from the same dataset on the same server(s). Now, I know what you are going to say - they are already making a dogbone buck on htmldoc. But there is no reason that we couldn't have thrown them 25K with a note that said:

  Dear Mike,

  Thanks for asskicking software. Thanks for saving us from having to buy another Enterprise UNIX box CPU and another license from the bloodsuckers.
  - We don't even need any new features or performance upgrades in htmldoc -
  Thanks again and keep us the great work.

  Because otherwise when Adobe comes out with pdf spec 19.0 - uberpdf, Mike may say screw it, that's too much work to update htmldoc to all the new uberfeatures for the $ we are making... Hell, adobe should pay them and distribute it - why? to de-value report server products - there was a great paper that I read about how one of the economic benefits for Oracle from linux is that it de-values Operating Systems (cost-wise), thus freeing up money to be spent on database products, but I can't find the paper now.

• Shame companies like those on the busybox list into complying and if [we] aren't suing them, ask them to contribute to the effort/project that they are profiting from - how hard would it be for Belkin to throw some money at busybox. For cryin' out loud, they are going to nee

Hey, Easy Package Manager looks great. It's comparative table of existing installer/packager formats is a good answer to this topic. And it even has a FLTK graphical frontend (I love FLTK for its speed, lack of bloat and beautul API). However, it does not support Windows, which is raher logical from the design point of view.

But I found a nice list of existing packaging tools at the A-A-P which "makes it easy to locate, download, build and install software. It also supports browsing source code, developing programs, managing different versions and distribution of software and documentation." Definitely worth a look!

InnoSetup on Windows is really good, although some people also swear by NSIS (NullSoft Installer (brought to you by the same people who did winamp.

Might want to check out the ESP Package Manager. It seems to be able to generate output for multiple 'single package systems'. I just stumbled onto it while looking for more info on packing options. Haven't used it but it does make for a good/polished presentation...If the software is half as good...:-)

-l

My EPM software (http://www.easysw.com/epm/) supports the creation of software packages in multiple formats along with a common "portable" format that works on all systems.

You old folk crack me up. My profs require me to email them PDFs now. But I get almost the same grueling experience because I don't have Acrobat, so I hand-code HTML and then convert it using HTMLDOC.

HTMLDOC from Easy Software will convert an HTML file to PDF. I use it weekly, and it's fantastic.

HTMLDOC from Easy Software will convert an HTML file to PDF. I use it weekly, and it's fantastic.

RTF has been in office for years and it is an open, portable standard readable on many platforms and with many programs.

Obviously you haven't tried it. RTF has gotten more complaints from users than raw word Docs does!

Replace "RTF" with "HTML" and you've got a winner, though.


OK, Let's see you put a page break in that HTML document... Seriously, an extended HTML could make a very nice document format, some of the better ones, like the one used by HTMLDOC actually *do* let you put in line breaks and such. I've started using HTMLDOC to generate lots of my documentation now, because it does a pretty good job of retaining the gist of the formatting and produces very nice PDFs from the same web pages I have to generate anyway. This product has really improved lately. In fact, the only thing wrong with HTMLDOC, IMO, is that it uses the GPL rather than a truly free license.

Now if only the Netscape/Mozilla team would add support for the HTMLDOC extended tags in Composer, and make HTMLDOC a standard output filter option (which would dramtically improve their ability to print web pages, anyhow...) we'd really have something.

If you don't really care about sticking with the arcane tags and XML syntax of DocBook, you might want to consider anoter option that will get the job done easier and quicker: HTMLDOC.

This is a really clever program that allows you to take a regualr web page and produce very nice PDFs (or PostScript) from it. It supports a few new tags that let you do things like page breaks, headers/footers and such that always should have been in HTML (even if only as a hint for printing) but wasn't. It automatically builds tables of contents (fully clickable in the PDF), cover pages, and the like, too.

I've started using this tool more and more often over the last few months. It's just too handy for words. You can find it at Easy Software. (And yes, it's open source.)

A very nice tool for converting HTML to PDF is "HTMLDoc". It's GPL'ed. The HTMLDOC home page is located at http://www.easysw.com/htmldoc. It's not clear to me that it will really meet your needs, but if not, it may be possible to modify it to do what you want.

HTMLDOC is what i use. it's available on both UNIX and Windows platforms, is released under the GPL and does a good job for what i need (converting web reports to PDF for printing -- i wrote a wrapper for the binary). there may be some limitations for advanced stuff but this formats tables well, displays images, and supports color... sounds good to me.

I see your problem. The good news is that Minolta says they are partnering with SuSE in order to support their printers under linux. I can't tell if they have drivers for your printer or not... Perhaps a non-matching driver will work but not provide all functionality. I found these interesting links:

Linux filter page for Minolta printers

I found that link here:

MinoltaEurope.com (interestingly MinoltaEurope.com is running Apache!) - search for "linux" on that page and you can find their announcement about the partnership (no date specified though, could be way out of date).

ESP Print Pro is based on CUPS but it is a commercial product with more drivers. I found a couple drivers for QMS products with their printer search choice on their page there. Most of the drivers looked to be postscript so you might be able to simply use a standard postscript driver and not have to deal with product specific drivers.

Searching around on usenet at groups.google.com with "linux qms 1100l" found some interesting stuff... Does the printer do PCL? Some tips there.

Good luck and hope you get it working.

'm surprised no-one (that I'm aware of) has proposed a 'bundled' portable HTML file format... All it would take (IMHO) is an extended HTML document which contained each individual HTML page in < PAGE > < /PAGE > sections, as well as < MEDIA > < /MEDIA> wrappers around text-encoded graphics file. Fonts could possibly also be shipped within the document.

Only last week did I find out there's already a solution that does exactly this: HTMLDOC (See http://www.easysw.com/htmldoc/) It's free as in beer, but not totally free as in speech, since it's GPL'd, limiting your rights much more than a BSD license would. :-)

It's not a replacement for PDFs at all though: in fact, one of the things it can do is make beautifully formatted PDFs (or PS) from HTML files. It even has some fairly useful formatting options to support books and such.

This is a very nice program - I am VERY impressed, so much so that I'd like to see full HTML editors that understand the HTMLDOC extended tags in Konqueror, Mozilla, Netscape 6.next, etc., and also see that these and other browsers implement the HTMLDOC filter as a checkbox option when printing an HTML file.

HTMLDOC supports HTML 3.2 and some 4.0, and is supposed to support type 1 & 2 CSS in the next release.

Highly recommended. It's clearly not the right format for everything, and it's clearly not a page layout program, but it is applicable in a great many situations. It seems to bridge the gap between web/dynamic, page, and distribution formats quite well. It's even rich enough that a simple word processor could be built using it - perhaps a bit more like "HTMLroff" than Word, but then that's not a bad thing...

elsewhere, I wrote that documents have a three-tiered hierarchy of desirable features:

• information
• prettiness
• printability

information is desirable in any document, prettiness is also desirable in some cases, and printability is necessary in a few.

many people here are pushing RTF, which is good as far as it goes. however, plain text is best for most purposes, like the often-mentioned "writing a letter to your mother" or interoffice memos. when pictures and bold text are necessary, HTML will fit the document's prettiness needs in most cases, although RTF might allow a few more options; the decision on whether to use HTML or RTF really hinges on whether you want hyperlinks.

people keep bringing up print format information, like margins. most of the time, print format information isn't necessary. no one seems to mention that, if someone wants to print a document that doesn't have margins set, it's possible to set the margins when printing.

if exact print formatting is needed, the best portable format is PDF. and there's a nifty GPL program called HTMLDoc that will work just fine for windows users who need stricter format information. I only wish it would read CSS and all kinds of table formats.

I think it's important to seperate the needs of a document into information, prettiness, and printability as I've described, because really you should write all the information first, then go back and make it pretty, then format the pretty document for printing. the universal method these days seems to be to start messing with fonts and margins first, then write what you want to write last, which is why so many books these days are crap. (anyone who buys roleplaying games will know exactly what I'm talking about.)

I'm using SDF on a regular basis at work, and have been doing so for 3 years or so. Together with the wonderful htmldoc (from easy software products, it can turn any textfile into a beautiful, production quality document in no time.

Whenever I have to send out .doc files, I ask SDF to convert to .html, load it from word and save it as .doc (the default .rtf output sucks).

SDF is great - the input is still 100% readable as a plain textfile, and LaTeX, HTML, PDF and FrameMaker conversions are simply awesome. Unfortunately, it's no longer maintained, and even the download files aern't there anymore. Still, I've been using it for 3 years, and haven't encountered a single bug. The documentation is superb and -- if all else fails -- read the source, luke!

I am considering a switch to Doxygen - the input still remains human readable (although less so than SDF), and it has better support for LaTeX formulas and output formats.

I can't believe no one has mentioned Structured Text yet. It's really simple (you only have to learn a few simple rules of editing plain text ASCII files to express structure) and pretty intuitive (it's like Python in the sense that your indentation expresses your structure). You can convert it to decent looking html with existing scripts (that come with zope). You can convert this generated html into .pdf automatically using the GPL htmldoc program . And the Zope book was written in Structured Text, to prove that it scales.

• Convert HTML files to PDF or PostScript
• Generate a table-of-contents for books
• Generate indexed HTML files
• Generate files on-the-fly for web applications, from the command- line for batch jobs, or from a GUI for interactive work.

This works nicely on very simple HTML (tables, images, font sizes and blockquotes), and is open source. I use it for purposes similar to those requested by the submitter. I write HTML in HotMetal (an easy to use Dreamweaverish thing on Windows) then run it through htmldoc on linux to get a PDF. As far as I can tell you have to settle for Times Roman, Helvetica and/or Courier in the text output. It handles jpegs and non-transparent gifs as well.

It seems to be abandonware, but it's a handy tool to have around.

----

HTMLDOC appears to serve your purpouse. It appears only windows binaries are avalible however but the sourcecode is avalible under the GPL

I use cups and it does all I need to do and more.

It's almost completely manageable via a web interface (the only thing I know of that isn't is setting the default printer). It integrates very nicely with samba. It uses gimpprint drivers to create nice output on newer printers.

The reviews indicates that it can use cups, but I don't yet understand what this gives me that cups doesn't do already.

In any case, programs like my EPM (see http://www.easysw.com/epm/ for more info) are designed to create installation scripts, or RPM packages, etc. Definitely worth a look if you want to ship binaries for multiple platforms or even just multiple Linux distributions...

Real Bourne Shell will be released as source code sooner or later by Caldera. Here is the press release:

http://news.linuxprogramming.com/news_story.php3?l tsn=2001-08-20-003-06-CD

http://ir.caldera.com/ReleaseDetail.cfm?ReleaseID= 57417

And here are some quotes:

"The Regular Expression library and tools will be made publicly available on SourceForge this week at http://unixtools.sourceforge.net. In coming months, Caldera will Open Source other UNIX tools and utilities, including pkgmk, pkgadd, pkgrm, pkginfo, pkgproto and more, as well as the Bourne shell, lex, yacc, sed, m4 and make. The licenses under which these technologies will be Open Sourced will be decided based on community and business needs."

So, you must keep you eyes on this:

http://unixtools.sourceforge.net/

Meanwhile you can do portable shell-scripting with help from these WWW-pages:

http://www.raycosoft.com/rayco/support/porting.htm l

http://www.raycosoft.com/rayco/support/SANS_2001_f iles/v3_document.htm

http://sources.redhat.com/autobook/

http://sources.redhat.com/autobook/autobook/autobo ok_208.html

Ash is really good Bourne Shell clone and POSIX-shell implementation. I really like to use it for my shell-scripting, because it prevents me from using bashisms. In my Debian GNU/Linux 2.2 Potato /bin/sh is actually a symlink to ash that I compiled from sources I took from unstable Debian and it works.

But if /bin/sh is symlink to bash and you have some bashisms in you script that starts "#!/bin/sh", it seems, that even in that case bash won't complain about those bashisms.

But you must check out, which version of ash you are running. Debian has always used the latest version of ash. I think it is downloaded from this place:

ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src /bin/sh/

Red Hat Linux had ash version 0.2 and it really sucks. Then I made bugreports and latest versions of Red Hat have fresher version of ash.

But it seems, that Slackware still has that ash version 0.2:

ncftp ...ware-8.0/source/ap/ash > pwd
ftp://ftp.slackware.com/pub/mirrors/slackware/slac kware-8.0/source/ap/ash/
ncftp ...ware-8.0/source/ap/ash > ls
ash-linux-0.2.diff.gz _ash.tar.gz
ash-linux-0.2.tar.gz SlackBuild
ncftp ...ware-8.0/source/ap/ash >

BTW I really don't understand, why somebody would want to create installer scripts, when this kind of tool exists: http://www.easysw.com/epm/

EPM Is:

A free UNIX software/file packaging program that generates distribution archives from a list of files. EPM Can:

Generate portable script-based distribution packages complete with installation and removal scripts. Generate vendor distributions in AIX, BSD, Compaq Tru64, Debian, HP-UX, IRIX, Red Hat, and Solaris formats. Provide a complete, cross-platform software distribution solution for your applications.

Adobe Dimensions (wireframe and other 3D to postscript)

An SGI Article on how to render OpenGL to postscript (with examples and source)

GLP (another OpenGL to PostScript app w/ source)

Adobe Dimensions is probably your best bet. Hope one of them works for you.
--
He had come like a thief in the night,

http://reality.sgi.com/opengl/tips/Feedback.html

http://www.easysw.com/~mike/opengl/

Wouldn't it be cool to include ALL OS's? Not just the *NIX's (getting one package manager to correctly handle both BSD and Linux is a complicated task as it is), but Mac, Windows, etc?

I don't know whether you'd ever get all the *NIXes to adopt one package format (heck, not even all of the *NIXes that use the Linux kernel use the same package format, so far; is it even possible to generate an RPM that works, for a given instruction-set architecture, on all distributions that use RPM?).

It's probably even more unlikely that you'd get Windows, or MacOS Classic (MacOS X might be considered "one of the *NIXes", although it may be different enough from other *NIX-flavored OSes that it'd be even less likely that it'd adopt some standard package format).

If they could get something that would reliably install stuff under Win2K (InstallShield really doesn't cover it),

It might be possible to have tools such as Easy Software Product's Package Manager (as mentioned in another posting; ESP are the folks who do CUPS) work with various non-*NIX packaging tools, as well as handling the various *NIX package formats it now handles (debs, RPMs, SVR4 packages, IRIX packages of some sort, HP-UX packages of some sort, source tarballs).

Some tools for packaging on Windows include MindVision's Installer VISE (available for Windows and MacOS), for which "qualifying shareware and freeware developers" can get a free license (it's what the GTK+ and GIMP for Windows uses), and Nullsoft's "SuperPimp" Install System, which is also free. (I've not used either of them, so I can't say how good or bad they are.)

and do compiling for makefiles (I don't even know if there is something to do makefiles in Windows anyway),

Well, there's a tool called nmake, which comes as part of a package called "Visual C++" from some company up in Redmond, Washington that has done some software for Windows; its makefiles aren't exactly like those for the various *NIXes (but those aren't all the same, either - you have System V make, Sun's make which is a superset of SV make, GNU make, Berkeley make, etc.).

It's not clear that it's a package manager's job to deal with the differences between the "make"s on various platforms.

http://www.easysw.com/epm/index.html

Want to make $$$$ really quick? It's easy:
1. Hold down the Shift key.

However, you can use Perl script to generate a massive listing and index of the keywords and make this to be HTML files. HTML files are mostly accessable by most computer users. It's also good to include ASCII text files along with PDF files.

One drawback of using only ASCII text files is that if you have a lot of pictures or diagrams in this document and expect the users to print them, you don't really want them to open each image in GIMP or Photoshop and do the printing.

Also, you can try to write CGI scripts and put them on the CDROM along with the HTML files. You can make CGI script possible to do searching text for you.

Aside, you may want to try Perlfect Search 3.08.
Their web page description:"Perlfect Search is a sophisticated, powerful, versatile, customizable and effective site indexing/searching suite available under an open source licence. It comes as a pair of disctinct scripts. The indexer, that automatically, scans and indexes a web site, and the search engine, a cgi script that serves search queries for keywords over the index, and displays results pages in html, in a standard format including title, description and relevance ranking for each matching document. "

Another possibility is PDF format. You can also try PostScript file too. But I'm not sure if you can get any script to search text in PDF or PS format.

For making PDF file, you can buy the Adobe Acrobat, or try HTML DOC from Easy Software Products. It can convert HTML files into PDF and PS files and it's available in Linux, Windows, UNIX, IRIX, NT and Solaris.

Both HTMLDOC 1.8.8 and Perlfect Search 3.08 are in GPL.

Hope this help.

However, you can use Perl script to generate a massive listing and index of the keywords and make this to be HTML files. HTML files are mostly accessable by most computer users. It's also good to include ASCII text files along with PDF files.

One drawback of using only ASCII text files is that if you have a lot of pictures or diagrams in this document and expect the users to print them, you don't really want them to open each image in GIMP or Photoshop and do the printing.

Also, you can try to write CGI scripts and put them on the CDROM along with the HTML files. You can make CGI script possible to do searching text for you.

Aside, you may want to try Perlfect Search 3.08.
Their web page description:"Perlfect Search is a sophisticated, powerful, versatile, customizable and effective site indexing/searching suite available under an open source licence. It comes as a pair of disctinct scripts. The indexer, that automatically, scans and indexes a web site, and the search engine, a cgi script that serves search queries for keywords over the index, and displays results pages in html, in a standard format including title, description and relevance ranking for each matching document. "

Another possibility is PDF format. You can also try PostScript file too. But I'm not sure if you can get any script to search text in PDF or PS format.

For making PDF file, you can buy the Adobe Acrobat, or try HTML DOC from Easy Software Products. It can convert HTML files into PDF and PS files and it's available in Linux, Windows, UNIX, IRIX, NT and Solaris.

Both HTMLDOC 1.8.8 and Perlfect Search 3.08 are in GPL.

Hope this help.

Use PHP to write out formatted HTML (that's the tweak-heavy part) to disk, then use a shell command to run HTMLDOC and convert it to PDF, and display it in the browser. We've generated literally thousands of documents this way, and it works great. All free as in all free.

Much easier than using the PDFlib library that comes with PHP, as you can avoid having to learn anything about PostScript. You are at the mercy of HTMLDOC's formatting, which can be quirky. But it's vastly improved in the short time we've been using it, and new versions are out almost biweekly.

I've had good luck with CUPS the Common Unix Printing System. It supports LPD, SMB, AppleTalk, TCP (JetDirect), and the new IPP RFC (Internet Printing Protocol). Also the company that makes it Easy Software Products makes a graphical configurator (not needed) and a set of high quality print filters (very nice) based on GhostScript and .ppd files.

1440x720 DPI for the EPSON printers *is* available today; we have our ESP Print Pro drivers based on CUPS, and Robert Krawitz has been extending my print plug-in to support the Photo printers and the 1440x720 DPI modes in GIMP (available in the 1.1.x development versions.)

I can't help but think that X is lacking one thing that would really help the situation. (Though this could be done, and X is still great, regardless.) There ought to be some layer between X itself (Xlib and friends) and the window manager. As everyone keeps pointing out, the window manager is what controls the interface, but it's usually more complex than that. Nowadays, it's a combination of the WM, and the toolkit used to write the app. I may be silly, but I'd like a desktop with a consistent appearance. And when I'm running apps written in three (or four, five, six...) different toolkits (raw Xlib, Qt, GTK, fltk...) I get the feeling that things just aren't tied together. KDE and GNOME help somewhat, but only so long as you're running their apps.

If there were some layer of abstraction that dealt with general user preferences on how windows should behave/look but with enough freedom for toolkits to provide real added value (ie speed of widgets -> Motif moves like molasses uphill in January, whereas GTK is snappy) I'd be in GUI heaven.

This idea isn't really fleshed out fully, it just hit me while reading other people's comments, but I think X has the necessary basics to be a next-generation GUI. (Though it could certainly use a "cleanup" stage whereby unnecessary features are removed, and the important ones are made more universal -> shared memory)

-Brian

QT does seem pretty good. I don't think gtk-- is ready for prime time yet, and if you need the option of deploying on win32... On the other hand, I really don't like the fact that the code has to go through a pre-processor in QT, you're not really using C++ - I cannot believe this is necessary. Does anybody know if they fixed this in QT2.0 ?

You should definitely take a look at a fast, high quality, cross platform, toolkit. It's not very rich in widgets, but you can write your own, and it comes with a deceptively powerful GUI builder.