Hi Marcin,
This is rather a workaround, but don't use Adobe Reader, use any other
PDF viewer instead. (IIRC, there's also a workaround that makes Adobe
Reader behave correctly, i.e. not lock the pdf file, but I can't find
it now. See here, for example:
Hello,
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:
Isn't `orgfile' equal to `org-babel-exp-reference-buffer' in
`org-latex-compile'?
No, `org-babel-exp-reference-buffer' is a temporary buffer attached to
no file. It cannot help to find original file.
Regards,
Nicolas Goaziou wrote:
Sebastien Vauban sva-n...@mygooglest.com
writes:
Isn't `orgfile' equal to `org-babel-exp-reference-buffer' in
`org-latex-compile'?
No, `org-babel-exp-reference-buffer' is a temporary buffer attached to
no file. It cannot help to find original file.
OK. From reading
Hello,
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:
FWIW, I'm using this in some export code I have:
(let* ((orgfile (buffer-file-name))
(base-name (file-name-base orgfile))
(htmlfile (concat base-name .html))
Hello,
Nicolas Goaziou wrote:
Sebastien Vauban writes:
FWIW, I'm using this in some export code I have:
(let* ((orgfile (buffer-file-name))
(base-name (file-name-base orgfile))
(htmlfile (concat base-name .html))
(pdffile (concat base-name
Hi Nicolas,
IOW, it cannot tell the difference between a successful export and an
export failure with an already existing PDFFILE.
This is not true as this code checks for the `errors' variable in all
cases. With an already existing PDFFILE, you will end up with this
message: 'Process
Hi Charles,
First, I have subsequent messages in this thread and the discussion.
Should Nick's observation, that
IOW, it cannot tell the difference between a successful export and an
export failure with an already existing PDF
also include the qualification that the existing PDF file is
Dnia 2014-03-26, o godz. 18:33:30
Charles Millar mill...@verizon.net napisał(a):
If I remember to close the first exported PDF, the revised subtree
exports OK.
I'm just curious, does the problem exist iff the pdf, that is to be
replaced, is opened?
This is rather a workaround, but don't
Hi,
May I bump up this thread?
Thanks for your help.
Regards,
Francesco
Francesco Pizzolante wrote:
Hi,
This is not a definitive patch. It's just a first step in getting a better
one.
The issue is the fact that, when exporting to PDF, in some cases, Org tells
that the export has been
Hello,
Francesco Pizzolante
fpz-djc/ipccudyqhejpep6iedvlejwur...@public.gmane.org writes:
The issue is the fact that, when exporting to PDF, in some cases, Org tells
that the export has been done successfully while the PDF file has not been
produced!
As an example, if you open the target
Hi Nicolas,
Thanks for your answer.
As an example, if you open the target PDF file with Adobe Reader and, in the
meantime, you export your Org file again to PDF, you'll see that Org will
tell
you it's OK (Process Completed) while, if you look at the *Org PDF LaTeX
Output* buffer, you'll
Francesco Pizzolante f...@missioncriticalit.com writes:
IOW, it cannot tell the difference between a successful export and an
export failure with an already existing PDFFILE.
This is not true as this code checks for the `errors' variable in all
cases. With an already existing PDFFILE, you
Nicolas Goaziou wrote:
Francesco Pizzolante f...@missioncriticalit.com writes:
IOW, it cannot tell the difference between a successful export and an
export failure with an already existing PDFFILE.
This is not true as this code checks for the `errors' variable in all
cases. With an already
Nicolas Goaziou wrote:
Hello,
Nicholas and Francesco,
Francesco Pizzolante
fpz-djc/ipccudyqhejpep6iedvlejwur...@public.gmane.org writes:
The issue is the fact that, when exporting to PDF, in some cases, Org tells
that the export has been done successfully while the PDF file has not been
14 matches
Mail list logo
