denemo-devel
[Top][All Lists]
Advanced

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

[Denemo-devel] [bug #30450] Bugs


From: anonymous
Subject: [Denemo-devel] [bug #30450] Bugs
Date: Thu, 29 Jul 2010 16:54:46 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729)

Follow-up Comment #4, bug #30450 (project denemo):

This is a long post, but my theory and recommendations are at the bottom, and
you can just skip to those and see if it makes sense.  Follows are my
observations of this bug where print preview works only every other run on
windows.

1.RUN PRINT PREVIEW WITH NO denemoprint.* files in .denemo directory:
Lilypond produces denemoprint.ps invokes Ghostscript to convert to .pdf
(which it does successfully) and deletes the .ps.  The command to display the
file in pdf viewer is executed when lilypond is done, and (using the Adobe
reader) an AcroRd32 process is created which is using the denemoprint.pdf;
however, it is unseen except when you look at process list, and no pdf is
displayed.  (If you try to delete the pdf, you're told AcroRd32 is using it.)
NET RESULTS: denemo prints:.pdf, log file, .ly
invisible AcroRd32 process using the denemoprint.pdf

2.RUN WITH THE ABOVE RESULTS (i.e., with the lurking AcroRd32 process and the
.pdf file in .denemo):
On these runs, lilypond produces a .ps but doesn't delete it, it does not
even try to invoke ghostscript, and the pdf reader finally appears visible,
showing you the .pdf you created at a previous run of Print Preview.  Net
result: denemoprint.pdf file is untouched on these runs, and is finally
displayed in the external pdf viewer; denemoprint.ps is generated and left
alone to exist (until lilypond overwrites and then deletes it next run).

3.RUN WITH RESULTS FROM 1, BUT AFTER KILLING AcroRd32:
Same results as 1 above--so the difference is the lurking AcroRd32.

Note: If I run AcroRd32 at a command line when it's in that latent/lurking
state, it shows the desired denemo print.

My guess at what's going on: 
When there's no lurking pdf viewer process, I think lilypond invokes gs,
terminates and gives denemo the impression that all is done, and denemo
invokes the pdf viewer--but that gs is still processing the ps to make the
pdf, giving the pdf viewer no chance to load it when it's launched and leading
to weird behavior (lurking process).
In the case of 2, where the pdf viewer is already running (unknown to the
user) and holds the rights to the denemoprint.pdf, lilypond sees that the
would-be output file is already being used, so it can't overwrite it and it
doesn't bother to run ghostscript.  Lilypond terminates, denemo invokes the
pdf viewer, which is already running anyway and it shows the file it's been
holding the rights to all along, denemoprint.pdf.
So basically, denemo doesn't know that gs is still running.

My guess at how to fix it:
If gs is indeed still running when denemo gets the signal from lilypond that
it's done processing, then the only thing needed to do would be to have denemo
wait until gs is done-maybe invoking it itself instead of leaving that to
lilypond.
-Dan W.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30450>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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