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

Entry preview: wrong display of apostrophe (treated as special character) #2500

Closed
mlep opened this issue Jan 30, 2017 · 7 comments · Fixed by #2507
Closed

Entry preview: wrong display of apostrophe (treated as special character) #2500

mlep opened this issue Jan 30, 2017 · 7 comments · Fixed by #2507
Labels
bug Confirmed bugs or reports that are very likely to be bugs

Comments

@mlep
Copy link
Contributor

mlep commented Jan 30, 2017

JabRef version 3.8.2 and JabRef-4.0.0-dev--snapshot--2017-01-29--masr--7191a7055.jar
on Linux LMDE Betsy

Steps to reproduce:

  1. Create a new entry
  2. As title of the article, type L'oscillation (for example)
  3. In the table entry, the title is displayed as Lòscillation
    Note: the display is OK in the entry preview

apostrophe

@lenhard
Copy link
Member

lenhard commented Jan 30, 2017

The reason for this is that we are doing a LaTeX to unicode conversion for the entry table. Unfortunately, the plain text L'oscillation can be interpreted as valid LaTeX. There is no clean way to solve this issue, as there is no way to know that this text is not meant as LaTeX.

The only thing I can think of is to offer a preference option to turn of LaTeX rendering for the main table. So that people can decide what is more important to them: LaTeX rendering including the above error, or no LaTeX rendering. @JabRef/developers WDYT?

@matthiasgeiger
Copy link
Member

matthiasgeiger commented Jan 30, 2017

Isn't the "correct" LaTeX command (without the usage of special packages) {\'o} or \'{o}?

@lenhard
Copy link
Member

lenhard commented Jan 30, 2017

@matthiasgeiger Indeed! Stupid me, I should have tested this in a tex editor directly! In this case, it is just a bug in our converter, which is something that can be solved :-) Preferably with #2465

@lenhard lenhard added bug Confirmed bugs or reports that are very likely to be bugs ui and removed type: question ui labels Jan 30, 2017
@mlep
Copy link
Contributor Author

mlep commented Jan 31, 2017

Similar issue with some TeX special characters.
For example, Topo\_2d is displayed as Topo2d (no underscore)

@lenhard
Copy link
Member

lenhard commented Jan 31, 2017

The more issues we get in the display, the more I am convinced that we should use an external library for tex to unicode conversion.

@AEgit
Copy link

AEgit commented Jan 31, 2017

Similar issue with author name (with Preferences set to LatexToUnicode instead of HTMLChars):

O'Connor

is displayed

as

OĆonnor

@lenhard
Copy link
Member

lenhard commented Feb 1, 2017

So, after some contemplation, I am almost certain that the issues described here are caused by this PR: #2464

There, I implemented special handling for 'n, which really is a valid in LaTeX. Unfortunately this seems to have affected all other occurrences of ' and other letters. @JabRef/developers We should probably revert #2464 and go for a new solution for #2458.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs or reports that are very likely to be bugs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants