Latex2Unicode should parse journal macros from ADS/Harvard

[Siedlerchr]

Not sure whether we have to add an exclusion list or the Latex2Unicode converter itself.

http://discourse.jabref.org/t/ads-harvard-entries-contain-latex-commands-leading-to-a-blank-field-in-list-view/685

[lenhard]

I disagree. The problem is that the ADS system produces invalid BibTeX, i.e. code with macros that can only be read when you use their packages. They have quite a lot of custom macros for journals, see: http://adsabs.harvard.edu/abs_doc/aas_macros.html From the point of view of data portability this is terrible. They should much rather just have included the journal names.

JabRef is a general purpose BibTeX manager. I am opposed to implementing a workaround for one particular type of sources and we've decided against this for other sources on multiple occasions. Also, such a workaround would degenerate performance even further.

The only option I can see is to ask @tomtung if there's a potential of changing the converter or making it a little more configurable. Right now, unknown latex commands are simply eliminated. It might be a compromise if the converter could be configured to keep them instead.

[tobiasdiez]

In principle, I don't see any reason why we shouldn't support latex commands from other packages. It is just time that someone of us has to invest and create a PR. In the end, the corresponding commands only have to be added in the conversation map https://github.com/tomtung/latex2unicode/blob/master/src/main/scala/com/github/tomtung/latex2unicode/helper/Escape.scala.

However, I don't think that one of the core developers have time right now for this and thus I'll put this issue on hold.

[Knusper]

ADS is the default database in the astronomical community. I asked my colleagues how they deal with this issue, and those who use JabRef answered: "I am still using 2.11 because of this issue." The behaviour in 2.11 is that the macro is just displayed in the journal name field. I don't know why this is not the case anymore or what is preventing you from adding an option to display this issue, but this reason basically forces astronomers to still use the older version.

[tobiasdiez]

@Knusper You can easily help us here and add the missing journal macros here. The syntax should be self-explanatory and you can edit the file directly in your browser (click the pencil icon above the code listing). This would be a huge help. Thanks!

[Knusper]

Thanks, I will have a go at this. Indeed, I have a complete set of the ADS Journal Abbreviations macros here: http://cdsads.u-strasbg.fr/abs_doc/aas_macros.sty

Now we have to take a decision. In the contemporary astronomical literature journals are often abbreviated (e.g. MNRAS instead of Monthly Notices of the Astronomical Society).
So, should I expand to full journal names, or to the journal abbreviations that are common in the astronomical literature.You can see this in the AAS Macro list (this is used for ApJ, AJ, and some other AAS Journals. I do not know of any reasonably high-impact journal in astronomy that has not adopted to this convention, so I would prefer the abbreviated journal names.

[Knusper]

@tobiasdiez can you re-open this and assign it to me? And can we change the title of the bug "Latex2Unicode should parse journal macros from ADS/Harvard"?

[tobiasdiez]

Nice to hear that you are working on it! I can't assign the issue to you since it is your first contribution.

I would prefer the long un-abbreviated journal title. We may add a feature in the future that allows for a consistent display of un-abbreviated or abbreviated journal titles (we already have a pretty huge list). Then it is better to have the complete name instead of a possibly ambiguous abbreviation.

[Knusper]

Hey, so I was checking into this again. I don't think the file https://github.com/tomtung/latex2unicode/blob/master/src/main/scala/com/github/tomtung/latex2unicode/helper/Escape.scala is where the journal macros should go. Maybe @tomtung should comment on this?

[Knusper]

Issue still not resolved.

…

On Thu, Dec 31, 2020, 16:50 github-actions[bot] ***@***.***> wrote: This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs. As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form: - If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing). - Provide further steps or information on how to reproduce this issue. - Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process. - If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant. Thank you for your contribution! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2999 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABD4RFWHBZO7GHR2YJRJZUDSXTIXTANCNFSM4DSWE3ZA> .