- dev-luatex - NTG Mailing Lists

Fwd: luatex (suggestion by Ivo Welch)
by Taco Hoekwater 04 Jul '22

04 Jul '22

> Begin forwarded message: > > From: ivo welch > Subject: luatex > Date: 3 July 2022 at 21:46:46 CEST > > hi taco--- > > https://tex.stackexchange.com/questions/649666/lulatex-macos-font-mystery-f… > > I just ran into some lualatex problems with a font from macos Fontbook. > > suggestion: may I suggest improving the error messages with respect to > fonts? if a font is not found, print out *where* luatex was looking > for the font ("montserrat not found in /usr/...; /opt/..."). [maybe > also add the most similarly named font if one exists.] ulrike also > suggested that maybe the font was damaged, although it worked well > with other apps. in any case, if this could be the reason, perhaps > add a different kind of error message than "font not found." > > regards, > > /iaw > > -- > Ivo Welch (ivo.welch(a)ucla.edu) > http://www.ivo-welch.info/ > J. Fred Weston Distinguished Professor of Finance, UCLA Anderson > [please acknowledge receipt if this is the first email in a conversation] — Taco Hoekwater E: taco(a)bittext.nl genderfluid (all pronouns)

1 0

Re: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files
by Norbert Preining 04 May '22

04 May '22

Hi Luigi, hi all luatex devs, here at Debian we got a bug report about reproducability of luatex format dumps. It contains a patch to make the hyphenation exception list sorted. (I attach the patch) Could you please take a look whether this is still relevant for the latest release of luatex. Thanks Norbert On Fri, 08 Apr 2022, Roland Clobus wrote: > Hello maintainers of texlive-binaries, > > While working on the “reproducible builds” effort [1], I have noticed that the > live image for Cinnamon in bookworm is no longer reproducible [2]. > > The attached patch ensures that the output of the function 'exception_strings' > always uses the same order of the hyphenation exceptions. > I've written the solution in C, perhaps someone more versed in lua could > rewrite it more elegantly. > (The lua manual says for the 'next' function: 'The order in which the indices > are enumerated is not specified' [3]) > > With the attached patch applied, I'm able (with the help of FORCE_SOURCE_DATE=1 > and SOURCE_DATE_EPOCH) to reproducibly rebuild the .fmt files, as created by > 'fmtutil --sys --all'. > > Small test case to reproduce: > export FORCE_SOURCE_DATE=1 > export SOURCE_DATE_EPOCH=$(date +%s) > for i in `seq 1 10`; do luahbtex -ini -jobname=luahbtex -progname=luabhtex > luatex.ini > /dev/null; md5sum luahbtex.*; done > > With kind regards, > Roland Clobus > > [1]: https://wiki.debian.org/ReproducibleBuilds > [2]: > https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_cin… > [3]: http://www.lua.org/manual/5.4/manual.html#pdf-next > -- PREINING Norbert https://www.preining.info Mercari Inc. + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

4 14

Feature request: busy pdf
by Jérôme LAURENS 04 May '22

04 May '22

New CLI options --busy related to typesetting luatex --busy=0 default behavior, nothing new luatex --busy=1 Instead of writing the pdf output to jobname.pdf, write to jobname.pdf(busy) At the end remove any jobname.pdf and move jobname.pdf(busy) to jobname.pdf luatex --busy=2 foo.tex If there is a jobname.pdf(busy) bail out with a diagnostic message « typesetting already in progress » Otherwise do like --busy=1 Actually, the pdf is removed at the start of the typesetting process such that it is no longer available during that whole time. When the typesetting is a bit long, it is not practical at all. For continuous typesetting neither. Considering that we work in general on the end of a document, the first pages will not change a lot but are no longer available. synctex already supports this « busy » busyness such that the previous .synctex file is available during next typesetting process.

3 17

Setting up git mirror of luatex svn repo.
by luigi scarso 04 Apr '22

04 Apr '22

Hi all, I would like to set up a git mirror (on github or ..) of the current luatex svn repo. It should cover all directory in the current repo, i.e branches, tags , tools , trunk and vendor, all with the full history. As known, the main svn repo is experimental and not trunk, but I think that we can now switch to the usual (svn) model trunk / tags . I have done some experiments locally, but probably I have messed up some configs, so I am open to suggestions. -- luigi

2 3

Feature request: SyncTeX support
by Jérôme LAURENS 03 Apr '22

03 Apr '22

There are situations where synctex info is not available: consider ``` \immediate\openin 0 {subfile.tex} \immediate\read 0 to \My \immediate\closein 0 \My \bye ``` Synctex does not see `subfile.tex` at all, which forbids any kind of synchronization between subfile.tex and main.pdf. It would be very cool if the \openin could create a new tag and the \read could use that tag while parsing subfile.tex. A synctex information about the line number would be very nice as well, a default of 1 is far better than nothing. A tex.get_synctex_tag_for_name(‘foo') would be extremely handy. Finally, raw setters and getters should be provided for synctex tag and line, to control exactly what tag and line is written to the .synctex file. No save stack for them, no mode. Simply raw. Some global synctex state stack would help: save_synctex_state/restore_synctex_state… BTW that would be great to deactivate set_synctex_tag for mode 0 just like set_synctex_line is.

2 4

Problem with directlua and synctex_tag
by Jérôme LAURENS 30 Mar '22

30 Mar '22

We can use ``` \directlua{tex.set_synctex_tag(421)} \directlua{print('421=',tex.get_synctex_tag())} \bye ``` To set and read the synctex tag. But if we wrap this into a macro, things get broken and the synctex tag is not changed. ``` \def\test{\directlua{tex.set_synctex_tag(421)}} \test \directlua{print('421=',tex.get_synctex_tag())} \bye ``` For synctex_line there is no such problem. Is this a bug or a feature ?

4 13

Re: [Dev-luatex] 2 characters shift in error context
by luigi scarso 28 Mar '22

28 Mar '22

On Sun, Mar 27, 2022 at 5:11 PM Ikumi Keita <ikumikeita(a)jcom.home.ne.jp> wrote: > Hi, > > >>>>> luigi scarso <luigi.scarso(a)gmail.com> writes: > > I have checked it but luatex and pdftex manage the split the line in > > different way. > > For example this gives a different log > > Nullam eu ante vel est convallis dignissim.0123456789} Nulla posuere. > > \bye > > I will look at the xetex output closely. > > Do you have any news about this? > Sorry for the delay. I have to postpone it, no time now . I am not sure that I will fix it because I don't see a bug (yet). -- luigi

3 2

Re: [Dev-luatex] LuaLaTeX -- hyperlink with ragged right
by Suki, Venkatesan (TNQ Software) 26 Mar '22

26 Mar '22

Please send the LaTeX markup code also... SKV On Sat, 26 Mar, 2022, 8:34 am Kunchitapadam, Baskaran (TNQ Software), < n.k.baskaran(a)tnqsoftware.co.in> wrote: > Hi Team, > > I am working in LuaLaTeX templates. I have face the below issue in title > formatting. I have ragged right title content which is hyperlinked. > > Each line end blank also covered hyper link. We need to format like the > last line in below image. Kindly suggest a solution. > > -- > > Thanks and Regards > > Baskaran NK > > Tech. Lead – 4722 / 4847 > > M : +91 9840928250 > > TNQ Technologies Pvt. Ltd. > > Linkedin <https://www.linkedin.com/company/tnqtechnologies/> | Twitter > <https://twitter.com/TNQtechnologies> | Facebook > <https://www.facebook.com/TNQTechnologies> > > T : +91 44 4596 4800 | tnq.co.in <http://www.tnq.co.in/> > > > -- Disclaimer: The entire content of this email message, including any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or part of the entity, you should not disseminate, distribute, or copy this email. Please notify the sender immediately by e-mail if you have received this email by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

2 characters shift in error context
by Ikumi Keita 21 Mar '22

21 Mar '22

Hello LuaTeX developers, I have a few questions I'd like to ask you. In log message, luatex engine produces slightly different error context from what pdftex does. Here is a sample code: ---------------------------------------------------------------------- Nullam eu ante vel est convallis dignissim. } Nulla posuere. \bye ---------------------------------------------------------------------- When I process this file by luatex, it results in the following error: ------ luatex result ------------------------------------------------- ! Too many }'s. l.1 Nullam eu ante vel est convallis dignissim. } Nulla posuere. ---------------------------------------------------------------------- On the other hand, pdftex results in: ------ pdftex result ------------------------------------------------- ! Too many }'s. l.1 Nullam eu ante vel est convallis dignissim. } Nulla posuere. ---------------------------------------------------------------------- The output of luatex is shifted by two characters compared with that of pdftex. (I'm using TeX Live 2021.) This discrepancy confuses preview-latex (subsystem of AUCTeX), which depends on the precise position of the log messages: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54200 I'm not sure whether this behavior is a bug or not, but is it something I can expect to be fixed? If not, is there any workaround to make the output the same as pdftex? (e.g. command line option) Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine

3 8

bug with \showbox
by Petr Olsak 08 Mar '22

08 Mar '22

Suppose this file: -------------- \immediate\openout0=test.ref \setbox13=\hbox{aha} \showbox13 \end -------------- If I run "luatex file", it ends without errors and the \showbox result is written in the test.ref file. But if the \openout line is commented or it is opened another output stream than zero, then the behavior is correct: it ends with: ---------------- ! OK (see the transcript file). l.5 \showbox13 ? ---------------- luatex --credits: This is LuaTeX, Version 1.15.0 (TeX Live 2022) ... Development id: 7503 The luatex from TL2021 (id 7430) does have this problem, i.e the \showbox result is in transcript file always. Regards Petr Olsak

2 1