Toshiba Estudio 230 printer driver bug
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cups-filters (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Precise |
Fix Released
|
High
|
Unassigned |
Bug Description
Description: Ubuntu precise (development branch)
Release: 12.04
When trying to print on a Toshiba EStudio 230 printer using the stock driver, print jobs fail and the printer reports following error
ERROR:
invalidfont
OFFENDING COMMAND:
$definefont
STACK:
--nostringval--
/TVZYWM+
--nostringval--
/TVZYWM+
--nostringval--
--nostringval--
14
Printer is able to print using manufacturers driver downloaded from internet Toshiba EStudio 280
Related branches
Launchpad Janitor (janitor) wrote : | #1 |
Changed in aptdaemon (Ubuntu): | |
status: | New → Confirmed |
digsim (andreas-ruppen) wrote : | #2 |
I am facing the same problem. However, my printer is a Toshiba E-Studio 5520C. When I try to print I get the same result as in the description. Even with another ppd file. Could you explain what you mean by "using manufacturers driver downloaded from internet"?
Cheers
affects: | aptdaemon (Ubuntu) → cups (Ubuntu) |
digsim (andreas-ruppen) wrote : | #3 |
After a few tests it seems that I can print to this printer from the printing dialog. Yet, the "Print test page" from the printer setup menu will give me the error described in the bug report.
digsim (andreas-ruppen) wrote : | #4 |
Ok still a few tests later, I can say that some documents will print (like pdf) but only when choosing the right combination of options. It is for example not possible to print out more than one example a time. Other applications will not print at all like LibreOffice. It is however still possible to print from LibreOffice to a pdf and then print the pdf but that is not really a comfortable solution.
Christof Arn (christof-arn) wrote : | #5 |
Same Problem with Toshiba e-Studio 165, even using latest ppd from http://
I can print the printer test page, but no more documents from libreoffice.
I can print by printing form libreoffice to a pdf and then print by evince or adobe reader 9, but not by gtklp.
Problem occours with ubuntu precice 12.04, but also with ubuntu 10.04 and with debian testing.
Problem occours since one or two month, can't remember exactely, when the problem was first time.
Christof Arn (christof-arn) wrote : | #6 |
Sorry, i have to correct myself: Problem occurs not with ubuntu 10.4, but occurs with debian testing.
napnap (napnap) wrote : | #7 |
I had a similar bug with :
Toshiba e-studio 2040C
& Ubuntu 12.04
Tested with :
- manufacturers driver (TOSHIBA ColorMFP PPD)
- Ubuntu "built-in" driver (TOSHIBA e-STUDIO3510c Series PS)
Both of all worked fine with Ubuntu 11.10 and effectively, int 12.04 LibreOffice prints show this error but not the generated Pdf.
===
ERROR :
invalidfont
OFFENDING COMMAND:
$definefont
STACK:
--nostringval--
/TNVORA+
--nostringval--
/TNVORA+
--nostringval--
--nostringval--
14
===
Daniel Steglich (steglich) wrote : | #8 |
Toshiba-
Greg Carlsen (gcarlsen) wrote : | #9 |
I can confirm this affects the E-Studio 202L as well. Worked fine with 10.04 and 11.10.
Identical error as those above when printing a test page, pdf, Libreoffice... etc.
thomaskr (nmc) wrote : | #10 |
I can confirm this affects E-Studio-520 as well. Worked fine with 11.10, 11.04, 10.10, 10.04
Identical error as those above when printing a test page, pdf, Libreoffice... etc.
tried different ppd files e.g. from former release. which did not solve the problem.
any work around available?
walter salzmann (w-salzmann) wrote : | #11 |
Toshiba-
Greg Carlsen (gcarlsen) wrote : | #12 |
I tried the CUPS driver from Toshiba on my 202L and it still prints the error page with print test page, but otherwise, is working so far.
napnap (napnap) wrote : | #13 |
Is not a definitive workaround but to continue to use our Toshiba e-Studio with new Ubuntu distrib (12.04), first I've removed the cups package (and dependency) to install cups 1.5.0 (ubuntu 11 version).
Then download the source at http://
At compile time the --enable-dbus option seems to be necessary (Be sure to check if DBUS is found in config.log, if not, install dbus-1-dbg using apt (or libdbus-glib-1-dev I don't remember, I tested several *dbus*)
Make && make install. All seems to work like a charm.
affects: | cups (Ubuntu) → cups-filters (Ubuntu) |
Changed in cups-filters (Ubuntu): | |
importance: | Undecided → High |
milestone: | none → quantal-alpha-1 |
status: | Confirmed → Fix Released |
Till Kamppeter (till-kamppeter) wrote : | #14 |
- cups-filters_1.0.17-0bzr0.1_1.0.18-0ubuntu0.1.debdiff Edit (51.6 KiB, text/plain)
The problem is most probably caused by switching the pdftops CUPS filter from Poppler to Ghostscript and allowing higher image rendering resolutions when the pdftops filter has to turn graphical structures of the PDF input file into bitmaps when converting to PostScript and PostScript does not support these structures.
I have uploaded a cups-filters package to precise-proposed now which switches back to Poppler and limits the image rendering resolution to 360 dpi. Please test the package as soon as it gets available for download and give feedback here. This is required to make the new package an official update for Precise. Another comment with testing instructions will get posted here.
With the new package you can also test the behavior when switching between use of Poppler and Ghostscript and changing the resolution limit. Run the following commands in a terminal window for switching between Ghostscript and Poppler:
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
and
lpadmin -p printer -R pdftops-
to remove the setting. To change the resolution limit run a command like
lpadmin -p <printer> -o pdftops-
and set unlimited resolution via
lpadmin -p <printer> -o pdftops-
or remove your setting with
lpadmin -p <printer> -R pdftops-
Always replace "<printer>" by your printer's queue name (enter "lpstat -v" to find your printer's queue name).
See also
/usr/share/
See and tell us in this bug report which works best for you.
A debdiff of the changes is attached.
Changed in cups-filters (Ubuntu Precise): | |
status: | New → Fix Committed |
importance: | Undecided → High |
milestone: | none → precise-updates |
Till Kamppeter (till-kamppeter) wrote : | #15 |
- cups-filters-pdftops-c-1.0.17-1.0.18.diff Edit (12.2 KiB, text/plain)
To the SRU team: The relevant changes for the fix are in the file filter/pdftops.c. The file in the debdiff looks very cluttered as there are many lines where only white space (indentation) changed. Attached to this comment is a cleaner diff for this file with white space changes ignored (diff -b), here one especially sees how the conditional compiling for Ghostscript/Poppler is replaced by "if"s so that the Ghostscript/Poppler decision can be made at run time.
Martin Pitt (pitti) wrote : Please test proposed package | #16 |
Hello Jacques, or anyone else affected,
Accepted cups-filters into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https:/
tags: | added: verification-needed |
Till Kamppeter (till-kamppeter) wrote : | #17 |
Another test you should try:
After having tested the proposed package without changing any default settings, run the following commands in a terminal window
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o psdebug=true
with <printer> being the name of your print queue (You can find the name by ruuning the "lpstat -v" command).
After that try to print again. Does it work? If it works and if it is too slow, run
lpadmin -p <printer> -o pdftops-
and try again. If it is still too slow, run
lpadmin -p <printer> -o pdftops-
and try again.
Please report all your results here.
To get back to the default settings of the proposed package run the commands
lpadmin -p <printer> -R pdftops-
lpadmin -p <printer> -R pdftops-
lpadmin -p <printer> -R psdebug
napnap (napnap) wrote : | #18 |
Hello,
thanks to your good work. Success, This fixes the bug.
So I've made several test with LibreOffice Writer, text and images :
==
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
==
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o psdebug=true
==
I print pages after each change(==) but sorry, I see no difference. All pages are printed correctly with a time difference not significant. (I haven't tested low resolution).
Then, the psdebug option is supposed to do something? I don't see specific log file/messages...
Once again, thanks a lot for your work.
tags: |
added: verification-done removed: verification-needed |
Till Kamppeter (till-kamppeter) wrote : | #19 |
You suffered the problem with Ghostscript being used for turning PDF to PostScript and no limit in the image rendering resolution (resolution used when non-bitmap parts of the PDF input get converted to bitmap images in the PostScript output). In addition, Ghostscript compresses the page data before sending it to the printer.
After installing the package and before doing the first bunch of changes you are using Poppler for turning PDF into PostScript and the image rendering resolution limit is 360 dpi. This resembles Ubuntu 11.10 and you can print with it.
The first bunch of changes leaves you with Poppler for PDF->PS conversion and lifts the rendering resolution limit completely, so that always the actual printing resolution is used, even if it is very high. You can also print under these conditions. But note that without the resolution limit complex PDFs or PDFs printed with evince can come out slowly.
After the second bunch of changes you switch back to Ghostscript as PDF->PS converter. You are again working without resolution limit. The difference to the original configuration with which you have observed the bug is that now the PostScript output of Ghostscript is not compressed. The "psdebug" option turns off Ghostscript's page compression. As you can print with this configuration it seems that Ghostscript's compression is the culprit for the bug. So stay with this configuration and observe how printing works for you with it, especially also with other applications than LibreOffice. We are looking into making this configuration the default for Ubuntu Quantal (12.10).
Till Kamppeter (till-kamppeter) wrote : | #20 |
Chris, in this bug report a user has problems with Ghostscript's PostScript on a Toshiba printer and the problem goes away when suppressing Ghostscript's page compression ("psdebug" option for the pdftops CUPS filter). So it is possible that the compatibility of Ghostscript's PostScript with PS printers gets better when sending the pages uncompressed. So I recommend you to first ask the users to turn off compression via
lpadmin -p <printer> -o psdebug=true
and only if this is not sufficient do deeper investigation.
To get back to the original configuration, run
lpadmin -p <printer> -R psdebug
napnap (napnap) wrote : | #21 |
From what you said, I made some additional tests.
I printed a high resolution (2000dpi more Than http://
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -R psdebug
== Printing is good, latency about 2 mn,
lpadmin -p <printer> -o pdftops-
== Printing are good, latency about 2 mn.
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
== Printing are good, latency about 2 mn.
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o psdebug
== Printing are good, latency about 2 mn.
Ultimately, my conclusion is the same. I see no difference between the options. But everything works.
Till Kamppeter (till-kamppeter) wrote : | #22 |
Thank you for testing. Marking the bug as verified.
Thank you also for testing the different configurations. Please keep the following configuration:
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -R psdebug
as this is the one we would like to use in Ubuntu 12.10 as it gives best quality and color management.
If you get too slow printing or errors in the future, report another bug and change your configuration as follows:
For more speed:
lpadmin -p <printer> -o pdftops-
or even
lpadmin -p <printer> -o pdftops-
In case of errors:
lpadmin -p <printer> -o psdebug
and if this does not help
lpadmin -p <printer> -o pdftops-
Launchpad Janitor (janitor) wrote : | #23 |
This bug was fixed in the package cups-filters - 1.0.18-0ubuntu0.1
---------------
cups-filters (1.0.18-0ubuntu0.1) precise-proposed; urgency=low
[ Till Kamppeter ]
* New upstream release
- pdftops: Allow selection whether Ghostscript or Poppler is used
at runtime, setting the "pdftops-renderer" option to "gs" or
"pdftops". This way one can switch to Poppler per-queue if there
are incompatibilities with certain PostScript printers.
- pdftops: Allow setting an upper limit for the image rendering
resolution, also at runtime, setting the option
"0" means no limit.
- pdftops: Fixed crash by wrong usage of sizeof() function when adding
"Collate" to the fifth command line argument for the "pstops" CUPS
filter call (LP: #982675).
- pdftops: Removed newline from copies value when reading it from
the "%%PDFTOPDFNumC
- pdftops: Silenced compiler warning about ignoring the return
value of the write() function.
- pdftops: Added a crash guard.
- pdftops: Start determining the printing resolution with
the choice names of the "Resolution" option are marketing names
with higher numerical values than the actual resolution. Also
ignore error exit values of cupsRasterInter
function can error out after having found the resolution
(LP: #984082).
- pdftops: If printing resolution is determined by
resolution cannot be determined (LP: #984082).
* debian/rules: Set default renderer for the pdftops filter to Poppler
due to many printer's buggy interpreters having problems with GhostScript's
PostScript and set image rendering resolution limit of the pdftops filter
to 360 dpi to prevents slow processing by the printer if very high
resolutions are used or if the printing resolution is mis-detected by the
pdftops filter (LP: #668800, LP #951627 (comment #30), LP: #998087,
LP: #992982 (comments #26, #27, #30, #31), LP: #997728, LP: #994477,
LP: #998087, LP: #978120, LP: #862167).
[ Didier Raboud ]
* Drop libtiff5-dev, just use libtiff-dev, this fixes the FTBFS due to
incompatibility with cups.
-- Till Kamppeter <email address hidden> Wed, 16 May 2012 11:25:03 +0200
Changed in cups-filters (Ubuntu Precise): | |
status: | Fix Committed → Fix Released |
emptythevoid (emptythevoid) wrote : | #24 |
This bug is present in Ubuntu 12.10 64-bit and 32-bit. I'm trying to add the Toshiba 4540c using the default ppd available, and from Toshiba's website, and I'm getting the exact same error as described in this bug.
dac922 (dac922) wrote : | #25 |
Same error with Ubuntu 12.10 64bit and Toshiba EStudio 2500c.
dac922 (dac922) wrote : | #26 |
Btw.:
lpadmin -p <printer> -o pdftops-
helps..
cliddell (cjl) wrote : | #27 |
dac922, Did you (or could you) try the:
lpadmin -p <printer> -o pdftops-
lpadmin -p <printer> -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,
Chris
Marty (marty-supine) wrote : | #28 |
I'm seeing this error on 64bit 12.10 with an eSeries 2500c.
Tried the settings in comment #27 but they made no difference.
Marty (marty-supine) wrote : | #29 |
As per comment #26 switching to pdftops fixes the problem.
Laurent Cottereau (laurent-cottereau-name) wrote : | #30 |
I had the same problem with a Canon eStudio 455 and comment #26 resolved it.
Jacques Blain (blain-jacques) wrote : | #31 |
The problem seems to have comeback exactly as before when I changed computer from Ubuntu 12.04 to Ubuntu 12.10 !!??
cliddell (cjl) wrote : | #32 |
Jacques,
Did the:
lpadmin -p <printer> -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
Laurent Cottereau (laurent-cottereau-name) wrote : | #33 |
Hello, my comment #30 was not very detailled. I had the problem on 12.04 and lpadmin -p <printer> -o pdftops-
If you want me to try some things out, I should be able to help.
cliddell (cjl) wrote : | #34 |
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 cut the Ghostscript file down bit-by-bit, and a willing volunteer sends my edited files to their printer, and tells me whether it fails or not. That way we find the smallest file that will fail.
I may then have to "instrument" the Postscript to get further debug information back to narrow down *exactly* what causes the error, and hoepfully work out why - possibly by comparing it to the Poppler output. Although the Poppler output is often not directly comparable.
Obviously this can be a tiresome process for everyone involved, and can take some time. Equally obviously, the simpler the file we start with, the better!
Unfortunately, I can never remember how to tell CUPS to save the Postscript, instead of sending it to the printer..... I'm not a CUPS guy.
cliddell (cjl) wrote : | #35 |
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/<your printer's PPD>.ppd
Now print the job which failed on the printer "test" and as soon as the job disappears from the queue attach the file /tmp/printout to this bug report.
Coops (coops) wrote : | #36 |
Just for the record, this worked fine for me:
lpadmin -p TOSHIBA-
"TOSHIBA-
Cheers.
Laurent Cottereau (laurent-cottereau-name) wrote : | #37 |
1 - when I try to run the commands on #35, I get the following error message
lpadmin: Unknown argument "/etc/cups/
2 - Can you tell me how to come back to the "default" configuration : what is the default value of pdftops-
Thanks
cliddell (cjl) wrote : | #38 |
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-
2 -
"lpadmin -p <printer> -o pdftops-
sets it back to the default. We also need:
"lpadmin -p <printer> -o psdebug"
as that disables various features which can a) fix the problem or b) make the problem easier (or even possible) to debug.
mac.ryan (macryan) wrote : | #39 |
One more confirmation that the following works:
lpadmin -p <printer-name-here> -o pdftops-
for Toshiba e-Studio 2820c too.
Laurent Cottereau (laurent-cottereau-name) wrote : | #40 |
- The text file printed Edit (11 bytes, text/plain)
cliddell, I have captured the information thanks to https:/
The data sent is a simple text file containing the text "Hello World". It is printed through Firefox.
OK is the data that works
both KO and KO-nodebug do not work (never start printing, just "receiving data" on the printer)
22 comments hidden Loading more comments | view all 102 comments |
cliddell (cjl) wrote : | #63 |
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.
Laurent Cottereau (laurent-cottereau-name) wrote : | #64 |
I am so sorry to be that messy. I am getting very confused. The last file I sent (now that I look at it, it is indeed PDF) was obtained by printing a PDF document through the printer created by
lpadmin -p test -E -v file:/tmp/printout -o ~/temporaire/
as explained in #35 and #43
Maybe it is because the original file is PDF ? Or is that configuration just not doing PS ?
cliddell (cjl) wrote : | #65 |
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.......
Till Kamppeter (till-kamppeter) wrote : | #66 |
Laurent, the command in comment #64 is wrong. There must be a "-P" before the PPD file path, not "-o":
lpadmin -p test -E -v file:/tmp/printout -P ~/temporaire/
After having created the queue with this command, apply the commands from #61 to it:
lpadmin -p test -R pdftops-
lpadmin -p test -o psdebug-
The print your job to tyhis queue and attach the resulting /tmp/printout.
Laurent Cottereau (laurent-cottereau-name) wrote : | #67 |
- PS file of a 2 page PDF file Edit (150.0 KiB, application/x-tar)
At last, here it is and it seems to be the correct format (thank you @clj and @till-kamppeter)
lcottere@
20130121-toshiba: PostScript document text conforming DSC level 3.0, Level 2
Hope it works out.
mexlinux (mcanedo) wrote : | #68 |
Same problem on Xerox WorkCentre M20
The workaraund worked:
lpadmin -p <printer> -o pdftops-
Jason Straight (jason-jeetkunedomaster) wrote : | #69 |
Should this bug be re-filed or re-opened so it's not forgotten about [as this bug is marked fixed]?
Martyn Ranyard (ranyardm) wrote : | #70 |
As an alternative workround these printers do accept PCL - I have happily printed to e-Studio printers by selecting Generic PCL5 (mono) and PCL6XL drivers from the Cups "Generic" selection. The printers print happily and fast no matter what font I use.
Laurent Cottereau (laurent-cottereau-name) wrote : | #71 |
- printout.tar.gz Edit (46.9 KiB, application/x-tar)
I am back with the same file, this one from the same installation on 13.04 (the problem still appears and is corrected in the same way).
cliddell (cjl) wrote : | #72 |
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 start poking around.
BTW, I'm going to be away from my office for a few days, so it will probably be next week before I can look in detail.
Thanks,
Chris
Laurent Cottereau (laurent-cottereau-name) wrote : | #73 |
It's weird. I don't seem to be able to go back to the problematic state (it used to not work again when I did "lpadmin -p printer -R pdftops-
On 13.04, it was not working when I installed (from scratch but without reformatting /home). I think (but the paper is gone to trash) that the message was the same as the one on top of this thread.
I did "lpadmin -p <printer> -o pdftops-
cliddell (cjl) wrote : | #74 |
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 <printer name> -oraw printout
With "<printer name>" being the name of the print queue for your Toshiba printer, and "printout" being the name of file - the "-oraw" ensures that will send the file directly to the printer, avoiding any regeneration by an application, and any additional filtering by cups.
Frank Earl (linusti) wrote : | #75 |
Happens with the E-Studio printer series as well as other Postscript based printers (Konica-Minolta C353...)
Workaround at the top allows things to work right again. Seems to be a regression with 13.04 (Which is what I'm on right now.)
cliddell (cjl) wrote : | #76 |
Frank,
We've made changes to address problems with Konica-Minolta printers, but you may have found another problem.
We know how to track these problems down, but they take a lot of time and effort (and paper!) on the part of the users as well as us, and so far, no one has seemed willing to see the process through to a conclusion.
If I had direct access to these printers, things would be much quicker, but that's not really practical, unfortunately.
Tomas Gustavsson (tomasg) wrote : | #77 |
I am getting identical error message using Toshiba eStiduo 2050c.
A fresh installed Trust Tahr, 14.04 beta. Using a Toshiba eStudio 2050c printer over network. I was using this printer since a long time before on different Ubuntus, until I now reinstalled clean with 14.04.
Adding printer works fine. It is detected and all looks good. Using default install with driver "TOSHIBA e-STUDIO3510cSe
"Print test page" reports:
Page 1:
blank
Page 2:
ERROR:
invalidfont
OFFENDING COMMAND:
$definefont
STACK:
--nostringval--
/VUEKTG+
--nostringval--
/VUEKTG+
--nostringval--
--nostringval--
14
Page 3:
PS error: invalidaccess
Running the command:
lpadmin -p TOSHIBA-
(where I got the name from lpadmin -v)
And make a "print test page" again, results in a good test page.
Running the command:
lpadmin -p TOSHIBA-
Causes error again.
I will make a PS collection using instructions on page:
https:/
Tomas Gustavsson (tomasg) wrote : | #78 |
(lpstat -v it should say above)
Tomas Gustavsson (tomasg) wrote : | #79 |
- Attached printout on cloned queue, printout_tomas_20140324 Edit (656 bytes, application/octet-stream)
Tomas Gustavsson (tomasg) wrote : | #80 |
- printout_testpage_tomas_20140324 Edit (331.0 KiB, application/octet-stream)
Sorry that was a bad attachment, it was a self test, not a print test page. Find another one attached. printout_
cliddell (cjl) wrote : | #81 |
Okay. so the next thing I'll ask you to do is to try step 10 from this section:
http://
And see if that works better, and if not, attach the non-compressed file.
Thanks!
Tomas Gustavsson (tomasg) wrote : | #82 |
- printout_testpage_noncompressed_tomas_20140324 Edit (337.9 KiB, application/octet-stream)
Didn't work. Attaching uncompressed file.
Tomas Gustavsson (tomasg) wrote : | #83 |
Commands used:
lpr -P test -o psdebug printout_
lpr -P TOSHIBA-
cliddell (cjl) wrote : | #84 |
Hmm, that's not producing a non-compressed file - hopefully, Till will pipe up to tell us what's going wrong (as mentioned elsewhere, I'm not a CUPS guy, I'm a Ghostscript guy.....).
cliddell (cjl) wrote : | #85 |
- Properly uncompressed version Edit (735.6 KiB, application/octet-stream)
OKay, I have "manually" decompressed the various parts of the contents of the file (you'll note it is now double the size!). If you could follow the procedure to send this file directly to the printer (-oraw) and let me know the result. Thanks.
Note that, once again, five different Postscript interpreters from five different vendors all handle the original file without an error, so I assume this is a bug in the printer. Even if we can find a workaround, I would *strongly* encourage you to send a bug report to Toshiba about this - it is disgraceful that so many manufacturers are shipping PS printers that fail to interpret fairly basic Postscript, and I really feel we need to let them know it's just not acceptable!
Tomas Gustavsson (tomasg) wrote : | #86 |
lpr -P TOSHIBA-
produces the same error result.
Tomas Gustavsson (tomasg) wrote : | #87 |
A sidenote: Adding the printer as a "generic" PCL6 printer also produces proper test printouts.
Till Kamppeter (till-kamppeter) wrote : | #88 |
Tomas did exactly the right to obtain uncompressed PostScript. the option is "-o psdebug" as he did. I do not know why the PostScript came out compressed. Perhaps confused output files of different test runs? Or mistyped the option?
Tomas, to make sure that your further tests do actually deliver PostScript from Ghostscript, especially after the update to cups-filters 1.0.49, please run
lpadmin -p TOSHIBA-
lpadmin -p test -o pdftops-
Tomas Gustavsson (tomasg) wrote : | #89 |
root@donake:~# lpadmin -p TOSHIBA-
root@donake:~# lpadmin -p test -o pdftops-
(press print testpage)
root@donake:~# ll /tmp/printout
-rw------- 1 root root 338990 mar 24 16:02 /tmp/printout
root@donake:~# mv /tmp/printout /home/user/
root@donake:~# lpr -P test -o psdebug /home/user/
root@donake:~# ll /tmp/printout
-rw------- 1 root root 346007 mar 24 16:04 /tmp/printout
root@donake:~# mv /tmp/printout /home/user/
cliddell (cjl) wrote : | #90 |
- Cut down file Edit (185.8 KiB, application/octet-stream)
Tomas, can you try this one, too, please - same procedure.
FWIW, I'm expecting this to fail in the same way as the previous one.
Tomas Gustavsson (tomasg) wrote : | #91 |
Correct, the same error happens.
lpr -P TOSHIBA-
Identical error papers printed.
cliddell (cjl) wrote : | #92 |
Hrm, that's not a surprise, but it is a pain. I need to give this some thought.....
cliddell (cjl) wrote : | #93 |
- Uncompressed file with no ttf font Edit (636.2 KiB, application/postscript)
Tomas,
Can you give this one a try, and tell us how it behaves, please?
Thanks
Tomas Gustavsson (tomasg) wrote : | #94 |
Yes, that works!
I tested twice, with a non-working ps in the middle just to make sure it wasn't some random success :-)
lpr -P TOSHIBA-
works!
lpr -P TOSHIBA-
does not work (as expected)
lpr -P TOSHIBA-
works!
Cheers,
Tomas
cliddell (cjl) wrote : | #95 |
- printout_testpage_noncompressed_chris_nottf_20140326.ps Edit (637.8 KiB, application/postscript)
So, it is *definitely* to do with how ps2write emits Type42/TrueType fonts - that's a pain. As I said before, what ps2write does is slightly ls odd for this, but it *totally* standard Postscript.
Anyway, can you try this one, too, please? Depending on the result of this, I can make a recommendation to Till about a workaround
Tomas Gustavsson (tomasg) wrote : | #96 |
That one works as well:
lpr -P TOSHIBA-
cliddell (cjl) wrote : | #97 |
Okay, so it's clear that the Toshiba has an issue with how we handle TrueType/Type42 fonts - I know I'm repeating myself, but the Postscript is *totally* correct, many other interpreters from many source handle it happily, and both myself and another engineer with a great deal of Postscript experience have carefully reviewed it, found nothing incorrect (although, we both agree it is not how we would have written it!).
So, again, I would urge you (Tomas) to contact Toshiba and report this as a bug - their interpreter is failing to interpret valid and logically correct Postscript.
Anyway, back to our immediate concern. The issue can be worked around by adding the following to the Ghostscript command line (when called from CUPs):
-dHaveTrueTypes
What we have is the "HaveTrueTypes" setting which tells ps2write whether it should emit TrueType/Type42 fonts. Setting it to "false" means we convert the TTF outlines into bitmaps. This can happen in two ways: the bitmaps can be used to create a Type 3 Postscript font (this is preferred as it results in smaller file size, executes quicker on the target and often results in better quality output), or they are just normal image data in the PS.
The choice between the two approaches is dictated by the value of "MaxFontItem" - any glyph larger than MaxFontItem will end up as "normal" image data, rather than in a Type 3 font. Hence, I included code to set the value of MaxFontItem quite high, meaning we'll use the Type 3 font approach as often as is reasonable - but I'm wary about setting it too high, as I don't want to trigger resource problems on the target printers.
Till, this definitely should only apply to Toshiba printers (maybe just the Estudio range), and ideally, it would be good to set the resolution for Ghostscript to that of the target printer, or an integer division thereof: i.e. if the printer is 600dpi, you could reasonably set the resolution to 300dpi. It would preferable to avoid scaling by a non-integer value from both a performance and quality point of view.
Any questions, just ask...... (although, I can't promise a good answer!)
Tomas Gustavsson (tomasg) wrote : | #98 |
Reported the issue, linking here, to info.se(
Till Kamppeter (till-kamppeter) wrote : | #99 |
Chris, Tomas, thank you very much. I have applied Chris' GS command line workaround to the pdftops filter in cups-filters now, so that it will be present in version 1.0.50.
cliddell (cjl) wrote : | #100 |
Tomas,
Thanks for taking the time to report it to the manufacturer (not many users do!).
If I'm honest, I doubt you'll get much response (based on past experience), but as I said before, I think we need to start making it clear to printer makers that these broken implementations aren't acceptable.
Jason Straight (jason-jeetkunedomaster) wrote : | #101 |
Thanks to all of you for putting the effort in. I had been away for a while and came back the other day to a flurry of activity on this after nearly forgetting about it.
I doubt it'll make any difference as well, but I work for a Toshiba authorized dealer and will also report it. This problem has existed in all e-Studio generations.
For the most part, I get around it by using generic PCL drivers, but that's no good for some of the more advanced features.
Tomas Gustavsson (tomasg) wrote : | #102 |
Confirmed that it is working with our Toshiba eStudio after the cups-filter update. Awesome works from you guys. Glad to be able to help make Trusty a tiny bit better.
Status changed to 'Confirmed' because the bug affects multiple users.