can somebody tell me if it matters whether encoding subsets for ts1 are declared in sty rather than fd files? I noticed ltnews complains these haven't appeared in packages' fd files, but I'm struggling to think why that might matter. (as far as I know you could do all the font declarations in the sty, provided you didn't want to load the fonts independently of the package. but is independent loading the only reason?)

@cfr the complaint in ltnews is that subset declarations are missing generally. But beside this: fd is better as you can always load a font directly with the font family name and ignore the sty.

@cfr I think generally it's better to use fd for defaults, as @UlrikeFischer says people might access the font directly. Declarations in a package are most useful when you want a package to change to defaults (like fix-cm providing alternative declarations for cmr)

LaTeX2e 2024-11-01 dev release 4 at CTAN

@UlrikeFischer @DavidCarlisle the problem is that many .fd are automatically generated, whereas .sty usually are not.

@cfr well generating fd isn't a problem if they are for a new font family (as presumably set up in a package) they are only an issue if (likefix-cm) you need to distribute custom declaration for an existing family (as texlive really doesn't like having duplicate filenames)

@UlrikeFischer Using documentation to answer questions? Where did you learn that? :P

@samcarter Yes I was going to complain about that as well. shocking behaviour.

@DavidCarlisle Hola, I can appropriate the phrase "compatible with PDF tagging" for a package description if after many tests with lualatex-dev and verapdf everything seems to be OK?

@PabloGonzálezL yes

@PabloGonzálezL I would add "any tagging errors are not my fault and blame @UlrikeFischer" but you may wish to omit that part.

@DavidCarlisle Great, I guess I'll just wait for the official release :D

@DavidCarlisle I'll put that in the abstract :D

more seriously once it is released you could submit a small test file and get it listed as compatible at latex3.github.io/tagging-project/tagging-status/full

@DavidCarlisle The temporary repository is github.com/pablgonz/enumext-tmp

@DavidCarlisle The file enumext.pdf has the tagged PDF examples embedded ... If you have time and can give me your opinion I would be grateful.

@PabloGonzálezL I have no time at all for a couple of days but may look later

@DavidCarlisle Thank you very much, having your opinion would be great :D

@DavidCarlisle By the way, the new footnote code for tagged PDF allows using footnotetext/footnotemark with hyperref support... Will this be ported to the hyperref package or will it still have this limitation?

@PabloGonzálezL ask Ulrike (I haven't been following that in detail) Longer term most likely hyperref wont be needed at all if you have enabled tagging so perhaps the question won't make sense but short term both will need to work together

@DavidCarlisle I understand that hyperref will eventually not be necessary, but changes take time and it would be great if support with and without PDF tagging behaved the same way.

@DavidCarlisle I like this tagged PDF thing, but there is still a lot to do, it took me a while to understand what it is about and it is great, but many packages need to be adapted and I think that will take a long, long time.

@JosephWright By the way, will siunitx have support for tagged PDF?

@PabloGonzálezL not quite sure how you mean that. If you use the new footnote code it properly supports hyperref. So the question should be if the new footnote code will at some time replace the existing one.

@PabloGonzálezL well yes but look at how many "compatible" packages are in that url i just gave, we are ahead of where we thought we'd be with contributed packages

@PabloGonzálezL Yes, that's on the agenda but waiting a little yet as I'm not totally sure what to produce (I can adjust things, but I'd rather not make multiple changes)

@UlrikeFischer I'm more on the side that when using footnotemark with hyperref without tagged PDF, no links are created

@DavidCarlisle Yes I have fixed it, but some are missing like enumitem which is quite commonly used...although my new package achieves almost the same thing :D

@JosephWright Oh...that will be great :D

@PabloGonzálezL There's an issue logged and I know it needs doing - but as we are actively working on math mode, I'd like to see what happens about 'intent', etc., before moving forward

@PabloGonzálezL I get a link:

\documentclass{article}
\usepackage{hyperref}
\begin{document}
abc\footnotemark{}
\vspace{10cm}
bbb\footnotetext{blub}
\end{document}

@JosephWright But is it on your 2024 planes?...or will that debut in 2025?

@UlrikeFischer hyperref-doc pag 56 say NO ...mmm

@PabloGonzálezL Not for 2024, no

@PabloGonzálezL I think I need at least one more LaTeX kernel update to be out first before really looking at this

@JosephWright We will have to wait...stay tuned

@PabloGonzálezL the core tagging list code covers a lot of enumitem (and may cover more by the time its done)

@DavidCarlisle Indeed - Frank checked some stuff in for dev-4

@PabloGonzálezL Indeed - it's very much on my to-do list, but not right now - we have general math mode to talk about more first

@DavidCarlisle sorry, but I'm not sure I follow that. most of the .fd I distribute are generated. they do not contain encoding declarations for ts1. I added declarations into the package files. if somebody loads the fonts directly, they will obviously not get those declarations. it makes no difference, as far as I can see, whether the families are new or not.

@DavidCarlisle Yes, I have looked at it since you gave me the link to latex-lab, although I prefer the more classic code for the lists (I have never understood xtemplate)

\documentclass{article}
\usepackage{hyperref}
\begin{document}
abc\footnotemark[3]
\vspace{10cm}
bbb\footnotetext[3]{blub}
\end{document}

@PabloGonzálezL these are when you have two footnotemarks. Then it goes bad. But you do not need the full tagging code to avoid the problem. Simply the part that reimplements the footnotes:

\DocumentMetadata{testphase=new-OR}
\documentclass{article}
\usepackage{hyperref}
\begin{document}
abc\footnotemark{}
\vspace{10cm}
xxx \footnotemark{}

\addtocounter{footnote}{-1}
bbb\footnotetext{blub}
\stepcounter{footnote}
\footnotetext{aaa}
\end{document}

@UlrikeFischer Haaa...I get it...what happens is that I use the \footnotemark[...]| \footnotetext trick to redefine footnote and remove it from minipage, and I found it novel to see that the new code has support for these cases :D

@PabloGonzálezL the problem is that to create a link hyperref must now the target name. But you can not simply use the footnote number as name as they are often not unique, e.g. with per page footnotes or if there are minipages or similar. The new code tries to keep track which mark relates to which footnote. As long as the mark command if before the text command it normally works.

@UlrikeFischer And considering the order limitation... could it be implemented directly in hyperref?

@PabloGonzálezL The relationship between mark and text is something the kernel has to provide (the tagging code needs that too). It is not a hyperref task. If the relationship is known and correct both hyperref and tagging can use it, if not both have problems.

@samcarter ooh more secrets <3

@PauloCereda are frogs also good at secretes? All the frogs in the secret might otherwise give it away :)

@samcarter ooh frogs are not good at secrets because they think they are cool :)

@PauloCereda frogs don't cry!

(there is a song by a German band called "Frösche weinen nie")

@Skillmon ooh Germans have everything

@PauloCereda the song is about torturing frogs in order to make them cry...

@Skillmon oh no

@PauloCereda oh no, secrets are in danger :)

@Skillmon don't you have one about ducks?

@PauloCereda the band is known for making almost-non-sense funny songs. They have a very nice song about being a contracted killer for the mafia as well: youtube.com/watch?v=yGNmgKwoy_I

@DavidCarlisle oh no

@DavidCarlisle they also have a song about sharks, but none about ducks as far as I know.

@DavidCarlisle they have this one

There is one about marzipan and tooth ache on the melody of Lady in Black as well. Many great songs, unfortunately only funny if one understands German. So should be no problem for an esteemed linguistic like @DavidCarlisle

WHAT

Turning melons into an ocarina consort. Pretty amazing!

@DavidCarlisle I was trying to figure this out on the bus, but I came to the conclusion I have no idea what you mean at all. how are duplicate file names related? generating fd is a problem for me if I'm meant to get encoding declarations into the fd files because the generated files don't contain any such declarations. there's no problem putting them in sty files. I just edit the .dtx. but I can't do that for most .fd.

@PauloCereda @AlanMunn just me or is that both amazing and insane?

@cfr I don't understand how you are generating or not fd files, but by duplicated files I was comparing with fix-cm package that is declaring the cmr family but does not use fd files as they would have names like ot1cmr.fd which would then duplicate the existing ot1cmr.fd so the declarations are just in a package to over-ride the defaults as set up by the fd files. So "duplicates" are only an issue if you are redeclaring an existing font family, not if you are declaring a new one

@cfr oh did you mean just literally the encoding declaration with \DeclareFontEncoding ? I thought you meant the whole fd set of declarations. Ignore me then.

@cfr but \DeclareFontEncoding is usually in an <enc>enc.def file?

@PauloCereda c and @AlanMunn -- I wonder how many other melons were needed to get the holes in the right places to produce the proper notes? (I think he must have done this before.)

@DavidCarlisle oh, that's what you meant. ok, I did not get that at all before!

@barbarabeeton Most certainly, as there is an older video in which he does the same for Africa by Toto on sweet potatoes.

@DavidCarlisle I mean \DeclareEncodingSubset{TS1}{<family>}{<subset>}%. so latex news says these should be added to .fd files. I added them to .sty` files. adding them to .sty is easy because that's just generated from the .dtx. but the .fd are (mostly) not written by hand. they are generated as part of the font support package e.g. by fontinst. so adding declarations there is harder. I am wondering whether it is reasonable to leave them in the .sty files.

@cfr ah ok hmm no existing uses are in an fd file are they (was that a typo in ltnews? I'll read what it says but:

$ grep -l DeclareEncodingSubset /usr/local/texlive/2024/texmf-dist/tex/latex/base/*
/usr/local/texlive/2024/texmf-dist/tex/latex/base/latex.ltx
/usr/local/texlive/2024/texmf-dist/tex/latex/base/latexrelease.sty
/usr/local/texlive/2024/texmf-dist/tex/latex/base/textcomp-2018-08-11.sty
/usr/local/texlive/2024/texmf-dist/tex/latex/base/textcomp.sty

@DavidCarlisle I know. that's actually why I put them in .sty files originally. generally following the standard pattern is safe,

or wider search:

$ grep -Rl DeclareEncodingSubset /usr/local/texlive/2024/texmf-dist/tex/latex/
/usr/local/texlive/2024/texmf-dist/tex/latex/algolrevived/algolrevived.sty
/usr/local/texlive/2024/texmf-dist/tex/latex/base/latex.ltx
/usr/local/texlive/2024/texmf-dist/tex/latex/base/latexrelease.sty
/usr/local/texlive/2024/texmf-dist/tex/latex/base/textcomp-2018-08-11.sty
/usr/local/texlive/2024/texmf-dist/tex/latex/base/textcomp.sty
/usr/local/texlive/2024/texmf-dist/tex/latex/baskervaldadf/baskervald.sty
/usr/local/texlive/2024/texmf-dist/tex/latex/berenisadf/berenis.sty

it didn't even occur to me to put them in .fd files.

@DavidCarlisle you should get more results than that.

(but it depends how updated your install is.)

@cfr yes I got bored and stopped it:-)

@cfr but I suppose this is your question ltnews36 which has

Maintainers of font bundles that include \texttt{TS1} encoded font
files should add an appropriate declaration into the corresponding
\texttt{ts1}\textit{family}\texttt{.fd} file, because otherwise the
default subencoding is assumed, which is probably disabling too many
glyphs that are actually available in the font.\footnote{The \LaTeX{}
  format contains declarations for many font families already.  This
  was done in 2020 to quickstart the use of the symbols in the kernel,
  but it is really the wrong place for such declarations. Thus, for

so I guess it's the same issue that putting it in a package is OK but then only covers the loading via a package if someone goes \usefont{TS1}{yourfam}{m}{n} then the fd file will get loaded and the full TS1 encoding not subsetted will be assumed

@DavidCarlisle yes.

@DavidCarlisle other way: tiny subset will be assumed.

@cfr oh yes well whichever the default is it will do that, not the subset you have specified in the package.

@DavidCarlisle is it reasonable to say that somebody who uses \usefont can reasonably be expected to declare the subset for ts1 themselves?

so putting it in a package isn't terrible and is overwhelmingly more common, but putting it in th efd file would be better if you could arrange it

@DavidCarlisle but it also makes it hard to override.

@cfr yes but the idea is that it shouldn't be overridable as the font either does or does not have some set of characters, it's not a stylistic choice (like the size to use) it's simply a statement of fact

@DavidCarlisle I know that's the idea.

@DavidCarlisle well ... it's a bit more complicated ...

@cfr I don't think you are missing anything then, there are some tradeoffs and it's your package and your choice. Time for bed:-)

@DavidCarlisle ok, thanks. nos da!

@UlrikeFischer Could you give me some advice on tagging? I'm about to get rid of the last bit of tampering latex-lab-testphase-block internals, and for that I'm redefining my list environments with xtemplates. Because, as far as I can tell, that's the only (public) way to set the attribute-class of the list. This is all good, and is working. The problem arises if someone goes with testphase=phase-II, or something which does not load latex-lab-testphase-block. [...]

[...] Since I'm testing for \tag_if_active:TF, the document then breaks in not a pretty way. Should I just document that it requires phase-III and let things eventually find their way to the kernel? Or should I test before doing things which require latex-lab-testphase-block in particular? Any thoughts?