« first day (5071 days earlier)      last day (82 days later) » 

cfr
cfr
00:10
do I have to do something special for the following to be true?
> As a result you can use \LastMark{2e-left} and \FirstMark{2e-right} instead of
\leftmark and \rightmark.
[in the lthooks docs]
I don't get the same marks returned at all.
@AlanMunn you're abandoning TS?
 
2 hours later…
cfr
cfr
02:33
I guess the answer is don't use ltxdoc ...
 
3 hours later…
05:06
@daleif -- Send the suggestion to tech-support@ams,org.
cfr
cfr
05:39
@daleif scale will keep the aspect ratio if the two scaling factors are equal (as I understand it). I don't think there's an out-of-the-box way to provide a dimension and have the other calculated, but you can use the dimensions of coffins directly in calculations. (which may or may not help.) there aren't as many reasons to put coffins in boxes as there were, but there are still some .... (at least if you want to stick with published functions - I assume you could do it without otherwise.)
 
1 hour later…
07:00
I just discovered that if you load a font with fontspec and set the FakeStretch font feature, the veraPDF validation Report for UA-1 (also UA-2) conformity throws an error about glyph lenghts being inconsistent. Is this worth a bug report, and if yes, where should i report it? In the fontspec issue tracker, or in the latex3-tagpdf tracker?
07:53
@barbarabeeton the other way around, Ild like to make empheq able to place \qedhere when proof env from amsthm is used.
@Lupino in the luaotfload tracker. It fails also with low-level font selection (and without any tagging code or so, verapdf will always complain). with xelatex there is no warning, so it should be possible to implement the stretch with a correct width area.
 
2 hours later…
09:27
@JosephWright well, the manual does say one can use it in control sequences ;-)
09:42
@barbarabeeton but not in automatic way, more like give empheq an qedhere option, and it could issue a \qedhere at the right position.
10:18
@PauloCereda I blame you: bbc.co.uk/news/articles/c39lnn7vz80o
@DavidCarlisle :)
@DavidCarlisle ooh go cappy
10:41
@Rmano Your relatives causing a bit of chaos? www-spiegel-de.translate.goog/panorama/…
@samcarter I feel for the species... what, boarding without a ticket...
@Rmano The ticket machine probably didn't accept nuts as payment, so what else could they do? :)
@samcarter so now we know why they were upset...
10:57
@Rmano understandable upset :)
 
2 hours later…
12:48
Regarding merging PDF files that include hyperlinks. Is there a way to check that the links does work after merging, and that it is not some fluke? Wondering if uncompressing the PDF and looking in the data would help? (we have an important evaluation comimng up and have to submit a large report, so wanted to be sure the merged result works 100%)
@daleif just print it. No one expects working hyperrefs in print anyway so the evaluation will be a breeze.
@Skillmon Weeell
@daleif external url links or internal links?
13:09
@UlrikeFischer Both. So far I've only tested external one (had forgotten about internal ones). Acrobat seems to do a nice job.
13:31
@cfr Abandoning is probably too strong a word, but if VSCode can do what I want, I may start using it more for TeX as well as coding. Certain aspects of VSCode like the file view are nice. But I doubt I'll abandon it entirely.
@DavidCarlisle The lvt's seems easy enough to create, it is more the build.lua stuff that is a pain. All I wanted here was to download testfiles/github-0173.lvt and run l3buid save (I assume) on it.
13:45
@daleif if you have an existing l3build just saving that file in a testfiles directory should be enough, you wouldn't have to change build.lua, oh except we use source2e.tex and you probably want to use regression-test.tex in tests
cfr
cfr
@AlanMunn :-)
@daleif perhaps use an example not from the latex2e tests (which mostly predate l3build)
@DavidCarlisle Well, who gave me that list?
@DavidCarlisle I took, github-0053.lvt, it is fairly simple. It uses test2e, that might be what you were referring to. But no matter what it keeps complaiing about a missing build.lua.
@daleif Do you have a directory with a build.lua in it, with inside that a testfiles dir with the .lvt in it?
@daleif yes you need a build.lua it can have a single line module = "yourmodule"
@daleif and change test2e to regression-test (the latter being @JosephWright's pale imitation of the former)
13:56
@DavidCarlisle I did say we should rename it ... ;)
I have the following structure
/build.lua
testfiles/github-0053.lvt
Ahhj, not obvious that one should not use l3build save github-0053
l3build save testfiles/github-0053.lvt
Test "testfiles/github-0053.lvt" not found
wasn't there also some option that could make versions for pdflatex, xelatex and lualatex in one go? Probably best
oh you mean should use not should not use yes you need the name not the path (for check you can use the path as well but apparently not for save)
@DavidCarlisle right, mistype
14:04
@daleif By default we save one file which is expected to match all engines - if you need per-engine files, you make them in a second step
@JosephWright I was playing with that with memoir at one point and there was always differences between pdflatex and lualatex (presumably because of fonts). Ulrike (I think) mentions once how to make for several engine at once.
@daleif l3build save -epdftex,luatex <name>
For example
@JosephWright ohh, engine, I was writing the full function names, then I did remember correctly.
Written down this time
@daleif -- Right. Well, there's no mention of \qed or \qedhere in amsmath, but @DavidCarlisle might be able to help.
@barbarabeeton It is probably easier to understand with an example, here I'll show what empheq can do with ntheorem
\documentclass[a4paper]{article}
\usepackage{amsmath,amssymb}
\usepackage[amsmath,thmmarks]{ntheorem}
\usepackage[ntheorem]{empheq}

\theoremstyle{nonumberplain}
\theoremsymbol{\ensuremath\square}
\newtheorem{proof}{Proof}
\begin{document}

\begin{proof}
Foobar
\begin{equation*}
\sum_{\substack{a\in A \\ b\in B}}
\end{equation*}
\end{proof}

\begin{proof}
Foobar
\begin{empheq}{equation*}
\sum_{\substack{a\in A \\ b\in B}}
\end{empheq}
\end{proof}

\end{document}
Note how the tomestone is placed badly in the first example (yes I know it is bad style to end a proof with a displayed formula, it happens all the time).
And see how empheq (the lower one) has a better placement. I wanted to make support for this for amsthm's \qedhere. I'm thinking a syntax like \begin{empheq}[qedhere]{equation*} would be usefuil.
A kind of carrot to get users to use a coming expl3 based empheq and mathtools.
One def need all engines if one just runs something like
\documentclass[a4paper]{article}
\usepackage{mathtools}
\input{regression-test}

\showoutput

\begin{document}

\START

\[
\begin{gathered}
[t] = 100 \\
[v] = 200
\end{gathered}
\]


\end{document}
As there are differences in presision. Would it make sense to move \showoutput here?
cfr
cfr
14:35
@daleif why?
@daleif to avoid engine dependency? Not really. The LaTeX kernel does some curious stuff like changing fonts to keep engines "the same", but in all normal cases \showoutput gives different output. I restrict various tests to only one engine if it doesn't really matter.
Are there then options for `check` to ignore some of them?
** ./build/test/210_fixamsmath_allowspaces.luatex.tlg 2024-09-18 16:37:50.762084541 +0200
--- ./build/test/210_fixamsmath_allowspaces.luatex.log 2024-09-18 16:37:50.762084541 +0200
***************
*** 63,69 ****
.......\mathon
.......\OT1/cmr/m/n/10 [
.......\OML/cmm/m/it/10 v
! .......\kern0.35878
.......\OT1/cmr/m/n/10 ]
.......\glue(\thickmuskip) 2.77771 plus 2.77771
.......\OT1/cmr/m/n/10 =
--- 63,69 ----
.......\mathon
.......\OT1/cmr/m/n/10 [
cfr
cfr
is there a straightforward way to get l3build to include lua scripts in the ctan archive?
The first is space difference. Not sure why the other has differnt values. Here I ran l3build save 210_fixamsmath_allowspaces and afterwards l3build check and it gave differences on luatex and xetex.
I'd kinda like if l3build save testfiles/foobar was the same as l3build save foobar as the names are not always easy to remember. But it is probably like this for a reason.
@daleif I have folders "testfiles-pdftex" "testfiles-luatex" "testfiles-noxetex" etc, and suitable config-pdftex.lua etc which restrict the check engines. It slows down the checks (as unpacking has to happen more than once) but also reduces the danger of side effects between engine runs.
 
1 hour later…
15:58
@cfr sourcefiles={"*.lua", ...
@daleif as I say it got added for check (as Will and I can't accurately type a testfile name without using completion on the commandline which then needs the directory), so could probably do same for save
@DavidCarlisle Yeah, we could do something
@daleif \showoutput is an easy sledgehammer to get a test working, but it does tend to show engine differences. If you write a more specific test eg save to a box and show its width then it is easier to get the same result, or adjust \showboxdepth to show less. if you look at regression-test it has a lot of helper macros to test specific things and just write out enough for that difference to show in the log
@DavidCarlisle hm. doesn't work for me.
@UlrikeFischer with check ? I'm sure that got added a while back didn't it?
16:14
@DavidCarlisle yes, I tried with check. It doesn't work, neither with nor without extension and not in cmd and also not in bash. save doesn't work too.
@UlrikeFischer hmm perhaps we only discussed it:-)
cfr
cfr
16:27
@DavidCarlisle I can't add directory names to sourcefiles, though, can I? actually, I realise I'm not sure quite what I'm meant to be doing here already.
@UlrikeFischer (@daleif) it depends what you want to test. for tagging stuff you want to test the tagging is correct but it's essentially different for each engine, so the seoarate cnfigs make sense. for latex/base when we added luatex support the main thing was to test that lua/xetex gave more or less same outout as pdftex so there was oressure to be able to use the same tlg files even if that meant a very non standard lualatex (using OT1 fonts by default, and some other changes
@cfr ctan don't really like directories, do you mean the top level ctan file structure or a separate .tds.zip file with the installed directory layout?
@cfr sourcefiledir
@DavidCarlisle yes, I quite understand the history. I only meant that it is non-standard and that normally you simply get different .tlg as soon as some \showoutput is involved.
@UlrikeFischer was more for @daleif :-)
cfr
cfr
@DavidCarlisle neither. I mean in the source. build.lua is the only one in sourcefiledir. the others are shared - either in maindir or in a sub-directory of maindir which is the parent of sourcefiledir. (I shouldn't have asked karl what he wanted ....)
@cfr I got lost, but no matter I can smell dinner cooking, so time to go....
cfr
cfr
16:36
and do they really want 6-8 copies of the same files?
cfr
cfr
@DavidCarlisle I'd think?
@cfr why would you have to duplicate files for ctan?
 
1 hour later…
cfr
cfr
17:50
@DavidCarlisle no, sorry. that's not what I meant. I meant: I don't know how to do this so I don't duplicate them (and I assume I shouldn't duplicate them).
@cfr as I say I have lost the mental model of your file layout so I really can't guess the issues any more
cfr
cfr
18:06
@DavidCarlisle that's not really a question, but still:
but it is really that I'm not sure what I'm trying to do. if I include the lua scripts for each package, I'll end up with 6-8 copies of some files on ctan. but that can't be right, can it/
@cfr Hm, you could maybe create some kind of "base" package that just comprises the lua scripts and that is loaded by the "sub" packages ... something like that?
... and I don't know whether this is an "allowed" approach =D
18:25
@cfr but your lua scripts mostly seem to be build.lua we don't normally distribute the build scripts to ctan at all
 
2 hours later…
cfr
cfr
20:34
@DavidCarlisle hmm. yes, like I said, I shouldn't have asked. but it is really the fontinst.lua and font-tables.tex, I think. but those are used by all the packages except nfssext-cfr. so if I add them, ctan will end up with 7 copies of each. (I don't entirely understand the reasoning for wanting them, which is basically that texlive should contain the sources of the software it distributes as free. but this isn't really how free software usually works. at least, not how linux works.)
@cfr well if you want people to be able to install the packages separately you need to duplicate it or make the fontinst.lua a separate ctan package on which the otehrs depend. Or you make them all one big ctan package so they are installed together
cfr
cfr
if I need an unmodified kernel with debug symbols or to patch, I download the headers etc., but I don't get the sources when I update the kernel. I just get the binary. but that's fine.
@DavidCarlisle but they don't need it just to use the package.
@cfr I was just going to ask that, then I wouldn't put it in ctan at all
cfr
cfr
they need nfssext-cfr, but that's true already.
@daleif -- Okay, I've tried some things with amsmath. The one that I though might be promising ts what's suggested in this existing answer, where a \bmatrix ends an align* on the last line of a proof. But with empheq, it fails with "\tag not allowed here. There are things that have been tried and work with amsmath` constructs, such as when a tall graphic ends a proof. I'm looking for those, since I don't remember offhand what was done, and it's not in the documentation.
cfr
cfr
20:40
@DavidCarlisle even if karl wants it? you can't build some of the documentation without it.
as I understand, texlive only accepts documentation with the original source.
@cfr he may not have realised it's not needed at run time. Or as I say if they really want it you could have a separate cfr-build-utilitilities ctan package that just has the build scripts that texlive could dump in the source tree and not install in the input tree
cfr
cfr
@DavidCarlisle yes, I was wondering about that. I don't see the point in inflicting multiple copies of my first attempt at writing a lua script on the world.
@DavidCarlisle I think I'll do that to satisfy the tl requirement for documentation.
@DavidCarlisle thanks.

« first day (5071 days earlier)      last day (82 days later) »