bugGNU Octave - Bugs: bug #44463, Print command for...

 
 

bug #44463: Print command for "pdflatexstandalone" device produces output that doesn't compile

Submitted by:  Dan Sebald <sebald>
Submitted on:  Sat 07 Mar 2015 08:06:36 AM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 24 Aug 2016 05:39:42 PM UTC, comment #20: 

I've compiled the latest code and no longer see the x-tic text shifted above the x-axis.

Dan Sebald <sebald>
Wed 24 Aug 2016 10:59:23 AM UTC, comment #19: 

@Andy: thanks.

@Dan: I can't reproduce the misalignment issue. Can you post another bug report about that?

Can we close this report?

Pantxo Diribarne <pantxo>
Project Member
Wed 17 Aug 2016 08:07:53 AM UTC, comment #18: 

I forget exactly what the issue was here, but the example code drawing a line below works for me in Qt toolkit.  However, the placement of text doesn't match the graphics portion.  See the attached PDF file in which the tic annotation is all shifted about one character height too high.  Whether that is an Octave issue or pdflatex issue, I'm not sure.

(file #38239)

Dan Sebald <sebald>
Wed 17 Aug 2016 06:10:53 AM UTC, comment #17: 

@Pantxo: I've pushed your proposed patch here http://hg.savannah.gnu.org/hgweb/octave/rev/fc127f0e1ccd
(I'll remove the comment blocks after some weeks of testing)

which fixes bug #48519 and also fixed the script in comment #1 for me.

@Dan: Can you confirm this issue is fixed on the default branch?

Andreas Weber <andy1978>
Project Member
Mon 01 Aug 2016 08:15:48 AM UTC, comment #16: 

@Andy: sorry, indeed it looks like I forgot to attach the patch. As I am in vacations I won't be able to send it until late august. Anyway it was a very simple mod.:
in ObjectProxy.cc (ObjectProxy::init): change

>>connect (this, SIGNAL (sendPrint (const QString&, const QString&)),m_object, SLOT (slotPrint (const QString&, const QString&)));

to

>>connect (this, SIGNAL (sendPrint (const QString&, const QString&)),m_object, SLOT (slotPrint (const QString&, const QString&)), Qt::BlockingQueuedConnection);

and remove the unnecessary Fsleep at the end of Fdrawnow in graphics.cc

Pantxo Diribarne <pantxo>
Project Member
Fri 29 Jul 2016 01:08:52 PM UTC, comment #15: 

@Pantxo: I can't see an attached patch, is it missing?

Andreas Weber <andy1978>
Project Member
Sun 17 Jul 2016 01:25:20 PM UTC, comment #14: 

I found that QObject::connect lets you adapt the way the execution of signal/slots is handled.  
I attached a patch that forces blocking execution of the slots (in the gui threads) so that print_figure (in the interpreter thread) only returns when the file is actually ready.

I used the example in comment #1 for testing.

Any feedback?

Pantxo Diribarne <pantxo>
Project Member
Wed 22 Jun 2016 02:56:17 PM UTC, comment #13: 

Now it looks we are using more and more c++11 features, I'd like to experiment with std::condition_variable [1]. In addition to std::mutex, this may prove useful for synchronizing threads.

@jwe: I need to create two shared variables (a mutex and a condition_variable), which can be accessed in Backend.cc (interpreter thread) and Canvas.cc (gui thread). Where should I define such global variables?

Pantxo Diribarne <pantxo>
Project Member
Tue 24 Nov 2015 01:11:07 PM UTC, comment #12: 

Here is the structure of events ("->" means "calls methods of object") in the interpreter thread*:
graphics_object->Backend(Implements base_graphics_toolkit for Qt)->ObjectProxy

The latter then emits signals which are caught by corresponding Objects (Figure, Toolbar, Menu, Panel ...) and lead to the execution of the corresponding slot in the GUI thread. So ObjectProxy (last object in the interpreter thread) returns well before the operation is completed.

The very nature of this structure of events makes sequential operation impossible: we have no way to know if a slot execution has been completed before going forward. The current approach of using mutex doesn't help much: mutex are meant to make the execution of two functions (or part of) mutually exclusive, but can't provide actual synchronization hence the ugly sleep I added in drawnow.

See the following very simple example:

## see bug for other such examples #46501
hf = figure ();
delete (hf)

Here we delete a figure graphics_object (that does exist because graphics_objects are created in the interpreter thread) but we are not sure the actual GUI figure window construction (in the GUI thread) is completed and thus deleting the graphics_object is unsafe.

So my first statement is "we need to be able to force sequential operations".
Now the question is do we always want sequential operations: my answer ATM is yes, there is no benefit in having figures updated independently/asynchronously from the interpreter state. I can't see any example of any operation that does not require synchronous interaction between GUI and interpreter when it comes to plotting.

A possible approach could be to abandon the signal/slot mechanism in ObjectProxy and use return values to ensure sequential operation. Of course there may be more subtle solutions but I am no GUI expert.

Pantxo Diribarne <pantxo>
Project Member
Tue 24 Nov 2015 09:17:26 AM UTC, comment #11: 

The reason for using Fsleep is that it is comparable to the way we would do it in the interpreter. I though it was the preferred solution.

Now about looking for a real fix. I can summarize what I understand so far (I'll do this here in the coming days), to explain the race conditions we are currently facing with Qt toolkit, but as my first child is about to born I won't be able to implement the changes my self.

Pantxo Diribarne <pantxo>
Project Member
Tue 24 Nov 2015 02:04:32 AM UTC, comment #10: 

Pantxo, is there any reason that you used Fsleep instead of just calling the internal octave_sleep function directly?

And yes, we should continue to look for a real solution instead of sleeping here.

John W. Eaton <jwe>
Project Administrator
Thu 12 Nov 2015 09:09:19 PM UTC, comment #9: 

I pushed a cset that makes this bug less probable:

http://hg.savannah.gnu.org/hgweb/octave/rev/a7903de9c359

As it is not a real fix but rather "cache misère", I'll leave the report open until a proper solution is found.

Pantxo Diribarne <pantxo>
Project Member
Tue 28 Jul 2015 03:36:09 AM UTC, comment #8: 

I fix the problem add this modification at end of _opengl_print_.m file

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
while_no_exist(opts.name,10);

  if (! isempty (strfind (opts.devopt, "standalone")))
    opts.latex_standalone (opts);
  endif

endfunction

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% white time in seconds or existence of filename
function h=while_no_exist(FILENAME,TIME)
timeinit=100*cputime;
timecurrent=100*cputime;
do
pause(1);
timecurrent=100*cputime;
fd=fopen(FILENAME,'r+');
if(fd>=0)
tmp=fscanf(fd,'%c',inf);
estatus=fclose(fd);
if((length(tmp)>12)&&(estatus==0))
LECTURAOK=1;
else
LECTURAOK=0;
end
else
LECTURAOK=0;
end
until ( ( (timecurrent-timeinit)>TIME )||(LECTURAOK==1) )
end

Fernando Pujaico Rivera <trucomanx>
Sat 04 Apr 2015 09:40:18 AM UTC, comment #7: 

I could check that gl2ps is run in the gui thread: actually it is called by Canvas::print which is run in the gui thread, hence the race condition (the interpreter tries to read a file that still doesn't exist).

I have spent time on this bug but still can't understand why drawnow returns before the print_figure has actually completed and unlocked the gh_manager mutex.

FTR, I have tried a nasty trick: created a new method
int base_graphics_toolkit::safe_print (same, args, as, print_figure). The only difference with print_figure is the return argument: Fdrawnow has to wait for the return value before completing. This works (at least this bug disappears ) but doesn't explain why the mutex method does not work.

FTR  I used the value of "pthread_self()" cast as a uint16 to track the running threads.

Pantxo Diribarne <pantxo>
Project Member
Mon 09 Mar 2015 05:35:50 AM UTC, comment #6: 

I think this bug sounds similar:

https://savannah.gnu.org/bugs/?44470
ctrl-c after pause gives crash/segfault

and possibly this one:

https://savannah.gnu.org/bugs/?44459
Plotting with Qt or FLTK crashes Octave once in a while

But if you have something that seems very repeatable and can provide the commands, then maybe another bug report would be good.  Or retitled this one somehow.

Dan Sebald <sebald>
Sun 08 Mar 2015 10:57:21 PM UTC, comment #5: 

"The issues with pause(), Cntrl-C are noted in several other bug reports, so let's close this one"

Do you think the issue here is a duplicate of another bug? Can you post links to those bugs?

About bug #44187, I am know nothing about gnuplot but I will try to take a look at tex related outputs.

Pantxo Diribarne <pantxo>
Project Member
Sun 08 Mar 2015 07:42:21 PM UTC, comment #4: 

All right, I have tested and verified pdflatex and pdflatexstandalone.  I didn't know that "pdflatex" also handles PDF input as well as producing PDF output.

I know LaTeX and a few variations very well, but I don't know some of the latest things like lua, tikz, and so on.  I seems like you are pretty fluent in these and might also know a bit about gnuplot.  Could you please take a look at the new changeset posted here: https://savannah.gnu.org/bugs/?44187

There is a demo for print() as part of that changeset which will make the process of testing printed output much easier.  I can see several issues for all three graphics toolkits, but it is difficult to fix everything at once.  Also, if there are any gnuplot devices/terminals near the bottom of the listbox contents that you recognize and shouldn't be overlooked, let me know.

The issues with pause(), Cntrl-C are noted in several other bug reports, so let's close this one.

Dan Sebald <sebald>
Sat 07 Mar 2015 09:06:16 PM UTC, comment #3: 

There are definitely some timing issues.  I've had to place "pause(0)" in various places of a demo because the figure wouldn't draw before doing a "print".  I intend to look at that closer after finishing the gnuplot printing update.

Dan Sebald <sebald>
Sat 07 Mar 2015 12:34:22 PM UTC, comment #2: 

It looks like a timing issue between Qt and the interpreter. The "drawnow" command returns before the job (writing the base .pdf and .tex file) has been done by gl2ps. Then Octave fails to modify the .tex file to include the figure in a "minimal" document.

If I add a "pause (5)" just after the drawnow command at the end of _openg_gl_print_.m, the example in comment #1 works also with Qt toolkit.

Pantxo Diribarne <pantxo>
Project Member
Sat 07 Mar 2015 12:03:20 PM UTC, comment #1: 

For me, the following works perfectly with FLTK while it fails with Qt graphics toolkit:

close all
graphics_toolkit fltk
plot (1:10)
print -dpdflatexstandalone foo
system ("pdflatex foo.tex")

The output .tex file has no header when generated from a Qt figure. Looks like the last part of the job (including the image in a "minimal" document) is skipped. Can someone confirm?

With FLTK, the only issue I see is print.m documentation: we should explain that "pdflatexstandalone" has to be compiled using "pdflatex" or any pdf capable latex engine (e.g. lualatex).

Pantxo Diribarne <pantxo>
Project Member
Sat 07 Mar 2015 08:06:36 AM UTC, original submission:  

In the print command are these devices:

         `pslatexstandalone'
         `epslatexstandalone'
         `pdflatexstandalone'
                                                  ...In either case,
               the LaTeX file contains an `\includegraphics' command so
               that the generated graphics file is automatically
               included when the LaTeX file is processed...
                                 ...The `pdflatex' device, and any of the
               `standalone' formats, are not available with the Gnuplot
               toolkit.

gnuplot does have epslatexstandalone.  I will correct that with a changeset from another bug fix at some point.  Aside from that, part of the reason gnuplot doesn't have those is that, if I recall correctly, there really needs to be a bounding box in the postscript file in order for LaTeX to properly include the figure.  I've looked at the outputs for FLTK/OpenGL toolkit and both the EPS and PS file have bounding boxes, so technically the PS file is an encapsulated postscript file.  Although the files are quite different because they are scaled slightly differently, in some sense it is really the extension that differs...fine.

On the other hand, contrary to what the documentation suggests, including a PDF file in a LaTeX document isn't possible, unless there is some kind package to accomplish that, but I doubt that.  I've built a printing demo that sends the results to a temporary file and processes.  This example shows that, first, LaTeX can't find the file because it is by default looking for one with extension .ps or .eps:

! LaTeX Error: File `/tmp/oct-wBFKA0-inc' not found.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
...

l.12 \includegraphics{/tmp/oct-wBFKA0-inc}

So I copied those temp files over to my account and modified the imported file to include the full file name with extension.  The error then becomes:

! LaTeX Error: Cannot determine size of graphic in test-pdf.pdf (no BoundingBox
).

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
...

l.12 \includegraphics{test-pdf.pdf}

The reason is a PDF file hasn't a bounding box.  (At least not in readable ASCII.)  Really the only thing LaTeX does is look through the EPS file for the "Bounding Box" size definition so that it knows how much space to leave for the graphic and instruct DVI where to find the missing contents.  The DVI processing then embeds the PostScript file in place.

To me, I've always thought of "pdflatex" as being a different flavor of LaTeX.  I think it has a few extra commands and such and is geared for creating PDF files directly from processing.  That way pdflatex can create links within the created file (i.e., PDF viewer can click on links and jump to other parts of the file, e.g., table of contents).  Type "pdflatex" at the command prompt of your shell window and notice it is a "separate" program (both pdflatex and latex may use the same engine on some systems).  I suppose I'd welcome an actual pdflatex and associated standalone devices, but not at the moment.

So, the question is what to do with this.  pdflatexstandalone produces a result that doesn't compile for reasons that are the fault of Octave code, so that's at least a bug.

Dan Sebald <sebald>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #38239:  foo.pdf added by sebald (12KiB - application/pda)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by trucomanx (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-27 pantxo StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2016-08-17 sebald Attached File- => Added foo.pdf, #38239
    2016-08-17 andy1978 StatusNone => Ready For Test
    2015-03-07 pantxo SummaryPrint command for pdfstandalone device produces output that doesn\'t compile => Print command for "pdflatexstandalone" device produces output that doesn't compile

    Back to the top


    Powered by Savane 3.5