-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
CSL and entry table renders $ only, when it is backslashed. E.g. \$ #8650
Comments
This is related to the latex2unicode formatter. The latex2unicode formatter is called for the main table for each field. |
The Another additional option would be to add a (library) preference that allows users to choose the encoding that is ASSUMED to apply to the library. E.g. assume:
When choosing Latex, then the LaTeXtoUnicode formatter could apply when calling the entry preview. In #8490 (comment) I have already shown that it only leads to problems when different encodings are used by users within the same bibliography. Users should EITHER have everything in LaTeX syntax, everything in Unicode or everything in html (I have never used html syntax, so don't ask xD). This preference would help keeping bibliographies consistent to the chosen encoding, because users could compare their changes directly to the given CSL output. What do you think? Please correct me, if there is an obvious flaw in this reasoning. |
Ok, looking at this from a different perspective: If we wanted to write a test, this is what we would need to test:
|
Hello, I wanna have a try to solve this problem. Can I give it a shot? |
Sure, you can :-) Suggestion for solution: Add preference to choose (or allow disabling) different formatters (e.g. "Latex2unicode", "Unicode2LaTeX" or simply "Unicode") to be called for entry preview somewhere here: @Siedlerchr What do you say? Good idea? Bad idea? |
@0CoolMichael, as a general advice: Check out https://github.com/JabRef/jabref/blob/main/CONTRIBUTING.md for a start. Also, https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace are worth having a look at. Feel free to ask if you have any questions here on GitHub or also at JabRef's Gitter chat. Try to open a (draft) pull request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback. |
Thanks you for your suggestion, and I will try it out in the next few days. |
I'm not yet sure how feasible this is. I would go with the entry preview first. The table is more complex |
After thinking, I think that I should add a "ListView" component in the "Entry Preview". And there should be three choices called HTML, Unicode and LaTex. If one of them is clicked, I should invoke corresponding formatter to convert the text in preview. Is the thinking right? If so, I will start it right now. |
@0CoolMichael I strongly believe that you misunderstood the issue. This is not about a new feature that should be implemented, but a bug in rendering / parsing text in a bibfile and / or presenting it in the entry preview window. The improvement @ThiloteE later proposed is about a preference option of how to parse text in a bib file. The scenebuilder is nice, but breaks if custom made javafx controls are used. SceneBuilder can only handle vanilla javafx controls and those, that can be imported. JabRef has not implemented support for SceneBuilder, so you have to edit the fxml-files like in the good old days of web design, when html-pages were written by hand. ;-) Please use the Gitter-Chat for general coding questions about JabRef, so we can keep the discussion in the issue description short and issue-related. Otherwise one who would want to understand this issue would have to read pages of utterly useless words for him. |
JabRef version
Latest development branch build (please note build date below)
Operating system
Windows
Details on version and operating system
JabRef 5.6--2022-04-04--dbf921e Windows 10 10.0 amd64 Java 17.0.2 JavaFX 18+12
Checked with the latest development build
Steps to reproduce the behaviour
Workaround: use
\$
Appendix
No response
The text was updated successfully, but these errors were encountered: