Format issue: after importing the pdf note from Zotero, the note showing in Ob doesn't have any formation.

[a1576799]

After exporting from Zotero, we have the JSON file. However, when updating the literature note in Obsidian by the bibnote formatter, the pdf note has no formation like in Zotero note. For example, the H1, H2, or H3 titles become just paragraph texts. The same thing happens for bullet note as well. The whole Zotero note becomes plain text without any markdown grammar. Does anyone have the same problem? If I miss some settings or something, please help me out. Thank you so much!

[LiQiyan]

I have the exactly same problem, and can't solve it. Please let me konw if anyone can figure it out. Thank you ^ ^

[XuShenLZ]

Yes I confirm the same problem. Using latest bibnotes 0.9.146 + Zotero 6.0.8.

It seems that when we are editing our notes with markdown formats in Zotero, Zotero already transform that into proper style and somehow "hide" those syntax indicators. However, bibnotes are looking for those explicit characters. See below for my experiment:

Some more investigations: Zotero / Better-bibtext already transformed markdown format into HTML tags <h1>, <li>, etc. See the image below. So bibnotes should look for them and add the corresponding markdown indicators (e.g. when <h1>, add #+Space to the beginning of text)

Looking forward eagerly to a fix @stefanopagliari

[a1576799]

Hope this can be solved soon.

[a1576799]

Yes, I see that, too. Thank you for replying. However, it seems that an extra empty line appears between items, for example, the empty line between two bullet items, which makes the whole markdown context become so long that the structure is destroyed somehow and it cannot be read clearly. I hope it disappears, and could you please help me with that?

谢谢您的回复，但是我发现就是很多时候会出现大量的非必要的空行，比如，两个bullet的条目之间就空行了，再比如很多时候标题之后就空行，造成整个markdown很长，阅读起来也很费劲。不知道您是否有解决办法？谢谢。

[stefanopagliari]

I was able to replicate the problem. When formatting the notes added manually, the plugin currently removes all the html tags, including the formatting. I should be able to fix this.

[stefanopagliari]

I have added a fix in the latest version 0.9.151 https://github.com/stefanopagliari/bibnotes/releases/tag/0.9.151

Could you please test it and let me know if it works for you?

[XuShenLZ]

I have added a fix in the latest version 0.9.151 https://github.com/stefanopagliari/bibnotes/releases/tag/0.9.151

Could you please test it and let me know if it works for you?

Thanks for the update! However, it doesn't fix for me and also becomes unstable. I upgraded to 0.9.151

But there are many weird behaviors:

You can see in this case that it:

1. Lost some text "Decides to drive cooperatively" in Obsidian while they do exist in JSON
2. Lost the first heading "Contribution"
3. Got the second heading "Introduction" wrong and convert it into bullet points
4. The third heading "Formulation" becomes plain text

These weird behavior will appear after I extract PDF contents to contents (selecting some sentences and dragging them into notes or right-click and selecting "add to note").

If you just test with simple contents, I think 0.9.151 is working as below.

I suspect the characters in those long URL links for extracted content are messing up your parser.

[stefanopagliari]

@XuShenLZ thank you for testing this. I will give it another try later today

[stefanopagliari]

@XuShenLZ The final screenshot you posted work as expected. The html-to-markdown parser I have loaded in the package adds those symbols after the headers but they go away in preview mode.

I've tried to replicate the note above but it works fine on my end (with just the plain text). Would you be able to share with me the json file of that annotation so that I can replicate the problem?

[XuShenLZ]

@stefanopagliari You can download the file here. The one I showed in the screenshot has the citation key chengConflictResolutionModel2022

Plus, as @a1576799 said before, for these notes with extracted annotations, not only the format are messed up, but there are also a lot of empty new lines.

[stefanopagliari]

@XuShenLZ is the annotation in the screenshot from chengConflictResolutionModel2022 a mix of highlights extracted from the pdf with some manual editing within Zotero? If that is the case, that may explain the problem. I had written a parser to read the notes extracted from the pdf, and a different set of rules for notes added manually within Zotero. I did not envision the possibility of both happening in the same note.

[XuShenLZ]

Yes it is a mix of both. Sounds like it will be the cause. After mixing up the manual editing with extracted highlights, this note goes under the "Extracted Annotations" section in Obsidian. The plain text notes go under the "Comments" section.

Hope the parser can be compatible with the mix of contents! I found it very efficient to take personal notes during reading, while directly referring to the corresponding annotations.

[stefanopagliari]

I will check if it is possible to parse the manually typed of the note without losing the capacity to parse correctly the part extracted from the text. The use case I envisioned is that notes are made either directly in the pdf (using the comment function) or in a separate note within Zotero than the one extracted automatically.

[stefanopagliari]

Currently the code parse each note associated with an entry and it establishes if it is imported from the Zotero reader, Zotfile, or typed manually from the user. It is not possible to make this distinction line by line, at least not without a fundamental rewriting of the plugin.

I will write in the documentation that while it is possible to add user-generated notes, the plugin is not able to recognise when these are mixed with those extracted from Zotero.

One possible solution to import your data would be to create an empty note and paste into it the content of the mixed one. I don't know if that would work, but it could be worth a try

[XuShenLZ]

Thanks! I understand the difficulty if they are not designed to be recognized in the same note. I will adjust my habit to follow this restriction.

Although this issue can be closed for sure, hope this functionality can still be considered in the future iteration. Thanks again for the amazing work!