rstudio / rticles

LaTeX Journal Article Templates for R Markdown
https://pkgs.rstudio.com/rticles/
1.47k stars 519 forks source link

ajs journal included #437

Closed matthias-da closed 3 years ago

matthias-da commented 3 years ago

To contribute a new article template to this package, please make sure you have done the following things (note that journalname_article below is only an example name):

Lastly, please try your best to do only one thing per pull request (e.g., if you want to add two output formats, do them in two separate pull requests), and refrain from making cosmetic changes in the code base: https://yihui.name/en/2018/02/bite-sized-pull-requests/

Thank you!

CLAassistant commented 3 years ago

CLA assistant check
All committers have signed the CLA.

cderv commented 3 years ago

Hi @matthias-da

Thanks for the contribution. I am preparing a release for this week, so timing is right. I will review this and hopefully we can end the work quicly.

To ease the review, I'll merge master into this branch to get the correct diff. Some changes are not right currently.

matthias-da commented 3 years ago

Before going further into the review, I need to clarify something.

I see this is a template similar to JSS article: jss_article().

What is exactly the difference between both format ?

It seems we currently have duplication between both and only the documentclass is changing. Am I right ? Is there more ?

Thanks.

Indeed I with Achim Zeileis at the same University for some time and with his full commitment the Austrian Journal of Statistics uses only a slightly modified version of the Journal of Statistical Software (than Achim made) since 2013. It's only about 20 lines that differs in the 500 lines .cls file. It's great to have this for our traditional Journal (since the 60ties) from the Austrian Statistical Society. With such help we are able to run it open-access without fees.

cderv commented 3 years ago

Thanks for the precision !

If this is only the cls file that change, we may think of something else for rticles than duplicating the entire function.

From what I understand and see from this PR:

This means that currently, you are able to use jss_article() with a ajs.cls using this YAML header

---
documentclass: ajs
output: rticles::jss_article
---

Do we agree on this ?

Before looking at solution, we must agree on the "problem" to solve here:

Am I missing something ?

From there, I see several solutions:

Anyway, we should find a solution that suits your initial aim but we won't duplicate code the way it is currently done in the PR.

I need you to clarify the aim and the user experience. What is the desired behavior ? After that, I'll do the correct modification in the code base.

Thanks for your help

matthias-da commented 3 years ago

Dear Christophe,

thanks a lot for all this work. Currently, ajs has different .cls, skeleton (guidelines) and images. To your questions.

Before looking at solution, we must agree on the "problem" to solve here:

_jssarticle() works for AJS if you provide the right .cls and .bst file

correct

Those resources are not included in the package already.

I'm sure that I put them within the pull request under inst/rmarkdown/templates/ajs/skeleton/

It would be great to be able to write for AJS without having to download the CLS file.

Absolutely agree on this. Thus I would like to ask you to put them in inst/rmarkdown/templates/ajs/skeleton/. If I missed something on this, I'm happy to follow up on this.

Proposed solutions:

  1. To have a few lines of duplicated code. Everything will surely work and probably in future we differ to JSS also in template and jss_article(). This would be far the easiest solution (I would keep it rather simple) and we will be more flexible in future.

  2. In case you want to strictly avoid this, I would go for a solution for that users can use ajs_article() without knowing jss (we thanked in our guidelines to JSS and Achim)

ajs_article <- jss_article

I think we should strictly avoid to name jss in any call from users, i.e. many of our authors might be confused, and thus a solution like this in the following is not a the best one in my point of view:

output: jss_article: variant: ajs

It would be great to have ajs_article() independent from jss_article from the user perspective. What do you think? Thanks a lot.

cderv commented 3 years ago

It would be great to have ajs_article() independent from jss_article from the user perspective. What do you think?

I understand the reason you are giving. We'll offer a ajs_article() format then.

In case you want to strictly avoid this,

It is really not good practice to exactly duplicate the code of JSS. If the same behavior is required, then we'll use the function under-the-hood. The user does not need to know. If we need a different behavior, then we need to refactor into shared functions. But we don't want to have copy pasted part (which here is a whole file) in our code base.

Do you want to try to adapt the PR this way, avoiding the duplication ? I believe this is possible unless I missed something. This could require an adaptation of the current function though so that jss_article() can take an argument to choose the template, or we need to refactor the internals to use it in both jss_article() and ajs_article() - the later is probably better practice.

I can take it from here if you prefer.

matthias-da commented 3 years ago

I can take it from here if you prefer.

You are much more into the code and package of rticles, so this would be great, and probably less work compared to answer my potential difficulties and follow-up questions. Thanks a lot.

matthias-da commented 3 years ago

I just tested it. Looks great and does the job. Thanks a lot Christophe @cderv !

For the small issues regarding \section{}, href and preamble: of course, all ok (and better). I guess it's easier for you to change these three minimal issues as to handle a new pull request?

cderv commented 3 years ago

guess it's easier for you to change these three minimal issues as to handle a new pull request?

Those suggestion are made in the review so that you can easily accept them normally. http://haacked.com/archive/2019/06/03/suggested-changes/

I'll add them.

cderv commented 3 years ago

Thanks @matthias-da !