osdir.com
mailing list archive

Subject: Re: cups filter Xpdf/pdftops seems to produce - msg#00016

List: printing.cups.devel

Date: Prev Next Index Thread: Prev Next Index
Michael Sweet wrote:
>
> Helge Blischke wrote:
> > hans lux wrote:
> >
> >>Helge Blischke wrote:
> >>
> >>
> >>>hans lux wrote:
> >>>
> >>>
> >>>
> >>>>hi there,
> >>>>
> >>>>i downloaded and compiled the latest cups version 1.2.x.
> >>>>i was actually only interested in the pdftops filter.
> >>>>
> >>>>when applying the filter to an arbitrary pdf file
> >>>>like
> >>>>
> >>>>./pdftops 1 2 3 4 5 foo.pdf > out.ps
> >>>>
> >>>>and sending it to the printer,
> >>>>i get the following error:
> >>>>
> >>>>ERROR: VMerror
> >>>>OFFENDING COMMAND: pdfSetup
> >>>>
> >>>>STACK:
> >>>>
> >>>>and that's it.
> >>>>
> >>>>note: this error doesn't occur when i apply pdftops in version 2.01 and
> >>>>2.03
> >>>>and not in the command line version that comes mit Xpdf.
> >>>>
> >>>>can anyone attest this error ?
> >>>>
> >>>>hlux
> >>>>
> >>>>
> >>>
> >>>Post (an URL to) a sample PostScript file that produces this error.
> >>>
> >>>Helge
> >>>
> >>>
> >>>
> >>
> >>here you go
> >>
> >>http://www.metawire.org/~c42/cups/
> >
> >
> > The filter (pdftops300) seems to be broken. Near the beginning of the PS
> > file,
> > there is the code:
> > ---snip---
> > /pdfSetup {
> > 3 1 roll 2 array astore
> > /setpagedevice where {
> > pop pop pop
> > } def
> > ---snip---
> > which is definitely bogus.
> > It will produce PostScript errors in an unpredictable way (depending on
> > how the
> > PS interpreter's scanner does read ahead etc.).
> >
> > It should read instead:
> > ---snip---
> > /pdfSetup {
> > 3 1 roll 2 array astore
> > /setpagedevice where {
> > pop 3 dict begin
> > /PageSize exch def
> > /ImagingBBox null def
> > /Policies 1 dict dup begin /PageSize 3 def end def
> > { /Duplex true def } if
> > currentdict end setpagedevice
> > } {
> > pop pop
> > } ifelse
> > } def
> > ---snip---
> > (which is produced by the original pdftops utility from the Xpdf suite).
>
> Actually, no, we don't want the setpagedevice commands there, we
> want to eliminate this pdfSetup stuff entirely since the commands
> are printer-specific.
>
> Looks like I missed a few lines, it should just be:
>
> /pdfSetup {
> pop pop pop
> } def
>
> --

Yes, but then you'd have to interprete either the DocumentMedia or the
BoundingBox
comment to get the media size set up in the PDF file (it is determined
by the crop box,
if present, or the media box otherwise, if I remember correctly).
It sould be sufficient to remove the duplex stuff from that procedure as
that has no
counterpart in the PDF file itself.

Helge


--
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de
tel: +49 30 75301-360


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: Not authorized for remote job operations

Alan Somers wrote: > I'm attempting to issue job operations for a remotely queued job from a > program running on a client. I have configured the remote server's > cupsd.conf file thusly: > > <Location /jobs> > AuthType None > AuthClass Anonymous > Order Deny,Allow > Deny From All > Allow From All > </Location> > > However, when I attempt to perform an operation on a remote job, the status > returned in the response is IPP_NOT_AUTHORIZED. Here's the code (simplified) > I'm using on the client for one of my test cases (the job is queued and the > printer is stopped): > > ipp_t *response; > ipp_status_t requestStatus; > cups_lang_t *language = cupsLangDefault(); > char *host = "iCenter.local"; > char *uri = "http://iCenter.local:631/jobs/239"; > http_t *http = httpConnectEncrypt(host, ippPort(), > cupsEncryption()); > ipp_t *request = ippNew(); > request->request.op.operation_id = IPP_HOLD_JOB; > request->request.op.request_id = 1; > ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_CHARSET, > "attributes-charset", NULL, > cupsLangEncoding(language)); > ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_LANGUAGE, > "attributes-natural-language", NULL, > language->language); > ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_URI, > "job-uri", NULL, uri); > ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_NAME, > "requesting-user-name", NULL, "unknown"); > if ((response = cupsDoRequest(http, request, "/")) != NULL) > requestStatus = response->request.status.status_code; > > Does anybody have a clue as to what's wrong? I haven't had a bit of problem > requesting status from the remote server, nor do I have any problems going > through the web interface. I found a solution. I changed the resource (third argument) in the cupsDoRequest() call to "/jobs" and job operations now work. Unfortunately, with the Mac OS X Panther CUPS authentication problem, I'm forced to leave job control wide open as configured above, although it's not too big of a deal.

Next Message by Date: click to view message preview

Re: cups filter Xpdf/pdftops seems to produce

Helge Blischke wrote: ... Yes, but then you'd have to interprete either the DocumentMedia or the BoundingBox comment to get the media size set up in the PDF file (it is determined by the crop box, if present, or the media box otherwise, if I remember correctly). It sould be sufficient to remove the duplex stuff from that procedure as that has no counterpart in the PDF file itself. The setpagedevice command is printer-specific, and it is not safe to set the page size that way. The page size can be changed in a PDF file on a per-page basis, so the DocumentMedia and BoundingBox comments are not applicable. The current filter does not set the media size from the PDF file and centers the PDF page by default; the "fitplot" option scales the page down. We have some pending changes that will allow the user to choose the scaling and page size behavior independently, however they will *not* use Xpdf's pdfSetup but instead the printer-specific commands from the PPD file. We will, of course, include the corresponding DSC comments. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com

Previous Message by Thread: click to view message preview

Re: cups filter Xpdf/pdftops seems to produce

Helge Blischke wrote: hans lux wrote: Helge Blischke wrote: hans lux wrote: hi there, i downloaded and compiled the latest cups version 1.2.x. i was actually only interested in the pdftops filter. when applying the filter to an arbitrary pdf file like ./pdftops 1 2 3 4 5 foo.pdf > out.ps and sending it to the printer, i get the following error: ERROR: VMerror OFFENDING COMMAND: pdfSetup STACK: and that's it. note: this error doesn't occur when i apply pdftops in version 2.01 and 2.03 and not in the command line version that comes mit Xpdf. can anyone attest this error ? hlux Post (an URL to) a sample PostScript file that produces this error. Helge here you go http://www.metawire.org/~c42/cups/ The filter (pdftops300) seems to be broken. Near the beginning of the PS file, there is the code: ---snip--- /pdfSetup { 3 1 roll 2 array astore /setpagedevice where { pop pop pop } def ---snip--- which is definitely bogus. It will produce PostScript errors in an unpredictable way (depending on how the PS interpreter's scanner does read ahead etc.). It should read instead: ---snip--- /pdfSetup { 3 1 roll 2 array astore /setpagedevice where { pop 3 dict begin /PageSize exch def /ImagingBBox null def /Policies 1 dict dup begin /PageSize 3 def end def { /Duplex true def } if currentdict end setpagedevice } { pop pop } ifelse } def ---snip--- (which is produced by the original pdftops utility from the Xpdf suite). Actually, no, we don't want the setpagedevice commands there, we want to eliminate this pdfSetup stuff entirely since the commands are printer-specific. Looks like I missed a few lines, it should just be: /pdfSetup { pop pop pop } def -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com

Next Message by Thread: click to view message preview

Re: cups filter Xpdf/pdftops seems to produce

Helge Blischke wrote: ... Yes, but then you'd have to interprete either the DocumentMedia or the BoundingBox comment to get the media size set up in the PDF file (it is determined by the crop box, if present, or the media box otherwise, if I remember correctly). It sould be sufficient to remove the duplex stuff from that procedure as that has no counterpart in the PDF file itself. The setpagedevice command is printer-specific, and it is not safe to set the page size that way. The page size can be changed in a PDF file on a per-page basis, so the DocumentMedia and BoundingBox comments are not applicable. The current filter does not set the media size from the PDF file and centers the PDF page by default; the "fitplot" option scales the page down. We have some pending changes that will allow the user to choose the scaling and page size behavior independently, however they will *not* use Xpdf's pdfSetup but instead the printer-specific commands from the PPD file. We will, of course, include the corresponding DSC comments. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by