Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollback declarations should be improved in several files #1336

Closed
user227621 opened this issue Apr 25, 2024 · 2 comments
Closed

Rollback declarations should be improved in several files #1336

user227621 opened this issue Apr 25, 2024 · 2 comments

Comments

@user227621
Copy link

This is separated from #1333.

Some files distributed as part of latex2e have rollback declarations like the following (from graphics.sty):

\NeedsTeXFormat{LaTeX2e}[1995/12/01]
\providecommand\DeclareRelease[3]{}
\providecommand\DeclareCurrentRelease[2]{}

\DeclareRelease{}{2017-06-25}{graphics-2017-06-25.sty}
\DeclareCurrentRelease{}{2019-10-01}

There are two issues with the above:

  1. As discussed in Loading textcomp turns LaTeX Info messages into Package textcomp Info messages #1333, it would be better to remove these two lines:
\providecommand\DeclareRelease[3]{}
\providecommand\DeclareCurrentRelease[2]{}
  1. Rolling back to a date before 2017-06-25 in the above example fails although the graphics package existed long before 2017. This could be fixed by adding an additional \DeclareRelease{}{<date>}{<file>} line (which would require finding out when the packages were first released).

The following files from base, amsmath, graphics and tools contain \DeclareRelease declarations and are potentially affected by the issues described above:

doc.sty
amsmath.sty
graphics.sty
array.sty
array-2020-02-10.sty
longtable.sty
multicol.sty
multicol-2019-10-01.sty
showkeys.sty
varioref.sty

@davidcarlisle
Copy link
Member

Moving here as comments in PRs not so easy to reference later if fixed in a separate PR

Currently rolling back luatex prior to 2015 gives

! Undefined control sequence.
\@ifundefined ...e \expandafter \ifx \lastnamedcs 

as unprefixed luatex commands are undefined by the rollback.

We could do

  for _,i in pairs(tex.extraprimitives("luatex")) do
  if not string.match(i,"^U") then
        if not (string.match(i, "^luatex") or i == "lastnamedcs") then
                                                          %^^^^^^^^^^^

so that \lastnamedcs which is used within latexrelease.sty is left defined.

or we could define it under a custom name and then arrange to use that name for all engines within latexrelease (but that seems unnecessarily complicated) or we could remove the whole

  local i
  local t = { }
  for _,i in pairs(tex.extraprimitives("luatex")) do
    if not string.match(i,"^U") then
      if not string.match(i, "^luatex") then
        table.insert(t,i)
      end
    else
      if string.match(i,"^Uchar$") then
        table.insert(t,i)
      end
    end
  end
  for _,i in pairs(t) do
    tex.print(
      "\noexpand\\let\noexpand\\" .. i
        .. "\noexpand\\undefined"
    )
  end

block so leave luatex primitives with both prefixed and unprefixed names in the rollback.

I suspect this last version is most likely to lead to a successful emulation if just the format is rolled back but used in a current tex system with current packages expecting luatex names.

In particular for graphics the first change allows latexrelease to load but then the package errors as

! Undefined control sequence.
l.28       \ifnum\outputmode

If the whole block is removed so \outputmode is defined then this progresses further

The suggested graphics.sty change of using

\DeclareRelease{}{1994-06-01}{graphics-2017-06-25.sty}

Then works with the current lualatex but fails on all engines with -dev as you get

Runaway argument?
"example-image.pdf" \edef \Gin@ext {\Gin@sepdefault \filename@ext }\ifx \ETC

as kernel utf8 filename normalisation it's expecting a catcode 12 .pdf but the rolled back package is using a catcode 11.
but I haven't traced fully yet.

@davidcarlisle davidcarlisle mentioned this issue Apr 27, 2024
5 tasks
@davidcarlisle
Copy link
Member

actually I think the runaway error is just an artefact of my tests,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

3 participants