Moving fontfiles into a separate directory

[petrk23]

During time, we got many fontfiles in OpTeX and maybe many other will come. The problem is that they are in the same directory as the base macros of OpTeX. This makes the base directory messy. The best solution would be to move them into a separate directory. I think that fontfiles are very specific OpTeX files that could have a special directory.

It could be named fontfiles, font-files, ffiles, f-files. The name fonts would also be good, but his generality suggests that they are fonts inside, which is not true. But I would not have any problem with it, as it is in the TeX section of the distro. Maybe you have a better idea for the name... Anyway, it should also be chosen to match the naming style where it is placed.

There are two places where it could be added.

1. Leave it as a subdirectory in the base directory.
2. Move them one level up. It would place fontfiles as separate support files. It would give them the meaning of special type of font support packages, which they really are.

I can't tell which would be better. The second is cleaner, but this is my subjective opinion.

[vlasakm]

+1 from me, I too think that moving some files out of the base directory, and would make the more important files stand out more, not lost in between many support files.

I proposed something like this already a long time ago: #70, but I didn't have a concrete idea that would satisfy everyone (including me). At the very least I think there are a few categories of files:

• base - all the important files that in general are baked into the format (e.g. ref-file.opm),
• hisyntax - syntax highlighting files for various languages (e.g. hisyntax-c.opm),
• font-families - font family support files (e.g. f-lmfonts.opm),
• bib-styles - bibliography style files (e.g. bib-iso690.opm).

I really see at least two main categories here: "direct" files baked into the format, or files referred to directly by something in the format files, and "indirect" files loaded using something like \_input bib-#2.opm where the name is really up to the document author, and is meant to be extensible.

"Direct" files should be provided by this repository, whereas "indirect" files can come from anywhere - I can have my own on my personal machine, or publish a package on CTAN with them. Though many are for convenience maintained in this repository as this is a convenient place for the OpTeX community to centralize the effort.

The optex directory is directly provided in TeX distributions as the tex/optex directory (e.g. in TeX Live: https://git.texlive.info/texlive/tree/Master/texmf-dist/tex/optex), but in the TeX distributions, other packages also can provide files for the tex/optex directory, generally under tex/optex/<ctan-package-name> (e.g. lua-widow-control in TeX Live).

It has been customary to provide the "base files" of the format in <program>/<format>/base, e.g. tex/latex/base or metapost/base. Other packages had the non-base directories, i.e. <program>/<format>/<package-name>. Therefore, while I initially thought that something like this would be nice:

tex/
├── optex
│   ├── base
│   │   ├── ref-file.opm
│   │   └── ...
│   ├── bib-styles
│   │   ├── bib-iso690.opm`
│   │   └── ...
│   ├── font-support
│   │   ├── f-lmfonts.opm
│   │   └── ...
│   ├── hisyntax
│   │   ├── hisyntax-c.opm
│   │   └── ...
│   ├── lua-widow-control
│   │   └── lua-widow-control.opm

it actually has a problem of seeming like there are optex packages named hisyntax, or bib-styles (the current pkg and doc directories have the same problem). Maybe a better thing would be to have directories nested under tex/optex/base:

tex/
├── optex
│   ├── base
│   │   ├── ref-file.opm
│   │   ├── ...
│   │   ├── bib-styles
│   │   │   ├── bib-iso690.opm`
│   │   │   └── ...
│   │   ├── font-support
│   │   │   ├── f-lmfonts.opm
│   │   │   └── ...
│   │   ├── hisyntax
│   │   │   ├── hisyntax-c.opm
│   │   │   └── ...
│   ├── lua-widow-control
│   │   └── lua-widow-control.opm

In this scheme maybe even the demo, doc and pkg directories could go under base (and then the base directory in the OpTeX git repository wouldn't be that needed, since everything would be now under it).

This scheme I think nicely splits "direct" files, and "indirect" files of various categories, doesn't confuse in the tex/optex TEXMF/TDS directory what is coming from the base OpTeX package (i.e. https://www.ctan.org/pkg/optex), and what comes from other packages. Also @olsak's requirement for having all TEXINPUT files under one directory (base) is still satisfied.

@petrk23 @olsak thoughts?

PS: The actual names for bib-styles, font-support and hisyntax, are just place holders to give an idea of what I am talking about, I am not that sure about the names and probably don't even have a strong preference. Also, I kind of see the way how the OpTeX repository is structured as a bit different from what is on CTAN and what is installed in TeX Live, though I think it's preferable that we have in OpTeX git repository a directory which directly corresponds to base installed in TEXMF tree. (Though the optex directory can serve that purpose, it currently also has a Makefile and a README file, so maybe we should keep optex/base?)

[petrk23]

I like your idea to make place for CTAN packages directly in the OpTeX directory. This would make more sense, than placing them under general LuaTeX macros, as the most are at this time. And what's in the core of OpTeX would go under base. Organized in directories, of course. Exactly as you suggest in your second scheme.

What I'm not sure is what then to do with the contents of doc, pkg and demo. One solution would be to transform them into packages. Especially, I'm not sure if the separation of documentation is the right thing (maybe only subjective feeling at the moment of writing this). But pkg and demo would make sense if separated into packages, as they have very little to do with the core of OpTeX.

This is the only problem I see in this solution.

[olsak]

I am very sorry, I understand your arguments but I keep the files without changes now. I like the current arrangement of files without a lot of directory levels. And probably I maintain these files in base/ directory the most, so file arrangement here will be according to me. I don't need to do listing files in the base directory (i.e. doing ls or viewing in a graphical UI) so I don't see any mess. If I want to view a content of a file (for example f-termes.opm) then I do less ba<tab>/f-ter<tab>. On the other hand, if the arrangement is your then I must type less ba<tab>/fon<tab>/f-ter<tab> which is much more typing. If I want to find something in all base files I do grep foo ba<tab>/* .

[petrk23]

That's ok... The new structure would complicate your workflow, so I fully understand that you want to keep it as it is. Nevertheless, I'm glad that we now know why!