Tue, 20 Apr 2021 10:00:26 +0200
I have started to look at the implementation of the LaTeX required
primitives supplementary to TeX + e-TeX ones and I have some questions.
Note: I work with the definitions found in the pdfTeX manual and will
not look at the code since it is GPL'ed one and I don't want someone
later to claim that my code shall be released under GPL because my eyes
have touched GPL code.
PDF only primitives that I will not implement (correct?):
Primitives that seem highly linked to PDF and that, to be implemented,
would need to draw in not ISO C routines but POSIX or MS specific
because they are linked to filesystems:
Primitives that seem highly linked to PDF but that can be implemented
using ISO C routines:
\pdffilesize ? (size can be more than integer accepted by TeX)
Primitives whose output seem unclear:
said to generate "an integer" and, afterwards said to expand "to a list
of tokens". Do they provide, on each call, one integer with the defined
property or a series of a defined cardinal of such integers or an
infinite series of such integers until interrupted?
What is the behavior expected on error (syntax error; out of range)?
The pdf prefix exists because the primitives were added to TeX in pdfTeX
but it is unfortunate because it seems to link the primitives to the
PDF format. I'd like to implement them without the pdf prefix and
provide simply a file for compatibility with \let statements. Would it
Primitives I plan to add (RFC):
\engine: a read-only ASCII token identifying the engine: ex.: e-TeX;
\apimajor: a positive or nul integer identifying a definite list of
\apiminor: a positive or nul integer identifying a definite behavior
(nature, parameters, output, errors) of the primitives;
\apirevision: a positive or nul integer identifying an implementation
of the (major, minor) combination---the major and minor identify a
contract; the revision identifies a modification of the
implementation of the contract including a correction because the
implementation didn't actually provide the contract. I.e.: bug
fixes, optimizations etc. without any contract modification. The
contract is theoretical.
\outfmtlist: a series of ASCII tokens identifying the output format
supported by the engine. Ex.: DVI1.0 (traditional DVI), PDF1.3 etc.
The default format shall be listed first. (Note: I plan, some day,
to extend DVI.)
\outfmtset: setting the output format, that shall be amongst the formats
supported. If not, it returns an error and set the output format to
the default one. Shall be set before \shipout and errors if used
after output has started.
\outfmt: a token identifying the current output format.
Note: I will work progressively on this when I have a sufficient slot
of time. So no timeline set.
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C