IronPort-PHdr: A9a23:AtoSHBWuY841kXehxHsXD+OmyHHV8KzRUDF92vIco5tTbqSu+YjjN
               0XD5PJryWXERpjf9+kso/Dbt6nxAyod55fEsH0DfJFIXRIfhoMakl9oG9aLXGv8KvOidCkmB
               IJaTlYw43WyK09TFMvWf1rWs3uv6HgZHRCsfRFtKLHNE5XJx9+yy/j0/pTSZwtSgz/ofbNzI
               Q+svEPVv9MRh4dvAr0/0F3HuCgAYPxYkEVvI1/bhBPg/oGw8ZpkpjxXoO4k/tVcXL/SZKEkV
               eYGSi8rKX4078Dw8wLNV02B/BM0aGgdnxtWDgSA1ynUNr/XtS33/qpn1S2TLJewULY1HDSv7
               qtmTBXlkihBOzNruGfQwtd9iq5WunfD71R23pLUbYeJNfF/YrKVfNUUQnBEV9pQUCoJC521b
               o8GBe4MdehCqIy1q1wLpBq4TQ6iYYGngiNMj2Xx26E3+/wmFRDAwQlmFNUL8TzVoNjzKKYOQ
               LWt1qCbhT7Hbv5QxXL88N2ZKVZ4/rfVB+I2K5OImixNX0vfg16dqJLoJWaP2+AEojLd8uxhE
               OKiimIqrwt8uDfpysp/7+uBzo8T1F3A8j10hYgvItjtAlJ7YNO+CooWsyiAMI16T+s5TXsut
               jxwmdhk8darOTMHzpgq3UuVd/iOaY+O7h/LTOGVMDFlgTRuf7f11HPQuQCwj+b7UMezylNDq
               CFIx8LNun463BvW8sGbS/F58y+J4zuE2gHN5+0BGnga/YLjIoU6iv4qm54aoB6FAyn33UX7j
               aObck8p4Ofu5+m1Krnho5adMcdzhGSceuwyms2yG/4pdAwHRW+d9emUz7P5u0PjCLlHlfw5l
               KDFvYuSdJ9d//H/WlUFlNx6sl62FH++3c4dnGUbIV4gGlrPlIXvN1zUYbj5Afq5n1WwgWJuz
               vHCMKfmB8aFJXzCnbH9OLdlvh8HjlNsi4kFt9QOU+hSRZC7ElX8v9HZEBIjZha5x+/2UpNg0
               IJbWW+ODqKdOq7IvhmE67FKQaHEaYkLtTL6M/Vg6eTpiCpzhV8ccLOzzN0TYWq/GPhrC16Xe
               zzimJ1SdAVC9hp7V+HshFCYBHRPZ3e/RbgtoDUyEoWgAYrrXY63xrKblnTefNUediVNDVaCF
               m3tfoOPVqIXaS6cFcRmlyQNSbmrT4JynQHrrgLxzKBra/bF4iBN/4y2z8B7vqeA8HN6vSwxF
               cmW1HuBCn15jn9dDSFjx7hx+AR80gvRgPM+2qMeTIYDoasOCFtyNIaAnbUrW5aoHFuRIZHXF
               zPECp2nGW1jE4h3mIFIOhwiXY/+3ljCx3b4U+FTyeDNXsVstPmU3mCtdZYjjSiakvN41x97J
               6kHfWy+2vwvqU6NW8iTyh3fzvfidLxAjn6TsjnfizDX5AcHAUZxSfmXDS5ZOBeQ942hoBqfF
               NrMQfwmKlcTmZDEdPcMMISxywwbGL/iIIiMOjPs3TnqQ0nVgOrSK9C7M2Qb1yHABEVWlgkS+
               XmbM045HCjEwSqWDTplEU/jbhH36ec4rXq6Sk0500eBaEgp1ry+/gMZiK6HU/1KmKkKomEvs
               X0jFVK5lbr+MdeLqgt/cakZWusTiH9h0mTU/0xnM5ipPvokm1gfNgR6vk/j0x96EIoGncV45
               HUthBF/L66VyjYjP3uRwIzwN7vLK2Lz4AHnaqjY3Uvb2cqX/aFH4eoxqlHqtgWkXkQ49HAv3
               95Q2nqarpLEaWhaGYr2SVoy/gNmqqvyeSwh/9mKk2ZhK7e1uTLZncknHq0r0FfofttSNr+FC
               B6nE8AeAJvLSqRikFyoYxQYeeFKof9veZr5MaLciOjxZb8z1CirhmlG/o1nh1iB8yNtEKjV2
               ZdAw/yZ0gaDXTrmgxGtv5OS+8gMaDcME2640SWhCpRWY/g4YYYKBH20Mouzz895gZLgc2VW7
               hitHRlVva3hMQrXdFH70QBKgA4Ppme7nCKj0zFuuyossrLFgmrVzv78dREKIShQSnMkg02mc
               u3Wx5gKGUOvaQYujh6s4033krNaqKpIJG7WWU5UfiLyIglKYu6LrrOHJvV3xtYtuCRTXv67Z
               DiyUbDn5RUAgXqLN1sb/ygycnSRgru8nxF+jwq1N3NvtCCHP9p93wne79HHA+VfxHwIXnsg4
               RHnQ2OkNtzsxu260o/Zu4iWT2WlR5tOdG/gyobS7EOG
IronPort-HdrOrdr: A9a23:kjTlHat5mod89qNCtn1wiBbN7skDhdV00zAX/kB9WHVpW+afkN
                  2jm+le6A/shF8qKRQdsP2JJaXoexLh3LFv5415B8bAYCDDmE+FaL5v9pHjxTqIIUfD38pQz7
                  1pfaQ7KPCYNzZHpP336gW5DNosqePvmJyAv+vYwnt3JDsLV4hb8wx7BgyHe3caeCB6A/MCf6
                  a0145kqza4Q3gRc62AakUtbqzmh/nmqYnvaxxuPW9E1CC+yReh6Lv3CHGjsSsjbw==
References: <20210420080026.GA823@polynum.com>
            <0127509d-02b8-daa7-a49f-6bf459e75cd7@morningstar2.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Message-ID:  <20210420113548.GA5053@polynum.com>
Date:         Tue, 20 Apr 2021 13:35:48 +0200
Reply-To:     Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender:       Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From:         LARONDE Thierry <tlaronde@POLYNUM.COM>
Subject: Re: LaTeX required primitives: some questions
To:           LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <0127509d-02b8-daa7-a49f-6bf459e75cd7@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@gmx.net>
Status: R

Hello,

On Tue, Apr 20, 2021 at 11:36:57AM +0100, Joseph Wright wrote:
> Hello,
> 
> >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.
> 
> If you want to avoid the source of pdfTeX, you are likely best starting with
> descriptions of the 'cross engine' primitives that have been implemented by
> other engines.
> 
> I would start with:
> 
> - l3names. This makes copies of all primitives from all engines supported by
> expl3 into a single namespace. What's important here is that we've worked
> hard to identify which \pdf... primitives are actually PDF-related. Only
> those that relate to PDFs rtain the 'pdf' part of the name (*). See lines
> 605 onward of the current file (https://github.com/latex3/latex3/blob/5b6e6f30397930ba96a2b6744171263b370504d5/l3kernel/l3names.dtx#L605)
> 
> (*) The 'version' primitives \pdftexbanner, \pdftexrevision and
> \pdftexversion  retain 'pdftex' in their names when saved.
> 
> - The XeTeX manual. As XeTeX doesn't directly product PDF output,
>   any primitives it provides are not PDF-specific, naming
>   notwithstanding. (Newer additions to XeTeX omit the \pdf..., older
>   ones do not)
> 
> - The e-pTeX setup in https://www.tug.org/svn/texlive/trunk/Build/source/texk/web2c/eptexdir/pdfutils.ch?view=log,
> which provides the 'utility' primitive. (There is code in this file, but the
> first ~30 lines are purely descriptive)
> 
> >PDF only primitives that I will not implement (correct?):
> >
> >\pdfpageheight
> >\pdfpagewidth
> 
> These work (no error) in DVI mode with pdfTeX, but more importantly in XeTeX
> write information of xdvipdfmx to the XDV file. I would suggest having them
> at least as no-ops.

OK.

> 
> >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:
> >
> >\pdfcreationdate
> 
> This one is linked to the PDF, but not the file system: it's what is written
> to the PDF for /CreationDate.

OK, so it will not be implemented.

> 
> >\pdffilemoddate
> 
> This extracts data about a general file from the file system: it's not
> linked to PDF at all. It might be used for example to check on an image or
> data file.

Yes, but the format is the same as the one emitted by \pdfcreationdate...
(it's not an ISO date).

> 
> >Primitives that seem highly linked to PDF but that can be implemented
> >using ISO C routines:
> >
> >\pdffiledump
> >\pdfmdfivesum
> >\pdffilesize ? (size can be more than integer accepted by TeX)
> 
> Again, these are not linked to PDF at all: they all work in DVI mode. You
> could look at the Lua implementation of these used by expl3 - that avoids
> any GPL code. (We want the same *output* as pdfTeX gives, not the same
> implementation.)

Well, the output seems simple enough that it should not be a problem.

> 
> I don't think I've ever seen a test of what happens if \pdffilesize is used
> on a truly massive file.
> 
> >Primitives whose output seem unclear:
> >
> >\pdfnormaldeviate
> >\pdfuniformdeviate
> >
> >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?
> 
> Each use gives one integer. For example, if I do
> 
>     \pdfsetrandomseed 1234
>     \message{
>       \pdfuniformdeviate 1000\space\space
>       \pdfuniformdeviate 1000\space\space
>       \pdfuniformdeviate 1000\space\space
>       \pdfnormaldeviate \space
>       \pdfnormaldeviate \space
>       \pdfnormaldeviate \space
>     }
> 
> I get "555 3 641 34071 -99169 33759".
> 
> Note that the code for the RNG here comes from MetaPost, and was lightly
> modified to put it into pdfTeX. *Exactly* the same implementation is used by
> XeTeX, pTeX, upTeX and LuaTeX, means that with the same random seed the same
> series of values is obtained independent of the engine used. I would
> strongly urge you to look at the original MetaPost code (I believe not GPL).

Yes, I have seen this and these are implementations of D.E.K's
algorithms. So I will simply use the (adapted to fit) MetaPost's code
too.

> 
> >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
> >be OK?
> 
> As noted, XeTeX has adopted a 'no \pdf...' approach for newer stuff, e.g.
> \strcmp rather than \pdfstrcmp. That works fine provided the names are not
> too generic.
> 

OK.

> >\engine: a read-only ASCII token identifying the engine: ex.: e-TeX;
> 
> This is a very generic name. Moreover, the established pattern is that
> engine define \<name>version and \<name>revision, which can then be used as
> markers for the specific engine. Note that upTeX doesn't do that, and that
> makes identifying that engine more tricky already.
> 

OK, I will use this scheme.

> >\apimajor: a positive or nul integer identifying a definite list of
> >	primitives provided;
> >
> >\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.
> 
> Again, this just feels like \<engine>version/\<engine>revision: see for
> example how older pdftex.def used to check for available features.
> (Standardisation of engine features over recent years means that this is
> generally not needed.)
>

OK, this will be the above.

> >\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.)
> 
> pdfTeX already defines \pdfoutput, which is 0 for DVI and 1 for PDF. LuaTeX
> renames that to \outputmode but with the same numerical values. The version
> of PDF written by pdfTeX/LuaTeX is set separately using (in pdfTeX)
> \pdfminorversion/\pdfmajorversion, as this is really a separate concept to
> whether PDF or DVI is in use.
> 
> There is very little use at the macro level for the DVI level.

For now ;-) Since I plan to add code pages (256 blocks) extensions to be
able, at least, to have a MetaDVI and be able to bypass PostScript and
PDF...

>The PDF level

> does have some impact on output features but in a simply 'Sorry, not doable'
> sense.  Note that XeTeX uses XDV, which is a version of DVI dedicated to
> this engine. It's not necessary to test the DVI version at the macro level:
> what's important is for example which method to include imagines, which uses
> an engine test.
> 
> >\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.
> 
> See above: data in the same format as other engines is strongly preferred.

Well, since there is no real consensus and these are not amongst the
required---and with the identification of the engine, one could \input 
ad hoc macros---I will for now stick to my proposal.

> 
> I notice you don't mention a large number of the other utility primitives.

This is only because I don't have questions about the others :-)


> A full list of those assumed by LaTeX in an engine-neutral sense is listed in
> https://www.latex-project.org/news/latex2e-news/ltnews31.pdf. See in
> particular that \pdfpage(height|width) are included.
> 


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