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

RE: [XaraXtreme-dev] Printing on Linux

Charles,

--On 11 June 2006 22:36 +0100 Charles Moir <CharlesM@xxxxxxxx> wrote:


Interesting. So basically you're saying we can rely on doing only
Postscript printing because Ghostscript is standard and provides a means
of printing PS to any old printer?


On any modern Linux yes. On any non-modern Linux, the printing system
is so crap you might as well forget it.


If that's the case, you're in effect saying PS is the Linux printing
standard, then sure we should rely on PS printing, and forget about any
other method. Doesn't make any sense to do it any other way.


Yes


But I'd note:
A) Our PS output very out of date. E.g. we don't output any grad fills at
all. Everything is stripped in Camelot (and I'd expect to see evidence of
this e.g. Moiré patterns or at least banding, in almost all fills if you
looked closely enough). It's crude. Very slow and very out of date.


Actually that's not quite true. We do output gradfills as a postscript
procedure. It's in essence a sequence of clipped rectangles.

However:
1. Printing to postscript needs to work anyway. So if we need to fix
  things, we need to fix things.
2. Printing the whole lot as a bitmap will still work, whether the
  printer is real postscript or pseudo-postscript (i.e Ghostscript) -
  that's the current workaround for exactly the same problem on
  Xtreme. And if we were printing to (say) an Inkjet, that's all we'd
  do anyway.
3. You are talking about fill types we don't rasterize. Well, we'd
  have exactly the same problem with GTK - i.e. knowing which ones to
  rasterize. It seems a hell of a lot easier to (for instance) fix
  up the PS output to do gradfills, than completely work through all the
  hassle trying to get wxDC stuff to pixel align. If we don't like
  the way gradfills work, it would be trivial to get them to rasterize
  in any case.


B) I'm not at all sure you can assume Ghostscript is not broken. We had a
real tough time getting Ghostscript to render Xara PDF 1.5 files. I
recall that that it does not support transparency or masking correctly,
possibly more.


Doesn't support PS transparency? Well, we don't output it. All
transparency in Xtreme is sent as a bitmap.

As far as I know, Ghostscript is pretty much 3.x transparent.


I suggest try printing some Xara PDF 1.5 files that contain real vector
grad fills and vector grad transparency and see if you can get that to
either view or print correctly.


Why Xara PDF 1.5 files? (not even sure what that means).
Surely Xtreme PS files are sufficient (i.e. what LX would output
were the PS code reenabled). That's pretty much what I did. I took
fill types simple, scaled it up into one corner, then did some transparency
stuff overlapping and not overlapping text and vectors. All worked fine.

If you have some printing test .xar files, I'd be really interested.


(Of course since our PS printing IS so old fashioned (no grad fills or
transparency) this should ensure it will work reliably. It's our PDF
output that is bleeding edge (using new PDF transparency and masking)
that causes GS the problems.


Exactly. And we aren't using the PDF output. I am fully aware this
will be a crap way to make PDFs (though anything is better than nothing)
but I'm not talking about using the PDF code to print with, I'm talking
about using the PS output.

I can well believe there may be GS bugs with bleeding edge postscript,
but what we are sending is in essence 8 year old postscript, very tame,
and I believe unproblematic.

Sure I saw moire. In one fill (conical), and on screen only. It looked like
we'd have been better rasterizing it. But that's just as much a bug in
Xtreme's PS printing as LX.

As a side point, saying the PS output is problematic really doesn't
advance the argument much. We can either print as bitmap (through PS)
OR we could always fix the PS output. That would presumably be useful
for more than just LX :-)


The print as bitmap case is an option for all our print output and we
should keep this. Printing hi-resolution bitmaps is often more reliable
(because it's very simple and we just rasterise as we do for screen so
your guaranteed 100% WYSIWYG) and nearly always far faster (because of
the speed of Xara rasterising) - although bitmap printing on PS devices
is far from efficient).


Indeed. But as far as I can tell when a bitmap is printed through
libgnomeprint, it's printed to postscript anyway. We've made some effort
to do this in a sensible manner internally. I can't see going through
wx then GTK and THEN to postscript is going to make it any better.
There is another route here (the old gimpprint route) which would be
available if we are printing the whole page as bitmap, but as I said,
the PS route seems so surprisingly quick we might as well use it,
at least until it's proved to be inefficient (maybe low memory machines
or something).

Note I'm *not* suggesting we remove the "print as bitmap" option. Just
that the way "print as bitmap" will work is merely to print the whole
lot as one PS bitmap. Which is the way it works to a PS printer on
Xtreme AFAICS. Ghostscript seems to render these blindingly fast.

Re Cairo, I meant to add that once GTK etc. is using Cairo printing
primatives, and that's filtered through to wx, it may well be worth
resuscitating OSRenderRegion type printing if only to get decent PDF
output and because it might produce better PS than we do now. But that
isn't currently the situation AFAICS.

Alex