On 07.03.2010, at 19:51, manolo gouy wrote:
>>> Added support for landscape orientation to PostScript printers and files.
>>
>> Hi Manolo,
>>
>> thanks for adding landscape support.
>>
>> I also saw that you changed the PS level back to 2 and tried this with
>> the cups-PDF printer (and my two different laser printer configs).
>>
>> My observations (but you will probably know this already):
>>
>> - landscape layout works
>> - cups-PDF now renders the images, but ...
>> - image transparency is gone :-(
>
> What I see with PostScript level 2 :
> - RGB transparency does not work, but it's not really convincing
> in level 3 either, and does not work with MSWindows printers.
For me the "not really convincing" transparency in PS level 3 looks
like some bad form of dithering. I saw this with Roman's code in
1.1.4 as well, but don't remember if this was the same in FLTK 1.2.
I *think* that there is some better dithering algorithm in the current
Linux screen output (because it looks much better than the windows
dithering algorithm), but that's only from some expirements I made
in the past with transparency problems. Don't know for sure what
it's all about... But I seem to remember that I saw a dithering
algorithm in Roman's code somewhere.
> So this might not be a major problem. RGB images print well.
Yes.
> - Bitmap transparency works OK.
Yes, I can see that.
> - Pixmap background is not transparent. I have added a tentative trick:
> use the last color used in an fl_rectf() call as background color
> of pixmaps. This works well for example for pixmap buttons
> where the background is painted just before the pixmap. But it's
> far from perfect: if the pixmap is placed outside the button borders,
> it fails. In Roman's code there are some things around using a certain
> color for pixmap background that I have yet to clarify. May be
> there's a better solution therein. Mike wrote that there is a technical
> solution for true transparent color of pixmaps in PS level 2
> called clip masking. I don't know PostScript well enough to
> implement it, and don't understand why Roman's code requires
> level 3 to produce transparent background if level 2 would be able
> to do it. In short: help needed here.
Neither do I. Sorry, no help from me.
>> My first laser printer config (as some Apple PS printer) now renders the
>> PS files correctly (except missing transparency). It did not with
>> PostScript 3, although the alternate configuration I described before
>> (i.e., as Mike explained, via Ghostscript -> Gutenprint -> PCL) worked
>> with PS 3.
>>
>> Thus, I think we can confirm what Mike wrote: Problems with PS 3 with
>> existing printers (including cups-PDF), but (currently ?) missing
>> transparency with PS level 2. :-(
>>
>> I don't know how we can solve this. Should we make the PS level a user
>> configurable (printer related) option ?
>>
>> P.S.: to verify my observations, I changed lang_level_ to 3 again and
>> tested with PS file and direct printing (selected landscape).
>>
>> - PS file: worked, but portrait layout (contents at page bottom)
>> - cups-PDF: no images, but same layout (portrait, at page bottom)
>> - PS on Kyocera: didn't print (as before with PS 3)
>> - Gutenprint on Kyocera: worked, but same layout as above
>
> Do you mean that the layout seen in PostScript file output is not
> propagated unchanged to the printer output ?
No, it's the same if I look at the postscript file or the printed
output.
I mean that *only* changing that one statement lang_level_ = 2; to
lang_level_ = 3; changed the page layout to something that looks like
it "knows about" the changed layout, but *all* output is oriented on
the page in a way that the printed contents is on the bottom[1] of a
portrait layout page. The ps file begins:
%!PS-Adobe-3.0
%%Creator: FLTK
%%LanguageLevel: 3
%%Pages: 1
%%BeginFeature: *PageSize A4
<</PageSize[595 842]>>setpagedevice
%%EndFeature
%%EndComments
%%BeginProlog
That looks like a portrait page definition, but the output is located
at the bottom of the page, as if the postscript generation knows about
the transposed coordinates, but the coordinates in the ps file need to
be exchanged? Hmm, ... just changed the following line, and it looks
better:
<</PageSize[842 595]>>setpagedevice
The screen image shows on the left[1] side of the landscape page layout.
So something is wrong if PS 3 is used, but seems to be okay when
PS level 2 is used. This is the header from PS level 2 file:
%!PS-Adobe-3.0
%%Creator: FLTK
%%LanguageLevel: 2
%%Pages: 1
%%BeginFeature: *PageSize A4
<</PageSize[595 842]>>setpagedevice
%%EndFeature
%%EndComments
%%BeginProlog
With this, the contents is on the right[1] side of the landscape page.
There must be something else different WRT coordinate transformations.
---------------
[1] This means: if you rotate the printed (or ps/pdf file) page so
that the printed contents is in its upright position, then it is on
the {left|right|bottom} of the page.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
