LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML 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:
LARONDE Thierry <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 14 Oct 2020 12:56:11 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (57 lines)
Hello Frank,

On Wed, Oct 14, 2020 at 12:21:32AM +0200, Frank Mittelbach wrote:
> 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.

This: only requiring essential "page layout" supplementary primitives
but letting rendering (PDF only ones) be only tested for and optional, seems
to me the best solution.

No hurry for the LaTeX developers to change this immediately though: since in
some sense kerTeX will be the only distribution to need this, you can
wait for me to have implemented a .ch file against e-TeX of the required
general primitives before tackling the task ;)

And I will make the change file independent from the kerTeX routines (I
use e-TeX webmerge utility so it will be applied first before kerTeX
specific change file) in order for others to be able to use it in a 
different distribution.

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                http://www.kergis.com/kertex.html
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

ATOM RSS1 RSS2