On Monday, July 28, 2008, at 12:01PM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: > >On 28 Jul 2008, at 8:44 PM, Adam R. Maxwell wrote: > >> >> On Monday, July 28, 2008, at 07:56AM, "Christiaan Hofman" <[EMAIL PROTECTED] >> > wrote: >>> >>> On 28 Jul 2008, at 3:59 PM, Adam R. Maxwell wrote: >>> >>>> >>>> On Jul 28, 2008, at 2:13 AM, Christiaan Hofman wrote: >>>> >>>>> Yes, I see the warning now. Should be harmless. >>>>> >>>>> I inserted the newlines for saving to avoid long lines. The base64 >>>>> parser in the Omni frameworks ignores garnage characters like >>>>> newlines >>>>> and spaces. >>>> >>>> [...] >>>> >>>>> The heuristic is as follows: anytime we have a >>>>> newline >>>>> * in a string, that's reason to suspect a runaway. >>>> >>>> [...] >>>> >>>>> So it's the newline in the long string in combination with the >>>>> "=" at >>>>> the end that triggers the warning. >>>>> >>>>> Anyway, it's harmless. >>>> >>>> In general, that warning is not harmless, so users shouldn't get in >>>> the habit of ignoring it. Unfortunately, it will likely be quite >>>> common now since = often appears at the end of a base64 encoded >>>> string. >>> >>> >>> Perhaps we could remove the "=" padding at the end, and re-attach >>> them >>> if necessary? >> >> That sounds worse than the warning, and a potential nightmare for >> compatibility. If you implemented this, then saved a file with a >> nightly build, could you then read it with 1.3.18? If not, I'd >> guess that a few users would be fairly upset. Not that it matters >> to me personally...I'm using openssl for base64 in my own version. >> >> Why add newlines in the first place? A single line is easier to >> ignore in text editors that allow long lines, and updates to the >> alias will only cause a single-line diff for people who use version >> control systems. Inserting newlines seems like a solution in search >> of a problem. >> > >Some programs reading bibtex have problems with long lines, as we've >encountered before.
Is that a problem with the file fields? They're placed at the end of each item in the BibTeX output specifically to avoid the buffer length problem (ISTR adding a comment on that to BibItem.m). Annote/Abstract still default to the top of the item in order to preserve backwards compatibility for version control users, so they'll unfortunately cause problems for some users. >We certainly should accept added newlines, because other bibtex or >plain text editors may insert them. Absolutely, and fortunately Omni's base64 conversion handles that as you noted. If a user mucks about in the .bib file with a text editor or pretty-printer, the results are his own fault :). The openssl BIO functions have a flag to allow newlines, but it didn't work with Rolf's snippet for some reason (possibly the additional whitespace in the email). I should look into that if I get bored... ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
