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

Option to open the PDF associated to one test file #279

Open
projetmbc opened this issue Feb 23, 2023 · 3 comments
Open

Option to open the PDF associated to one test file #279

projetmbc opened this issue Feb 23, 2023 · 3 comments
Assignees

Comments

@projetmbc
Copy link

projetmbc commented Feb 23, 2023

To test the visual output of a macro, we need to see the PDF to accept or reject a test.

As far as I know, at the moment, if I use for example l3build save test1, I have to open build/test/test1.pdf by hand. It would be very useful to have an option like l3build save --pdf test1 that opens the PDF file if it exists.

This new feature should be customizable inside the build.lua file, such as to indicate the tool used in the command line launched. For example, on macOS, the command open build/test/test1.pdf works, but this would fail on most Linux OS.

@FrankMittelbach
Copy link
Member

I like the feature but maybe it needs a bit though how to best inferface that. Maybe --view and some variable to set the view command if necessary (with some defaults based on default save engine and platform?

@josephwright
Copy link
Member

I guess my immediate thought is 'does this go with save'? That, well, changes the .tlg, which if you are not sure it's right seems a bit odd. I'd imagine more it goes with check , but when only one engine is in use (also one test?):

l3build check --view foo

Perhaps if given without --engine we assume that the standard engine is required? And if --engine is given, we use only the first name?

@projetmbc
Copy link
Author

projetmbc commented Sep 28, 2024

What about just adding a view option like l3build view foo. This could be implemented like this when launching the l3build.lua relatively its dir:

-- TOY CODE: do not use it in serious live! :-)

VIEW_TAG = "view"

function viewPDF(xtra_args)
  if xtra_args == nil or #xtra_args ~= 1
  then
    print("One single test file name needed!")
    return 1
  end

  testfilename = xtra_args[1]
  pdffile = "build/test/" .. testfilename .. ".pdf"

  if fileexists(pdffile) == false
  then
    print("No PDF file found.\nSee: " .. pdffile)
    return 1
  end

-- Works on MacOS, but not on Linux.
  trycmd = run(".", "open " .. '"' .. pdffile .. '"')

  if trycmd ~= 0
  then
    print("No command to open PDF files.\nSee: " .. pdffile)
  end

  return 0
end

target_list[VIEW_TAG] = {
  func = viewPDF,
  desc = "Open a PDF of tested files",
--   pre = function(xtra_args)
--   end
}

A serious API could work like this.

  1. The user can specify a command used to open a PDF.
  2. If no command is specified, we can print the PDF path if the file exists. This can be useful in iterm2, for example, which allows clicking on path to open the associated dir or file.

It remains to build more seriously the PDF file path by respecting the user setting.

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

No branches or pull requests

3 participants