# Zotero Style: reading progress, tag columns and journal-rank tags inside Zotero

> Ethereal Style is a Zotero addon that adds columns for reading progress, annotation counts, tag rendering and publication ranking. It is aimed at researchers who live in Zotero's item list, and its install path runs through an xpi file rather than a plugin store.

**MuiseDestiny/zotero-style** — Ethereal Style for Zotero

- Repository: https://github.com/MuiseDestiny/zotero-style
- Stars: 5,282 · Forks: 165
- Language: JavaScript
- License: AGPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/muisedestiny-zotero-style

## What Zotero Style adds to the Zotero item list

Zotero's default item list is deliberately plain. It shows title, creator, year and whatever columns you enable, and it treats reading state as a binary flag. Zotero Style, published as "Ethereal Style for Zotero", rewrites parts of that list. The README describes three additions that change how a library reads at a glance: a title column whose background encodes reading progress, a progress column that represents annotation word count per page, and a read/unread state that bolds unread papers in the same way Zotero's RSS reader does. The audience is narrow and obvious: people who keep hundreds of PDFs in Zotero and annotate them there, and who want the list itself to carry information that currently requires opening each attachment. It is not a citation-style tool despite the name. The repository has nothing to do with CSL styles, Vancouver formatting or reference output; it is a UI layer over the library view.

## Reading progress, annotation counts and the tag columns

The mechanism behind the title column is per-page reading time. The README states that the title background visually reflects "the distribution of your reading time of each page for the PDF under a item, the darker the color the longer the reading time." So the column is not a percentage bar; it is a heat map of where you spent time inside a document, which is a different and more honest signal than a completion estimate. The progress column is simpler: it represents the annotation word count of each page. Both depend on the plugin's own tracking of PDF interaction, which is why they only make sense for items with attachments you actually opened.

Tags get split out. Zotero normally renders tags before the title; Zotero Style moves them into a separate Tags column and adds a second column called #Tags that renders text directly. The distinction matters because #Tags supports a Prefix setting that filters which tags appear. A prefix of # shows all tags starting with # and strips the prefix. A prefix of ~/ shows all tags except those beginning with /. You can also supply a regular expression, and the README notes that multiple (.+) groups are joined automatically. This is a small feature with a real consequence: it lets you keep a noisy tag vocabulary in Zotero and surface only the slice you care about in the list.

## Publication Tags and the Fields setting

Publication Tags is the most opinionated part of the plugin. It generates tags automatically to represent the rank of a publication, drawing on a long list of institutional and national journal lists. The README's table names datasets including ccf, swufe, cufe, ssci, sci, sciif, jci, sciif5, ahci, fdu, sjtu, xmu, cssci, ruc, cscd, swjtu, uibe, pku, xdu, sdufe, eii, nju, zhongguokejihexin, cqu, hhu, ajg, xju, cug, fms, scu, utd24, ft50, sciUp, sciBase, sciwarn, cju and zju. The underlying sources are named too: the CCF recommendation list, the JCR 2022 partition and impact factor PDF, the CSSCI 2021-2022 source list, the Chinese Academy of Sciences upgraded and basic partitions, and the CAS early warning list, among others. Which fields appear is controlled by the Fields entry in Column Settings, and if you use a custom dataset you must locate its custom field definition and fill it in there yourself.

The honest reading of this design is that it hardcodes a snapshot of academic evaluation data from roughly 2018 to 2022, depending on the list. The README even admits one gap directly: for sciif5, the five-year impact factor, it says the newest data had not been collected and 2021 figures were still in use. If your institution updates its list, you are editing the dataset or writing a custom field, not waiting for an upstream refresh.

## Installing Zotero Style from the xpi file

There is no plugin store entry. The README links a download directly, and Zotero's own addon installer is the install path. Download the xpi first, then in Zotero open Tools, then Add-ons, and use the gear menu to install from file.

```bash
curl -L -o zotero-style.xpi https://gitee.com/MuiseDestiny/plugins/raw/master/zotero-style.xpi
```

The README also points at the GitHub release asset for the latest build:

```bash
curl -L -o zotero-style.xpi https://github.com/MuiseDestiny/zotero-style/releases/latest/download/zotero-style.xpi
```

After installing, restart Zotero and right-click the column header row in the item list to enable the new columns. The README's own update instructions are explicit that you should not rely on GitHub releases for updates: it says minor versions will not be published as GitHub releases and that the Zotero-provided update mechanism, shown in an image in the README, is how you get every version. That is worth taking literally. If you pin the xpi from a release page, you will miss the smaller builds.

For developers, the repository builds with npm and launches a development Zotero instance. The scripts distinguish Zotero 6 from Zotero 7:

```bash
npm install
npm run build
npm run start-z7
```

The package.json defines start-z6 and start-z7, plus stop and restart-dev and restart-prod targets, so the build tooling assumes you have a target Zotero installation to point at.

## Where Zotero Style falls short

The README's TODO list opens with two unfinished items: syncing view groups and colour settings, and theme switching. Neither is implemented. The practical effect is that the view configuration you build on one machine stays there. If you work across a desktop and a laptop, or across Zotero profiles, you will rebuild the column setup by hand. For a plugin whose entire value is a configured view, that is the central limitation, and it sits at the top of the project's own backlog rather than being an edge case.

The second gap is testing. package.json defines test as a command that prints an error and exits with status 1, meaning there is no test suite in the repository. Combined with the absence of documented rollback, that means an upgrade that breaks your column layout has no supported undo beyond reinstalling an older xpi. The README does not document rollback.

The plugin is also the wrong tool if you do not annotate. Reading progress and annotation word counts are computed from your PDF interaction; in a library of unread PDFs, or one where you read in an external viewer, both columns stay empty and the plugin reduces to a tag filter.

## How this differs from Zotero's own columns and from Zotero Better BibTeX

Zotero's built-in columns are metadata fields. They show what is stored on the item, and they are the same on every machine because they are part of the item data. Zotero Style's columns are derived state: reading time, annotation volume, generated rank tags. That is the real difference in approach, and it explains most of the plugin's constraints. Derived state has to be recomputed, it can be lost, and it is not covered by Zotero's sync in the way item metadata is.

A closer comparison is Zotero Better BibTeX, which also extends Zotero's list behaviour but does it for citation keys and BibTeX export rather than for reading telemetry. Better BibTeX's output feeds a manuscript; Zotero Style's output feeds your own triage of a library. If your problem is that your bibliography export is unstable, Zotero Style will not help you at all, and the publication-rank tags it generates are display labels, not citation data. Choosing between them is not a matter of quality; they solve different problems in the same window.

## Licence and maintenance cost

The repository is licensed AGPL-3.0, and package.json states AGPL-3.0-or-later. That matters if you plan to fork and distribute a modified build, because the AGPL's network clause is stronger than a permissive licence's. Bundling the plugin into a hosted service, or shipping a modified xpi, carries obligations that a plain MIT dependency does not. This is a description of the licence text, not legal advice; if your institution has rules about AGPL code in distributed products, check them before forking.

The last push to the default branch was on 2026-06-07, and the most recent release listed is 6.0.8, titled "Menu Visibility Manager", from the same date. Earlier releases include 5.7.9 on 2025-11-24 and 5.7.7 on 2025-11-18. The repository is not archived. Note the version mismatch between the release tags and package.json, which reports version 2.6.7; the build metadata and the release numbering are not in step, so do not use package.json to decide whether you are on the current build. Upgrade cost is low in the normal case because the plugin updates through Zotero itself, but the absent test suite and the missing rollback path mean you should keep the previous xpi file around before accepting an update.

## Conclusion

Adopt Zotero Style if you read and annotate PDFs inside Zotero and want the item list to show reading progress, annotation volume, tag rendering and journal-rank labels without leaving the client. Skip it if you need your view and colour configuration synced across machines, or if you want a plugin with documented rollback and a test suite: the README's TODO still lists syncing view groups and colour settings, and package.json's test script exits with an error. Before installing, check which Zotero version you run against the start-z6 and start-z7 scripts, since the plugin ships separate launch paths for Zotero 6 and 7.

## FAQ

### How do I install the Zotero Style plugin?

Download the xpi file linked from the README, then install it through Zotero's own add-on installer from the Tools menu. After a restart, right-click the column header row in the item list to enable the columns the plugin adds.

### Where can I download the Zotero Style xpi file?

The README links an xpi at gitee.com/MuiseDestiny/plugins/raw/master/zotero-style.xpi, and the GitHub release asset is also available at the latest release download path. The README warns that minor versions are not published as GitHub releases, so it recommends updating through Zotero's built-in mechanism instead.

### What does the Zotero Style plugin actually add to Zotero?

It modifies some existing Zotero columns and adds new ones: a title column whose background encodes per-page reading time, a progress column for annotation word count per page, a read/unread state that bolds unread papers, and separate Tags and #Tags columns. It also adds Publication Tags that generate journal-rank labels from named datasets.

## Sources

- [Issues](https://github.com/MuiseDestiny/zotero-style/issues)
- [License: AGPL-3.0](https://github.com/MuiseDestiny/zotero-style/blob/master/LICENSE)
- [MuiseDestiny/zotero-style on GitHub](https://github.com/MuiseDestiny/zotero-style)
- [README](https://github.com/MuiseDestiny/zotero-style/blob/master/README.md)
- [Releases](https://github.com/MuiseDestiny/zotero-style/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/muisedestiny-zotero-style