LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 14 Oct 2020 00:21:32 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
Karl

> 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

https://www.latex-project.org/news/latex2e-news/ltnews.pdf

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.

frank

ATOM RSS1 RSS2