Toshiba Estudio 230 printer driver bug

Status changed to 'Confirmed' because the bug affects multiple users.

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

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.

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.

Same Problem with Toshiba e-Studio 165, even using latest ppd from http://business.toshiba.com/support/downloads.jsp?site=usa . (--> "GA119x CUPS Driver")
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.

Sorry, i have to correct myself: Problem occurs not with ubuntu 10.4, but occurs with debian testing.

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+Ubuntu-Medium
--nostringval--
/TNVORA+Ubuntu-Medium
--nostringval--
--nostringval--
14
===

Toshiba-e-Studio-2500c is also affected.

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.

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?

Toshiba-e-Studio-2330c is also affected.

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.

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://www.cups.org/software.php?VERSION=1.5.3&FILE=cups/1.5.0/cups-1.5.0-source.tar.gz then compile it.
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.

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-renderer-default=gs
lpadmin -p <printer> -o pdftops-renderer-default=pdftops

and

lpadmin -p printer -R pdftops-renderer-default

to remove the setting. To change the resolution limit run a command like

lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440

and set unlimited resolution via

lpadmin -p <printer> -o pdftops-max-image-resolution-default=0

or remove your setting with

lpadmin -p <printer> -R pdftops-max-image-resolution-default

Always replace "<printer>" by your printer's queue name (enter "lpstat -v" to find your printer's queue name).

See also

/usr/share/doc/cups-filters/README.txt.gz

See and tell us in this bug report which works best for you.

A debdiff of the changes is attached.

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.

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://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

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-renderer-default=gs
lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440
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-max-image-resolution-default=720

and try again. If it is still too slow, run

lpadmin -p <printer> -o pdftops-max-image-resolution-default=360

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-renderer-default
lpadmin -p <printer> -R pdftops-max-image-resolution-default
lpadmin -p <printer> -R psdebug

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-renderer-default=pdftops
lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440
lpadmin -p <printer> -o pdftops-max-image-resolution-default=0
==
lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440
lpadmin -p <printer> -o pdftops-max-image-resolution-default=0
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.

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).

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

From what you said, I made some additional tests.

I printed a high resolution (2000dpi more Than http://farm8.staticflickr.com/7151/6760135001_14c59a1490_o_d.jpg) with Gimp and made ​​a pdf with this image and text added, printed with evince.

lpadmin -p <printer> -o pdftops-renderer-default=pdftops
lpadmin -p <printer> -o pdftops-max-image-resolution-default=0
lpadmin -p <printer> -R psdebug

== Printing is good, latency about 2 mn,

lpadmin -p <printer> -o pdftops-max-image-resolution-default=360

== Printing are good, latency about 2 mn.

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-max-image-resolution-default=0

== Printing are good, latency about 2 mn.

lpadmin -p <printer> -o pdftops-max-image-resolution-default=360
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.

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-renderer-default=gs
lpadmin -p <printer> -o pdftops-max-image-resolution-default=0
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-max-image-resolution-default=720

or even

lpadmin -p <printer> -o pdftops-max-image-resolution-default=360

In case of errors:

lpadmin -p <printer> -o psdebug

and if this does not help

lpadmin -p <printer> -o pdftops-renderer-default=pdftops

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
       "pdftops-max-image-resolution-default" to the desired limit in dpi.
       "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 "%%PDFTOPDFNumCopies" entry of the incoming PDF file.
     - 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
       cupsRasterInterpretPPD(), this is the most reliable as often
       the choice names of the "Resolution" option are marketing names
       with higher numerical values than the actual resolution. Also
       ignore error exit values of cupsRasterInterpretPPD() as the
       function can error out after having found the resolution
       (LP: #984082).
     - pdftops: If printing resolution is determined by
       cupsRasterInterpretPPD() do not stick on 100 dpi if the
       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

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.

Same error with Ubuntu 12.10 64bit and Toshiba EStudio 2500c.

Btw.:
lpadmin -p <printer> -o pdftops-renderer-default=pdftops
helps..

dac922, Did you (or could you) try the:

lpadmin -p <printer> -o pdftops-renderer-default=gs
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

I'm seeing this error on 64bit 12.10 with an eSeries 2500c.

Tried the settings in comment #27 but they made no difference.

As per comment #26 switching to pdftops fixes the problem.

I had the same problem with a Canon eStudio 455 and comment #26 resolved it.

The problem seems to have comeback exactly as before when I changed computer from Ubuntu 12.04 to Ubuntu 12.10 !!??

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

Hello, my comment #30 was not very detailled. I had the problem on 12.04 and lpadmin -p <printer> -o pdftops-renderer-default=pdftops resolved it. The problem came back when I installed 12.10 and the same command resolved it.

If you want me to try some things out, I should be able to help.

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.

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.

Just for the record, this worked fine for me:

lpadmin -p TOSHIBA-e-STUDIO2330C -o pdftops-renderer-default=pdftops

"TOSHIBA-e-STUDIO2330C" was the name taken directly from the gnome printers GUI.

Cheers.

1 - when I try to run the commands on #35, I get the following error message
lpadmin: Unknown argument "/etc/cups/ppd/Palier.ppd".

2 - Can you tell me how to come back to the "default" configuration : what is the default value of pdftops-renderer-default (since I changed it to pdftops to make it work)

Thanks

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".

2 -
   "lpadmin -p <printer> -o pdftops-renderer-default=gs"
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.

One more confirmation that the following works:

   lpadmin -p <printer-name-here> -o pdftops-renderer-default=pdftops

for Toshiba e-Studio 2820c too.

cliddell, I have captured the information thanks to https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data

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)

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.

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/TOSHIBA_EST455_855_CUPS.ppd
as explained in #35 and #43

Maybe it is because the original file is PDF ? Or is that configuration just not doing PS ?

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.......

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/TOSHIBA_EST455_855_CUPS.ppd

After having created the queue with this command, apply the commands from #61 to it:

lpadmin -p test -R pdftops-renderer-default
lpadmin -p test -o psdebug-default=true

The print your job to tyhis queue and attach the resulting /tmp/printout.

At last, here it is and it seems to be the correct format (thank you @clj and @till-kamppeter)

lcottere@dsi-cottereau:~/temporaire$ file 20130121-toshiba
20130121-toshiba: PostScript document text conforming DSC level 3.0, Level 2

Hope it works out.

Same problem on Xerox WorkCentre M20
The workaraund worked:

lpadmin -p <printer> -o pdftops-renderer-default=pdftops

Should this bug be re-filed or re-opened so it's not forgotten about [as this bug is marked fixed]?

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.

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).

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

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-renderer-default").

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-renderer-default=pdftops" and it worked. But I don't know how to come back to the previous state. So the previous attached file is probably a working one...

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.

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.)

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.

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-STUDIO3510cSeries" (standard included in Ubuntu and used to work before).

"Print test page" reports:

Page 1:
blank

Page 2:
ERROR:
invalidfont
OFFENDING COMMAND:
$definefont
STACK:
--nostringval--
/VUEKTG+Ubuntu-Medium
--nostringval--
/VUEKTG+Ubuntu-Medium
--nostringval--
--nostringval--
14

Page 3:
PS error: invalidaccess

Running the command:
lpadmin -p TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -o pdftops-renderer-default=pdftops
(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-TEC-TOSHIBA-e-STUDIO-Series -R pdftops-renderer-default

Causes error again.

I will make a PS collection using instructions on page:
https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer

(lpstat -v it should say above)

Sorry that was a bad attachment, it was a self test, not a print test page. Find another one attached. printout_testpage_tomas_20140324.

Okay. so the next thing I'll ask you to do is to try step 10 from this section:
http://tinyurl.com/p5cb4kf

And see if that works better, and if not, attach the non-compressed file.

Thanks!

Didn't work. Attaching uncompressed file.

Commands used:

lpr -P test -o psdebug printout_testpage_tomas_20140324
lpr -P TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -oraw /tmp/printout

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.....).

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!

lpr -P TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -oraw printout_testpage_really_noncompressed_chris_20140324

produces the same error result.

A sidenote: Adding the printer as a "generic" PCL6 printer also produces proper test printouts.

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-TEC-TOSHIBA-e-STUDIO-Series -o pdftops-renderer-default=gs
lpadmin -p test -o pdftops-renderer-default=gs

root@donake:~# lpadmin -p TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -o pdftops-renderer-default=gs
root@donake:~# lpadmin -p test -o pdftops-renderer-default=gs

(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/tmp/printer/printout_compressed
root@donake:~# lpr -P test -o psdebug /home/user/tmp/printer/printout_compressed
root@donake:~# ll /tmp/printout
-rw------- 1 root root 346007 mar 24 16:04 /tmp/printout
root@donake:~# mv /tmp/printout /home/user/tmp/printer/printout_uncompressed

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.

Correct, the same error happens.

lpr -P TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -o raw printout_testpage_really_noncompressed_chris_20140324_2

Identical error papers printed.

Hrm, that's not a surprise, but it is a pain. I need to give this some thought.....

Tomas,

Can you give this one a try, and tell us how it behaves, please?

Thanks

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-TEC-TOSHIBA-e-STUDIO-Series -o raw printout_testpage_noncompressed_chris_nottf_20140325.ps
works!

lpr -P TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -o raw printout_testpage_really_noncompressed_chris_20140324_2
does not work (as expected)

lpr -P TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -o raw printout_testpage_noncompressed_chris_nottf_20140325.ps
works!

Cheers,
Tomas

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

That one works as well:

lpr -P TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -o raw printout_testpage_noncompressed_chris_nottf_20140326.ps

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=false -c "<< /MaxFontItem 500000 >> setuserparams " -f <input file>

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!)

Reported the issue, linking here, to info.se(at)toshibatec-tnd.com in Sweden.

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.

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.

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.

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.