lualatex file luabidi.sty not found. where must I place it? - latex

I am getting lyx set up on my xubonto laptop. I have used some online guides to set the thing and slowly worked my way around several issues, so I cannot recall exactly what I have set up. I am using non-Tex "Culmus" fonts (had to rename them for luatex to recognize them), and Document Class article standard.
Lyx have no problem exporting a luaTex file (or a xetex file) but am complaining about a luabidi.sty file-not-found (or a bidi.sty file-not-found).
So I have downloaded luabidi but I am not sure where to place it..
it contains 2 folders tex and doc, so I have placed their content in
/usr/share/texlive/texmf-dist/tex/luatex/luabidi
/usr/share/texlive/texmf-dist/doc/luatex/luabidi
But it did not resolve the issue... Some specific help would be appreciated, as well as may be a better way to manage luatex packages and files?

Installing texlive-lang-arabic fixed it.

Related

Texpad do not find chapter image on Mac

I am using a latex template I found on Overleaf (link). Using directly Overleaf, I do not have any problem when compiling. Same when using Sublime Text. However, when using Texpad, I got the following error:
LaTeX Warning: File `chapter_head_1.pdf' not found on input line 100.
./main.tex:100: Package pdftex.def Error: File `chapter_head_1.pdf' not found:
using draft setting.
In the beginning, I thought the problem was related to Sandboxing, but I granted already accessibility to the whole folder, so it does not make sense to me that Texpad cannot find the file.
As additional information: I am using the latest version of Texpad v1.8.15 for macOS Catalina v.10.15.6.
I really like some features offered on Texpad, so I would appreciate it very much if you could let me know how to solve this problem. Thanks!
Update: <Sept. 30th, 2020> Find the .log in this link.

Opening a Latex Overleaf template: Parskip.sty not found?

I would like to open this cv template on my tex. However, after downloading it, I get this error:
! LaTeX Error: File `parskip.sty' not found.
I believe I downloaded the source files correctly and moved them into Latex packages, including the cls. I also tried updating the packages on my Latex.
Can anyone please assist? Thank you.
You need to download the missing file which is the parskip-2001-04-09.sty from source and save it as parskip.sty to where your other files are.
Tested on Ubuntu.

Unable to open a cgns file

Okey, this is not a core programming question; it is more of a question regarding cgns (CFD general notational system) API.
I've exported a grid/mesh file from ANSYS Fluent (which was first created in Gambit 2.46), and I wrote a very simple Fortran program to open and close it (doing nothing else). To check the file is not corrupt I plotted it in Tecplot.
So, when I compiled using gfortran with the mentioned cgns and ran the program I got this error (as part of cg_error_exit_f())
ADF_Database_Open:File does not exist or is not a HDF5 file
Here is the program
program cavity
include "/usr/include/cgnslib_f.h"
call cg_open_f("Cavity.cgns",CG_MODE_READ,index_file,ier)
!check for error if so exit
if (ier .ne. CG_OK) then
call cg_error_exit_f()
end if
write(*,*)"I kind of opened the file?"
call cg_close_f(index_file,ier)
stop
end program cavity
I'm able to write both structured and unstructured grids in cgns format, without any problem.
I suspect the cgns library I'm using(version 2.5.5 packaged in Fedora 15 and Scientific linux 6.1) is built to support only HDF5, while the exported grid file is written in ADF format.
Any ideas to circumvent this or perhaps adding ADF? Which by the way is not packaged in both the distributions. Any other grid generator which is compatible with cgns version 2.5.5?
I hope I was clear. Any further info required, I would provide.
There is so much that could've gone wrong in here, and I'm afraid you didn't exactly narrow the problem down.
You said you exported a file from Fluent (what kind of a file is it? Be sure!). cg_error_exit_f() gave you an error listed. I'm assuming you have the source of the mentioned routines? In the program you include a cgnslib_f.h file - what's in it? I'm assumming the program compiled without errors of any kind, making this a file format question, not a fortran question.
Again, verify what kind of file Fluent produced.
When I ran into this situation, I discovered the following tools:
hdf2adf
adf2hdf
They are in the cgns-convert package on Ubuntu and are probably available for your distribution as well.

Problem with Gnuplot 4.4 and TikZ

I'm using Gnuplot 4.4, compiled with Lua support. It supposedly has the tikz terminal.
I've successfully compiled my gnuplots to tex using "set terminal tikz". However, when adding this source to my latex document I keep getting the following error:
! Package pgfkeys Error: I do not know the key '/tikz/gnuplot' and I am going t
o ignore it. Perhaps you misspelled it.
I've included the tikz package in the original tex document. Any ideas?
EDIT: Solved. See answer bellow.
I didn't give in until I found a solution:
\usepackage{gnuplot-lua-tikz}
If you don't have the gnuplot-lua-tikz.sty just get it from the latest gnuplot development snapshot
http://sourceforge.net/projects/gnuplot/
Unfortunately I am not allowed to comment here, hence a new answer. The .sty file is not sufficient, you need both of the following files from gnuplot (unfortunately the package is no gnuplot-lua-tikz package at cran):
gnuplot-lua-tikz.sty
gnuplot-lua-tikz-common.tex
For later happless Fedora users: The package containing this here is gnuplot-latex, dnf doesn't recognize it as tex(gnuplot-lua-tikz.sty).

Delphi "E2161 Error: RLINK32: Error opening file ________.drf " during Build All

I am trying to resolve a problem with a set of packages that apparently have dependency issues. Occasionally during a Build All, I get this error:
Delphi "E2161 Error: RLINK32: Error opening file ________.drf "
What does it mean / indicate, and what is a "drf" file?
It looks like this turned out to be the main problem / solution.
Open up all the packages for which you have source code, and specify the compile option:
'Rebuild explicitly' instead of 'Rebuild when needed'.
In addition to the Solving the 'cannot find drf file' problem when compiling packages article, I also came across Delphi bug report #44134, in which a commenter mentions that the problem stems from having your .dpk files in the same directory as your .pas files when that same directory is in the library path and "rebuild as needed" is enabled.
You thus have three options for fixing this problem:
Turn off "rebuild as needed". This seems to be the most common solution.
Put your package files (*.dpk, *.dproj) into a separate directory and then reinstall the packages. I have done this, with success.
Remove the directory containing your .dpk and .pas files from the library path. Note that Delphi will add it back again in certain circumstances, including when you install/reinstall your package.
Hmm... never heard of them. I just searched the project that inspired the question you linked to, and there's nothing in there with a "DRF" extension. Checking here doesn't turn up anything Delphi-related. But the fact that it's a linker error, not a compiler error, would lead me to guess that the first two letters stand for "Delphi Resource."
Try a search through your project's directory tree and see if you can find anything with a DRF extension. If so, try opening it with a text editor to see if it's readable, and if not, try a hex editor if you know anything about reading binary file formats. See if you can make any sense of it.
If you don't find any, then Delphi's probably getting it from somewhere in the code it's compiling. Try running a grep search for "DRF" on your directory tree and see if it turns up anything.
From http://www.delphifaq.com/faq/delphi/delphi_ide/f157.shtml :
When you compile with packages, you
can specify which packages should be
considered for linkage. The package
requirements of the project get stored
into a temporary Windows resource file
with a .DRF extension.
Whatever that file with the many underscores is, the linker is most probably searching it in what it thinks the tempdirectory is (you can confirm this using filemon). The explanation at DelphiFaq, where a misdefined %TEMP% is the culprit, is as likely as any reason.
Sometimes the problem was file access permissions.
A workaround was run Delphi as Administrator.

Resources