Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"application/octet-stream ..." in /etc/cups/mime.convs does not work any more #1667

Closed
michaelrsweet opened this issue May 8, 2006 · 19 comments
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

Version: 1.2-current
CUPS.org User: till.kamppeter

A user has an HP DeskJet 970C connected to a Linux box (Mandriva Cooker) and he can print perfectly from the Linux machine itself. From a Windows client he can also print via Samba, but only with CUPS 1.2 up to Subversion rev 5257. From rev 5316 on and newer he cannot print any more from the Windows client (local printing still works).

Update to rev 5431, 5441, and 5497 and also updating Samba to 3.0.22 does not help.

See logs and more info here:

http://qa.mandriva.com/show_bug.cgi?id=21814

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

We'll need the PPD file and CUPS error_log file with LogLevel set to debug or debug2.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: stefankl

Same here with s HP PSC-1510

D [13/May/2006:00:00:01 +0200] Print-Job http://192.168.6.3:631/printers/kleprn01-bw-low
D [13/May/2006:00:00:01 +0200] print_job: auto-typing file...
D [13/May/2006:00:00:01 +0200] print_job: request file type is application/octet-stream.
I [13/May/2006:00:00:01 +0200] Print-Job client-error-document-format-not-supported: Unsupported format 'application/octet-stream'!
D [13/May/2006:00:00:01 +0200] cupsdProcessIPPRequest: 10 status_code=40a (client-error-document-format-not-supported)

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: till.kamppeter

Mike, the original poster has now added the data which you have requested to the Mandriva bug report
http://qa.mandriva.com/show_bug.cgi?id=21814.

As it is required for print jobs from Windows clients with the original Windows driver on the client, the original poster has also uncommented the "application/octet-stream ..." lines in both /etc/cups/mime.* files, but he still gets the error of "application/octet-stream" not being supported.

Now I have tried a simple test case: I have also the "application/octet-stream ..." lines in both /etc/cups/mime.* files uncommented and I have CUPS 1.2.0. My print queue is for a native PostScript printer with manufacturer-supplied PPD file, so no "_cupsFilter: ..." line in the PPD. But it seems that CUPS has added a "_cupsProtocol: None" line in the very end of the PPD file when it created the queue (what does this line mean?). Printing an executable file (no script) to this queue gives:

[root@majax d]# lpr -P SAGEM /usr/bin/xpp
lpr: Unsupported format 'application/octet-stream'!
[root@majax d]#

So using the "application/octet-stream ..." rule in /etc/cups/mime.convs does not work any more. The rule in my /etc/cups/mime.convs looks like this:

application/octet-stream application/vnd.cups-raw 0 -

Either there is a bug that prevents raw printing with this rule or this kind of raw printing was intendedly removed from CUPS and then we have a documentation or config file bug (no mention in documentation and invalid rule in config file).

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: setera

I'm seeing exactly the same behavior on my Ubuntu Dapper installation. Looking at the code, it appears that the problem occurs within the block of code in scheduler\ipp.c around like 1231 (from a recent nightly snapshot). The code reads like it is trying to see if the target printer supports application/octet-stream or application/vnd.cups-raw.. at least given my limited knowledge of this code. For grins, I added the following lines to my Stylus-CX5800.ppd file to see if that would help, but it did not.

*cupsFilter: "application/octet-stream 5 -"
*cupsFilter: "application/vnd.cups-raw 5 -"

Thanks for any help.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Will look into this some more, but have downgraded this since raw printing without any options is a low priority for us...

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: kagou

"Will look into this some more, but have downgraded this since raw printing without any options is a low priority for us..."

I disagree completely with that. This Bug is more than serious simply because my linux box can't act as a printer server. All my windows clients can't print at office. It's a major Bug.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mat.pod

Hi same here mepis 6 (based on ubuntu dapper).
not sure why you're downgrading it if no one can print to a print servr anymore?
cheers,
mat

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: hva

same, here: I totally disagree as i find that is really a major bug, since there are an incredible number of CUPS based print-server out there in a mixed os environment, in high-end production environment as well

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: till.kamppeter

Raising to "High" as the reactions show that there are many users out there which have a CUPS server and print from Windows clients (via Samba, LPD, or IPP) using the manufacturer-supplied Windows driver on the clients.

I also remember that there were many postings on the lists from users who could not print from Windows clients and people told them to uncomment the "application/octet-stream ..." lines.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Windows clients using the CUPS driver for Windows will send PostScript. Vendor drivers sending raw print data will send raw data - not something we recommend for a variety of reasons...

Till: Reducing the priority back to 2 again - please don't change it again or I'll go ahead and drop your developer privileges on this site. Regardless of what you think the priority is, we (as the developers of CUPS) are the ones to determine the severity of issues, not you.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: hva

mike, are you saying raw data printing has been disabled on purpose? if it is like that, i think it would be a huge step ahead for adoption of cups in a productive environment: there are fields where using the producer's printer driver on windows is crucial point. In our office for example it would mean re-engineer all printing system and possibly drop CUPS as printer server software. If it is a bug i really do not understand how interoperability between different os could be considered a minor issue.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: martin.pitt.canonical

Seconding hva here:

  • The Windows drivers are better in quite many cases (both printing quality and available options)
  • Windows does not come with a proper PostScript driver (at least it's non-obvious)
  • Suddenly dropping raw printing support breaks upgrades.

If you want to disable it in the upstream version, can you please give us a small hint how to activate it again? it's a release-critical bug for us. Thank you!

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Look, we aren't and haven't dropped support for raw printing. Obviously it still works since "lp -oraw foo" still works.

The issue is why the automatic raw printing is not working after it has been enabled in mime.convs, which is an entirely different thing - that is why I downgraded the severity, and there are already workarounds available in Samba (they added support for passing cups options in 3.0.x), e.g.:

cups options = "raw"

You'll find this example in the smb.conf(5) man page...

So, please calm down and let me figure out what is going wrong - the problem will get fixed, but it just doesn't qualify as a priority 4 (show-stopper) kind of bug since there is a workaround and does not affect normal (non-raw) printing with supported drivers.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: ivoks

If I may add... Printing from Windows over IPP is broken too (in the same way), so changes in samba won't fix all the issues.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: till.kamppeter

I have found out what caused the problem:

When the scheduler is setting up the internal data structure for the available print queues, it also determines which file types can be converted to a format which the printer understands and saves a list of them. The raw file type "application/octet-stream" is explicitly excluded from being checked during this procedure and so even with an appropriate conversion rule in one of the *.convs file "application/octet-stream" is not accepted.

The attached patch removes the exlicit exclusion when determining the printer's accepted file formats, and so it fixes this bug.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

The patch isn't correct; if you look a little lower you'll see we explicitly add application/octet-stream as the first supported type for all printers. You change just adds a second copy of the same attribute and will not make a difference as to whether cupsd will find a filter rule for the printer.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Fixed in Subversion repository.

See attached patch...

@michaelrsweet
Copy link
Collaborator Author

"cups-1.2.0-auto-raw.patch":

--- scheduler/printers.c.orig 2006-05-16 20:42:49.000000000 +0200
+++ scheduler/printers.c 2006-05-16 20:45:19.000000000 +0200
@@ -2924,10 +2924,6 @@
type;
type = mimeNextType(MimeDatabase))
{

  • if (!strcasecmp(type->super, "application") &&
  • !strcasecmp(type->type, "octet-stream"))

- continue;

 snprintf(mimetype, sizeof(mimetype), "%s/%s", type->super, type->type);

 if ((filters = mimeFilter(MimeDatabase, type, p->filetype, NULL)) != NULL)

@michaelrsweet
Copy link
Collaborator Author

"str1667.patch":

Index: scheduler/testmime.c

--- scheduler/testmime.c (revision 5530)
+++ scheduler/testmime.c (working copy)
@@ -98,6 +98,8 @@
if (src)
printf("%s: %s/%s%s\n", argv[i], src->super, src->type,
compression ? " (gzipped)" : "");

  •  else if ((src = mimeType(mime, "application", "octet-stream")) != NULL)
    
  • printf("%s: application/octet-stream\n", argv[i]);
    else
    {
    printf("%s: unknown\n", argv[i]);
    @@ -158,7 +160,8 @@
    filter->dst->super, filter->dst->type,
    filter->filter, filter->cost);
  • type_dir(mime, "..");
  • type_dir(mime, "../doc");
  • type_dir(mime, "../man");
    }

return (0);
@@ -280,6 +283,9 @@

while ((dent = cupsDirRead(dir)) != NULL)
{

  • if (dent->filename[0] == '.')

  •  continue;
    

    snprintf(filename, sizeof(filename), "%s/%s", dirname, dent->filename);

    if (S_ISDIR(dent->fileinfo.st_mode))

    Index: scheduler/printers.c

    --- scheduler/printers.c (revision 5530)
    +++ scheduler/printers.c (working copy)
    @@ -2924,10 +2944,6 @@
    type;
    type = mimeNextType(MimeDatabase))
    {

  • if (!strcasecmp(type->super, "application") &&

  • !strcasecmp(type->type, "octet-stream"))

- continue;

 snprintf(mimetype, sizeof(mimetype), "%s/%s", type->super, type->type);

 if ((filters = mimeFilter(MimeDatabase, type, p->filetype, NULL)) != NULL)

@@ -2953,14 +2969,20 @@

  • Add the file formats that can be filtered...
    */
  • if ((type = mimeType(MimeDatabase, "application", "octet-stream")) == NULL ||
  •  !cupsArrayFind(p->filetypes, type))
    
  • i = 1;
  • else
  • i = 0;

attr = ippAddStrings(p->attrs, IPP_TAG_PRINTER, IPP_TAG_MIMETYPE,
"document-format-supported",
cupsArrayCount(p->filetypes) + 1, NULL, NULL);

  • attr->values[0].string.text = _cupsStrAlloc("application/octet-stream");
  • if (i)
  • attr->values[0].string.text = _cupsStrAlloc("application/octet-stream");
  • for (i = 1, type = (mime_type_t *)cupsArrayFirst(p->filetypes);
  • for (type = (mime_type_t *)cupsArrayFirst(p->filetypes);
    type;
    i ++, type = (mime_type_t *)cupsArrayNext(p->filetypes))
    {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant