@DavidCarlisle you're welcome :)

@JosephWright when they are asking about editors and the obvious non-subjective answer is clearly emacs?

Ooh, a discussion in the latex3 repo: github.com/latex3/latex3/discussions/1496

@DavidCarlisle you confused something, the hypothetical question was about editors, not operating systems. The answer would then be VIM of course. And since emacs lacks a good editor, even for operating systems one can't really recommend it.

@DavidCarlisle is "Because colour support isn't really built into TeX but added by using \special which outputs a whatsit that might have side effects if used in the wrong place, the \leavevmode reduces the risk of strange things." ok as an explanation to tex.stackexchange.com/questions/712075/… or do you want to comment?

Can somebody explain to me how tuples are implemented in the l3fp package? I tried to make sense of the code, but it is a bit too complicated for me. As far as I understand, tuples are not stored in a special way, rather the existence of a comma in an expression makes it a tuple. In math operations involving tuples, these are then just split up at the commas and the operations are then done with these pars of the tuples via loops. Is this correct?

So, other than using loops, there might not be an efficient way to select a certain item from such a tuple (which is the reason why I ask)?

@JasperHabicht From memory that is right: tuples were a lightweight addition to the core

@JasperHabicht Likely, yes

@JosephWright Seems like \clist_item:Nn (which I would assume being quite similar) also uses a loop. So this would probably really the way to go.

@JasperHabicht All of the expand item functions use loops

@JasperHabicht there's not really another way than a loop I'm afraid, unless you have a hard coded number of elements in your tuple and those are no more than 9.

@JasperHabicht one could think of a data format that would give better performance for really large lists of items, at the cost of roughly 10 * ceil(log10(nmax)) additional control sequences I'd have a plan, but that's a rather unlikely to really be needed.

@JasperHabicht for instance, the following would be accessible in (almost) constant time: \mark1{<element1>}\mark2{<element2>}...\mark9{<element9>}\mark10\mark0{<element10>}\mark1{<element11>}...\mark20\mark0{<element20>}\mark1{<element21>}.... You could then access element 956 by using \use_none_delimit_by_mark:nnw{900}{\use_none_delimit_by_mark:nnw{50}{\use_none_delimit_by_mark:nnw{6}{\check_exists_and_use:n}}}<list>\mark900\mark50\mark6{<non-existent-marker>}.

with \use_none_delimit_by_mark:nnw being defined as \cs_new:Npn \use_none_delimit_by_mark:nnw #1 { \use:c { __use_none_delimit_by_mark_ #1 _aux:nw } } (of course \mark<num> should be a single token)

Right, but I doubt that l3fp should be rewritten in order to support this? I am (as you might have guessed) just thinking about a proper solution to the ”get me the x value of point p” problem :)

@JasperHabicht Well of course there we do know the number of elements we need to allow for, and can arrange to throw away any excess - so we don't need a loop

@Skillmon Clever, but not happening ;)

@JosephWright stop breaking LaTeX because it breaks LaTeX :)

oh wait

@PauloCereda P0000+a000+u00+l0+o

@mickep ooh

@PauloCereda dodos are good at adapting.

@mickep ooh

@JosephWright Well, if we say that accessing coordinate parts from points should be done via l3fp, we will eventually still need to use a loop because l3fp should of course implement a more general way to access items from tuples.

But it wouldn’t matter much, since a loop with max 2 steps is still quite quick.

@JasperHabicht As I said before, if there are good use cases, there's no problem adding to l3draw: it's that I wanted to start small and see what real use cases come up, as there are key differences to pgf

@JasperHabicht If we need fast access to a single component, then that's a perfectly good reason to add something - as I always say, 'use case'

@JosephWright Debian might be relevant because the only two differences between the old, correct PDF/PS file and the newly generated PDF/PS file is half a year of updates or upgrades of TeX Live, both as Debian stock packages and in the current online repository of TeX Live 2023. Unfortunately, I don't know which of the two I used on July 20, 2023. Probably, the Debian stock packages, too. Stock TeX Live in Debian was happy with SymbolMT in the same EPS file for one and a half decades.

@AlMa1r You can mention Debian in the body of your question, it does not have to be in the tags if you are running out of tags.

preparing a presentation here, not very knowledgeable about latex,

i'm scared that the aspect ratio may be different to my presentation as I see it in my laptop

@JosephWright One more thing changed: I uninstalled the Debian package ttf-mscorefonts-installer and linked the native Windows fonts from my Windows partition instead. So, hypothetically, the change might also be not mainly related to Debian.

@samcarter Done so already.

@Minsky If you show your presentation with the presentation mode of your pdf viewer, it should show the whole slide regardless of the aspect ration (will add empty space around it). How to make sure your images fit in the slide will depend on how you include them.

atril doesn't display well though, maybe it's the pdf viewer (approx 1/10th of the slide is off view)

@Minsky try another viewer?

yes i'll do. browsers work well but they do not have --fullscreen flag

just to be clear, you'd advice not to use the aspect ratio keyword /option right ?

@Minsky no. If you know the aspect ration of the venue in advance, you can use it to tailor the layout of your slides to it. However if your slides aren't the correct aspect ration, then the pdf viewer should still show the completely in presentation mode.

it's for a job interview, i wonder whether i should ask that technicality, they'll be unhappy i think

169 should be a good for most venues

if i don't put 169, what is beamer doing ? taking the AR from my monitor ?

@Minsky 4:3 is the default

@samcarter Can't show evince bookmarks?

using xrandr seems both monitors are also 16:9

@UlrikeFischer No idea. I'm not near a machine with evince at the moment. I can try to find one tomorrow.

seems to have improved a lot thanks @samcarter, i just adjusted the images from the includegraphics command. I wonder if I should have some if/else condition that creates a multiplier for the include graphics width based on the aspect ratio.

@Minsky As said above: how to adjust images to the aspect ration will depend on how you include them

@Minsky Try something like \includegraphics[width=0.7\textwidth,height=0.7\textheight,keepaspectratio]{./images/actions.png}

@AlMa1r A debian tag would be specific to Debian: almost certainly the important thing here is your TeX Live version

@AlMa1r That's likely 'you didn't have the fonts', which again isn't platform-specific

@UlrikeFischer thank you so much

@JosephWright Alright. I already found one, will add more if I encounter them to the issue at GitHub. I‘ll try to carefully evaluate whether this really can’t be solved in a feasible way using tuples. =)

You are totally right! This is what discussions are for

@JosephWright of course not. Also, it'd be hard as where to draw the line... For sequences this could be defined dynamically at a very low overhead, but tuples aren't assigned but have to be built expandably and retrieved expandably, so would need a hard decision on which is the highest number of elements supported. With pdfTeX and XeTeX this could be rather easily decided (there is a hard maximum, at least for default memory settings), but LuaTeX with dynamic allocation proves to be difficult :)

@JasperHabicht the loop has <n>/8 steps, I'd estimate (or at least the one I'd code would've)

@UlrikeFischer Just checked: evince shows bookmarks just fine (they call them outline)

@JosephWright I likely had a font advertising itself as SymbolMT in July 2023, and I have such a font now: ttf-mscorefonts-installer was very likely installed then and is installed now. Meanwhile, I updated some Debian TeX-Live packages from Trixie into stable (to get unrelated bugs fixed); SymbolMT might have disappeared in the process. Another possibility is that apparmor or the Gnome font manager don't like the symbolic link to /my_Windows_partition/Windows/Fonts/. Both are related to the OS.

@AlMa1r That sounds like tagging the answer not the question ;)

@JosephWright Possible. Frankly, I don't know.

@samcarter Lovely clean document design. Much better than those messy beamer themes.

@DavidCarlisle Themes just distract from the intrinsic beauty of beamer :)

@samcarter thanks for confirming that.

@UlrikeFischer You're welcome!

@Skillmon Phew, nested tuples ... how to properly loop then? I really wonder how \__fp_tuple_map_o:nw works. Just too :weird for me