No way to get `fullcite` behavior
Currently, the achemso package uses the natbib formatting scheme. I have been able to work around most of the limitations brought about by using this package scheme, but there is one task which is nearly impossible. Providing an in-line full citation, as one might want to do in a response to reviewers. The achemso package is wholly incompatible with the most common way to accomplish this, using the bibentry package. It would significantly improve the utility of the package if either a macro for full inline citations were added, or if the incompatibility with bibentry were solved.
I have a change committed: you mentioned other issues, so before I release, is there anything specific I should look at?
Thanks for your assistance with this!
Since you asked, most of the issues I have are related to the supporting information and my response to reviewers.
I'm not certain if this is on purpose, but formatting supporting information is quite a challenge, and I wasn't able to get it quite how I wanted.
Ideally (in my opinion) if you create a figure within the suppinfo environment, the counter should reset, and the ref should read S#1 instead of #1. I created my own sfig environment to get that behavior, but it's a common enough task that it seems like it should be the default behavior.
Code snippet of my sfig environment below:
\DeclareFloatingEnvironment[
fileext=sup,
listname={Supporting Figures},
name=Figure,
placement=tbhp,
within=none,
]{sfig}
\DeclareCaptionLabelFormat{sfigs}{\textbf{#1} S#2}
\captionsetup[sfig]{labelformat=sfigs,labelsep=colon}
Additionally, most published SI sections have a reprint of the full title block in them. I spent a good long while trying to get a second instance of \maketitle working, but to no avail. Admittedly, some of this is just my PI being pedantic about formatting, and wanting things to look exactly like a final article proof, but it would be nice for the suppinfo section to have the option to invoke the title again.
Many of my other issues have come from trying to make a response for reviewers in the same Overleaf document as the main text. It allows for convenient refs of the main text, but it doesn't always play nicely with some of the achemso macros.
I'm guessing that these things are more than could be handled in a patch release, but they're the main pain points that I've run into when using the package.
I'm not certain if this is on purpose, but formatting supporting information is quite a challenge, and I wasn't able to get it quite how I wanted.
From your description, it sounds like you were trying to put the supplementary information into the suppinfo environment, rather than in a separate document. The idea of suppinfo was really it's like abstract, a handy semantic way to mark up a small block of text.
I think that makes sense to an extent, but if you want to reference the supporting info figures in the main text, having a completely separate document complicates the referencing quite a bit, especially in Overleaf. I've figured out how to make that work for my response to reviewers, but I think it's not an ideal solution. As an author, I'm constantly moving things between the SI and the main text to try to find the right balance, and having to issue separate compile commands for both is a significant workflow interruption.
I can respect the decision to use it for small text formatting, but I think the verbiage in the user documentation should be changed to reflect the limited scope.
Something like:
The sections for acknowledgements and supporting information have dedicated environments available. These ensure that the section headings are generated, and that the text size is corrected when creating a communication. Note that the suppinfo environment is primarily intended for small to medium blocks of text. For articles with extensive supporting information, including figures, the creation of a separate document is recommended. Overleaf users may refer to this guide (https://www.overleaf.com/learn/how-to/Cross_referencing_with_the_xr_package_in_Overleaf) for a way to have consistent citations between multiple separately compiled documents.
(From Section 4.5 - Special Sections of the current version of the user documentation on CTAN)