LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

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

Print Reply
LARONDE Thierry <[log in to unmask]>
Tue, 20 Apr 2021 13:35:48 +0200
text/plain (227 lines)
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

ATOM RSS1 RSS2