Most of the time, what we want to return to is not a document.

It is a place inside the document.

It might be a page in a PDF, a passage in an EPUB, a block in Markdown, or a specific section in a saved web page. For reading, research, and note-taking, that need to get back to an exact place is often more real than the need to simply reopen the file.

That is part of how DoCube thinks about links.

In DoCube, a link does not just point to a document. It tries to point to a precise location inside the document.

That sounds like a small detail, but once your library grows, it starts to matter more and more. Saving documents is usually not the hard part. Getting back to the exact place later is.

Why Locations Matter More Than Documents​

If all you want to do is save a resource, a document link is enough.

But when you are reading, quoting, writing notes, or organizing ideas, the need is usually more specific:

• I want to go back to this exact page in a PDF
• I want to return to this passage in an EPUB
• I want to jump from a note back to the matching spot in the source
• I want a sentence like “See Section 5.5, Choosing and Evaluating Embedding Models” to jump to the right place inside the document

Those are not fully solved by “open the document.”

What DoCube cares about more is whether a link can preserve that sense of place. In other words, what you copy is not just “this resource,” but “this place inside this resource.”

It Is Not Only for Cross-Document Links​

When people think about links, they often think about jumping between different resources.

But in DoCube, links inside the same document matter just as much.

Imagine you are reading a long document and see a sentence like “See Section 5.5, Choosing and Evaluating Embedding Models.” In many tools, you would still scroll or search for it manually. In DoCube, a more natural approach is to turn that sentence into an in-document location link. The next time you see it, one click takes you straight to the target section.

The value is not that there is one more button. The value is that reading becomes smoother. You do not have to treat a document like one large block that you keep scanning again and again. You can move through it by location.

Markdown Can Tie These Locations Together​

In DoCube, Markdown is not just a place to write notes. It can also become a place to connect positions across sources.

Because Markdown supports docube:// links directly, you can organize the materials around one idea in a much more concrete way:

• a page in a PDF
• a passage in an EPUB
• a block in Markdown
• a specific place in a saved web page

In practice, the simplest flow is to copy the current location while reading, then paste those docube:// links into Markdown. The point is not just to paste links into a note. It is to turn Markdown into something closer to a navigation layer for your knowledge.

And when you use docube:// links in Markdown, DoCube can also resolve the document title from the link metadata. That makes the note easier to read, not just clickable.

These Links Can Be Used Outside DoCube Too​

At the core, DoCube links are docube:// addresses.

That means they are not just a small internal feature trapped inside one panel. You can copy the current location, paste it into another app, and keep using it as a precise reading address.

So from DoCube’s point of view, a link is not just something that works inside the current window. It is an address you can take with you.

Links Also Become Part of History​

DoCube links are not only something you can copy. They also become part of history.

This is one of my favorite parts, because it solves more than “how do I save this address?” It also solves “how do I keep moving through these places later?”

In DoCube, you can move backward and forward across different document tabs. You can also move backward and forward through the locations you just visited inside the same document.

It feels a bit like browser history, except what gets recorded here is not web pages. It is your reading addresses.

DoCube Wants to Save More Than Files​

At one level, DoCube links are obviously solving a navigation problem.

But at the product level, what they are really trying to preserve is not just the document itself, but the place where you were reading it.

Because for reading, research, and note-taking, the most meaningful action is often not “I opened this resource once.”

It is “Can I get back to that exact place later?”

That is why in DoCube, links do not just point to documents. They point to precise locations inside them.

PDFs have never been a format that nobody complains about.

But I increasingly feel that many of those complaints miss the real problem.

I do not dislike PDFs. If anything, I think PDFs are still a remarkably strong document format. Their expressive range is rich, their layout is stable, and their rendering is consistent across devices. For papers, reports, court decisions, scanned books, and other layout-sensitive documents, that stability is not a flaw. It is one of the main reasons the format remains useful. Complex layout, charts, footnotes, formulas, and page relationships can all be preserved with reasonable fidelity. If the goal is to deliver content accurately to a reader, PDFs still do that job very well.

So I have never felt that the core problem with PDFs is that they are too old, or that they should disappear.

What bothers me more and more is not the PDF itself, but the annotation workflow built around it.

When people complain about PDFs, the first complaint is often that they are hard to edit. That is true, but for most reading, learning, and research scenarios, it is not the most important pain point. Most of the time, people are not trying to rewrite a PDF into another document. They are trying to read it, mark key passages, add comments, return a few days later, recover what mattered, compare it with other material, or quote it in their own writing.

The problem is not whether a PDF can be edited. The problem is whether what happens after annotation can keep participating in actual work.

That is where the PDF ecosystem still feels weak.

PDFs are strong at page representation, not at knowledge interaction. They are good at presenting content reliably, but not at expressing how a reader's understanding of that content should keep evolving. The PDF spec does include annotation features, but in practice they remain limited. Highlights, underlines, comments, sticky notes, and drawing tools feel more like patches attached to a page than a mature layer for working with knowledge.

As a result, almost every PDF reader ends up inventing its own annotation model.

That fact alone says a lot. The PDF ecosystem has effectively accepted that reading can be shared, but annotation cannot. The format itself takes responsibility for showing the page consistently. Once the question becomes how a reader interacts with that page, every app goes its own way. Each reader has its own highlights, its own comments, its own sync logic, and its own export format. They all work, in a limited sense, but most of them stop at a fairly primitive stage.

What does that stage usually look like? An annotation list.

You highlight twenty passages, write five comments, and in the end the reader gives you an annotation panel telling you they are all there. That is not useless. It is better than nothing. But it is also where the system often stops. It helps you look back, but rarely feeds your learning or research process in a meaningful way.

Most annotation systems in PDF readers solve the problem of recording. They do not solve the problem of continuation. Your highlights remain highlights. Your notes remain notes. They rarely enter other workflows. They do not meaningfully participate in search, in later organization, in cross-document connection, or in spaced review and reuse. They remain traces on a page rather than active objects inside a knowledge workflow.

But I increasingly feel that a valuable annotation should not be just a mark attached to a page.

It should participate in search, because annotated content is usually more important than unmarked content.

It should participate in review, because learning is rarely a one-time event.

It should participate in connection, because real understanding often emerges across multiple documents rather than inside a single one.

That is why I care less about whether a reader supports highlighting at all, and more about what happens after the highlight.

Over the last few years, while building document tools myself, I have come to believe something fairly simple: annotations should not remain side attachments to a document. They should enter the next layer of work. They should influence retrieval because marked passages are often the most valuable ones. They should enter review because important material should not end with "I highlighted this once." They should be able to connect documents because knowledge grows across references, not inside isolated files. Only then does an annotation become more than proof that I once read a passage. It becomes an entry point for future work.

That is also why I have grown increasingly impatient with another very common PDF habit: turning a PDF into a mess of handwritten notes.

I understand why people like doing this. Writing arrows, circles, stars, and margin reactions directly on a page can feel immediate and satisfying. It gives a sense of involvement. Sometimes it even creates the feeling that real thinking is happening right there on the page.

But I like this workflow less and less, for one simple reason: it barely participates in any efficient process afterward.

Handwritten notes are usually not text. They are not structured data either. They are hard to search, hard to reuse, hard to aggregate, hard to connect cleanly to other documents, and hard to bring into any more automated workflow for review, retrieval, or synthesis. In many cases, their only unquestionable value is the feeling they provide at the moment of writing. After that, they often turn into visual noise that competes with the document instead of making understanding more durable.

I am not against writing by hand, and I am not against the physical feeling of thinking through marks and gestures. What I object to is an annotation style whose value ends almost entirely with the immediate act itself. In learning and research contexts, if a note cannot enter search, review, connection, and reuse, it tends to become inefficient over time.

So what I actually want is not more decorative annotation.

I want annotations that can keep working.

They should be searchable. They should be reviewable. They should be connectable. They should be reusable. Ideally, they should preserve at least some structure instead of surviving only as visual residue.

Seen from that angle, what really needs to be rethought is not PDF reading itself. PDFs are already quite good at reading. What feels outdated is our understanding of annotation, and the role annotation should play in learning, research, and knowledge organization.

PDFs do not need to be replaced.

But the tools built around them, especially everything that happens after annotation, still need serious redesign.

Because if annotations remain only marks on a page, and cannot keep participating in search, review, connection, and reuse, then the PDF ecosystem in knowledge work still remains at a surprisingly early stage.

And the more I work on document tools, the more certain I become that this is where the next generation of them should begin.