Re: unified FLTK & Gnuplot printing

[Shai Ayal]

On Mon, Aug 30, 2010 at 5:10 PM, bpabbott <address@hidden> wrote:
> On 30 Aug, 2010,at 09:43 AM, Shai Ayal <address@hidden> wrote:
>
> 2010/8/30 Ben Abbott <address@hidden>:
>> On Aug 30, 2010, at 1:16 AM, Jordi Gutiérrez Hermoso wrote:
>>
>>> On 23 August 2010 20:13, Ben Abbott <address@hidden> wrote:
>>>> I've prepared a changeset to unify the printing for both the FLTK
>>>> and Gnuplot backends.
>>>>
>>>> For both backends, ghostscript is relied upon more heavily than
>>>> before.
>>>
>>> I've been meaning to comment on this.
>>>
>>> It's nice that you've found a unified method for all formats. I still
>>> think, however, that we could profitably use a bitmap method for
>>> bitmap output formats. Vector graphics aren't good for getting a
>>> picture of a colourful surface with shading at an interesting angle.
>>> It would also be nice to generate an exact screenshot of what's shown
>>> on the screen in a bitmap format, which at least Søren has wished for.
>>>
>>> I have no idea how much work this will be, but I want to get started
>>> on it, as an option or alternative to gl2ps at least for some output
>>> formats. Maybe not for the 3.4 release, but soonish.
>>>
>>> - Jordi G. H.
>>
>> I've occasionally noticed the on screen rendering looks better than the
>> printed version. However, I don't have a deep enough understanding the
>> technical details to conclude why.
>>
>> The two cases for the FLTK backend
>>
>> (1) OpenGL -> bitmap (on screen may have anti-aliasing, or may not).
>>
>> (2) OpenGL -> Postscript -> bitmap (usign gs with anti-aliasing)
>>
>> I assumed any visible difference would depend upon which anti-aliasing
>> method is superior (assuming each image is the same size and resolution).
>>
> Also, way (1) is limited to screen resolution (i.e. if you have a
> 400x300 pixel figure window, you'll have a 400x300 image, while way
> (2) can be any resolution you like (using the -r flag to gs and print)
>
> Shai
>
>
> Shai, I assume that the on screen requirement for the glReadPixels, is *not*
> the same as what is required for "drawnow ('eps', 'file.eps')"?
> To get the correct result I temporarily change the size of the figure window
> so that its dimensions in pixels is equal to what is desired in points.
> Would this work for glReadPixels as well?
> Ben
>
I'm not sure, but since glReadPixels reads the actual pixels, I would
guess that after resizing, you would first need to be able to see the
resulting figure, and only then read the pixels

Shai