[cups] debugging file auto-typing

[Tim Mooney]

In regard to: Re: [cups] debugging file auto-typing, pipitas said (at...:

Sorry for the delay in responding.  I ended up having to solve an
unrelated problem before I could get back to focusing on this problem...

> Maybe I misunderstand your description...
> In /var/spool/cups the files starting with 'd' never have a .pdf extension.
> What follows the 'd' always is the current job ID (a number) and it has
> not any extension.

That's correct.  The data file is 'd' followed by the job ID followed by
a '-' and a three digit number.  I'm pretty certain I know what the
3-digit number is for (file number within the job), but I haven't actually
checked the documentation to confirm that.

However, the auto-typing code has access to what the original file name was, 
so if a client system submits a print job to a CUPS server, and the
file was originally named 'helloworld.pdf', the auto-typing code knows
that.  That's where the .pdf file extension is being detected; from
the original file name the client submitted.

> You can copy that 'dNNNNNN' file to a place in user space.

I've done that.

> Then look at its first few lies in a good editor.
> If it starts with '%PDF-' you can add a .pdf extension and open it in your
> favorite PDF viewer.

It's not; it was converted to PCLXL (PCL 6) by the print rendering
service, before it was submitted to our CUPS server.  The first few lines
of the file are

ESC%-12345X at PJL JOB NAME = "DataSvcsRequestForm-Mem Union.pdf"
@PJL COMMENT "PrintWhere 6.2 Plug-in 0974 (0.3.1584.23510); Windows Server 2016 Standard 6.2.9200.3; Unidrv 0.3.16299.402"

There are something like 60-70 lines of @PJL SET after that, followed
by the (now mostly binary) data for the pre-rendered print job.

> If it's no PDF, try other standard methods to identify its real mime type.
> If you cannot identify the mime type, try to apply the PDF-typing rules
> (there are not that many) from /usr/share/cups/*.types manually to the
> file(s) to find out why CUPS auto-types them as PDF.

Well, trying to apply those rules "by hand" is certainly a possibility,
but wouldn't you agree that it's more error prone and tedious than
just having CUPS tell you which of its rule(s) matched and which one
it chose?

As mime.types(5) describes in the "TYPE MATCHING AND PRIORITY" section,
there can be multiple types that match a particular file.  When that
happens, CUPS has ways to decide on which type it chooses.

CUPS already has to try *every* rule, and it already knows which one(s)
matched and which ones didn't.

Since it's already doing all the work, all I was asking was whether there
was an "easy" way to get it to output all the matches.

Thanks,

Tim
-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164