I think I know what causes this bug, see below please.
Testing version: 2.0.9 (11930) on Ventura 13.5.2
What were you doing:
Just trying to create notes with tables. Also I was inserting (not typing) multi-line text into table’s cells that I copied from another source (from a PDF).
What feature did you use
Tables.
What happened:
Tables broke pretty often, but I also created other notes with table which did not break. Later I realized what made them break and it was a specific pattern: copying/inserting multi-line text from that PDF.
Btw, table did not break right away, but either after I closed the note and then came back/reopened the note - that’s when the table appeared broken. Or, another case, if I copied and pasted the table, then it broke right away.
By breaking I mean this: the header looked ok but the rest was scrambled. The text was there mixed with some table markup (| and
). But it was no longer a table.
What did you expect to happen:
Not that.
So I looked at the multi-line text I was inserting in a text editor with hex support (I was looking at the note after I exported it after it broke) and it appears that the problem was that the line breaks where encoded as 0d (carriage return) instead of 0a (new line) in the source - i.e. in the PDF. It’s possible that’s what caused the issue. When I copied these lines they were not processed properly. Looks like bear’s code replaces line breaks, i.e. 0a with
, right? But 0d was not replaced. And for some reason later on that broke the tables. At least in my case.
I also tried to copy these lines into another text editor from the PDF first and only then into a bear table - that solve the problem, because that intermediate editor converted 0d to 0a. I think. I only did a quick check, did not debug this a lot, so I could be wrong. Also I don’t really know how the bear app works.