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. PDF only primitives that I will not implement (correct?): \pdfpageheight \pdfpagewidth 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 \pdffilemoddate 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) 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? General question: What is the behavior expected on error (syntax error; out of range)? Modifications: 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? Primitives I plan to add (RFC): \engine: a read-only ASCII token identifying the engine: ex.: e-TeX; \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. \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.) \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. Note: I will work progressively on this when I have a sufficient slot of time. So no timeline set. Best, -- 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