Am 17.11.25 um 13:46 schrieb Max Chernoff via ntg-context:

...

FROM registry.gitlab.com/islandoftex/images/context:lmtx

That image is deprecated

https://gitlab.com/islandoftex/images/context#context-docker-image

in favour of

registry.gitlab.com/islandoftex/images/texlive/texlive:context

The "texlive/texlive:context" should include every ConTeXt module available in TeX Live. Ok, thank you! Since it works with the texlive:current container, I trust it will also work with texlive:context (can only check tomorrow).

Hraban

Hi Hraban, On Tue, 2025-11-18 at 20:13 +0100, Henning Hraban Ramm wrote:

Am 17.11.25 um 20:03 schrieb Henning Hraban Ramm:

...

Am 17.11.25 um 13:46 schrieb Max Chernoff via ntg-context:

...

The "texlive/texlive:context" should include every ConTeXt module available in TeX Live. Ok, thank you! Since it works with the texlive:current container, I trust it will also work with texlive:context (can only check tomorrow).

Unfortunately, it didn’t, the container was not found.

Sorry, it looks like I gave you the wrong tag name. You want texlive:latest-context instead. I've included a full list of all the ConTeXt-related tags at the end of the email. Thanks, -- Max $ skopeo inspect docker://registry.gitlab.com/islandoftex/images/texlive | jq --raw-output .RepoTags[] | grep -i context TL2025-2025-07-17-context TL2025-2025-07-17-context-doc TL2025-2025-07-17-context-doc-src TL2025-2025-07-17-context-src TL2025-2025-07-20-context TL2025-2025-07-20-context-doc TL2025-2025-07-20-context-doc-src TL2025-2025-07-20-context-src TL2025-2025-07-27-context TL2025-2025-07-27-context-doc TL2025-2025-07-27-context-doc-src TL2025-2025-07-27-context-src TL2025-2025-08-03-context TL2025-2025-08-03-context-doc TL2025-2025-08-03-context-doc-src TL2025-2025-08-03-context-src TL2025-2025-08-10-context TL2025-2025-08-10-context-doc TL2025-2025-08-10-context-doc-src TL2025-2025-08-10-context-src TL2025-2025-08-17-context TL2025-2025-08-17-context-doc TL2025-2025-08-17-context-doc-src TL2025-2025-08-17-context-src TL2025-2025-08-24-context TL2025-2025-08-24-context-doc TL2025-2025-08-24-context-doc-src TL2025-2025-08-24-context-src TL2025-2025-08-31-context TL2025-2025-08-31-context-doc TL2025-2025-08-31-context-doc-src TL2025-2025-08-31-context-src TL2025-2025-09-07-context TL2025-2025-09-07-context-doc TL2025-2025-09-07-context-doc-src TL2025-2025-09-07-context-src TL2025-2025-09-14-context TL2025-2025-09-14-context-doc TL2025-2025-09-14-context-doc-src TL2025-2025-09-14-context-src TL2025-2025-09-21-context TL2025-2025-09-21-context-doc TL2025-2025-09-21-context-doc-src TL2025-2025-09-21-context-src TL2025-2025-09-28-context TL2025-2025-09-28-context-doc TL2025-2025-09-28-context-doc-src TL2025-2025-09-28-context-src TL2025-2025-10-05-context TL2025-2025-10-05-context-doc TL2025-2025-10-05-context-doc-src TL2025-2025-10-05-context-src TL2025-2025-10-12-context TL2025-2025-10-12-context-doc TL2025-2025-10-12-context-doc-src TL2025-2025-10-12-context-src TL2025-2025-10-19-context TL2025-2025-10-19-context-doc TL2025-2025-10-19-context-doc-src TL2025-2025-10-19-context-src TL2025-2025-10-26-context TL2025-2025-10-26-context-doc TL2025-2025-10-26-context-doc-src TL2025-2025-10-26-context-src TL2025-2025-11-02-context TL2025-2025-11-02-context-doc TL2025-2025-11-02-context-doc-src TL2025-2025-11-02-context-src TL2025-2025-11-09-context TL2025-2025-11-09-context-doc TL2025-2025-11-09-context-doc-src TL2025-2025-11-09-context-src TL2025-2025-11-16-context TL2025-2025-11-16-context-doc TL2025-2025-11-16-context-doc-src TL2025-2025-11-16-context-src latest-context latest-context-doc latest-context-doc-src latest-context-src

KeenWrite has an automated installation of ConTeXt in a podman container. The source code for the Containerfile is at: https://repo.autonoma.ca/?action=blob&repo=keenwrite.git&hash=e23a2a0f03894070ff01472d36dc133285c39120&name=Containerfile Fonts aside, this produces a fairly minimal installation. There's an "rm -rf modules" in the file that you'll need to remove to keep the modules intact. May need to add a few other commands to add specific modules. It also grabs free fonts from https://fonts.keenwrite.com, so you'll probably want to change that. Cheers! On Wed, Nov 19, 2025 at 2:09 AM Henning Hraban Ramm wrote:

Am 19.11.25 um 02:16 schrieb Max Chernoff via ntg-context:

...

Hi Hraban,

...

Unfortunately, it didn’t, the container was not found.

Sorry, it looks like I gave you the wrong tag name. You want

texlive:latest-context

instead. I've included a full list of all the ConTeXt-related tags at the end of the email.

Thank you! Now it works.

Hraban

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net

___________________________________________________________________________________

Am 24.11.25 um 19:16 schrieb Bruce Horrocks:

Just as a reminder, there are already instructions for installing ConTeXt into a Docker container on the Wiki. No need to hack the Keenwrite version.

https://wiki.contextgarden.net/Installing_ConTeXt_LMTX_into_a_Docker_contain...

But it’s still easier to use one of the containers provided by Island of TeX. Hraban

Hi Thangalin, Some thoughts on your comments below:

On 25 Nov 2025, at 19:48, Thangalin wrote:

Just as a reminder, there are already instructions for installing ConTeXt into a Docker container on the Wiki. No need to hack the Keenwrite version.

https://wiki.contextgarden.net/Installing_ConTeXt_LMTX_into_a_Docker_contain...

Some possible issues with the container code on that page:

* Inkscape isn't installed, so SVG files may not fully work in all cases.

Fair point, I can see if I can add that.

* The base image (debian:latest) has a far larger footprint than needed (alpine:latest is minimal).

I think, at the time, there was no MUSL version of ConTeXt so Alpine couldn't be used. It can be swapped but unless someone is planning to run a vast swarm of ConTeXt containers the image size isn't really an issue. (And if they are they'll already know how to reduce it.)

* Lots of files remain that are not needed, bloating the image more than necessary (e.g., PDF docs).

Not sure what you mean here. The ConTeXt PDF documentation is retained because it's part of the distribution.

* No extra fonts are installed, so users may have to modify the container anyway to add those fonts.

There's no way to know what fonts people might want, so maybe some commented-out lines could be included as an example to show people how to add a font but it wouldn't get added by default.

* Certificates may not be up to date.

ConTeXt doesn't use any certificates, afaik. If the installer uses tools such as 'curl' and they use certificates then the base OS container takes care of it.

* May be helpful to set OSFONTDIR.

I didn't need it when I was testing the container but might be needed if additional fonts are added.

* Relies on Docker (and Docker names), which isn't free on all platforms; podman is free on all systems.

I'm not sure what the issue is here. The page uses standard Docker terminology so that it will build on a Docker installation. If someone wishes to use podman or Orbstack or one of the several other container build/runtime environments available instead then they are expected to consult the documentation that comes with their preferred system to understand what changes need to be made. Sticking to standard terminology makes that simpler. (Or, put another way, if you replaced the wiki page with a podman version using container files and 'podman' on the command line then there would soon be a plea on the mailing list "Is there a docker version?") As for cost: the command line version of Docker is still free and is fine for running a single instance; and some users may well be companies who choose to pay for Docker so they can obtain support - it's not our place to make that choice for them.

* Nit: Hard-coded references to "linux-64" could use a variable, instead.

The container base OS is linux-64 so it just got hard-coded. If an Alpine version is created then it might make sense to move it to a variable then. Regards, — Bruce Horrocks Hampshire, UK

I'm not sure what the issue is here.

It's a pet peeve of mine: using a specific term instead of a general term when writing software and configuration files. Instead of a "Docker" image you can make a container image that works with both Docker and podman. Instead of a "Dockerfile" you can call it a "Containerfile" and it'll work with both podman and Docker and whatever other containerization platform comes out in the future. For documentation you can write, "works with Docker and podman" to help the searchers. Speaking of images, another issue with the wiki's example is that there isn't an obvious way to import external images from outside the container environment (i.e., no external directory paths are mapped). Anyway, I recommend looking at the Containerfile I put together, as it adds a number of features to running containerized ConTeXt. Feel free to pilfer or not. Cheers!

Hello ConTeXt community, Following Bruce Horrocks’s recent message about containers and ConTeXt, I wanted to share a small observation and ask for guidance. I am a complete beginner regarding Docker and container-based workflows, but I wanted to experiment a bit on my macOS system (MacBook Pro with Apple Silicon). With the help of AI tools I managed to get a ConTeXt LMTX container running successfully. I am not entirely sure how the ConTeXt distributions end up inside the various container images maintained by the community, but I encountered a reproducible issue that might be relevant — or at least worth mentioning. Environment I am not using Docker Desktop. Instead I run Docker via Colima, installed through Homebrew: * macOS (Apple Silicon, M1) * colima 0.6.x * docker 27.x (client) * container image from: registry.gitlab.com/islandoftex/images/context:lmtx * ConTeXt inside the container reports: system > ConTeXt ver: 2025.11.24 17:55 LMTX fmt: 2025.11.30 int: english/english For basic test documents everything works perfectly. However, when I try to compile some of my older teaching materials that use a combination of: * TikZ (included through my own module t-math.mkiv), * itemize structures, * margin texts, * buffers reused through \startbuffer / \getbuffer / \dorecurse, the following happens: Observed behaviour * ConTeXt runs without any visible TeX error. * The .log file contains no errors or warnings beyond normal module loading. * A PDF is generated — but instead of typeset content, some pages show a large, plain “ERROR” message. * The error does not occur in my older standalone installation of ConTeXt LMTX on macOS: the same sources compile correctly outside the container. After some investigation, isolating parts of the code, and temporarily removing modules, I found: Cause located experimentally If I comment out the line in my module that loads TikZ: \usemodule[tikz] then the document compiles without the “ERROR” output. So it appears that: ➡ The issue is triggered by the interaction between TikZ (m-tikz.mkxl) and ConTeXt LMTX inside the container. To be clear: I’m not explicitly using TikZ drawings in the affected document — the module simply loads TikZ because I use it in other teaching materials. What I would like to ask 1. Is this expected behaviour in the current LMTX version? (i.e. TikZ support being partial or not intended to be used during this phase of development?) 2. Could there be differences between the container build and standalone builds that affect TikZ integration? 3. Is there a recommended way to include TikZ conditionally, so that documents which do not use actual TikZ graphics avoid triggering internal errors? 4. If useful, I can prepare a minimal reproducible example (buffer + itemize + margin text) that triggers the issue when TikZ is loaded. Additional diagnostic detail * The issue is not related to Docker/Colima caching, mounts, or filesystem access. * Buffers, itemize, and my macros all work as expected when TikZ is not loaded. * The error page appears to be generated by some fallback mechanism in the TikZ module (not by TeX error handling), since the log file remains clean. ________________________________ If this is already known behaviour or a limitation, I would gladly adjust my workflow. If not, I’m happy to help provide reproducible test cases. Many thanks to everyone maintaining ConTeXt and the container images! Best regards, Jaroslav Hajtmar Here is the email I am referring to: 4. 12. 2025 v 1:08, Bruce Horrocks : On 1 Dec 2025, at 06:24, Thangalin wrote: I'm not sure what the issue is here. It's a pet peeve of mine: using a specific term instead of a general term when writing software and configuration files. Ah, I see. Well, Docker did get there first and for a while there was no other terminology. However a Google has showed me that there does seem to be a general effort to moved to more neutral wording so I'm happy to change the page. Instead of a "Docker" image you can make a container image that works with both Docker and podman. Instead of a "Dockerfile" you can call it a "Containerfile" and it'll work with both podman and Docker and whatever other containerization platform comes out in the future. For documentation you can write, "works with Docker and podman" to help the searchers. This would work. Speaking of images, another issue with the wiki's example is that there isn't an obvious way to import external images from outside the container environment (i.e., no external directory paths are mapped). Anyway, I recommend looking at the Containerfile I put together, as it adds a number of features to running containerized ConTeXt. Feel free to pilfer or not. Is that the Keenwrite one? https://repo.autonoma.ca/?action=blob&repo=keenwrite.git&hash=e23a2a0f03894070ff01472d36dc133285c39120&name=Containerfile It contains a copyright statement so I wouldn't want to take too much. I think it will be easiest to position the Wiki page as a simple container that provides the minimum needed for people to get going and link to the above containerfile for advanced users. Regards, — Bruce Horrocks Hampshire, UK ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___________________________________________________________________________________

On 12/5/2025 4:25 PM, Hajtmar Jaroslav wrote:

To be clear:

I’m not explicitly /using/ TikZ drawings in the affected document — the module simply loads TikZ because I use it in other teaching materials.

then don't load tikz ... it slows down a run (which likely is already slowed down due to the container)

Is this expected behaviour in the current LMTX version?

see Hrabans answer

(i.e. TikZ support being partial or not intended to be used during this phase of development?)

optional (context is more a metapost thing)

Is there a recommended way to include TikZ conditionally, so that documents which do not use actual TikZ graphics avoid triggering internal errors?

maybe some mode

The error page appears to be generated by some fallback mechanism in the TikZ module (not by TeX error handling), since the log file remains clean.

you get the error page for any job that fails Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------