search for: luatex

...gt;> progname, substcount = string.gsub(progname, '%-sys$', '') >> local sysprog = (substcount > 0) -- true if there was a -sys suffix >> removed >> >> and it does further processing using the program name. >> >> This has to be fixed on the luatex end, it must be able to work with >> short paths (e.g. expand it appropriately). You could probably work >> around the installation before it gets fixed, e.g. by creating another >> wrapper which would expand to long names, delete the short name, patch >> the script, etc. Af...

...t; be in the short name: > > progname, substcount = string.gsub(progname, '%-sys$', '') > local sysprog = (substcount > 0) -- true if there was a -sys suffix removed > > and it does further processing using the program name. > > This has to be fixed on the luatex end, it must be able to work with > short paths (e.g. expand it appropriately). You could probably work > around the installation before it gets fixed, e.g. by creating another > wrapper which would expand to long names, delete the short name, patch > the script, etc. After all, if it w...

...t;-sys" suffix, which won't be in the short name: progname, substcount = string.gsub(progname, '%-sys$', '') local sysprog = (substcount > 0) -- true if there was a -sys suffix removed and it does further processing using the program name. This has to be fixed on the luatex end, it must be able to work with short paths (e.g. expand it appropriately). You could probably work around the installation before it gets fixed, e.g. by creating another wrapper which would expand to long names, delete the short name, patch the script, etc. After all, if it works via a shell...

...erly. You have run into a case when an external wrapper has a bug and isn't able to deal with short names. There could easily be other wrappers around, which have a different bug and cannot deal with long names, e.g. because of spaces, when passing them to other programs. Very much like in luatex. And they may have been written in times when they actually were correct. Best Tomas > Regards, > Yihui > > > > On Mon, Oct 30, 2023 at 3:03?PM Prof Brian Ripley<ripley at stats.ox.ac.uk> wrote: >> On 30/10/2023 16:18, Yihui Xie wrote: >>> Hi, >>>...

...t of \userpackage[inputenc] (Sweave seems to read LaTeX comments as real; but that's probaby a mis-feature...); SWeave probably should not stripe @ without a starting <<>>= noweb marker. Had a couple of discussion elsewhere - it seems that international stuff in LaTeX, XeTeX and/or LuaTeX are the main ones to use, but for most parts people still stick to regional encodings (e.g. iso 8859-11 for Thai) so dependences on inputenc is not really useful. FWIW.

Hi all, I can't fathom why the accented "?" in the following ggplot2 graph makes R hangs when using tikzdevice,? whereas it works using simple pdf device. ###### library(tikzDevice) library(ggplot2) options(tikzDefaultEngine = "luatex") tikzLualatexPackages =c( ? "\\usepackage{tikz}\n", ? "\\usepackage[active, tightpage,psfixbb]{preview}\n", ? "\\usepackage{fontspec,xunicode}\n", ? "\\PreviewEnvironment{pgfpicture}\n", ? "\\setlength\\PreviewBorder{0pt}\n" ) x<-...

Sure. I'm not sure if it's possible to make it easier to reproduce, but for now the example would require installing TinyTeX (via tinytex::install_tinytex(), which can be later uninstalled cleanly via tinytex::uninstall_tinytex() after you finish the investigation). Then run: system2('fmtutil-sys', '--all') # or tinytex:::fmtutil() if fmtutil-sys.exe is not on PATH

? Fri, 1 Mar 2024 10:46:53 -0500 Benjamin Tyner <btyner at gmail.com> ?????: > my platform info: > > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Ubuntu 22.04.4 LTS Quick things first: have you installed all the build-dependencies? apt build-dep r-base (maybe with --install-suggests? haven't tried that in a while) should do that. In particular, the build

I have read about "system() not using a shell on Windows" on the help page many times before but never understood what it means technically. Please forgive my ignorance. I still do not understand it, but thanks a lot for the explanation anyway! I'm just curious if the full path would work in system() today. If it still would not work because today's Windows is still like Windows

On 29 May 2018 at 16:37, R P Herrold wrote: | On Tue, 29 May 2018, Dirk Eddelbuettel wrote: | | > On a CentOS 7 machine, I am at a loss with respect to an inability to run a | > full R CMD check as anything involving tex files ends in tears. | | Hi, Dirk | | Have fun at the upcoming conference at UIC | | I seem to have 56 font packages installed under CentOS 7 | locally, but then I work

...0130427_r30134.el7.x86_64 texlive-gsftopk-svn26689.1.19.2-38.el7.noarch texlive-helvetic-svn28614.0-38.el7.noarch texlive-hyperref-svn28213.6.83m-38.el7.noarch texlive-hyphen-base-svn29197.0-38.el7.noarch texlive-hyph-utf8-svn29641.0-38.el7.noarch texlive-ifetex-svn24853.1.2-38.el7.noarch texlive-ifluatex-svn26725.1.3-38.el7.noarch texlive-ifxetex-svn19685.0.5-38.el7.noarch texlive-index-svn24099.4.1beta-38.el7.noarch texlive-jknapltx-svn19440.0-38.el7.noarch texlive-kastrup-svn15878.0-38.el7.noarch texlive-koma-script-svn27255.3.11b-38.el7.noarch texlive-kpathsea-bin-svn27347.0-38.20130427_r30134.e...

....el7.x86_64 | texlive-gsftopk-svn26689.1.19.2-38.el7.noarch | texlive-helvetic-svn28614.0-38.el7.noarch | texlive-hyperref-svn28213.6.83m-38.el7.noarch | texlive-hyphen-base-svn29197.0-38.el7.noarch | texlive-hyph-utf8-svn29641.0-38.el7.noarch | texlive-ifetex-svn24853.1.2-38.el7.noarch | texlive-ifluatex-svn26725.1.3-38.el7.noarch | texlive-ifxetex-svn19685.0.5-38.el7.noarch | texlive-index-svn24099.4.1beta-38.el7.noarch | texlive-jknapltx-svn19440.0-38.el7.noarch | texlive-kastrup-svn15878.0-38.el7.noarch | texlive-koma-script-svn27255.3.11b-38.el7.noarch | texlive-kpathsea-bin-svn27347.0-38.20130...