Re: Overhaul FLTK toolkit resize/redraw functions

[Ben Abbott]

On Jul 24, 2014, at 10:51 AM, Andreas Weber <address@hidden> wrote:

> On 24.07.2014 15:12, Ben Abbott wrote:
>> 
>> On Jul 24, 2014, at 3:23 AM, Andreas Weber <address@hidden> wrote:
>> 
>>> Am 23.07.2014 20:18, schrieb Ben Abbott:
>>> 
>>>> On MacOS X, I can confirm that I'm able to print when the figure window is
>>>> minimized and I've built Octave using fltk_overhaul.diff.
>>>> 
>>>> However, line objects no longer print for me. For the example below, I've 
>>>> attached junk.pdf
>>>> 
>>>> figure (1)
>>>> clf ()
>>>> plot (rand(3))
>>>> print -dpdfwrite junk.pdf
>>>> 
>>> 
>>> Hi Ben, thanks for testing.
>>> 
>>> Do you see the lines in the plot window? Is this only when called
>>> figure(1), clf() before plot or does this also happen when calling
>>> plot(rand(3)) alone?
>>> 
>>> Please try:
>>> plot(rand(3))
>>> print -color -deps junk.eps
>>> 
>>> This bypasses "gs" and stores the ouput of gl2ps directly.
>>> 
>>> Then please try
>>> drawnow("eps", "dummy", false, "junk2.eps")
>>> 
>>> Which does basically the same as print -color -deps but doesn't do a
>>> resize of the canvas before drawnow which could be a reason for timing
>>> issues.
>>> 
>>> If it's a timing issue you could add
>>> 
>>> draw ();
>>> 
>>> in OpenGL_fltk::print just before glps_renderer rend (fp, term);
>>> 
>>> 
>>> For the MXE build we have a bug report #42534 "No lines when printing
>>> plot (fltk)" which perhaps could be related.
>>> 
>>> -- Andy
>>> 
>> 
>> The junk.eps file also has missing lines. However, junk2.eps includes the 
>> lines. Both are attached.  Adding the draw() command didn't fix the problem.
> 
> Hi Ben,
> I had a look at gl2ps-renderer.cc for the first time and was surprised
> that gl2ps itself is able to produce pdf or svg but instead print with
> fltk always uses eps as gl2ps output and let ghostscript do the
> conversion to pdf.

That was a decision I had made.  To minimize the amount of coding needed to 
support print() across the different toolkits and the various output formats, I 
chose to streamline everything to eps.  This choice was strongly influenced by 
my work with the gnuplot backend which is still in need of a major rewrite 
(very ugly coding, imo). How the gnuplot backend functions is overly complex 
and has discouraged a rewrite.  I really wanted to avoid having OpenGL suffer 
the same fate.

When the classdef stuff is ready for prime-time, I think it would be a good 
idea to rewrite the print() stuff.  imo, OOP will allow special things to be 
done without making the m-files so difficult to follow.

> Nevertheless, could you add some debugging output in
> gl2ps-renderer.cc glps_renderer::draw ?
> 
> I would output print_cmd (should be "cat > 'out.eps'" when "print
> out.eps" is called from octave) and term which should be "epsis2D" for
> your plot(rand(3))
> 
> Then I would remove GL2PS_SILENT from gl2psBeginPage so that we see
> errors and check the return value of gl2psBeginPage. Perhaps gl2ps tries
> to tell us whats the problem but nobody listens?
> 
> Btw, the draw command suggested before is needless, it's called right
> after gl2psBeginPage.

I'm loaded with tasks at home and work (one month old twins at home and a large 
production ramp at work).  So, my time is very restricted. However, I do end up 
with a few spare hours a day, and if you can provide a diff/patch/changeset I'm 
happy to apply it, build, run, and report back.

Ben