[cups] Can't detect file type / Not a PDF file
Brian Potkin
claremont102 at gmail.com
Thu May 2 04:45:19 PDT 2019
On Thu 02 May 2019 at 11:29:26 +0100, Henrik Morsing wrote:
> On Thu, May 02, 2019 at 10:38:15AM +0100, Brian Potkin wrote:
> >
> > The job has undergone filtering on the client.
> >
> [...]
> >
> > It then gets filtered again on the server.
> >
> > https://wiki.debian.org/PrintQueuesCUPS#Double_Filtering
> >
> > might help to explain why this is not a good idea.
>
> Well, yes, that has been one of my concerns ever since this stopped
> working, but I can't see a way around it. CUPS has abandoned raw
> queues, I found that documented somewehere, and Windows can't print
> without you going though which printer you have and doesn't have raw
> printing either. It does have a "print to PDF" printer but that
> appears to just print to a local file.
>
> So I'm still stuck... But yes, the double-filtering has puzzled me
> ever since this broke...
I am completely unfamiliar with printing from Windows but, TBH, I cannot
see why the the server should not process a PostScript file. That's in
spite of pointing you in the direction of double filtering.
> E [02/May/2019:07:13:46 +0100] [Job 278] Can\'t detect file type
That looks like a gstoraster message. I am also unfamiliar with coding
but gstoraster.c has
parse_doc_type(FILE *fp)
{
char buf[5];
/* get the first few bytes of the file */
rewind(fp);
/* skip until PDF/PS start header */
while (fgets(buf,sizeof(buf),fp) != 0) {
if (strncmp(buf,"%PDF",4) == 0) return GS_DOC_TYPE_PDF;
if (strncmp(buf,"%!",2) == 0) return GS_DOC_TYPE_PS;
}
return GS_DOC_TYPE_UNKNOWN;
}
and
doc_type = parse_doc_type(fp);
if (doc_type == GS_DOC_TYPE_UNKNOWN) {
fprintf(stderr, "ERROR: Can't detect file type\n");
goto out;
}
It might be worth capturing the file sent to the server and looking at
the header.
https://wiki.debian.org/DissectingandDebuggingtheCUPSPrintingSystem#Capturing_the_File_Received_by_CUPS
--
Brian.
More information about the cups
mailing list