octave-maintainers
[Top][All Lists]
Advanced

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

Re: unified FLTK & Gnuplot printing


From: bpabbott
Subject: Re: unified FLTK & Gnuplot printing
Date: Mon, 30 Aug 2010 14:10:44 +0000 (GMT)

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]