| Summary: | tdeprint does not support the compressed PPD database | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Timothy Pearson <kb9vqf> |
| Component: | tdelibs | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | NEEDINFO --- | ||
| Severity: | normal | CC: | bugwatch, gamrat.kristopher, kb9vqf, michele.calgaro |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
Timothy Pearson
2014-11-19 19:02:52 CST
Assigning this to myself as I have at least a partial fix in the works. Very preliminary compressed PPD support has been added to make_driver_db_cups in GIT hash 540db0b (tdelibs), but has not been tested beyond initial driver database creation. Whereas normally TDE would call make_driver_db_cups like this: make_driver_db_cups /usr/share/ppd/ instead if it is called like this make_driver_db_cups /usr/lib/cups/driver/foomatic-db-compressed-ppds the compressed PPDs from the specified file will be used to generate the database. Note that database generation from compressed PPDs is very slow compared to using the uncompressed PPDs; this is the price paid for portability. We have to call the Python accessor script over 7000 times to extract the needed info... tdeprint is not yet aware of the fact that it can call make_driver_db_cups on the compressed database file, nor am I certain tdeprint currently understands the output of make_driver_db_cups when run against a compressed database file (protocol is foomatic-db-compressed-ppds instead of ppd). Setting this bug back to NEW as I am not currently working on it. I decided to at least bring this to a functional skeleton before taking a break from it; as of GIT hash 5a97ffd (tdelibs) tdeprint loads drivers from the compressed foomatic database at a reasonable speed and the loaded drivers work properly with CUPS. Current issues are: 1.) The compressed PPD database is highly inconsistent within itself. Manufacturers, models, etc. use multiple different tags for the same keys, and in some cases the manufacturer is missing entirely from the summary output (!), forcing a slow scan of the extracted PPD file. There is nothing we can do about this other than report a bug upstream... 2.) Capitalization of the various printer models is highly inconsistent. Once again (aside from forcing models to all caps which is not a good idea for legibility reasons) there is nothing we can do about this other than report a bug upstream. 3.) Each printer's driver is duplicated on the driver selection screen. I'm not sure if this is a bug in the PPD database or in TDEPrint, though I suspect the latter. 4.) The location of the compressed foomatic PPD archive is currently hardcoded (tdeprint does not search paths as I don't know what the standard paths, if any, are). Also, as I did not know what the correct course of action was OpenBSD does not look for the compressed file at all. Once item #3 above is fixed we can theoretically ship tdeprint on Linux systems with a dependency on either the compressed or uncompressed foomatic PPDs. Duplication fixed in GIT hash b3e3f60. At this point I need people to test tdeprint with the compressed foomatic database installed. Please report any regressions noticed versus tdeprint using the uncompressed foomatic database here. Thanks! (In reply to Timothy Pearson from comment #4) > Duplication fixed in GIT hash b3e3f60. > > At this point I need people to test tdeprint with the compressed foomatic > database installed. Please report any regressions noticed versus tdeprint > using the uncompressed foomatic database here. > > Thanks! I have updated the packaging files to not conflict with the compressed foomatic database in GIT hash 42aa1eb (tde-packaging). Hopefully this will increase the number of people testing the compressed PPD support in R14 RC2... With the compressed database installed, TDEPrint takes several minutes to rebuild the database, then displays a bunch of manufacturers and printers. Beyond this, I cannot confirm that this bug is fixed since I don't know which of the drivers are from foomatic and which are from the other printer driver packages I have installed (unfortunately removing some of them isn't an option for me) -- are there any specific printers I should check for to confirm? |