Some interesting tidbits from the Haiku world. Firstly, the WebKit port bounty has reached its target, meaning Ryan Leavengood can get to work. Secondly, Vasper has made huge strides in getting CUPS ported to Haiku. And on a funny note, BeOS icons were used in the “24” TV show.
I’ve always been somewhat mystified why people chose to port the gigantic CUPS when all that is needed is a local print spool and an IPP client.
I’ve always been somewhat mystified why people chose to port the gigantic CUPS when all that is needed is a local print spool and an IPP client.
Drivers.
Since BeoS (at least r5) can already use PPD’s (the drivers CUPS are using) that’s sort of moot in this case.
Also, you don’t need drivers for IPP, you just send your docs to the IPP-capable printer.
Come to think of it, BeOS r5 had an IPP client/driver and could use PPD’s so why the need for CUPS at all? It’s not like anyone is seriously going to use Haiku as their company print server, which is what CUPS is mainly intended to be.
All printers are not IPP-capable
[CUPS]
I would like use dot-matrix printers, and you cannot do that with stock BeOS R5, nor with IPP/PPD/whatever. PPD’s got used by a Anything-to-PostScript printer driver, but if your printer is not PS enabled… your’re out. And that’s the part that CUPS can provide, as it has “filters” that do translate “raw data” to the language your printer understands, ie. “raster2epson”.
Granted, I would preffer to have those specific backend morphed into a BeOS printer addon instead, but… oh well.
[WebKit]
Great to see it comming to Haiku!
Probably because there is almost no info or guides about that.
You are confused about what roll CUPS plays and what a PPD actually is.
CUPS isn’t big. It really isn’t. It is a local spooler, and it is an IPP server that allows other LAN connected hosts to use your locally connected printer. It is also a scheduler, so CUPS can drive the various stages of the print pipeline, such as Ghostscript, on it’s own.
A PPD is just a “Postscript Printer Definition” file. It isn’t a driver. All it does is describe the features and capabilities of the printer, but to actually drive the printer you need a print driver. The attraction of using CUPS is that you can use it with drivers such as GutenPrint and Splix.
I’m actually slightly dismayed to see that Haiku are planing to use Foomatic as part of the port. It’s a horrendous hack that isn’t really needed with a modern scheduler/spooler such as CUPS.
I think that’s why people feel uneasy with Haiku wholly importing projects like CUPS or foomatic: they aren’t stepping back and thinking, “How can we do printing better?” For example, they could create their own printing system that fits better with the BeOS paradigm instead of the web interface CUPS uses to be configured. Or they could replace foomatic with something entirely better and more intuitive. I understand Haiku is in a rush to create a working desktop environment as soon as possible, but I think a desktop with all the pieces fitting nicely together instead of being slapped on is better.
I’m actually slightly dismayed to see that Haiku are planing to use Foomatic as part of the port. It’s a horrendous hack that isn’t really needed with a modern scheduler/spooler such as CUPS.
Haiku, Inc. has not made this decision – the CUPS port was a bounty generated by a community site called HaikuWare, and the port was picked up by vasper – the creator of BeOS MAX. I highly doubt the CUPS port is going to find its way into the official Haiku repository (although, it may) – so I wouldn’t necessarily say that Haiku (official) is porting CUPS – it’s a community effort.
I am just trying to port CUPS. It is not part of the Haiku tree and cannot be (correct me here if I am wrong) as it is GPL, not MIT. I guess it can be added to a Haiku base distro as an add-on.
I also don’t know if I will even succeed. I want to see first how it goes. If I see I am close to a port I will see how I proceed.
As for foomatic, as I get it, is just an xml database with all drivers supported by CUPS and other spoolers. Also I would appreciate a suggestion, instead of a “I’m actually slightly dismayed” statement. What would you use by the way?
Edited 2007-08-01 20:06
The core of foomatic is the foomatic-rip script which is a honking big PERL script that sits in the critical print path and basically duplicates the functionality offered by the CUPS scheduler to drive Ghostscript and the printer drivers. It uses the foomatic XML database to provide information on how to do that. It was written back in the day when Open Source printing was an even bigger mess, and is capable of driving six (I think) different spoolers and various Postscript pipelines (Including enscript, any2ps and Ghostscript). Given that, foomatic is actually a pretty neat bit of work, but needless to say it makes it rather baroque.
I’d do it the way I did it on Syllable and ditch Foomatic entirely. You can build most of the useful drivers such as Gutenprint and Splix as proper CUPS raster drivers, with their own CUPS PPDs that will allow the CUPS scheduler to drive the print pipeline itself. You lose the ability to use a handful of Ghostscript and non-standard drivers such as foo2zjs, but there is no PERL in the print pipeline and in my opinion, it’s just a whole lot cleaner.
At worst, I was considering re-implementing a foomatic-alike in C that implements only the most basic functionality required to drive the pipeline (Which is basically knowing how to invoke Ghostscript or the non-standard filter) while leaving the rest of the scheduling up to CUPS. It’s still messy, but it would eliminate PERL. I havn’t decided if I’ll do that yet though.
I think as long as CUPS is a separate program, you can distribute it, as long as it’s isn’t mixed with Haiku code.
from http://www.cups.org
and
“You are confused about what roll CUPS plays and what a PPD actually is. ”
No I’m not.
“CUPS isn’t big.”
Compared to the default beos printing system it is.
I used PPD’s with the R5 IPP driver just fine with our office printers (no, they weren’t PS printers). IIRC I got the PPD’s from linuxprinting.org or some such. Worked like a charm.
How does CUPS fit in with the BeOS/Haiku printing model anyway? It’s yet another interface for configuring things so you’d have two places where printers are configured.
Oh well, then I stand corrected. I’ll just go back to my Postscript books.
i badly wish it was out and merged to the native haiku build.
i guess it would be the thing that made me consider to start using Haiku daily – and probably it’s not just me.
Buy a Mac or install KDE. Haiku alone crash after a minute or two of usage right now. And the network stack is far from being “stable”.
Edited 2007-08-01 13:27
Let me question you did not get me. Of course I ment testing / usage on the adequate level.
I already have my Mac and my Kubuntu up and running, thank you
I just want to see the Haiku OS boosted up, and a natively running advanced browser would be a huge step.
CUPS is not a matter of best plan, but of choice. Best plan would be to create 1000 native drivers for 1000 printers in BeOS. However porting CUPS (if possible) will bring choice of those 1000 printers a 1000 times faster… don’t you think?
And open source software is all about choice…
Edited 2007-08-01 12:13
Great. Now we’ll have another half assed port rather than a properly operating kernel.
No, we will have a fully working OS, even without CUPS.
The Haiku kernel is not a port, it is a rewrite of the NewOS kernel (MIT licensed) that aims to be binary compatible with BeOS. All other parts of Haiku are written from scratch.
CUPS is an open source, GPL, cross platform printing system that supports 1000 printers. A port of CUPS to BeOS will bring choice of printing. Not of Kernel!!! If you don’t want CUPS, don’t install it… Just don’t expect printer companies to write drivers for Haiku…
Edited 2007-08-01 13:17
Actually, it’s a -fork- of NewOS.
CUPS is an userspace application that has nothing to do with the kernel. I have no idea from where you came with that idea. And if CUPS is good enough for Apple with its operating system then it certainly is good enough for Haiku.
The way I read the GP post, he complains that now efforts will be spent on porting jet another piece of alien software rather than working on the kernel. The proper answer to that would be that porting CUPS is not done by the Haiku team, so resources are not drain from kernel development.
Good point about CUPS being good enough for Apple.
What are you suggesting as a solution? That the Haiku project leaders order the developer to stop working on the Webkit port and address your specific concerns instead? Perhaps they could enforce that order by threatening that not to pay him.
See, my understanding of CUPS is that it uses PPD drivers (standard postscript printer definition file or whatever it stands for) and then for other printers, it converts them to postscript with an additional layer – and provides it’s own custom CUPS-PPD files for those…
In the grand scheme of things, Haiku already supports PCL5/6, IPP, PS, and LIPS control languages – it seems like the right thing to do now is to write layers to translate the PPD and CUPS-PPD files into something Haiku can use natively.
Has anyone asked Michael Pfeiffer (the guy who did most of the printing kit for Haiku) what the right strategy would be from his perspective?
Actually I and others just continued what Ithamar R. Adema had started.
Here is just my opinion, not an official Haiku position: Let’s see and wait for the completion of the port and how well it integrates into the BeOS/Haiku printing system. If it works well enough, why should we waste our time implementing and maintaining printer drivers.
Actually I and others just continued what Ithamar R. Adema had started.
I had a bad feeling I was wrong there – thanks for the clarification
.
Here is just my opinion, not an official Haiku position: Let’s see and wait for the completion of the port and how well it integrates into the BeOS/Haiku printing system. If it works well enough, why should we waste our time implementing and maintaining printer drivers.
Fair enough – and I think that’s a reasonable position. There are some interesting dependencies so far – reading through vasper’s CUPS-related postings on HaikuWare.. if some of those can be eliminated, I guess I don’t see how it could be so bad.
“Best plan would be to create 1000 native drivers for 1000 printers in BeOS.”
You dont need 1000 native drivers. As I said earlier I used PPD’s with IPP just fine. Maybe I was the only one who bothered to figure this out?
You’d probably only need one driver for each printing protocol, ie IPP, SMB, lpr etc.
This is turning into another discussion about which is the best way for those that can write a few thousand lines of c++ code…!!! Simplicity in usage. Plain and simple.
The user doesn’t care how it is done, as long as it is done. After giving the ability to print to 1000 printers, we can start redesigning to get simplicity on the developers side. And since CUPS already worked on Zeta as part of the system, I don’t see why not on R5 and Haiku.
If there was some other reason, like too much memory, or a huge delay or something like that, it would have to be redesigned now. But there is no such reason. The only goal is to get Haiku and R5 to print on 1000 printers as fast as possible. Provided of course I can do the port!!!
Edited 2007-08-02 06:52
“The only goal is to get Haiku and R5 to print on 1000 printers as fast as possible.”
Why is this important for an OS in Alpha state? It’s not like there’s going to be a significant userbase in the near future.
But hey, it’s your time and if you want to port it, well, that’s your problem.
How does CUPS work on Haiku anyway? How does it integrate/interact with the print dialogs? Do you always use the IPP protocol? I presume you still have to configure the printer(s) use the web interface?
That’s fine if you’re talking about network printers, but I would guess that most home users have an inkjet printer connected directly in which case a PPD isn’t going to cut it.
In addition, even those network printers that most people don’t buy (I purposely did by a network printer for personal use, due to having multiple machines) often don’t support PostScript, either, meaning it would still require at least GhostScript or something else in addition to a PPD. Here’s hoping the PostScript PPD interpreter/preferences for Haiku are more capable than under BeOS: with my printer, I had to strip options out of the PPD because it wouldn’t support that many options! I get the impression PostScript printers back when Be wrote their stuff rarely or never had as many options :/
People was saying that Apple’s project will never involve in the OSS.
As for Sun and Solaris / Java, they are wrong…
Most networked printers might not support PostScript, but they usually do support PCL5 or higher these days, which is easy enough to chose in printing prefs.