Skip to content

Commit

Permalink
Correctly convert BibTeX entries containing a carriage return
Browse files Browse the repository at this point in the history
Fixes #23
  • Loading branch information
michel-kraemer committed Nov 20, 2016
1 parent f05e1bf commit 729ca2c
Show file tree
Hide file tree
Showing 2 changed files with 16 additions and 1 deletion.
Original file line number Diff line number Diff line change
Expand Up @@ -175,7 +175,7 @@ public CSLItemData toItemData(BibTeXEntry e) {
//get all fields from the BibTeX entry
Map<String, String> entries = new HashMap<>();
for (Map.Entry<Key, Value> field : e.getFields().entrySet()) {
String us = field.getValue().toUserString();
String us = field.getValue().toUserString().replaceAll("\\r", "");

This comment has been minimized.

Copy link
@chriba

chriba Nov 21, 2016

It would be better if \r is replaced by a space since currently the lines would be connected which changes their meaning.

This comment has been minimized.

Copy link
@michel-kraemer

michel-kraemer Nov 21, 2016

Author Owner

I thought about this too, but actually \r should never appear alone. There should always be a \n too (like in the unit test below). \n is replaced by space.

This comment has been minimized.

Copy link
@koppor

koppor Nov 21, 2016

When the bibtex is produced on linux, it is unlikely that it follows the windows CRLF style.

This comment has been minimized.

Copy link
@michel-kraemer

michel-kraemer Nov 21, 2016

Author Owner

@koppor Do you have bibtex files containing only \r and not \n? This is very unlikely. Which program creates such files?

This comment has been minimized.

Copy link
@michel-kraemer

michel-kraemer Nov 21, 2016

Author Owner

Maybe a file from Mac OS 9?

This comment has been minimized.

Copy link
@michel-kraemer

michel-kraemer Nov 21, 2016

Author Owner

The fix is quite easy, actually. See here dc800d1.


//convert LaTeX string to normal text
try {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,7 @@
import org.jbibtex.BibTeXDatabase;
import org.jbibtex.BibTeXEntry;
import org.jbibtex.Key;
import org.jbibtex.StringValue;
import org.junit.Test;

import de.undercouch.citeproc.csl.CSLItemData;
Expand Down Expand Up @@ -122,4 +123,18 @@ public void allEntries() throws Exception {
assertEquals("The UNIX Time-Sharing System", cid.getTitle());
assertArrayEquals(new int[][] { new int[] { 1974, 7 } }, cid.getIssued().getDateParts());
}

/**
* Test if a BibTeX entry whose title contains a CR character (\r) can
* be converted correctly.
*/
@Test
public void carriageReturnInTitle() {
BibTeXEntry e = new BibTeXEntry(new Key("article"), new Key("a"));
e.addField(new Key("title"), new StringValue(
"syst\\`emes\r\ndiff\\'erentiels", StringValue.Style.QUOTED));
BibTeXConverter conv = new BibTeXConverter();
CSLItemData i = conv.toItemData(e);
assertEquals("systèmes différentiels", i.getTitle());
}
}

3 comments on commit 729ca2c

@koppor
Copy link

@koppor koppor commented on 729ca2c Nov 21, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reading http://stackoverflow.com/questions/1761051/difference-between-n-and-r, I think, \r is never is used in 2016 and the test case in JabRef should be adopted accordingly. We thought that \r was the issue, because of

Bad character inside entry Lexical error at line 1, column 97. Encountered: "\r" (13), after : ""

Full issue at JabRef/jabref-koppor#174

https://github.com/JabRef/jabref/blob/master/src/test/java/net/sf/jabref/logic/citationstyle/CitationStyleGeneratorTest.java#L16

entry.setField(FieldName.AUTHOR, "Doe, John and \rDoe, Jane");

should become

entry.setField(FieldName.AUTHOR, "Doe, John and\nDoe, Jane");

@michel-kraemer
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification. Does this suggest that I should revert dc800d1 and go back to the behaviour from 1.0.1?

@koppor
Copy link

@koppor koppor commented on 729ca2c Nov 21, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please revert. My issue described at JabRef/jabref-koppor#174 is fixed by using version 1.0.1 of the library.

Please sign in to comment.