@UlrikeFischer I made a mess while uploading, so I need to talk with CTAN to clean it up. The luamml update will probably end up going out tomorrow morning.

@MarcelKrüger incoming says something about luaotfload?

@UlrikeFischer Yes, I uploaded under the wrong name...

@JosephWright I sent a hyperref update and this will affect a latex-lab test (actually it corrects it). And Karl seems to have sent another tugboat update so the firstaid test will perhaps break again.

@MarcelKrüger ;-) But ctan will sort it out.

@JosephWright if I build the docs before trying to build ctan, it works. (well, it fails later, but that's expected). so my l3build config is wrong for check. I think because I don't know what to use in place of typesetsourcefiles. So effectively, I have

checkdeps = {maindir .. "/nfssext-cfr", maindir .. "/fnt-tests"}
checkengines = {"pdftex"}
checkformat = "latex"
typesetdeps = {maindir .. "/nfssext-cfr"}
typesetexe = "TEXMFDOTDIR=.:../local: pdflatex"
typesetfiles = typesetfiles or  {"*.dtx", "*-tables.tex", "*-example.tex"}
typesetsourcefiles = {keepdir .. "/*", "nfssext-cfr*.sty"}
typesetdeps = {maindir .. "/nfssext-cfr"}
typesetruns = 5

Is there a check equivalent of typesetsourcefiles?

or should I just add to checkinit_hook?

what is unpackdeps intended to do? based on the docs, I thought it would work similarly to checkdeps and typesetdeps, but at the unpack` stage. but what it seems to do is (presumably) unpack whatever right before unpackdir is cleaned, so the effect is disappointing. so is it meant to be for something different? or is this not the intended behaviour? if I rewrite the functions from l3build-unpack.lua it does what I expect ;).

@MarcelKrüger Ah, yes - I wonder if we should talk to Hans about that - as he's added \dimexpression/\numexpression, perhaps he could live without the ; extension

@cfr Unpack, move to the local tree, then clean out unpackdir - every unpack step must run with a clean unpackdir

@cfr That's just sourcefiles

@cfr I had a brief look at your setup yesterday but I didn't have time to dig in properly - all the changing paths and whatnot makes life very tricky, so first I need to unpick that :)

@cfr As in, the script you have as it stands isn't portable - I can't simply run l3build <whatever> in a clean checkout with a standard MacTeX

@MarcelKrüger I was saying to @UlrikeFischer that this needs documenting - tidy isn't a standard tool ...

@JosephWright but then later things want to count it as source e.g. manifest etc.

@cfr Those aren't sources ... they are things that go to CTAN - sourcefiles is stuff that gets unpacked or if not using DocStrip things that go directly into the live tree

@JosephWright but isn't sourcefiles supposed to be for things in this package? as opposed to stuff from a different package?

@cfr Files for a different package would be in a different place :)

@cfr I suspect I'm missing something here - with a directory foo containing a build.lua, sourcefiles would be (as standard) those files inside foo which are needed to produce files in the 'live' TeX tree (so not purely for documentation)

@JosephWright but I want to unpack files from a different package along with files from this package because this one depends on the other one.

@cfr Sure, but that is what unpackdeps is for, e.g. we need to unpack l3backend when we build l3kernel, but only the l3kernel source files go into the CTAN package

(Or for base, or whatever - this is something the team needs routinely and was in l3build from the start)

@JosephWright so a bunch of font packages all need files from fontscripts. so fontscripts needs to get unpacked for each of them. that is, i want a clean unpackdir with, say, fontscripts.dtx, fontscripts.ins, electrumadf.dtx and electrumadf.ins.

@JosephWright yes, but the unpackdeps get deleted because the dependency is unpacked before the directory is cleaned.

@cfr Like I said, they get moved to localdir: after unpacking a dependency, it's unpacked files are installed into the local tree, which is then added to the TeX search path so they'll be found by the following unpacks

I will check I am right - I'm pretty sure ..,.

Hmm, perhaps not ...

@JosephWright that would be fine if they could be found ....

@cfr I'll look at this - perhaps there's an oversight on my part

@JosephWright I would like to make this not the case ....

@cfr I'm sure :)

[except berenisadf, which definitely won't build without other things.[

@cfr Just checked - if you do e.g. l3build unpack in latex2e/required/tools, you get all of the unpacked base files in unpack/local as I thought you did :)

Seems like expl3 is a real problem, because it's so standardised that ChatGPT can almost write code with it. (in the lights of tex.stackexchange.com/a/729704/117050)

@JosephWright does it work for you for a case where bundleunpack isn't redefined in the build.lua?

although I can't see why that would matter ...

@JosephWright should I list them as installfiles even though they end up in the source tree?

then they would presumably get installed into build/local ...?

@Skillmon :)

@cfr Yes - that redefinition is just to print a message for tools (and I spot I can shorten a bit)

@cfr I get the feeling you are trying to do something a bit at variance with the way l3build works in terms of dependencies

@cfr We start with the idea that each module will be installed to CTAN, etc., independently, and any files that package B needs from package A are installed in the 'live' tree

@cfr So for example even thought tools is developed along with latex-base, you could take a virgin TeX system, install latex-base from CTAN, then unpack tools by hand at the terminal as the dependencies would be found by kpse

@cfr On the other hand, things that are 'just for unpacking locally' are in unpacksuppfiles - so for example we need some hyphenation stuff to unpack latex-base in the development repo, but it's not part of something we send to CTAN at all

@PabloGonzálezL F41 already? :)

@PauloCereda I updated a week ago and haven't had any crashes or anything, but I don't know if the official version is ready (I just used my usual dnf upgrade-system)

@PauloCereda Ohhh...yes it's official now :D

@PabloGonzálezL I was just caught off gard that gnome-terminal is no more. :)

(well, if you have it installed, it won't go away, but when I rebased my Silverblue, it got removed)

@Skillmon Oh no! We should add more :weirdness and :Dubiety to it!

@JasperHabicht Be careful! If you spell it like this, it looks Vim-ish and it could scare some (@DavidCarlisle)

@yo' :Vim-ish? =D yes

@samcarter in beamer, is there a way to add a layer on top of the footline layer? Trying to recreate some PowerPoint slides in beamer. And one PP slide has some images that covers half the footline. But in beamer this layer is below the footline, and so that it still visible. There is a logo in that corner. Been trying to use \onslide<...>{logo} on that, to some very inreliable results.

@daleif The footline is the front most layer. However you could add things to this layer and e.g. use tikz to position it where you want it on the frame.

\documentclass{beamer}
\usetheme{Warsaw}
\usepackage{tikz}

\begin{document}

{
\addtobeamertemplate{footline}{}{%
  \begin{tikzpicture}[remember picture,overlay]
  \node at (current page.south) {\includegraphics{example-image-duck}};
  \end{tikzpicture}
}
\begin{frame}
  abc
\end{frame}
}

\end{document}

@samcarter That is what I'm trying, though I also try to combine it with \onslide, and for some reason only <2> is triggered. And I cannot figure out why.

\documentclass{beamer}
\usetheme{Warsaw}
\usepackage{tikz}

\begin{document}

{
\addtobeamertemplate{footline}{}{%
  \onslide<1>{1}
  \onslide<2>{2}
}
\begin{frame}
  abc \pause def
\end{frame}
}

\end{document}

@daleif overlays won't work there. You could test for the page number.

@samcarter so the footer is basically always drawn with the largest overlay number?

@daleif you could use the shipout/foreground hook. It is before:

\documentclass{beamer}
\usetheme{Warsaw}
\usepackage{tikz}

\begin{document}

\AddToHook{shipout/foreground}{\put(0,-\paperheight){\includegraphics[height=4cm]{example-image-duck}}}
\begin{frame}
  abc
\end{frame}


\end{document}

@daleif it is meant to be a static element :)

@UlrikeFischer that does not support overlays :-(

@daleif Another approach: use the background layer to draw the footline

@samcarter nice image. You should add the shipout hooks to it.

@UlrikeFischer Andrew Stacey kindly agreed that beamer can use it in the manual. Good idea! I'll see if I can add them.

Combining the hook and a page number test does work. But is prone to human error

@daleif add a disclaimer that only ducks can use your code - rules out all human error :P

@daleif I'm not sure how you want overlays to change that, but

\documentclass{beamer}
\usetheme{Warsaw}
\usepackage{tikz}

\begin{document}

\makeatletter
\begin{frame}
\AddToHookNext
   {shipout/foreground}
   {\put(0,-\paperheight)
     {\includegraphics[height=4cm,page=\beamer@overlaynumber]{example-image-duck}}
   }
   abc \pause def
\end{frame}

\begin{frame}
blub
\end{frame}

\end{document}

@UlrikeFischer the images added to the frame are not the same one each overlay.

@daleif well my example uses two different images (I was only lazy and used the page number of the example-image-duck to get them).

@UlrikeFischer Ahh, was missing \beamer@overlaynumber, that would probably simplify my code quite a bit

@Skillmon a BBox is missing but apart from this this looks ok:

\DocumentMetadata{uncompress,testphase={phase-III,table},pdfversion=2.0,lang=en}
\documentclass{article}
\usepackage{ducksay}
\begin{document}
\leavevmode
\begingroup
\tagpdfsetup{table/tagging=false}%
\tagmcend\tagstructbegin{tag=Figure,alt=a duck saying hello}\tagmcbegin{}%
\ducksay{hello}
\tagmcend\tagstructend \tagmcbegin{}%
\endgroup
\end{document}

@UlrikeFischer that's neat :) I think it would be great if LaTeX defined the tagging related commands from the testphase as no-ops if it's not loaded. Would allow package authors to just put the code there and it essentially doing nothing unless the testphase is loaded. Currently packages that want to support tagging have to check whether tagging is activated and branch accordingly...

@Skillmon there is a tagpdf-base that does that but yes, at some point that will get merged into the format (as @UlrikeFischer gets braver:-)

@Skillmon well you can hide that inside a tagging socket. That works always. So \NewSocket{tagsupport/ducksay/before}{0} with a suitable plug and then \UseTaggingSocket{ducksay/before}

@UlrikeFischer are sockets the preferred way for package authors? Seems like quite some overhead for these few commands. Anyways, let's see when I get to that :)

@UlrikeFischer with "a BBox is missing" do you mean that the tagging structure also gets told how big the tagged "figure" is?

@Skillmon well they are predefined. And you can exchange them. But you can also simply load tagpdf-base.

@UlrikeFischer you suggested me to use a \NewSocket, which somehow conflicts with "predefined" in my head :P

@Skillmon yes, the *** Figure structure wants to know its absolute coordinates on the page (so that e.g. derivation to html can make a screenshot).

@Skillmon the tagging socket interface is there. So \UseTaggingSocket always works.

@UlrikeFischer absolute coordinates sounds really like a PITA :(

Is the tagging alt text expected to get translated? (sorry for all those questions but I really have no idea about most of the tagging stuff, I just don't have the time to follow everything you're doing in that regard)

@Skillmon This is PDF, absolute coordinates, absolute byte offsets within the file, absolutely impenetrable specifications, ...

(and as always "I don't have the time" is the universal code for "I don't intend to take the time as I have things I prefer doing")

@DavidCarlisle Oh, you do not like the format? :)

@mickep I like it, but I preferred it when the specs were behind a paywall, as then there was a good excuse for not reading them. I think I read the entire pdf spec when it first came out and I definitely read the entire postscript level 1,2,3 specs, but reading the current pdf specs is... harder

@DavidCarlisle Sore eyes...

@DavidCarlisle It seems to me that the standard is also evolving a bit arbitrary, when looking at pdf-issues.pdfa.org/32000-2-2020 . Well well, would be worse without pdf, I guess.

@Skillmon the alt text is what screen readers are supposed to read (some, I don't give names, additionally read all the ascii art of ducksay, but there is not much one can do, if everything is tagged as artifact, nothing is read at all.)

@UlrikeFischer I guess if one wants to prevent that one would have to turn the glyphs into PDF paths. Doesn't sound like something I'd do :)

@JosephWright maybe, but not for the reason you suggest, I don't think. the packages aren't dependant on fontscripts. (they do depend on nfssext-cfr.) you can download the font packages and install and use them without fontscripts. that's not a problem. you only need fontscripts if you want to generate the TeX font support files (tfms, vfs, maps, fds, encs etc.). so they're dependent only in the same way they're dependent on fontinst.

@JosephWright I do this because the packages share etx, mtx and lua files. none of that is needed to typeset the docs, run docstrip or use the packages for typesetting. but the files have to be found when fontinst runs. (specifically, I need that the etx and mtx files are found.)

@JosephWright so how would you do it, if you wouldn't separate those out? if I was setting it up from scratch, it might be more sensible to make them a bundle, but that would have its own disadvantages and would alter the ctan/tex distribution setup, which would likely break various things for people.

@JosephWright I could not send fontscripts to ctan at all and everything would still work. I'm only sending it to ctan because tex live wants source.