ATBD & Reference Titles Should allow LaTeX formatting

[aboydnw]

Description

Based on feedback from a user on October 10, 2022.
Titles of scientific papers often have superscript, subscript and other unique characters. Right now, this is a plain text field. For both the ATBD title and the reference title, users need the ability to enter super- and sub-scripts so that scientific paper titles are accurately presented in the reference section.

Tasks

• Create a unicode cheat sheet (commonly used characters) that will be added to APT (just like the LaTeX cheat sheet) (Brad)

Acceptance Criteria

• Unicode cheatsheet submitted to DevSeed for integration into APT

[deborahUAH]

This is a needed feature and will be scheduled as a must-have in PI23.2

[deborahUAH]

An example title needing to be added to the reference section is "Fourier Transform Ultraviolet Spectroscopy of the A²Π_3/2 ← X²Π_3/2 Transition of BrO" This indicates that more than just super and subscripts are needed. Unique characters are also needed.

[wrynearson]

We did some testing/review (thanks @oliverroick). Greek characters (Π, µ, ∑, etc.), as well as all unicode characters work. Oliver was able to recreate the title:

There are unicode superscript and subscript characters (e.g., ², ₂ and others here). The issue seems to be from rich text characters, which is probably coming from copying and pasting from word processors.

The immediate solution is to have users only use unicode characters, which can achieve the goal of having super- and sub-script.

The long term feature, to increase usability, would be to allow for rich text in the title.

cc: @deborahUAH @bwbaker1

[wrynearson]

For future consideration, this would be a time consuming feature to implement., which would require:

• db field update statements
• db migrations for existing docs
• data model update
• switch form component on frontend
• switch render component on frontend
• PDF equivalent

As this is the title field, it can get way more complicated. The title is used in several places (modals, confirmation prompts, emails even), and it will no longer be a simple string. Operations that are trivial on strings, become more complicated on rich fields.

If deemed necessary, we can devise ways around these things, like removing the rich features when rendering in some cases (like the superscript in an email for example), but all these cases have to be found and accounted for.

Thanks @danielfdsilva for this!

[deborahUAH]

@wrynearson @bwbaker1
Just to clarify: So a user needing to enter the reference title above can do so with unicode characters and since the needed changes would require too much effort and time (which we don't have), the better solution is to explain this in the user guide and have a demo of how to ingest a complicated title?
So long as there is a feasible workaround so that no reference needs to be left out due to the tool's inability to incorporate it, I am fine.

[bwbaker1]

@wrynearson @deborahUAH After some brief testing, I think the unicode work around is fine. Like Deborah mentioned, we just need to make sure it is included in the user guide and maybe we can consider something similar like the LaTeX cheatsheet (see below) but with common Greek/unicode characters. Just a thought.

[wrynearson]

Correct @deborahUAH, and good idea @bwbaker1. For Unicode text entry, users can search for their symbol on Google, Wikipedia, etc. and then copy the result.

[wrynearson]

@batpad flagging this issue because it could either be very complex, or a simpler user-driven workaround.

[wrynearson]

@batpad @frozenhelium @kamicut thoughts on this ticket? Now we're relying on users to enter unicode characters.

[wrynearson]

@bwbaker1 @deborahUAH we talked about this ticket as a team earlier today.

One idea that could be a future improvement over the current workflow is to have users input special characters through flagging their special input with a certain character(s). They could then us $\LaTeX$ formatting to input the character they choose.

For example, using the example above:

Fourier Transform Ultraviolet Spectroscopy of the A²Π_3/2 ← X²Π_3/2 Transition of BrO

The use could input the following into the ATBD title field:

Fourier Transform Ultraviolet Spectroscopy of the A{^2]{\Pi}{_3/2} ← X{^2{\Pi}{_3/2} Transition of BrO

Which would be rendered something like this:

Fourier Transform Ultraviolet Spectroscopy of the $A^2\Pi_{3/2} ← X^2\Pi_{3/2}$ Transition of BrO

Let us know your thoughts. We could then investigate this in a future sprint. I can't estimate the level of effort yet but it would take some time to ensure that all of the fields that we use doc titles and reference titles would support this.

cc @batpad @frozenhelium

[bwbaker1]

@wrynearson Anthony suggested we complete this ticket sooner than later because it could complicate things once we have existing public ATBDs.

I'm still okay with copy/paste unicode characters, but we need to inform users somehow of this capability.

[wrynearson]

@sunu @frozenhelium @kamicut @batpad @thenav56 any additional thoughts on how we can implement additional characters / rich text in titles? It'd be nice to scope this out and come up with a good solution.

[sunu]

@wrynearson If we go the LaTeX route described in #586 (comment), we will only require frontend changes to render the proposed syntax.

[wrynearson]

Update – the initial infrastructure is in place (see NASA-IMPACT/nasa-apt-frontend#533). We'll keep the PR open while @frozenhelium adds:

1. Information for the users
2. A live preview of the title field, so users can see if the $\LaTeX$ they've entered is correct.

[wrynearson]

@bwbaker1 this is ready for your review. Please see NASA-IMPACT/nasa-apt-frontend#533 for some screenshots and context.

[bwbaker1]

@wrynearson This looks good to me.