Gnu System Design Wishes

1. Directory structure ideas
2. Filename Suffixes for CJK TeX Preprocessor Sources
3. WWWBROWSER environment variable and mozillaclient

1. Directory structure ideas

1. Basis of the discussion: Existing standards
2. Documentation Directories
3. Source Format Fonts
4. /variability during normal operation vs during system update

1.1. Basis of the discussion: Existing standards

• Filesystem Hierarchy Standard
• TeX Directory Structure

Some aspects of these standards need to be elaborated and/or streamlined.

1.2. Documentation Directories

1.3. Source Format Fonts

1. Proposal
2. Rationale

1.3.1. Proposal

format:

ttf, ps-pfa, ps-pfb, ps-cid, ot, mf, bdf etc

coding[-range]:

ucs, ucs-planes-1, ucs-planes-1-3+5-6, big5, iso8859-1 etc

foundry:

adobe, bitstream, wadalab, dynafont, font21 etc

name:

palatino, courier, fangsong etc

subrange:

in case of large fonts or cooperative foundry work, subdivisions may be useful

1.3.2. Rationale

1. Why subdivide by <format> first?
2. Why not allocate an extra directory level for subtypes of formats?
3. Why subdivide by <coding> next?
4. Why not allocate an extra subdirectory for the coding-range?
5. Why subdivide by <foundry> next?
6. Why allocate an extra subdirectory for the <subrange>?

1.3.2.1. Why subdivide by <format> first?

1. Programs are first of all interested in formats. There is always one program/module that can handle truetype and another that can handle metafont.
2. People can handle the format distinction with less uncertainty than any other distinction. When no CID rendering machinery is available, the administrator may want to move away all CID fonts with one command.

1.3.2.2. Why not allocate an extra directory level for subtypes of formats?

1. We want to keep a consistent number of subdirectories, so that globbing expressions like /usr/share/fonts/*/ucs/ will work.
2. The criteria for subclassification are often unclear.

1.3.2.3. Why subdivide by <coding> next?

1. Programs are next interested in the coding. The coding is a special parameter that every program must know, and many programs can only handle certain codings. Programs do not care about foundries and names, but they do care about formats and codings.
2. The coding distinction roughly corresponds to a language distinction. Administrators can handle this distinction easily. When a certain language cannot be supported on the system, the administrator may want to move away all fonts of that language.

1.3.2.4. Why not allocate an extra subdirectory for the coding-range?

1. Many codings do not have subranges. The tree is easier to handle, if there is a consistent number of subdirectories.
2. UCS, which may eventually become the only coding, is so large, that it will necessarily be divided into subranges. One UCS subrange roughly corresponds to one legacy coding.

1.3.2.5. Why subdivide by <foundry> next?

1.3.2.6. Why allocate an extra subdirectory for the <subrange>?

1. letting programs conveniently load subranges of huge fonts, e.g. the Arabic range of a complete UCS font.
2. organising volunteer cooperative font designing work: one person may be responsible for a certain range of Han characters that are stored in a separate file.

Allocating this extra level does not make globbing / regexp searching on the directory structure significantly more difficult, because the subdivision is occuring only at the end.

1.4. /variability during normal operation vs during system update

When a new printer is added to the TeX system, this is a modification of the system, and the variable data produced by texconfig needn't go into /var/lib/texmf, but rather belong to a configuration hierarchy like /etc/texmf or to /usr/share/texmf itself, which is not considered to be read-only even during installation and extension of the system itself. A reason to nevertheless use /var/lib/texmf could be the wish to add printers that are both only preliminary local solutions (i.e. non /usr/share) and shareable across a network (i.e. non etc). Still, in this case at least all other printer drivers should go into /usr/share/texmf, and the /var/lib/texmf solution is only a private local one that needn't be of concern to the system standard designer.

Likewise, there can be some doubt as to whether /var/lib/rpm is the right place for the rpm database. This database is only written to when the system itself is changed. This would be a reason to place it in /etc/ rather than in /var. Another reason would be that, unlike /var/lib/texmf, are system-specific and not shareable. RPM offers an interface library that allows alien programs to query and even write to its database. The database is therefore of systemwide concern and belongs into something like /etc/rpm/db.

Althought the two above examples may not seem totally cogent, there is a need for clarification of the notion of variability. Otherwise the borderlines of the /var tree may be gradually blurred.

2. Filename Suffixes for CJK TeX Preprocessor Sources

To make CJK LaTeX files with Chinese big5, Japanese sjis and some other specially coded characters acceptable for LaTeX, special preprocessing with programs like sjisconv, bg5conv, cefconv etc is needed. The LaTeX source files understood by these preprocessors are not .tex files but should have the special suffixes, see table below.

Moreover, since many people will want to write their TeX source in UTF-8 and use a preprocessor before handing it to a non-Unicode TeX, some special suffixes are needed for these UTF-8 files also.

Using special suffixes allows LaTeX and other programs to recognize which files it can compile directly and which preprocessors have to be applied, and makes it easy to automatically create makefiles for generating all the target documents (eg. PS, PDF) from the source.

The file magic database /etc/magic should be updated so as to recognize the preprocessable file types.

3. WWWBROWSER environment variable and mozillaclient

• An environment variable like WWWBROWSER, which will be recognized by all programs that need to invoke an external web-browser
• A moziallaclient that works like the emacsclient: makes an already active mozillaserver open a frame with the URL passed to moziallaclient as an argument by some application (like a mailer) that invokes an external WWWBROWSER.