Forest ext/prooftrees

[cfr42]

Not at all sure this is how this should be organised ...

Ref #1171

[cfr42]

What I'm not clear about is what I should then do with other libraries from the same package. That is, if the status page lists libraries separately, does every library in the package need its own entry in the table? Do builtin libraries in forest also need separate entries? But tikz, for instance, includes a huge number of libraries yet has a single entry?

[mbertucci47]

@cfr There are entries for problematic tikz libraries like external and matrix but yes not all libraries have an entry. I don't know how subpackages works with library entries. Better to ask @davidcarlisle

[cfr42]

OK, thanks. I will see what David says.

The forest libraries are actually .sty files. They're only libraries in the sense that forest handles them specially. (In contrast to tikz/pgf, where libraries aren't regular packages, the handling here uses the regular LaTeX mechanism for package loading and declaration i.e. \RequirePackage and \ProvidesPackage.

[cfr42]

Maybe I should just delete this and start again. But I don't know what it should look like re. the libraries, so I'm not sure that will be any better.

[davidcarlisle]

Sorry I just saw I was pinged here,

@cfr42 I think you could use the new(ish) subpackages feature rather than make complete new entries

see

- name: bera
  type: package
  status: compatible
  included-in: [ol0.02]
  subpackages: [beramono,berasans]

that would be enough that if you use the check-tagging-status option in a latex run they'll be "known" and assumed to have the same status as forest.

[cfr42]

@davidcarlisle

Sorry I just saw I was pinged here,

No worries. (I almost asked you in TeX SE chat yesterday, but decided that was illegitimate.)

@cfr42 I think you could use the new(ish) subpackages feature rather than make complete new entries

see

- name: bera
  type: package
  status: compatible
  included-in: [ol0.02]
  subpackages: [beramono,berasans]

that would be enough that if you use the check-tagging-status option in a latex run they'll be "known" and assumed to have the same status as forest.

I'm not sure I understand this suggestion. Do you mean e.g.

- name: forest
  type: package
  status: partially-compatible
  included-in: [arxiv01, ol0.1]
  priority: 6
  comments: "Tagging requires third-party library ext.tagging."
  issues: [1087]
  package-repository: "https://github.com/sasozivanovic/forest"
  external-issues: ["https://github.com/sasozivanovic/forest/issues/15"]
  tests: true
  tasks: needs more tests
  updated: 2026-02-26

- name: forest-ext
  type: library
  status: partially-compatible
  included-in:
  priority: 9
  issues: [1007, 1171]
  comments: "Library ext.tagging tags forest trees via Alt added on surrounding Figure."
  package-repository: "https://codeberg.org/cfr/prooftrees"
  tests: true
  subpackages: [ext.ling, ext.multi, ext.tagging, ext.utils]
  updated: 2026-02-26

It seems a bit odd? forest-ext is only the CTAN package. It isn't itself anything you can load. And it seems a bit weird to describe ext.tagging as 'partially-compatible'?

Probably ext.tagging should be compatible and ext.ling, ext.multi and ext.utils should be partially-compatible for the same reason as forest i.e. because you have to explicitly add ext.tagging for compatibility?

I think I must be over-complicating this, but I don't quite see how to fit this into the boxes.

[davidcarlisle]

@cfr42

It seems a bit odd? forest-ext is only the CTAN package. I

ah yes ignore that then.

in general the status file doesn't need to be complete so you can include or ignore packages as you wish, but one thing that is useful (and where subpackages can help) is in the latex checking can then know about them

if a user goes

\DocumentMetadata{check-tagging-status}
\documentclass{article}

\usepackage{forest}

\begin{document}

\end{document}

they get a report:

======================================
 Status report of the tagging support
======================================
 Details at https://latex3.github.io/tagging-project/tagging-status
 Report erroneous entries at https://github.com/latex3/tagging-project

 A. CLASS
 ********

 article.cls is compatible

 B. PACKAGES, LIBRARIES, etc
 ***********

 1. Unsupported
 --------------------------
 NONE

 2. Currently incompatible
 --------------------------
 forest.sty

 3. Partially compatible
 --------------------------
 tikz.sty
 pgfrcs.sty
 amsmath.sty
 amsbsy.sty

 4. Compatible
 --------------------------
 array.sty
 graphicx.sty
 keyval.sty
 graphics.sty
 trig.sty
 xcolor.sty
 pgffor.sty
 pgfkeys.sty
 pgfmath.sty
 pgfopts.sty
 etoolbox.sty
 environ.sty
 trimspaces.sty
 xparse.sty
 expl3.sty
 amstext.sty
 amsgen.sty
 amsopn.sty
 infwarerr.sty
 grfext.sty
 kvdefinekeys.sty
 kvoptions.sty
 ltxcmds.sty
 kvsetkeys.sty
 pdftexcmds.sty
 iftex.sty

 5. Unknown
 --------------------------
 pgf.sty
 pgfcore.sty

  6.Unclassified files with extension .sty
 --------------------------
 elocalloc.sty
 inlinedef.sty

====================================
 End of status report
====================================

If a package necessarily loads another (eg I assume forest loaded elocalloc) then it's good if the referenced packages are listed as sub packages or have their own entry as that way they don't end up in that final "unclassified" section. If a user loads a package described as compatible (or partially compatible) but that necessarily loads a bunch of "unclassified" files, the report is a bit strange.

[cfr42]

@cfr42

It seems a bit odd? forest-ext is only the CTAN package. I

ah yes ignore that then.

in general the status file doesn't need to be complete so you can include or ignore packages as you wish, but one thing that is useful (and where subpackages can help) is in the latex checking can then know about them

OK, but I am not clear what the libraries should be subpackages of. I take it you do not want a different entry for each library since e.g. you would end up with numerous entries for tikz.

forest-ext provides 4 forest libraries.

• If the ext.tagging library is loaded, it provides support for tagging forest trees.
• ext.multi supports tagging iff ext.tagging is loaded (checked in the begindocument hook).
• ext.tagging loads ext.utils.
• ext.ling is independent, but this will probably change at some point.

In terms of generating a useful report (thanks!), probably ext.ling, ext.multi and ext.utils should be partially-compatible because they require ext.tagging for tagging compatibility. But ext.tagging should be compatible.

Does that sound right? If so, do I make 4 entries? That seems excessive ...

Or should I just leave the other 3 out? It's not clear to me how useful it is to add the other 3 libraries now.

[davidcarlisle]

@cfr If in doubt leave stuff out, the worst that can happen is that some file gets an "unknown" status in some report, which is probably a true state anyway. It's easier to add things later than take them out later if you want to revise the settings after more experience, or the package updates.

[cfr42]

@davidcarlisle do you want me to do anything different with this? or delete it? or ...?

[davidcarlisle]

@cfr42 oh sorry I missed that the draft flag had been removed. Let's just merge as is and if any issues come up we can always adjust later. Thanks for the PR.