🚀 go-pugleaf

The Natural Philosopher wrote:
> Been trying to iron out some niggles..
> 
> Some stuff prints well, other stuff has oddities.

You're asking the wrong question, or the wrong way.

Firstly, what's the printer (make and model) you're using?

Secondly, which printer driver are you using within CUPS, and how is it
configured?  (For example, a number of printers offer both PostScript
and their own language, such as HP-PCL.)

Thirdly, how are you viewing the PDF on screen?  Are you using Acrobat,
or GhostView (gv), or xpdf, or something else?


Basically, without knowing which RIP is being used for each of screen
and printer, it's not easy to diagnose.

That said:

If your printer is being treated as a PostScript printer, but has an
alternative language, try that.  Alternatively, if your printer offers
PostScript, but you're using the alternative, switch.  You may need to
tweak the driver config a bit to get the same results, but it's worth
the effort.

Jon
-- 
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
  with 'green-lines'.

Jon Green wrote:
> The Natural Philosopher wrote:
>> Been trying to iron out some niggles..
>>
>> Some stuff prints well, other stuff has oddities.
> 
> You're asking the wrong question, or the wrong way.
> 
> Firstly, what's the printer (make and model) you're using?
> 

Two. Both postcript native. Ricoh 3800 and HP laserjet 5.

> Secondly, which printer driver are you using within CUPS, and how is it
> configured?  (For example, a number of printers offer both PostScript
> and their own language, such as HP-PCL.)
> 
Not sure on this one. Foomatic comes into the RICOH for sure.


> Thirdly, how are you viewing the PDF on screen?  Are you using Acrobat,
> or GhostView (gv), or xpdf, or something else?
> 
> 
Acrobat and other screen based programs see the PDF's as intended. ONLY 
cups screws up.

It also screws up with almost any bitmap where transparency is applied.

> Basically, without knowing which RIP is being used for each of screen
> and printer, it's not easy to diagnose.
> 
> That said:
> 
> If your printer is being treated as a PostScript printer, but has an
> alternative language, try that.  Alternatively, if your printer offers
> PostScript, but you're using the alternative, switch.  You may need to
> tweak the driver config a bit to get the same results, but it's worth
> the effort.
> 

Its not the printer end of things..its something to do with the 
transparency elements of bitmaps being disregarded.

I.e. we can print the pictures fine using acrobat direct to the printer, 
or Corel Draw, or indeed any other way that bypasses CUPS and uses a 
normal print program talking direct to the printer.

There is a bug report out on ghostscript that seems to suggest it is the 
culprit.

But I need to pin it down a bit.

If it helps, I can publish a little PDF file on the net somewhere that 
illustrates the problem.


> Jon

On Fri, 23 Jan 2009 10:12:39 +0000, The Natural Philosopher wrote:


> But what is HPJIS, and foomatic, and where does ghostscript come in?

AFAIK, these are old style stuff for lpr, lprng, etc. If you have cups,
then you shouldn't need to install these.

Ghostscript does the ripping, aka converts the print commands
into code that the printer understands. AFAIK, foomatic provides
pre and post processing of the input/output


> 
> I suspect my problems are with ghostscript actually,

Unless it is something bleeding edge, highly nlikely. Ghostscript has been
around for decades and has never given me trouble with watermarks, etc

> So I upgraded from
> the latest stable debian to the bleeding edge testing sources, but it
> still has an issue (transparent background images in PDFs do not have
> the transparency respected)..that is something that looks like a couple
> of days worth at the source code level would fix..but where to first be
> sure that is the issue, and secondly identify where images are handled
> in Ghostscript. Its HUGE.
> 
> Anyone care to point me in the right direction?

Have you checked that the postscript code being fed into the front end
actually has the correct Postscript in it. More likely, the application
printing the pdf isn't creating the postscript properly.

although pdfs are supposed to be postscript internally. Differing versions
of postscript?

terryc wrote:
> On Fri, 23 Jan 2009 10:12:39 +0000, The Natural Philosopher wrote:
> 
> 
>> But what is HPJIS, and foomatic, and where does ghostscript come in?
> 
> AFAIK, these are old style stuff for lpr, lprng, etc. If you have cups,
> then you shouldn't need to install these.
> 
> Ghostscript does the ripping, aka converts the print commands
> into code that the printer understands. AFAIK, foomatic provides
> pre and post processing of the input/output
> 

whatevr that means..
> 
>> I suspect my problems are with ghostscript actually,
> 
> Unless it is something bleeding edge, highly nlikely. Ghostscript has been
> around for decades and has never given me trouble with watermarks, etc
> 

well it has to be whatever takes PDFs and turns them into postcript.


>> So I upgraded from
>> the latest stable debian to the bleeding edge testing sources, but it
>> still has an issue (transparent background images in PDFs do not have
>> the transparency respected)..that is something that looks like a couple
>> of days worth at the source code level would fix..but where to first be
>> sure that is the issue, and secondly identify where images are handled
>> in Ghostscript. Its HUGE.
>>
>> Anyone care to point me in the right direction?
> 
> Have you checked that the postscript code being fed into the front end
> actually has the correct Postscript in it. More likely, the application
> printing the pdf isn't creating the postscript properly.
> 

well yes, I have. In that every other PDF renderer actually sees the 
correct output, but cups cant print it.

That goes for both my home brew PDFS generated from code, and exports 
from CorelDraw.


> although pdfs are supposed to be postscript internally. Differing versions
> of postscript?

No. I am almost certain its ghostscript

The correct way to apply a transparency is to flatten the non 
transparent parts down to their pixel values, and then to flatten the 
transparent parts  to whatever is 'behind' them. This is non trivial, 
and my guess is that ghostscript simply doesn't bother, but assumes that 
the background is white, or somesuch.

(Sorry for the long quote, it's all for context, I'm not being lazy!)

The Natural Philosopher wrote:
> Jon Green wrote:
>> The Natural Philosopher wrote:
>>> Been trying to iron out some niggles..
>>>
>>> Some stuff prints well, other stuff has oddities.
>> You're asking the wrong question, or the wrong way.
>>
>> Firstly, what's the printer (make and model) you're using?
>>
> 
> Two. Both postcript native. Ricoh 3800 and HP laserjet 5.
> 
>> Secondly, which printer driver are you using within CUPS, and how is it
>> configured?  (For example, a number of printers offer both PostScript
>> and their own language, such as HP-PCL.)
>>
> Not sure on this one. Foomatic comes into the RICOH for sure.
> 
> 
>> Thirdly, how are you viewing the PDF on screen?  Are you using Acrobat,
>> or GhostView (gv), or xpdf, or something else?
>>
>>
> Acrobat and other screen based programs see the PDF's as intended. ONLY 
> cups screws up.
> 
> It also screws up with almost any bitmap where transparency is applied.
> 
>> Basically, without knowing which RIP is being used for each of screen
>> and printer, it's not easy to diagnose.
>>
>> That said:
>>
>> If your printer is being treated as a PostScript printer, but has an
>> alternative language, try that.  Alternatively, if your printer offers
>> PostScript, but you're using the alternative, switch.  You may need to
>> tweak the driver config a bit to get the same results, but it's worth
>> the effort.
>>
> 
> Its not the printer end of things..its something to do with the 
> transparency elements of bitmaps being disregarded.

It might still be the printer.  If you're using gv or xpdf to view the
pages, and they look fine, but the printer's not getting it right, it
could well be that CUPS is delegating the PS rendering to the printer,
rather than pre-rendering it.  The fact that Acrobat printing directly
gets it right definitely adds more weight to this theory.

So, what you see on screen is GhostScript's (or Adobe's) rendering, but
what you get from the printer (via CUPS) is the printer's own.

Try using HP-PCL for the LaserJet instead of PostScript, and see if it
changes things.  If it does, stick with it, or find a way to get CUPS to
 pre-render the page so that PS delegation doesn't happen.  If that
works, repeat with the Ricoh.


Jon
-- 
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
  with 'green-lines'.

Jon Green wrote:
> (Sorry for the long quote, it's all for context, I'm not being lazy!)
> 
> The Natural Philosopher wrote:
>> Jon Green wrote:
>>> The Natural Philosopher wrote:
>>>> Been trying to iron out some niggles..
>>>>
>>>> Some stuff prints well, other stuff has oddities.
>>> You're asking the wrong question, or the wrong way.
>>>
>>> Firstly, what's the printer (make and model) you're using?
>>>
>> Two. Both postcript native. Ricoh 3800 and HP laserjet 5.
>>
>>> Secondly, which printer driver are you using within CUPS, and how is it
>>> configured?  (For example, a number of printers offer both PostScript
>>> and their own language, such as HP-PCL.)
>>>
>> Not sure on this one. Foomatic comes into the RICOH for sure.
>>
>>
>>> Thirdly, how are you viewing the PDF on screen?  Are you using Acrobat,
>>> or GhostView (gv), or xpdf, or something else?
>>>
>>>
>> Acrobat and other screen based programs see the PDF's as intended. ONLY 
>> cups screws up.
>>
>> It also screws up with almost any bitmap where transparency is applied.
>>
>>> Basically, without knowing which RIP is being used for each of screen
>>> and printer, it's not easy to diagnose.
>>>
>>> That said:
>>>
>>> If your printer is being treated as a PostScript printer, but has an
>>> alternative language, try that.  Alternatively, if your printer offers
>>> PostScript, but you're using the alternative, switch.  You may need to
>>> tweak the driver config a bit to get the same results, but it's worth
>>> the effort.
>>>
>> Its not the printer end of things..its something to do with the 
>> transparency elements of bitmaps being disregarded.
> 
> It might still be the printer.  If you're using gv or xpdf to view the
> pages, and they look fine, but the printer's not getting it right, it
> could well be that CUPS is delegating the PS rendering to the printer,
> rather than pre-rendering it.  The fact that Acrobat printing directly
> gets it right definitely adds more weight to this theory.
> 
> So, what you see on screen is GhostScript's (or Adobe's) rendering, but
> what you get from the printer (via CUPS) is the printer's own.
> 
> Try using HP-PCL for the LaserJet instead of PostScript, and see if it
> changes things.  If it does, stick with it, or find a way to get CUPS to
>  pre-render the page so that PS delegation doesn't happen.  If that
> works, repeat with the Ricoh.

I suspect that the problem is well known

http://www.cups.org/str.php?L280+P0+S0+C0+I0+E0+M20+Qtransparent


In short, they don't expect anyone to print PDFS using ghostcript but 
use Xpdf instead.

Sadly CUPS uses gs to do the conversion from pdf to postcript. If you 
feed it a PDF rather than a ps type file.

I know that, cos I screwed up gs when attempting to install the latest, 
and the printer stopped working!

Remember, these machines have no X on them.


> 
> 
> Jon

The Natural Philosopher wrote:
> I suspect that the problem is well known
> 
> http://www.cups.org/str.php?L280+P0+S0+C0+I0+E0+M20+Qtransparent

Bear in mind that that report is more than five years old.  It might be
worth your while to find something a little more ... contemporary.

> Sadly CUPS uses gs to do the conversion from pdf to postcript. If you 
> feed it a PDF rather than a ps type file.

Yeah, but PDF _is_ PostScript, with a bit of wrapping around it.  PDF to
PS conversion is little more than unpackaging, with a nod to security.
It's not a rendering stage.

If it's still feeding the unpackaged PS to the printer, for the printer
to do the rendering, the problem is *still* with the printer!

Jon
-- 
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
  with 'green-lines'.

Jon Green wrote:
> The Natural Philosopher wrote:
>> I suspect that the problem is well known
>>
>> http://www.cups.org/str.php?L280+P0+S0+C0+I0+E0+M20+Qtransparent
> 
> Bear in mind that that report is more than five years old.  It might be
> worth your while to find something a little more ... contemporary.
> 
>> Sadly CUPS uses gs to do the conversion from pdf to postcript. If you 
>> feed it a PDF rather than a ps type file.
> 
> Yeah, but PDF _is_ PostScript, with a bit of wrapping around it.  PDF to
> PS conversion is little more than unpackaging, with a nod to security.
> It's not a rendering stage.
> 
Well there you are wrong

> If it's still feeding the unpackaged PS to the printer, for the printer
> to do the rendering, the problem is *still* with the printer!
> 

And there as well.

I was able to also reproduce it with pdftops.No printer involved at all,



> Jon

In article <1232722601.22282.0@proxy00.news.clara.net>, The Natural Philosopher wrote:
>> 
>> Have you checked that the postscript code being fed into the front end
>> actually has the correct Postscript in it. More likely, the application
>> printing the pdf isn't creating the postscript properly.
>
>well yes, I have. In that every other PDF renderer actually sees the 
>correct output, but cups cant print it.

Do you mean PS renderer, or have you not actually checked the Postscript,
only the PDF?

Alan Braggins wrote:
> In article <1232722601.22282.0@proxy00.news.clara.net>, The Natural Philosopher wrote:
>>> Have you checked that the postscript code being fed into the front end
>>> actually has the correct Postscript in it. More likely, the application
>>> printing the pdf isn't creating the postscript properly.
>> well yes, I have. In that every other PDF renderer actually sees the 
>> correct output, but cups cant print it.
> 
> Do you mean PS renderer, or have you not actually checked the Postscript,
> only the PDF?

Ok, what I did yesterday was parse the PDF to a PS using pfdtops, which 
uses the same core as the CUPS system.

The problem was in the PS file, so it happens in the conversion to 
postscript.

 From what I can glean reading through the debian bugs, this is a known 
problem, and there are various forks off GS, one of which solves this 
problem and may yet get into the main stream of CUPS.


I think someone else pointed out that postcript does NOT contain the 
concept of transparency: therefore a PDF containing a transparent image 
has to be rendered to a bitmap and a mask applied to the background to 
enable the transparent part of the image to be rendered correctly.

So its easy to see why this bit might have come late in the core libraries.