Hi,
i´m on Gramps 5.2.2 an Win64.
My problems are on create reports.
If i take Report/Graphical Reports/Family Tree but unfortunately I got the following error message that didn’t get me any further. It is:
Gramps Error 2 No such file or directory
Whats going wrong?
Stefan
The double backslashes between folder levels appear to be the problem.
Try changing them (in the Document Options in the bottom section of the Report option tabs) to single backslashes. Check that this is a valid filepath with folder browse — the button to the right of the Filename: path.
Hi,
the backslashes in the Document Options are correct. Only one between the words
After clicking ok, the report dosn´t create and the end is ist the error message.
Does this error show for all reports?
The report you are attempting to run is the Trees >> Ancestor Tree
You actually need to set the output to LaTeX File which writes the code to create the PDF file. To do this you also need to install MiKTex to get it to work.
I just attempted to run it with generations set to 8. It failed to create the PDF saying there were bad boxes. Lowered the number to 4 and it worked fine. Note: I have my paper option set to Custom Landscape with the size set to width 72 inches, height 48 inches. Did not try a larger size for 8 generations. I also have the Tree Option to display Timeline as Up. Did not alter any of the other options such as node size.
When the TeXworks file is created you will be presented with a code file. Select the Green arrow in upper left corner to actually create the PDF file.
Yes, the error are at all Trees…
THX Dave,
my mistake are does i didn´t install MikTex.
It works now an i have a little play with it…
Does this mean that you can let Gramps start MiKTeX as designed? Or are starting the conversion by yourself, as instructed by Dave?
I’m asking, because when I install MiKTeX as described, meaning as admin, and with the option to download all needed things automatically set to Yes, I can see PDF as an output option, but I still get the same error as you reported.
The PDF option dosn´t work. I use the LaTeX file format and set the checkbox “open with standart program”.
If i click ok MiKTeX start and i push the green arrow to run. After a while an other window open the ready tree.
But by to mutch generations or a to big papersize the MikTex crash.
I would have more generations to display and more option for to display other names or thomething else in the person boxes. But i dont cry at this time…
OK, thanks. This suggests that we have an old bug here, because Gramps can detect that the tool is there, but doesn’t seem to communicate with it in the right manner.
@DaveSch can you tell if MiKTeX can be controlled by Gramps and well with some extra settings? I tried it on Windows 10 and 11, but found no clues about the things that make it fail here. There is no info in the logs, and I can’t find any settings to change that.
What I would expect Gramps to do is to create a temporary .tex file somewhere, and then start the tool, with the supplied PDF file path as output, so that the PDF appears in the right place, after a few seconds, maybe minutes.
Yes. We just call lualatex and then copy the file from the temporary directory to the location specified by the user.
With MikTex installed, when you output a Gramps report to the LaTeX File option, with the Open with default viewer checked, the code file will automatically open in MiKTeX. On this file, there is the green arrow button that when pressed creates the desired PDF file.
The .tex file is not a temp file and is created in the desired folder with the desired name. Running the .tex file creates the .pdf file and a .synctex.gz file.
A quick check here suggests that the call fails. I think that, because I added some print statemenst to the code, and saw no anomalities in the path, meaning no things like double backslashes in the path that’s passed to lualatex, but did notice that the whole thing completed way too fast.
For my home person, me, lualatex needs about two minutes to try to create a PDF from the TeX, after which it fails. That’s when I run it in CMD, with the paramters as suggested on the wiki. When I choose the PDF option in Gramps however, the error is shown after a second or so. And in fact, when I remove the whole process invokation from the Python code, it still needs the same second, which is probably needed to create the TeX file, and I see the same error, which means that the copying of the output file, which should have been created in the Temp folder, fails. And in this case, it fails, because I just removed the call.
This suggests that we have a problem with command invokation, which is not shown, but is proven by the fact that things go way too fast, and with the error message itself, which should not double the backslashes.
I ran another quick test on Linux, after installing lualatex there, and initially, the same thing happened there, meaning that things went way too fast there too. And when I ran the command in terminal, I saw that some styles were missing, which caused a quick exit, which wasn’t reported by Gramps.
Here too, the error popup just showed that some temp file wasn’t there, with proper single forward slashes, so that part is OK. 
After installing all needed styles, reading between the lines on the wiki, the command completed for the home person of a smaller tree, and failed on mine, after a minute or so. And in both cases, I think that there’s a big chance that the user has no clue about what Gramps is doing. I have that now, because I’m just experimenting, but it might help to inform the user that Gramps might seem to be dead for a while. And when things go wrong, there is no log file to be seen.
I knew that, and after trying to let Gramps work with the tool, I think it’s the best option for Windows, where I didn’t see it start at all, and probably also for Linux, because the document generation can take a while, and can also produce errors when styles are missing, and even run out of memory.
Thank you for your help. Maybe it will work a little better in the next version.
Yes, there is an old bug about this: 10696 - [GenealogyTree] Path issue in sandclock tree in Windows. The last time I looked at it I was curious to know if this was a Windows-only issue or Linux and Mac as well - anyone have that info?
I you scroll back a bit, you can read that I did a test on Linux, where I ran into the same problem, until I installed the tool mentioned by Nick. And initially, that didn’t help much either, because it only works if you also install the proper styles. And that’s something that is quite easy to figure out for me, because I’m a very experienced Linux user, where it’s often easier to start tools in terminal, and where I know how dependencies work.
The problem with this report is, that most of these things are hidden from the user, and that the code seems to be based on the assumption of a perfect installation, where the dependencies are all met, and it is indeed possible to use that pipe. And that works very bad on Windows, where the average user has no idea about those mechanisms. Unix users often learn quite soon about them.
And since macOS is unix based, more or less, I expect that it can work with similar tools as I use on Linux, but there too, most users probably have no clue, because the OS hides way more things than Linux does.
I know that the missing file is a symptom of bad code, but that is not clear to the user.
The “[Errno 2] No such file or directory …” error message is produced by lualatex. In such cases we don’t know what error messages to expect, so we just present them to the user in a dialog. Unfortunately, when running external tools there is not much more that we can do.
In the case of lualatex, lots of intermediate files are produced, including the tex file. We create a temporary directory for these which is cleaned up when an error occurs.
The best way to debug a genealogy tree report problem is to select tex output instead of pdf and then run lualatex manually.
My tests show that this is not true, and I know that, because in the message that started this topic, the user was on Windows, where he had no lualatex installed. And the error was about the PDF file, which was the expected output of the tool. The error message would be completely different if it where an actual complaint of that 3rd party tool.
I also know this, because I know how long it takes to process a Tex file for a report that has more than one or two generations, and I have seen that Gramps displays the error message way faster than that. And when the tool complaints, it is about a missing input file, a syntax error, or a missing style, or even running out of memory, and never about a missing PDF like you can see in the 1st message. That’s output, not input, and Gramps shows the error when the output is not there.
It’s been quite a long time since I worked with pipes myself, as a programmer, but when you use them, they’re not one directional, so you can read the output of the program, and process that to provide feedback to the user. And when the program on the other end of the pipe exits with an error, you can process the error code too.
You get even more ways to diagnose things when you use the subprocess module, which is something that we must do in the near future, because pipes will be removed in Python 3.13, as shown here:
And with that, you have all the means that I have known since long, including ways to read from both the program’s output and its error channels.
