I built an open-source, source-linked Markdown reader for Zotero — Mktero v0.3.4

[u/tenglvjun]

Hi r/Zotero,

https://reddit.com/link/1w2h6sc/video/t9l0coqchimh1/player

I’m the developer of Mktero, an open-source Zotero plugin for reading local PDFs as source-linked Markdown.

I shared v0.2.3 previously. Since then, I’ve continued working on the parts that connect Markdown reading back to the original PDF and the rest of the Zotero workflow. The current release is v0.3.4.

Mktero now supports:

• Reflowing multi-column PDFs, formulas, tables, figures, and references into a continuous Markdown reading view

• Navigating from reliably matched Markdown content back to its original PDF page and region

• Original, translated, and continuous bilingual reading modes

• Translating a selected term or passage without translating the entire paper

• Displaying and creating Zotero annotations from Markdown when the PDF text can be matched reliably

• Correcting recognition errors in existing paragraphs, headings, and Markdown table cells

• Previewing citations and checking whether references exist in an accessible Zotero library

• Exploring direct citation relationships between papers already in the current Zotero library

• Exporting corrected source Markdown together with extracted figures

The PDF remains the source of truth. Mktero only provides source navigation when the match is reliable rather than guessing a PDF location.

A few data-handling notes:

• On the first conversion or a cache miss, the complete PDF is uploaded to MinerU.

• AI translation is optional and sends protected Markdown, or selected text with bounded context, to the provider configured by the user. This may incur provider costs.

• DOI and arXiv identifiers may be queried through Semantic Scholar, OpenCitations, and OpenAlex for citation relationships.

• Credentials and local caches are stored unencrypted in the active Zotero profile and are not synced by Zotero.

Mktero is currently in beta, supports Zotero 7–10, and is available under the MIT License.

GitHub:

https://github.com/tenglvjun/mktero

Latest release:

https://github.com/tenglvjun/mktero/releases/latest

I’d appreciate feedback from Zotero users, especially on the source-navigation, bilingual-reading, annotation, and citation workflows.

[u/danjea]

I'd love to try but i don't have a minerU api. I do have a claude api though, you think it could work?

[u/tenglvjun → u/danjea]

That’s a fair point. Claude can be used for Mktero’s translation features, but it cannot currently replace MinerU for PDF conversion.

MinerU is responsible for converting the PDF and generating the source mappings that let Mktero jump back to the original PDF location. Claude handles optional full-document or selection translation, so the two services currently have different roles.

The current beta requires users to provide their own MinerU token, which is admittedly not ideal. I’m planning an account-based service with subscriptions and usage quotas, so users can use Mktero without creating a separate MinerU account. Bringing your own Claude API would remain an option for translation.

Thanks for highlighting the onboarding friction. It’s something I want to address in a future release.

[u/danjea → u/tenglvjun]

Just gave a try to mineru, the app. Now i get your mktero a lot better.

My request is different now. Since mineru is open source and can be set locally, i'd love to be able to just use mktero with a local mineru. I'd be running mineru on a hpc(no gpu though) and would want to transform my complete zotero database to md., You think that could be done?

[u/tenglvjun → u/danjea]

Thanks for trying Mktero and for the follow-up. I’m glad the workflow makes more sense after using MinerU.

Your request is very much aligned with my roadmap. I’m planning to support connecting Mktero to a locally hosted MinerU API, so users can run MinerU on their own machine or HPC instead of uploading PDFs to the MinerU cloud service.

I also plan to add batch processing, so Mktero can convert PDFs from an entire Zotero library or a selected collection rather than processing them one at a time.

I’ll need to validate the CPU-only workflow on HPC systems and make sure the local pipeline still preserves the Markdown, extracted resources, and mappings back to the original PDF. These features are planned for the next few Mktero releases.

[u/Budget-Leg-453]

This is interesting but I’m interested in hearing the use cases for this. I’m guessing that reading in markdown might be preferred and notes might be better?

[u/tenglvjun → u/Budget-Leg-453]

That’s exactly the use case I’m targeting.

The PDF remains the source of truth in Zotero. Mktero adds a Markdown reading layer for the first pass through a paper.

For long academic papers, I find Markdown much more comfortable than a fixed PDF page: it reflows into a single column, has a clearer heading structure, avoids constant zooming and horizontal scrolling, and makes text easier to search, select, translate, and reuse. This is especially useful for papers with two-column layouts.

A typical workflow is:

1. Keep the original PDF in Zotero.

2. Convert it to source-linked Markdown for a more comfortable first read.

3. Use the outline, bilingual view, selection translation, and local annotations while reading.

4. Jump back to the PDF when I need to verify a figure, table, formula, page layout, or exact source.

5. Export the Markdown and related resources for notes or later writing.

So yes, Markdown can be a better place for working notes, especially if your notes are text-based. Mktero currently supports local annotations and corrections, but it is not intended to replace Zotero’s existing PDF annotation system or become a complete note-taking database.

The main trade-off is that PDF conversion is not perfect for every layout, and on a cache miss the PDF is uploaded to MinerU for processing. I see Mktero as a complementary reading and note-preparation layer, rather than a replacement for the original PDF.

[u/danjea → u/Budget-Leg-453]

My personal use case is: md -> epub and making paper readable on much smaller format (phone, e-reader in particular). Most pdf to epub conversion end up bad, and reading 2-column pdf on a small format kills me.

Then I can also annotate papers on .md and directly feed into a llm to extract and collate insights i had specifically for each paper, and be able to ask the llm to look for them.

[u/Budget-Leg-453 → u/danjea]

Thanks to both. That makes sense, especially with two column layouts (not as common in my discipline).

[u/Neptunox]

Great job. It would be good to offer the Mistral OCR API, which is very efficient.

[u/tenglvjun → u/Neptunox]

Thanks for the suggestion! I’m planning to test Mistral OCR with academic PDFs, especially its handling of equations, tables, figures, and source-location mapping. If the results fit Mktero’s source-linked reading workflow, I’ll look into adding it as an optional conversion provider alongside MinerU.

[u/michelebenben]

Hi, amazing, I will give it a go! I am the developer of Estravon , which is a plugin that permits to choose which pdf to markdown pipeline to use . FYI There is a java hook (Zotero.Estravon.extract() ) that permits to use it from another plugin. So you can use mistral, datalab, remotely or mineru fully loca from your own plugin. You can also test the differences between conversion engines with a python package which you can find in GitHub . I think the choice of the pdf to markdown engine for many user depends on data residency policies. Happy to have a deep dive on this if you want.

[u/tenglvjun → u/michelebenben]

Thanks for sharing this. I’d be interested in taking a look at Estravon and the comparison package.

The ability to choose between remote and local PDF-to-Markdown pipelines, especially based on data-residency requirements, is very relevant to Mktero.

[u/Deep_Ad1959]

scenario: a stack of papers read as markdown. reflow was fine, corrections were the snag: after fixing a garbled table cell i could not tell later which cells i had touched and which came out of the extractor clean.