@UlrikeFischer thanks. I'm mostly thinking of private code which I know will not be compatible. I doubt font packages lend themselves to tagging and I've no idea what tagging should look like for logic. I assume linguistics is likely to have a similar question.

@UlrikeFischer Thank you for the answer. As yet, my package is unpublished and has only one user (me). I will have a good look at the tagging project, and try it out when I have some time. I will likely open some questions if I find something I can't understand.

@cfr font packages are tagging wise mostly unproblematic, but in view of accessibility one has to check the ToUnicode mappings, as an example check the issue about the chessfss package ...

@UlrikeFischer thanks. I suspect my packages are problematic on that score. but wouldn't you really want to just use unicode fonts?

@UlrikeFischer I'm ashamed to admit this, but I don't know what trying with the prototype means. I have seen this instruction before. (I have looked at some of the documentation, so I have some idea of what to put in a document but I don't know if that is connected.)

@cfr look at any of the newer issues in the tagging, or at the various test files that are linked from the status page. They all show "prototype" documents. Mainly it means to put the DocumentMetadata-line at the begin.

@UlrikeFischer oh, that's all? thanks.

@cfr ;-) Well naturally there is much going on with tagging once you look at details. But first tries do not need more.

@DavidCarlisle is the pdftex option of lscape supposed to work with geometry?

@cfr the main goal of the project is to make it easy, so at the end users should not need much more than that.

@UlrikeFischer that's not what I meant.

@UlrikeFischer to me a 'prototype' is a physical thing. I had no clue what that was meant to mean. (I saw the same instruction elsewhere.)

this seems to work, but I don't know if it is a good idea:

\documentclass[a4paper]{article}
\usepackage{geometry}
\usepackage[pdftex]{lscape}
\makeatletter
\def\endlandscape{%
  \clearpage
  \endgroup
  \global\@colht=\textheight
  \global\vsize=\textheight
\global\@colroom=\textheight}
\ExplSyntaxOn
\hook_gput_code:nnn { env/landscape/begin } { lscape mod }
{
  \ifGin@pdftex
    \hook_gput_next_code:nn { shipout/after }
    {
      \hook_gput_code:nnn { shipout } { lscape mod }
      {
        \pdfpageattr{/Rotate ~  90}
      }
    }
  \fi
}
\hook_gput_code:nnn { env/landscape/end } { lscape mod }

@cfr not sure what you are trying to achieve but why don't you use pdflscape?

@UlrikeFischer I seemed to remember last time I needed this, the pdftex option for landscape worked when I encountered some complication with pdflscape. but I probably didn't need multiple pages in landscape.

@cfr well this pdftex option to add a rotation is rather crude. It only works with pdftex and it only affects the last page. pdflscape has the correct implementation (and also works with the pdfmanagement loaded by \DocumentMetadata). If you have a problem with it, it would be better to resolve this problem than to fall back to lscape.

@UlrikeFischer thanks. honestly, I very rarely use either. I generally just use rotating and geometry because either I want to rotate a single object or I want landscape for the document.

@PabloGonzálezL see wrapstuff for an attempt at this. Else, there is an insbox-based answer by myself on the network that works in some lists.

@PabloGonzálezL I think I have a different answer somewhere which works with lists (at least sometimes). however, it doesn't use xgalley or, as far as I remember, expl3. I think it uses a generic package (i.e. not latex).

@cfr er probably but there is no specific code in either package to support the other

@UlrikeFischer pdflscape got added when I was not really watching things closely: it should simply have been an update to lscape (still could be, I suspect)

@DavidCarlisle Oh, so things sneak in when you look away.

@DavidCarlisle I don't think it is geometry. I think it just doesn't work for multiple pages. but I remembered why I end up using lscape rather than pdflscape. (but I don't think I will admit why.)

@DavidCarlisle That's great!

@DavidCarlisle Now I'm doing some Asymptote :-) pdf.js cannot render all, but %!TeX return pdf works fine

@StefanKottwitz not my fault :-)

@StefanKottwitz although if it works in firefox where the native browser renderer is essentially pdf.js anyway, it may be that updating the version of pdf.js packaged at texlive.net might help, but not today

@DavidCarlisle sounds good!

I used Chrome btw.

@StefanKottwitz That image claims to be pdf.js version 2.4 current version seems to be 4.5, I wonder if they fixed anything in the last three years.... :-) github.com/mozilla/pdf.js/releases

@DavidCarlisle Possibly :-)

@StefanKottwitz email me a failing pdf and I may try later

@DavidCarlisle Ok! that has time, also I never noticed an issue with pdf.js before, that run well all the time.

@cfr The truth is that the solution presented works partially without affecting the horizontal spaces of the environment.

@cfr Yes there are some modifications, but not in xgalley as such, rather in l3galley...I would have liked a mix of galley/coffins but I like your approach with box :D

@Skillmon I've used it and it's great, unfortunately and as you've written in the repo, it fails sometimes :(

@Skillmon I've seen some where insbox is used for minipage+wrapfig and I'm clear that \parshape is the complication here :( ...in the LaTeX2e repo there is a thread with this (github.com/latex3/latex2e/issues/1112)

@cfr We currently have two document/design interfaces, a keyval one and a more 'traditional' looking one, and there is the question of which to go with

@PabloGonzálezL Still not at all clear - pulling off a major change here is extremely risky

@PabloGonzálezL (@cfr) l3galley really is a set of experiments to see what might be doable - and with the need to maintain working documents, that might be the end point for these ideas in LaTeX

Was the defintion of \fp_if_nan:nTF changed recently? It seems that the first argument does not understand arbitraty tokens anymore

I thought that this function returns true for anything that is not a number. Or maybe this is already fixed? MikTeX is a slow with updating packages these days ...

@JasperHabicht true for things that are floating point ieee NaN not for arbitrary non fp tokens though isn't it?

@DavidCarlisle Hm ... well, currently it throws an error if I put in "x" for example

@JasperHabicht that seems reasonable

@JasperHabicht x isn't a NaN

@JasperHabicht it's testing if a floating point value is a NaN not if the argument is a floating point value.

Yes, that's right ... I think. I wonder whether it has always been like this. But probably yes.

Something broke in my package and I try to approach the issue, but now that I think about it, it is probably somewhere else anyways ...

Applied math people know a good tool when then find it. @DavidCarlisle

@AlanMunn keeps a roof over my head

\OT1\obeyedline where does this come from? It breaks everything ...

At this point there is a linebreak in the original string which I read in verbatim with \c_str_cctab. But there should not be anything, or should there?

Doesn't \c_str_cctab set \endlinechar to -1, so nothing?

@JasperHabicht er comes from some code you are not showing? the default definition of \obeyedline isn't encoding specific so there would be no \OT1 version.

@PabloGonzálezL well, all of those packages use \parshape at their core, so does insbox. But insbox is so plainly simple that it's easy to adapt to work in lists. Let me take a look.

The question that started my insbox usage: tex.stackexchange.com/questions/417516/…

An improved version by myself: tex.stackexchange.com/questions/419271/wrapimage-inside-list/… (in LaTeX's standard enumerate)

I already answered my own question. Hooray ... =)

And another one, this time in exam: tex.stackexchange.com/questions/476381/…

@PabloGonzálezL see, I said there are some answers about this using insbox... :)

(those are not all results when i search for insbox and my user id)

@JasperHabicht yes I just saw, I may look later still don't see where OT1 came from the default definition is \protected\gdef\obeyedline{\par}

@DavidCarlisle Well, if I redefine locally, everything is fine and the stuff is gone. Could also be from \msg_log

@Skillmon This is a great answer (compatible with enumitem), but if \end{enumerate} is not followed by \par then \end{enumerate}\parshape 0 must be used (which is the approach given by the letrine package)

@Skillmon It is possible to do this without using insbox or rather migrate the code (if possible) to expl3...The wrapstuff package and the classic wrapfig do a great job, but they fail in list environments (they are quite special :), having a \InsertList[keys]{stuff} command would be great.

@JosephWright Ok I understand, unlike the rest of the experimental packages (or those that were at the time), the documentation is not very user-friendly to me :(

@JasperHabicht you misled me, you don't have \OT1\obeyedline you have \OT1\o beyedline with an OT1 scandanavian slashed o \o , the point is it sets catcode of o to 12, so \obeyedline is like \+beyedline with a one-character csname followed by text.

@DavidCarlisle Oh, yes you are right! Now it makes sense!

... and beyedline is forwarded through the code until it gets parsed by \fp_if_nan which finally throws: "Unknown fp word beyedline" ... which is the reason I first suspected something with fp