If the lualatex process ends with an error code, we display it in an error dialog. We also display any message from the shell, which will be the case if lualatex doesn’t exist.
In this case, the lualatex command probably runs without error but doesn’t produce an output file for some reason. The error would then be from the copy command. I’ll add a test for the existence of the output file.
I have created pull request #1720.
This checks for the existence of the output file. If it doesn’t exist then I use strings that are already translated to give the error message:
Empty report
Could not create C:\Users\stanw\Documents\test_gt_ancestor.pdf
Can you clarify whether you mean that choosing PDF output directly from Gramps succeeded for a Tree report after you installed lualatex in the case above?
@Nick-Hall
On Windows with MikTeX installed, including lualatex (pdflatex, etc.) generating PDF output from Gramps does not ever succeed. Generating LaTeX files succeeds, and using TeXWorks to generate PDF using lualatex works, and using lualatex directly from the command line works as well, but PDF via Gramps never works. Note that there are no errors from lualatex at all. Overfull boxes are not errors, and the exit code from lualatex on the command line is 0.
I pulled PR 1720 and the error message is an improvement but it does not fix the failure in generating PDF files directly from Gramps. Is that expected?
Yes, it worked on Linux, after some tweaking, directly from Gramps, choosing PDF output.
I got it working by starting lualatex with the TeX file generated in a previous session, in my Linux terminal. And by doing that, I could check the errors and warnings, especially those that mentioned missing styles. And I was able to install those styles by adding a selection of the packages that are mentioned on the wiki here:
https://gramps-project.org/wiki/index.php/Addon:GenealogyTree#Linux
This worked for me, because I know how to install those packages, and also feel safe experimenting with these things. And that’s an interactive process, based on trial an error, which is not for everyone.
Anyway, when I got that right, I could do the same from Gramps, and I still can, for a small tree. It still fails when I select myself and 10 generations, because in that case, lualatex stops with an arithmetic overflow, whatever that may mean. I saw it run out of memory with other settings, and in both cases, Gramps still tells me that the PDF can not be found. I’m testing this with 5.1, because I’m not ready to migrate, and will probably skip 5.2 anyway.
My personal conclusion is, that you can use the PDF output, if lualatex is installed with all the required styles, on Linux. And over here. it always failed in Windows, even when I followed the instructions to configure MikTeX in such a way that it would download all missing resources on the fly. And there, the message saying that the PDF wasn’t there came so fast, that I knew that the tool didn’t even start.
I knew that, because I know that it can take a few minutes, even on my high end PC, and on Windows, the error appeared after a few seconds.
And on this PC, the program may even run for a minute or more, before it ends with that arithmetic overflow, or runs out of memory. And in either case, you will not know what happened, because even with Nick’s latest patch, you won’t see what the program actually did.
When I run it in terminal, lualatex produces a lot of output, and as far as I can see, it does not send the error text to the proper channel, being stderr, like it should. And that behavior makes it very difficult to give proper feedback to a ‘normal’ user.
Thank you - this is the information I was looking for, i.e. there is a scenario in which it works on Linux, but on Windows it doesn’t work even after following set up instructions, installing all required style files, and being able to generate the PDF from tex using lualatex via command line.
And that’s quite weird, because there are only minimal differences between the way that Gramps starts lualatex on Linux and Windows. The parameters are the same, and there is a small difference in the way the process itself is started, and I assume that that was tested by the author, Josip, who was a pioneer in creating the Gramps AIO package.
A probable cause here is that in Linux, the environment is often simpler than in Windows, because it’s routine to install every new package in a place that’s in the path, so that you can start it from every working directory, just like gramps itself. And on Windows, things happen so fast, that I suspect that the program isn’t even started, even when it seems to be installed by the book.
This suspicion is supported by the fact that in the source code, I see no check on whether the program was actually started.
Actually the process launch is the big difference. On Windows it’s using the DETACHED_PROCESS option. Just for kicks I made Windows use the same code as the other platforms, and now direct PDF generation works from Gramps. The change for Windows was introduced as part of a fix for 10418 - New tree category reports have a bad character encoding.
The related discussion is in pull request #544.
I don’t know why Windows uses different code here. Does the Linux code work for both Windows 10 and Windows 11?
Yes, and this comment in particular.
Yes, when using the same code on Windows, PDF generation works on both Windows 11 and 10.
proc = Popen(args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
A couple of caveats:
Nice! Very nice!
I must admit that I already found it a bit weird to use a detached process on Windows, and not on Linux, but assumed that this was tested properly, while it was not. And the reason is, that if you want to communicate with a process, you want the calling process to wait for its completion, because otherwisem there is no way to read what’s coming back from the pipe. And even by its name, detaching sounds like breaking the pipe, which is something that you don’t want, unless you are not interested in what the process does. And that only makes sense if you don’t want Gramps to display the PDF, because you can only do that, if you wait.
There is another thing too, which is that if you create a tempary TeX file, a detached process can read that, but if you modify the code to read the TeX data from the pipe, you can’t detach it, because of what I wrote above, which is that detaching breaks the pipe. And that aligns with the seeing NUL for the pipe in the comments, because using NUL tells the started process that there is no pipe, and that is OK if there is a file, but only then.
Another thing is, that if you use a detached process, and a temp .tex file, you can’t let Gramps open the PDF, because Gramps does not wait for the process to complete, and hence does also not know when the file is ready.
Detached processes are a good thing if you want to make Gramps more responsive, but if you do that, you must not only supply a .tex file to read from, but also a file parameter to catch the program’s outout, so that the user can see what it did, or did not do.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.