Use of CR or LF in exported GEDCOMs

[philipt18]

I was testing the export of a GEDCOM from Reunion 11.07 and importing it into GRAMPS 4.2.1, and it choked on the import. GEDCOM 5.5 with UTF-8 character set. After a brief discussion on the GRAMPS bug tracker, they seem to think the problem is that the GEDCOM is using CR (\r), and GRAMPS was expecting LF (\n). From what I understand Mac OS X normally uses LF (as opposed to OS 9 and before which used CR).

Is Reunion still using CR line endings? Perhaps this was initially for backwards compatibility, but at this point, is it really necessary? In either case, could there be at least a preference to use LF instead of CR?

[Dennis J. Cunniff]

Re: Use of CR or LF in exported GEDCOMs

After a brief discussion on the GRAMPS bug tracker, they seem to think the problem is that the GEDCOM is using CR (\r), and GRAMPS was expecting LF (\n).

There may be a more direct answer (diff. character set, e.g.), as I haven't investigated the actual GEDCOM output.

But TextWrangler/BBEdit would let you load in the GEDCOM file and then export it with your choice of line breaks. (Unix = LF, Classic Mac = CR, Windows = CRLF).

[Gregg]

Re: Use of CR or LF in exported GEDCOMs

GRAMPS was expecting LF (\n)

GRAMPS should be expecting: [CR] or [LF] or [CR LF] or [LF CR]

From the GEDCOM spec...

http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch1.htm

terminator :=
The terminator delimits the variable-length line_value and signals the end of the gedcom_line . The valid terminator characters are:
[carriage_return |
line_feed |
carriage_return line_feed |
line_feed carriage_return ]

GEDCOM files created by Reunion end with CR ("\r") -- the first option listed in the GEDCOM spec. I would be very surprised if any established genealogy program were having problems with Reunion's line endings.

[philipt18]

Re: Use of CR or LF in exported GEDCOMs

I'm sure it's in the spec, but I'm just wondering why Reunion still uses CR when Mac OS X no longer uses it. I assume the original reason Reunion used CR was because Reunion was on Classic Mac OS, but now, why not switch?

As for GRAMPS, it turns out it's a bug related to the switch from Python 2 to Python 3 recently. Normally, Python converts all line endings to LF anyways, but they're reading it in binary mode or something like that, and it retains the original line endings. Apparently before the switch they never needed to consider CR as an option because Python was converting it to LF anyways, but due to the way they're reading the files and how the function changed in Python 3, that's no longer the case. They're working on a fix.

[Gregg]

Re: Use of CR or LF in exported GEDCOMs

I assume the original reason Reunion used CR was because Reunion was on Classic Mac OS, but now, why not switch?

GEDCOM files are exported from Reunion on a character-by-character basis using functionality that is in no way tied to the operating system's preference for line ending. The line endings in the exported GEDCOM file have never (for Reunion) had anything to do with the current platform. There would be no reason to do that, most GEDCOM files are destined for Windows or the Web -- not another Macintosh.

Our decision to "still" use [CR] line endings was consciously made because it's caused the least amount of compatibility issues with other genealogy applications. Namely Windows based programs which sometimes expect [CR LF] but do not have a problem if the LF was missing -- while, some Macintosh software would not be happy with the extra LF after the CR.

[riegelstamm]

Re: Use of CR or LF in exported GEDCOMs

I agree with Gregg; the standard allows for carriage_return OR line_feed OR carriage_return + line_feed OR line_feed + carriage_return, so Gramps just needs to fix their bug. It's good to know that TextWrangler change change the line feeds.