PDF Annotation: Copy Text With Block Ref, Citekey, and Page Number

I’ve been experimenting with an ideal academic workflow in Logseq, and many of the roadblocks I encountered had to do with PDF annotation. It is important to think not just about getting text into Logseq, but how it is processed later. Having it as a block ref, without selectable text, without a citekey, and without the page number, means that it is hard to further refine your notes or move them on to other apps for long form academic writing. The request is to have a third option in the PDF annotation menu: “Copy text with reference” which would do all three.

(Note: user @bluejaw has made a version of this request as part of a large discussion, but I don’t see it listed as a separate feature request.)

Right now, when you copy a highlight to your graph, you have two options:

  • Copy ref
  • Copy text

But neither is ideal. Ref text is not editable or selectable, and text does not include a link back to the original text in the PDF. The “copy text with reference” would be a combination. It would be a plain text note but it would have a pin (similar to this request) at the beginning or end of the text with the link ref.

Something like this:

“Consuetudium lectorum Mirum est notare. Eodem modo typi qui nunc nobis videntur parum clari fiant sollemnes in futurum” [📌](((ref code)))

Ideally, the format could be customized however. In my ideal workflow the quote would also have the [@citekey] used in Zotero so that it is easy to move from Logseq to writing a markdown formatted paper that can be processed with PanDoc to have a full bibliography. (Zettlr is one such app.) Since Logseq is planning on outsourcing Zotero support to a third party plugin, there needs to be some way to allow that plugin to talk to the PDF annotator to modify the notes to include the citekey. (I’ll let someone like @Aryan make a proper feature request for this, since I’m not sure what is needed.)

The full thing might look like this:

[:pushpin:](((ref code))) "Consuetudium lectorum Mirum est notare. Eodem modo typi qui nunc nobis videntur parum clari fiant sollemnes in futurum" [{@citekey PAGE}]

Finally, it would also be good to have the page number included along with the citekey. If the app can pull the page numbers from Zotero it can know the starting page number and calculate the actual page. Otherwise it should be possible to set the start page number manually.

With all this in place, one could simply copy an article quote into a Markdown formatted paper and the bibliography and in-text citation would be formatted without having to do any additional steps.

On a related note:

Before the number of “Copy …” shortcuts get out of hand, it’s important for logseq to revisit its copy-and-paste model. Apps (and even macOS) have long realized that it makes more sense to have a general “copy” operation and then a bunch of “paste …” operations.

Take a look at Microsoft Word:
screenshot.2022-07-24T083335Z

Or macOS:
screenshot.2022-07-24T083438Z

The point is that the user should defer what they want to get out of the copied element at the moment of pasting—not at the moment of copy. There are 2 benefits: (1) deferring decisions until the moment of usage leads to fewer wrong decisions and (2) the user can then repeat different kinds of pastes without having to go back to the original element to copy, saving a huge amount of time.

(Somewhat relatedly, macOS smartly got rid of the ability to “Cut” files in Finder. Instead, the user always does a “Copy” and then later decides whether to “Paste” or “Move”)

So in fact, we should get rid of “Copy ref” and “Copy text” and instead have a “Paste ref” and a “Paste text” and whatever else this feature request wants to add.

1 Like

This should definitely be a third option, not a replacement to the two existing one’s though.

Having the highlight + page + citekey in all of the highlights seems a bit superfluous. That becomes only important for bibliographic reasons should the note enter your draft, not while organising ideas.

I’ve been dealing with this by putting the highlight reference as a child block of whatever I want to reference it to and then collapse it.

1 Like

The application of citations should definitely be configurable by the user, and as I said above - it would be something done by the plugin, not the core app. Still, there should be an easy way to add this info directly to the block when needed to suit different workflows…

4 Likes

It’s a great idea. But I’m really concern about the tech difficulty.
For example, the ref (uuid) is not a regular type of clipboard item in OS.

This is exactly what I have been looking for, and the reason I don’t switch from Citavi to Logseq as my main repository of notes. It should be a seamless process. Ideally it should work like this 1. On Import of a PDF from Zotero, or any other software, Logseq assigns a citekey to the PDF 2. Logseq automatically adds to any annotated fragment of that PDF the citekey and the page number (of the document, not the PDF - most of the time the first page of the PDF will not be 1). In that way, the process of annotation is extremely fast when you are composing your article draft. (Ok I realize I basically described the same thing as the OP)

The fact that Logseq can’t duplicate Citavi’s functionality to make blocks into a new paper with references is very frustrating.

As @francescoragazzi suggested, adding a block with a citation needs to be able to include said citation. This could be added to the “Move Block” plugin as an additional option such as “Copy with reference” or similar.

Can we please, please get this?? Would make Logseq better than Citavi and the Zotero integration would make it much better than Obsidian or Zettlr!

“But neither is ideal. Ref text is not editable or selectable, and text does not include a link back to the original text in the PDF.”

Therefore the content of Ref text doesn´t get recognized and won´t create Unlinked References, which is sad. You have my vote for this third option or any other version that creates the possibilty to jump to the source with at the same time also making the annotation content readable for logseq.

As a workaround i will stick to this solution: