dac922, Did you (or could you) try the:
lpadmin -p -o pdftops-renderer-default=gs
lpadmin -p -o psdebug
As I understand it, the "psdebug" option disables a bunch of compression
stuff in the Ghostscript output. It seems lots of printers have really
bad decompression implementations :-(
Thanks,
It seems that the fix for this was:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8031fd57
For me (using git cherry-pick) the patch applies cleanly to the 9.05
sources.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
Not being over sensitive, but:
"What is discussed here is the broken postscript code that makes Brother
printers to fail completely."
The Postscript is *not* broken, it is demonstrably valid. But it hits a
breakage in the Brother printer - the problem is with the printer, not
the Postscript.
Chr
I'll need the exact Postscript being sent to the printer, and the
command line invoking Ghostscript to create the PS.
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1049635
Title:
Cannot print
Okay, so we think we know the source of the problem.
All the text in the PDF is drawn with text rendering mode 7, which means
"add to clip". So drawing the text accumulates an enormous path, which
is then use to clip. Hence the limitcheck error on clip.
Now the Ghostscript ps2write output (for so
Frankly, that's what I feared. The Adobe produced Postscript can be made
to resemble either the Ghostscript output or the poppler output
(depending on the settings used in Acrobat), and it looks to me as
though this is simply a case where the (mostly minor) differences in the
imaging capabilities o
I can't see any way to reproduce the page description accurately without
running into the same problem.
IIRC, some Windows Postscript drivers have the option to produce the
page as an image, which I believe is intended to work around this type
of issue. Thus reducing the PDL complexity, for such l
I've attached the result of printing the first page from Acrobat,
through the KPDL Windows driver. It looks similar to the poppler output
(it builds the clipping path using charpath operations).
The Kyocera driver does, indeed, include a "Print As Image" option - although
it comes out grayscale,
Well, I think it's fair to say that if Kyocera's very own driver does
not/cannot produce PS that the printer can interpret, it's not
unreasonable that we don't. I'm not saying if there were a reasonable
way for us to workaround the problem that we wouldn't, on that basis -
but frankly, none of us c
No, we're not going to add that option to ps2write, that would, frankly,
defeat the whole point of ps2write.
There is already a cups imagetops filter, so it would be a lot less work
to have the option have Ghostscript convert to pnm and then do imagetops
on the pnm.
--
You received this bug noti
For tracking the Ghostscript end of this, see:
http://bugs.ghostscript.com/show_bug.cgi?id=693197
** Bug watch added: Ghostscript (AFPL) Bugzilla #693197
http://bugs.ghostscript.com/show_bug.cgi?id=693197
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
Right, again with much help from Felix, we're narrowed the problem down
to the fact that the images in the originating PDF request
interpolation, thus so does Ghostscript's Postscript output, and it
seems that, for the class of image in question, at least, the 1350D's
implementation of interpolatio
I'm relieved to put another issue to bed!
BIG thanks to Felix for his patience (and paper!) in helping us track
this down.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1026974
Title:
Printing Bahn
I can't find a gs command line anywhere in the logs. Could someone post
the command line cups gives to GS these days? Perhaps that could be
added to the cups logging? Also any PS that gets prepended.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subsc
Oh, it looks like this is one of the printers we opted to disable page
"stream" compression, but IIRC, Till, you put in user controls to allow
disabling of font compression - that might be a good place to start.
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
I'll need the Postscript that gets sent to the printer, too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025061
Title:
Kyocera FS-1300DN cannot print with gs backend
To manage notifications abou
Felix,
that's the poppler emitted PS (which is useful, I would probably have
asked for it down the line anyway), but I really need the PS generated
by Ghostscript, if you could thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
Felix,
First of all, (and I may have told you this before, but I would like it
recorded in this, and all relevant bugs): this is *not* a bug with the
Ghostscript Postscript output. The GS Postscript is valid - we spent a
lot of time confirming that when these bugs started to come to light.
The fau
Darn it! Sorry, I forgot I needed to add the device specific stuff to
the file.
http://www.ghostscript.com/~chrisl/nolzw2.ps
Should be more what we want apologies again.
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
Okay, so it is not a problem with the LZW filter. That still leaves
another (non-compressing) filter that could be at fault, but I'll try to
narrow things down a bit before we get to that. On that basis, I'll work
on modifying the version with the compression, since it's a lot smaller
(obviously!).
Felix,
by the way, if there is a more convenient way of communicating for you
than using launchpad (e-mail or IRC or something) then let me know. I
can summarise progress on the problem here as required.
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Hmm, I did *not* expect that :-(
If you can try this one:
http://www.ghostscript.com/~chrisl/printout-003.ps
In this one I have removed all the ps2write "marking content", and
replaced it with just a blank page.
If IRC would be easier, I'm on #ghostscript on freenode most days (I'm
on UK time) -
Again, I really didn't expect that :-(
http://www.ghostscript.com/~chrisl/printout-004.ps
That one should (on a fully functional printer) produce no output at all
- not even a blank page.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Felix joined us on #ghostscript and with his help, I narrowed the
problem down to the fonts in the file.
The way ps2write currently works is that it writes a pfb (binary encoded
Type 1 Postscript font) and ASCII85 encodes it so the binary data
doesn't trip up the communications channels.
The Kyoc
I ran across this problem with Oneiric on my Lenovo x100e. With James'
fix, the issue no longer occurs, and after several hours use, there does
not appear to be any regressions caused by it.
Thanks,
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
Till,
I believe we've been through enough of these that you should know the
basic groundwork required before I can really do anything.
To start with, try the "uncompressed" CUPS option, and if that doesn't
work, then gather the (preferably uncompressed) Postscript that is being
sent to the printe
Jeremy,
Whilst we will investigate this, we are confident that the Postscript
being emitted by Ghostscript is valid and correct, based on our own
inspection of the Postscript code, and since it works correctly on a
large number of devices.
Given that, it seems almost certain that there is a bug i
Jeremy,
Your next step should be to try doing:
lpadmin -p -o psdebug=true
where "" is the name of the Xerox print queue, and try printing
normally.
If that still gives the error on the printer, refer to:
https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_
Jeremy,
If you don't mind, could you do me favour, and repeat the test print
after doing:
lpadmin -p test -o psdebug=true
(assuming you called your file output queue "test" as suggested in
"Getting the data which would go to the printer"), please?
It's just it will save time if I don't have to
Could you repeat the "capture the data going to the printer" stage after
applying the "psdebug" setting to the "testing" print queue (that is,
the new print you created to send the printer data to a file), and
attach the output here, please?
Could also confirm which version of Ghostscript is insta
On the BizHub unit referenced in the above Ghostscript bug,
investigation by KonicaMinolta UK suggested that this was a firmware bug
which has been addressed in the most recent revisions - I've yet to
receive confirmation from the user on that, but KM were unable to
reproduce the crash on their own
Thanks. Hmm, the "psdebug" option is not working as I understood it - I
*thought* it was supposed to produce very "plain" uncompressed, and (as
far as possible) "unfiltered" output. But what you've got out of it is
exactly the same as the non-psdebug output.
Till, can you confirm (or deny) what ps
Steve,
Till is looking into the possibility of providing an option to use the
poppler tool as a workaround, I'll leave it to him to update on that
when/if he has news.
Obviously, in the long term, we'd like to resolve these issues that
various printers have with the Postscript output from Ghostsc
Steve,
Could I ask you to send this file (stream1-uc.ps) to your printer,
please? It is the same content as your original, but with the
compression removed.
You need to use:
lpr -P -o raw stream1-uc.ps
If the HP in question is your only only, or your CUPS default printer,
you can probably leav
Jacques,
Did the:
lpadmin -p -o psdebug=true
have any effect?
Also, can you try a different font from Ubuntu-Medium? Myabe one of the
DejaVu ones if you have them.
If we have to really debug this, it will take quite a bit of effort from
both us (and possible a fair amount of paper!).
Chris
-
What normally happens is that someone posts the Postscript that is sent
to the printer from the Ghostscript workflow, preferably uncompressed by
using the "psdebug=true" option. Ideally, in cases like this, also from
the Postscript from the Poppler workflow.
We then go through a process where I cu
Aha, assuming nothing has changed, grabbing the printer PS can be done
like this (originally from Till):
cupsctl FileDevice=yes
lpadmin -p test -E -v file:/tmp/printout /etc/cups/ppd/.ppd
Now print the job which failed on the printer "test" and as soon as the
job disappears from the queue attach
Laurent,
1 - Erm, dunno! As I said, I just copied the instruction from a comment
from Till on another bug. I don't know the best way to find which PPD
your printer is actually using, but the PPD name *usually* reflects the
make/model of the printer - for example, mine is "HP-
Officejet-h470.ppd".
Laurent.
I'm afraid that
"https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data";
is wrong, or at least misleading these days.
What it captures is the file(s) from the cups print queue, which is
printer independent (PDF, as a matter of fact), and not the final page
descriptio
Huh, debug option doesn't do everything I thought it did - never mind, that
gave me enough I could get what I need with a little manual hacking.
First of all, your printer is broken!!! Four different Postscript
interpreters, all from different vendors (include Adobe) all agree that
this is valid,
Realy?!?!? I did *not* expect that.
That suggests that there is a bug either with the LZW decode filter, or
with that filter's interaction with other aspects of the interpreter. I
have seen such things before.
Thanks for testing it Marty.
Okay, so if I can ask as many interested parties from
Once again, that is a PDF from the CUPS print queue, not the Postscript
that is actually being sent to the printer.
Note you are not supposed to be using the *default* configuration, you
have to apply the settings from Till in post #57.
--
You received this bug notification because you are a mem
Sorry, I know I'm repeating myself, but I'm *not* a CUPS developer (I
work on Ghostscript), so I don't know the ins and outs of getting the
data out of CUPS.
Hopefully, Till will pipe up...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
It should noted that if anywhere in the CUPS workflow uses the
Ghostscript ps2write device, CIDFonts will not "survive" that
conversion.
CIDFonts are a Postscript level 3 feature, so ps2write has to "flatten"
them to some other font format, and in doing so, will lose the original
"encoding" (there
Till,
Well, it's Ken that's going to have to make the change, so it's
dependent on him - I'll pass on the request.
The CUPS (or whatever) change will be adding an extra option to the
Ghostscript command line, for these printers only - once again, we don't
want to slow down good printers to work a
Bruce or Till,
Can you post the Postscript you get when you do:
pdf2ps -dCompressPages=true -dCompressFonts=false -dNoT3CCITT
-dEncodeMonoImages=false printout printout2.ps
Thanks,
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Thanks, but I made a mistake, sorry, I meant:
pdf2ps -dCompressPages=false -dCompressFonts=false -dNoT3CCITT
-dEncodeMonoImages=false printout printout2.ps
It's been a long day.
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
Bruce,
Can you try sending these two tests to your printer, please?
http://www.ghostscript.com/~chrisl/printout2-1-pjl.ps
http://www.ghostscript.com/~chrisl/printout2-2-pjl.ps
Let us know the results.
Thanks,
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs
I think your printer is even more broken that we thought!
At some point, someone is going to have to tell Brother their Postscript
is broken!
But given that this is clearly a different issue, I think it would be
best if you opened a new bug to track this new problem.
Chris
--
You received this
Bruce,
Thanks for doing this in a new bug.
I've created a simplified test:
http://www.ghostscript.com/~chrisl/ZLogManual-p1.ps
This is just the first page, and is uncompressed. Can you see if this
still errors, please?
Chris
--
You received this bug notification because you are a member o
Bruce,
You need to send:
http://www.ghostscript.com/~chrisl/ZLogManual-p1.ps
to your printer directly, not via the cups print queue, as per the method you
used in the previous bug:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/93
Chris
--
You received this bug notification
Bruce,
Please try this one, again, directly to the printer:
http://www.ghostscript.com/~chrisl/ZLogManual-p1-002.ps
Again, please post the result..
Also, have you reported this to Brother? It's clearly a bug with the printer,
not the Postscript.
Chris
--
You received this bug notificati
Bruce,
Yes, that's the right way to send these files to the printer.
So, I'm just guessing about where the problem might lie, but can you try
this version, please?
http://www.ghostscript.com/~chrisl/ZLogManual-p1-003.ps
again using the "lpr -oraw" method
Thanks,
Chris
--
You received this b
Laurent,
Could you post the error message you get from that file, please? I'm a
bit confused because the file you posted in comment #71 seems different
to the ones I remember looking at before in this bug - it's *much*
simpler, which is good, but I need to be sure where I should look before
I star
The file you attached in comment #71 definitely comes from Ghostscript (the
meta-data comments at the head of the file show that), and not from poppler, so
that was the configuration that gave you the error in 12.10.
If you grab the attachment from #71, decompress/untar it, then do:
lpr -P -or
101 - 155 of 155 matches
Mail list logo
