@LaTeXereXeTaL Yeah, I must have missed that bit. :p

(sorry, internal unix joke)

quack

baa!

ooh a sheep

@PauloCereda @Plergux chat.stackoverflow.com/transcript/message/51097118#51097118

@CarLaTeX LOL! It's a sheep in ducks clothing :D

@Plergux lol!

@CarLaTeX Maybe it's trying to get at the bread. :p

@CarLaTeX WAIT WHAT

@Plergux as in "I is duck, give bread"? :)

@PauloCereda Exactly. There is an Icelandic writer/poet who has actually written a poem about a sheep that thinks it's a duck! :D Let's see if I can quickly find it...

@Plergux Or s/he is wondering "how wacky is my human daddy/mommy?"

@Plergux ooh

@Plergux oooh

Very quickly and badly translated. In Icelandic it's got rhyme and stuff. :p

@Plergux Maybe you could post the Icelandic version too?

(and also done from memory cause I couldn't find the book :p)

@Plergux oh. I see

@Plergux ooh this is disturbing and epic at the same time

@HaraldHanche-Olsen Ok, I'll see if I remember it correctly.

ooh I understood bra and mee

Icelandic level UP!

*correction "Sem hélt hún væri ÖND en síst nein rolla" obviously XD

The name is a play on the Old Norse Heimskringla, to be read Heimsk-Ringla, i.e. 'stupid and confused' (rather than Heims-Kringla 'world round').

I actually had one of those mis-parses yesterday where LaTeX split "relationship" in my abstract as "relations-hip" XD

@Plergux ooh \usepackage[shakira]{babel}

@PauloCereda LOLOLOL

@Plergux isaksskoli.is/wp-content/uploads/2019/11/… second page, bottom left

@HaraldHanche-Olsen Thank you! Your google-fu is strong :p

@Plergux I just used the first line. Fortunately, you remembered it well.

@HaraldHanche-Olsen Lol, I didn't think of that XD Well, I haven't finished my coffee yet. Brain not working :p

@Plergux I got curious about the word “heimsk”. We don't have that in modern Norwegian, but I recognised anyhow, from Swedish “hemsk”.

@HaraldHanche-Olsen It's literally 'always staying home' (heim-skur), i.e. ignorant.

@PauloCereda @HaraldHanche-Olsen some people I know sent me their mis-parse data cause I was interested, and of course I couldn't resist being silly... :p

@Plergux LOLOLOL

and, of course my favourite... :p

/dies of cuteness

@Plergux your comics are adorable!

@PauloCereda thanks :)

@Plergux waters pout? And seen in a Norwegian newspaper: svangerskap-spermisjon.

(I don't know the English word for those letters, typically an s or an e, used to join words together. In Norwegian: fuge-s and fuge-e.)

@HaraldHanche-Olsen That Norwegian one is a right old mess! XD

@HaraldHanche-Olsen I know what you mean, we have them too. Usually s, a, or u. :)

@Plergux :)

@Plergux Yeah. NSFW and all that.

@Plergux I don't know if newspapers even employ typographers anymore. I think it's a long time since they stopped having proofreaders.

@HaraldHanche-Olsen :( And they probably should have employed more when they started lifting it all off the internet :|

@AlanMunn pronoun.is/vi/vim/vim

@DavidCarlisle Would you have some time to explain some of the internals of revtex's front-matter handling?

I understand you did much of its development

I'm having a go at writing a package to add author ORCID IDs

In more specific terms, I would like to understand how the \@author variable (command?) works

i.e. how it is initialized, how it's modified, how it can be read out, and how it gets re-set to blank after each author's name has been handled

(for now I think the best approach would be to add a parallel variable with similar behaviour, absent an overhaul of revtex that modifies that data structure.)

@EmilioPisanty well I did an initial prototype but then ran out of time and someone else took over but I'm mostly not online for a couple of days, you are probably bets just to post a question on site

@LaTeXereXeTaL you should certainly take ABC from the same font

@JosephWright A new release of l3kernel also today? Petra will be glad!

@egreg ooh

@egreg I heard David has one of those red telephones with a direct contact line with CTAN. :)

@DavidCarlisle Fair enough! many thanks =).

@egreg :)

 Unprocessed Uploads
2020-12-07-11-52-45-469-albatross

ooh

@DavidCarlisle Yes I agree.

@JosephWright ^^ BOO

@PauloCereda Another day, another uploiad

@JosephWright BOO

for completeness =)

@AlanMunn Ah right. Well, the UI is not really fortunate. It searches within the current file only, and it is I think strictly lines-only.

@DavidCarlisle no complaints from CTAN, today is a good day. :)

@JosephWright not sure if you saw the dvipdfmx message: \__pdf_backend_link_last: can now be implemented for xdvipdfmx too. On my system it works fine, but if I run the following in tl19 the annot object is missing in the pdf. Can you test on tl20 in a linux system? If it works there one could put it in the pdfmanagement code for now, this requires a new system anyway.

\documentclass{article}
\usepackage{l3pdf}
\ExplSyntaxOn
\pdf_uncompress:
\int_new:N \g__pdf_backend_link_int
\cs_set_protected:Npn \__pdf_backend_link_begin:n #1
  {
    \int_gincr:N \g__pdf_backend_object_int
    \int_gset_eq:NN \g__pdf_backend_link_int \g__pdf_backend_object_int
    \__pdf_backend:x
      {
         bann ~ @pdf.obj \int_use:N \g__pdf_backend_object_int \c_space_tl
         <<
           /Type /Annot
           #1
         >>
      }
  }

\cs_set:Npn \__pdf_backend_link_last:

@UlrikeFischer As we are talking pretty experimental, just add it? I will try it out over my lunch break (a few minutes yet)

@UlrikeFischer No link for me

@UlrikeFischer Ah true

@PhelypeOleinik I feared so. What do you get from xdvipdfmx --version?

@UlrikeFischer But only if they are using our code? Or do you mean generally?

@UlrikeFischer Doesn't it only activate it you use the experimental code?

@UlrikeFischer This is xdvipdfmx Version 20200315 by the DVIPDFMx project team,

@JosephWright yes, but if we restrict the experimental code to "windows only" I fear someone will blame me ;-)

@PhelypeOleinik yes, clearly too old. Perhaps I should reactivate the idea with retrieving the version with ??? (or whatever we had there)

@UlrikeFischer That looked good to me (as far as I can remember). It would be nice if TeXLive would update its binaries more often than once a year though

@PhelypeOleinik I meant extractbb not epstopdf.

@PhelypeOleinik On windows I get more updates. My xdvipdfmx is from 20201111.

@UlrikeFischer Mac binary is the same as Linux

@UlrikeFischer Still the only people who would be impacted are those using experimental PDF support, no?

@PauloCereda :)

@JosephWright yes, if we put it in the extra backend files I wrote (the natural place would be l3backend there you already have a stubs for \__pdf_backend_link_last:).

@UlrikeFischer Extra files?

@JosephWright the new backend commands (the stuff that still depends on zref).

@samcarter_preparing_for_xmas twitter.com/NintendoUK/status/1335947169166188544

For Northern Hemisphere players

/cries

@UlrikeFischer Ah, right

@PauloCereda :D will you get this in August on your Hemisphere?

@samcarter_preparing_for_xmas nah, we don't exist for them. :)

@PauloCereda Ohh no!

@samcarter_preparing_for_xmas :)

Interesting Twitter thread: twitter.com/KhaledGhetas/status/1335932287075094528

@JosephWright hmmm Adobe

@PauloCereda Yes, point being they are using HB

@PauloCereda As are 'we' (After a lot of effort from Khaled amongst others)

@JosephWright a bit difficult to understand without more context.

@UlrikeFischer I read back: complaint was that it's hard to test if Adobe have fixed Arabic shaping, and then moved to the fact they use HB but not for Arabaic

@UlrikeFischer Honestly, I think we just add it there and accept that we'll have a few months having to say that the dvipdfmx routes need a bang-up-to-date backend as we are pushing the feature set to the max (same with color spaces)

@JosephWright we can simply add a version test around with a suitable small default. Then everyone having a newer one only need to set it to a higher value (and I can add some tools/keys to do this, manually or by calling extractbb):

  {
         bann ~
          \int_compare:nNnF { \g_sys_dvipdfmx_version_str } < {20201111}
           {
             @pdf.obj \int_use:N \g__pdf_backend_object_int \c_space_tl
           }
         <<
           /Type /Annot
           #1
         >>
      }

@UlrikeFischer Would work: do we have that version string set up?

@JosephWright no, I just made it up ;-). l3backend could do something like the following, and then I could think how to get timing right to reset the value:

\str_new:N  \g_sys_dvipdfmx_version_str  %Name?
\str_gset:Nn\g_sys_dvipdfmx_version_str {0} %or whatever

\int_new:N \g__pdf_backend_link_int

\cs_set_protected:Npn \__pdf_backend_link_begin:n #1
  {
    \int_gincr:N \g__pdf_backend_object_int
    \int_gset_eq:NN \g__pdf_backend_link_int \g__pdf_backend_object_int
    \__pdf_backend:x
      {
         bann ~
          \int_compare:nNnF { \g_sys_dvipdfmx_version_str } < {20201111}
           {
             @pdf.obj \int_use:N \g__pdf_backend_object_int \c_space_tl

(an int would naturally work too, I can never decide what is better ...).

@UlrikeFischer Should I do it or will you?

@JosephWright I'm unsure how to distribute the code. The initialization of \g_sys_dvipdfmx_version_str should then go into l3sys? Is the name ok?

@UlrikeFischer I'll take it: I'll just risk it :)

@UlrikeFischer Later today for me, then

@Plergux -- You know that when you encounter such a mis-hyphenation (in English), you should report it to me, to add to the growing exceptions list. (See the hyphenex package at CTAN.) I'm actively updating it now, and will add this.

@UlrikeFischer I'll think about it a bit then add

@Plergux -- Actually, with the default U.S. English hyphenations, this is correct (re-la-tion-ship), but the principle re reporting holds. A published update is scheduled for the next TUGboat issue. (The cartoons of other glitches are delightful.)

COUNTDOWN TO WINTERBASH 2020 don't let coV dampen your spirit

@skullpatrol Oh Deep Joy

:D

@skullpatrol Emergency Temporal Shift

Is this the hat thingy?

@PauloCereda yes

@PauloCereda You saw my response, you guess :)

@PauloCereda yay, finally some hats

@Skillmon ooh

I managed to be alive at the right moment, again.

@barbarabeeton Ok, I will let you know :)

> Medal of Honor: Above and Beyond requires more than 177 GB of storage

@JosephWright ^^

@PauloCereda Wow!

@PauloCereda and I thought having 3 TeX Live installations was a waste of space...

@Skillmon ooh

@PauloCereda Yeah, I'll just stick to West of Loathing, thanks. :p

@Plergux :D

@barbarabeeton in the latest Simpsons episode, aired yesterday, the last scene shows Lisa as a teen in her dorm at Yale. Outside, there's a group of barbershop singers annoying her:

[Barbershop singers, singing] She's got a huge college debt!
[Lisa, yelling at them] Please, I am trying to study!
[Barbershop singers, singing] Then go to Brown!

@Plergux -- Good. (You might like to know that "eggshell" has been added, not because of a bad hyphenation, but for no hyphen. That's also a reason.)

@PauloCereda -- Well, in the Brown bookstore, I've seen a t-shirt "Harvard, for someone who can't get into Brown". I've been sorely tempted to spoof the Harvard shield by revising the motto as "VA-NI-TAS". (But if I had gone to college in Boston, it would have been to MIT.)

@barbarabeeton ooh! :)

@Skillmon LOLOLOL

So the TUG Twitter account announces an update to the l3kernel (which was processed after IoT's), but no mentions of our new tool... :(

Gosh, it's behind 2 days?!

@PauloCereda Always seems to be a bit random

@PauloCereda Should I tweet them>

@JosephWright And it seems to not rely on on ctan-ann neither... they just posted about babel-japanese.

@JosephWright no

@PauloCereda Cool

@barbarabeeton Ok, like if there is an overfull box and I'm like "Y U NO hyphenate dis!" :p

@JosephWright I just got the l3kernel update but the formats were not recreated?

@UlrikeFischer Ooops

Quack, dinner, Baa, pineapple, blame @UlrikeFischer, @PauloCereda's thesis. Did I miss anything?

@LaTeXereXeTaL spot on. :)

@PauloCereda Excellent.

@Plergux -- Yes! But only if it really can be hyphenated. Some quite long words aren't; more and more chemical terms are being reported, and names of peple and places also. Often, those don't follow the patterns of the "local" language. Look at the file tb0hyf.pdf in the ``hyphenex` package on CTAN; It shows what TeX does (with U.S. patterns) and what should happen for the same word.

@LaTeXereXeTaL ooh

@LaTeXereXeTaL and déjà vu. Oddly, the “you are mean” meme seems to have faded into teh bacground. (Misspelling credit: @DavidCarlisle.)

@UlrikeFischer Checkin coming up

@UlrikeFischer I'm going to keep the data internal for the moment

@HaraldHanche-Olsen Noted!

Now that I have vimtex working in Vim, what other plug-ins might I find uselful, particularly for LaTeX?

I have to say that I like Vim.

@barbarabeeton Ok cool :D

@UlrikeFischer Setting up the test files now ... I guess I'll look at color as well soon

@JosephWright you mean the version str? fine with me as long nobody complains when I change it outside the module ;-)

@UlrikeFischer For the present, I'm going for internal, and we can look again if we need it

@PhelypeOleinik wanna shed some light in tex.stackexchange.com/questions/574038/…? I already gave a minimalist comment.

@UlrikeFischer Keeping it internal means everything falls inside l3backend; should keep Petra happy! (I'll look at color this evening before a release)

@JosephWright with color do you mean the colorstack business or something else?

@UlrikeFischer Color spaces

@JosephWright right, there was some code depending on a new xdvipdfmx too. I think a version test could be quite useful in more than one place in view of the development there.

@UlrikeFischer I'm still thinking about color stacks: at the present I favour keeping internal and seeing if we need public interfaces

@UlrikeFischer Exactly

@UlrikeFischer I might have to remind myself what, but part of that was multiple color stacks, so it all fits

@JosephWright sorry to bother, but any consensus on tex.stackexchange.com/questions/573812/… yet?

@JosephWright would be fine with me, I only want to move the backend dependant code out of (new-)transparent.

@UlrikeFischer Sure: I guess I'm assigned to do this :)

@Skillmon The n-type expandable functions are relatively 'new': we originally had just N-type expandable (e.g. \tl_map_function:nN) and n-type non-expandable (e.g. \tl_map_inline:nn); that's why we have fewer of the 'map_tokens' ones

@skullpatrol Any way to check whether I'm still opted out? I don't wanna ye akin hatz.

@JosephWright yes, I know. My question was more: Did any conversation in the team happen whether you'd favour \keyval_parse:nnn over \keyval_parse:NNn. I volunteer to implement it, but it doesn't make much sense to maintain both concurrently (so that I'd just use \cs_new_eq:NN \keyval_parse:NNn \keyval_parse:nnn for backwards compatibility).

@Skillmon I think 'team' here comes down to '@DavidCarlisle and Joseph' - Frank will only worry if there is a problematic performance hit. I'm happy to merge a PR when one turns up :) (We probably should provide map_tokens for all-the-things)

@JosephWright (implementation would likely take me until New Years Eve, menukeys is already in the queue and waiting for me to find some time -- also I have to decide whether \ekvparse should support n-type as well or not)

@Skillmon I'll look forward to it: I guess the other 'resident' team members have no objections :)

@JosephWright performance hit is already measured. \keyval_parse:nnn will be about roughly 4-5% slower than \keyval_parse:NNn. Compared to the speed up due to my expandable implementation this is a small step back. And if I'm allowed to consequently introduce pre-expansion of things like \__keyval_trim:nN and port back some other changes I did in expkv, I might even be able to net-gain a bit of speed while supporting the n-type argument compared to the current keyval implementation.

@Skillmon I think the 5% we can live with; Frank won't be keen on too much pre-expansion

@JosephWright the current implementation of exkpv (with patched in n-type support) is 36% faster than \keyval_parse:NNn (but one has to consider the fewer tests exkpv enforces, namely no error is thrown on blank key-names in \ekvparse, and no error is thrown on two top-level = signs).

@JosephWright understood. Will see what I can achieve (I hope that the net effect will be at least as fast as the current \keyval_parse:NNn, even without all the pre-expansion).

@Skillmon If we need performance, we can argue that toss later

@JosephWright I think a \cs_new:Npo (and friends) wouldn't hurt in l3basic (Bruno even had mentioned interest in more functionality to pre-expand certain functions; but I doubt he'll follow that road just now). What I'd love would be some functionality in l3docstrip for pre-expansion (and while at it, named parameters like @PhelypeOleinik's namedef).

@Skillmon That's all interesting, but it's Frank's domain not mine ;)

@JosephWright I know, and I fear nobody really has the time for it, right now.

@Skillmon Certainly we have some stuff on :)

@JosephWright yep, and real-life got me covered.

@Skillmon I guess you might want to look at l3ldb and l3precom: Frank et al. have in the past looked at some pretty nifty performance stuff, but at a rather different stage (the idea being to avoid repeatedly prcoessing material)

@JosephWright maybe I should. Is it in experimental?

@Skillmon Trial

@Skillmon It's, er, pretty out-there

@Skillmon precom is in leftovers.

If I wrote a PR with \keyval_parse:nnn, what would be the correct thing to do with \keyval_parse:NNn? Move it to deprecated?

@Skillmon Probably just retain

@UlrikeFischer Oh, yes: I was mixing things up

@Skillmon It's been around a long time: I don't think we could really risk dropping it

@Skillmon Not much light to shed there. The user should move the class to a searched path or use one of the proposed workarounds (there's one in the linked issue). That or wait for the patch release. Thanks for pointing it out!

@Skillmon I've been working on something like that, but then thesis: exists

@Skillmon I don't even remember what I had implemented

@UlrikeFischer I remember now: what I wanted to alter in the backend was color support in drawings. The latest dvipdfmx can do foreground/background in the dedicated specials, so we might be able to move all color onto the stack. But I was stuck on dvisvgm: I can't use @DavidCarlisle's PostScript trick (a la dvips)

@UlrikeFischer Might also be worth discussing with @HenriMenke: if we can pull of using the color stack for all color, it could be ported to pgf too

@JosephWright port more dvipdfmx specials to dvisvgm ?

@DavidCarlisle That was my though too

@DavidCarlisle @UlrikeFischer I'm wondering whether just to change the code and say 'dvisvgm might not work properly: tough'

Just come back online in time to see my name being pinged:-)

@JosephWright is it worth to discuss it with the dvisvgm maintainer?

@JosephWright github.com/mgieseki/dvisvgm has had checkins within last few days so seems actively developed..

@DavidCarlisle yes, he is also here on tex.sx and sees e.g. questions.

@UlrikeFischer Yes, I guess so

@UlrikeFischer User name?

@Martin Could we talk about a few additions to dvisvgm?

@UlrikeFischer Mod ping time

@JosephWright but last seen end of november ... so perhaps a github issue would be an idea too.

@UlrikeFischer On the color/graphics stack, I think the main decision is a name: I'm not sure I can readily abstract in a cross-engine sense, so something like \g__kernel_color_stack_int

@UlrikeFischer Ah, right

@UlrikeFischer Ok, what's missing? Foreground/background color, color space support (?), color stack?

Looks like Bruno is going to sort regexes for document commands: github.com/latex3/latex3/issues/820

@JosephWright I have no idea ;-) svg is not pdf and so it is quite outside my radar (I hope I won't have to add lots of missing backend commands here ...).

@UlrikeFischer Hmm, it's all tricky as like you say it's entirely different

@JosephWright in most cases I assume they should simply do nothing at all. graphic and color is different, but what else should matter? Or do you know other pdf commands which make sense for svg too?

@UlrikeFischer At the moment, it's just color: I think I'll hack about a bit first

@UlrikeFischer , @JosephWright dvisvgm speaks Postscript, so I wouldn't put effort into graphics and colour, but let @Martin decide.

@AlexG OK, I'll test a few things out

@MarcelKrüger I looked at this tex.stackexchange.com/q/574047/2388, and it fails with the dev branch in texlive too, but with a different error: ! error: (linebreak): invalid node with type glue found in discretionary. Something is wrong in harf mode with this font.

@UlrikeFischer Yes, I just seen it. Does it work for you (in any branch) if you load amsthm later?

@MarcelKrüger in dev it breaks without amsthm, simply this:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{CharisSIL}[Renderer=HarfBuzz]
\begin{document}
Harmless definition
\end{document}

@MarcelKrüger in miktex the amsthm example errors always. I can't reproduce the claim, that changing the order should help.

@UlrikeFischer Ok, that's what I got too with TeX Live.

@MarcelKrüger what was the way to see the luaotfload files in the log?

@UlrikeFischer LUAOTFLOAD_TRACE_SUBMODULES=1 lualatex-dev ...

@UlrikeFischer Or whatever weird incantation you need in Windows to set the environment variable LUAOTFLOAD_TRACE_SUBMODULES to 1.

@MarcelKrüger the version info is confusing I get 3.16-dev in dev, but an earlier date.

@UlrikeFischer (@DavidCarlisle) I've been looking at the dvipdfmx colour stacks and stroke/fill support. I think the best plan is to align dvipdfmx with pdfTeX for colour, provided the backend is new enough. I see broadly how to do that: happy for me to adjust?

@UlrikeFischer (@DavidCarlisle) I'll probably do that first, then address generalising the colour stack support so we can handle transparency (@AlexG)

@DavidCarlisle (@UlrikeFischer) I'm left wondering if we should back-port to graphics-def at some point

@JosephWright back port or just make graphcs use the l3 backend?

@DavidCarlisle Well that would be good, yes, but I bet some plain users would complain (graphics-def doesn't need e-TeX, etc., I think)

@JosephWright sure.

@UlrikeFischer I think I've re-written colour support more than just about anything else ... every time a new concept comes up, I have to re-work the entire thing :) (@DavidCarlisle)

@JosephWright well if necessary I can cut the graphics-pln loose from latex, just as when we stopped distributing auto-pic I put a copy in the plain distribution.

@UlrikeFischer Might take a couple of days

@DavidCarlisle Hmm, at some stage, yes: I guess once we tie down a few things for graphics (colour is basically done: the adjustments here are all new features)

@DavidCarlisle We might also want to talk more with @HenriMenke: the backend colour improvements could/should show up in pgf (though that might be ... fun)

so basically freeze graphics def just for use for graphics-pln and keep a frozen graphics.sty that uses that

@UlrikeFischer The dev issue is fixed and the original issue doesn't happen in dev either.

@MarcelKrüger we probably should try to make a release in the next days. Is there anything open in the branches?

@UlrikeFischer Probably, even though I still don't really trust the new harf discretionary code. We should be prepared for a hotfix release if necessary. There is nothing in the branches which is relevant for this release.

@MarcelKrüger well now that polyglossia forces harf mode, we get more tester here ;-) Is there anything that needs to get documentated?

@UlrikeFischer The entry point is called luaotfload.lua instead of luaotfload-main.lua(but the old name is still provided for compatibility), we have pre/post_shaping_filter callbacks and we are now generating first/second discretionaries which will confuse everyone who looks at \showoutput lists or similar, everything else should be internal and/or bug fixing.

@MarcelKrüger should we change ltluatex.dtx to require luaotfload not luaotfload-main ?

@DavidCarlisle The plan is to keep loading luaotfload-main for now, and switch to luaotfload after some tme when we can be reasonably sure that everyone has a sufficiently updated version.

@MarcelKrüger sure but in develop probably everyone has an up to date system. (Nice change by the way: the naming confused me when we first started to pull it in to the format and not rely on the existing latex package)