[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Printing impossible

Title: signature_jp_2
Hi,

Ok now I am completely blocked. It results from the thread on the bugreport that:
- I tried all I was advised, it does not work
- The upstream devs explain Debian is responsible
- No answer from Debian Printing team.

Well, I am out of idea and, as often, people upstream explain it is Debian :D Not easy to hope fixing easily such problems.

Thanks very much for your further help.

Best regards,

Logo Hypra JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Facebook Hypra Twitter Hypra Linkedin Jean-Philippe

Le 26/03/2018 à 05:51, MENGUAL Jean-Philippe a écrit :

Logo Hypra 	JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61 <tel:+33184730661> Mob : +336 76 34 93 37
<tel:+33676349337>
jpmengual@hypra.fr <mailto:jpmengual@hypra.fr>
www.hypra.fr <http://www.hypra.fr/>
Facebook Hypra <https://www.facebook.com/hyprasoftware/> Twitter Hypra
<https://twitter.com/Hypra_> Linkedin Jean-Philippe
<https://fr.linkedin.com/in/jean-philippe-mengual-800133135>



Le 26/03/2018 à 01:17, Brian a écrit :

On Sun 25 Mar 2018 at 22:51:25 +0200, MENGUAL Jean-Philippe wrote:


Le 25/03/2018 à 19:05, Brian a écrit :

On Sun 25 Mar 2018 at 11:29:38 +0200, MENGUAL Jean-Philippe wrote:


I'll add that I set up a queue with

  lpadmin - p 1750 -v file:/dev/null -E -m drv:///splix-samsung.drv/ml1750.ppd

and printed the test page from the CUPS web interface. All filters
completed without any errors, as they do when cupsfilter was used with
any file I threw at it. Not much use in my testing the Ghostscript
command in that situation. The OP's experiences might be different, of
course.


I did all this. On http://demo.accelibreinfo.eu/error_log you have my
newest log, job 74 and 75. Still not printing.

Are we to assume you did the following?

1. Set up a queue as shown above. (There is no output because it goes to
   /dev/null).

With lpadmin, yes. And in Printers - Queue - Default options.



2. Print to it with 'lp -d /etc/services'.

I tried to print a test page. If I do lp -d /etc/services, I get "no
such file or dir". If I add a pdf file (lp -d /etc/services file.pdf" or
"lp file.pdf -d /etc/services", I get a similar error message.

Sometimes a respondent makes an error or a there is typo. Consulting the
lp manual might have helped you to sort it yourself.

 lp -d 1750 /etc/services

Ok thank. Sorry I did not look at the man as I am very confused with the
complexity of Cups commands as the problem requires advanced commands.
So in the global stream, I lack of knowledge sometimes. :) Anyway, the
command gives the same result. Log is up-to-date on
http://demo.accelibreinfo.eu/error_log




3. Examine the error_log. Four filters are used. Do any of them fail?

Logs dont seem to say another error than the initial mail I posted,
"COuld not find default_gray.icc", and "Cannot find device profile".
Just some lines later however, I have "gstoraster filter stopped" with
status 1. So I would say this filter fails.


I add also that I think indeed it is a ghostscript problem, but changing
the commandline as suggested in the bug report is impossible for me as I
dont know how I could set cups to change the commandline it sends.

Your three logs show gstoraster stopped, so spliX has no input from it
to render. We can test the ghostscript command without doing anything to
cups. The command is in your logs.

gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
   -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
   -sOutputFile=%stdout \   <----- Replace %stdout with out.ras.

Not sure I understood: I did: -sOutputFile=out.ras \

That's ok.


   -sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
   -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
   -dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
   -I/usr/share/cups/fonts -c \
   input.pdf

I have removed the -c switch and its argument because the argument is
interpreted as PostScript code and we are not inputting PostScript.

I have also split the command to use short, readable lines; the "\"s
have to be omitted when it is put on a single line.

Before running the gs command we need an input.pdf which has been
processed by cups. Do this:

cupsfilter -p /etc/cups/ppd/Samsung.ppd -m application/vnd.cups-pdf /etc/services > input.pdf

ok many thanks. input.pdf processing (first command) gives:
  ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
default_gray.icc
| ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
device profile
Unrecoverable error: rangecheck in .putdeviceprops
Operand stack:
    true


Also use any other PDF on your machine as input.pdf.

I get:
 ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
default_gray.icc
| ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
device profile
Unrecoverable error: rangecheck in .putdeviceprops
Operand stack:
    true


That is wh I reported to ghoscript before asking here.

And upstream at https://bugs.ghostscript.com/show_bug.cgi?id=695873 said:

 > The only way to tell for sure would be to try removing each
 > option until the problem goes away. You can do *that* from
 > the command shell yourself.

You have the command. Remove options one by one and report back.

ok thanks very much. You gave me essential things to go on while I was
lost.

I go on with the bugreport, as even without option, the problem is still
there. I let you informed when I get improvements with upstream.

Regards

Reply to: