LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Wed, 14 Oct 2020 00:21:32 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=utf-8; format=flowed
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (35 lines)

> LaTeXers - personally, I think it would be nice if the "primitive
> requirements" became a permanent part of the LaTeX
> documentation. (Apologies if they already there.) Maybe?

any suggestion where that should be? I consider ltnews actually not a 
bad place especially as there is also

which puts them all together.

more for @Thierry ...

It might be possible to make a distinction between primitives that are 
specific to pdf generation (because they are not relevant if dvi is 
produced (which we intend to support)) and those that are for general 
coding, e.g. \ifincsname, \expanded or \pdfstrcmp (which has nothing to 
do with "pdf" other than it was first introduced in pdftex) and a number 
of others.

The general coding primitives are rather essential and for most of them 
there is no way to emulate in any way that still allows a somewhat 
reasonable performance even if technically TeX is Turing-complete.

In other words it should be possible to drop the primitives which are 
really PDF output specific (if we list any of them as required) and 
require them only for engines/engine-modes that target PDF directly and 
make sure that the format doesn't complain if they aren't there, but 
there is not reasonable way going forward without the general coding 
ones that are now (fortunately) available in all major engines.