Can I show images and working links inside a generated table, or does it only render plain text?

Not a limitation — you are producing a string where you need to produce either markup or a link object, and the distinction is the whole answer.

Why the path renders as text. Your field holds a path, which is a string. The table renders values, and a string renders as its characters. The app is not scanning generated output for anything that resembles a path and helpfully turning it into an image.

Two ways to fix it, and they suit different situations.

1. Build the markup in the query. Concatenate your path into an image embed and let the result render as markup rather than as text. A column expression that produces the embed syntax around your path value will display the picture. You can size it in the same expression, which you will want to — full-size covers make a table unusable.

This works for links too: build the link syntax around the target, and it renders clickable.

The caveat is quoting. If a path contains spaces or brackets, naive concatenation produces broken markup, and the symptom is a column that renders as a mangled string rather than as an error. Store paths without spaces if you can.

2. Store the field as a link in the first place. This is the better answer when the field points at something in the vault. Write the value as an actual link in the note rather than as a path string — then the plugin indexes it as a link object, and the table renders it as a working link with no query-side work at all.

Same for images: if the field holds a link to an image inside the vault, the embed form of that link renders the picture.

For anything more involved, drop to the scripting variant. The declarative query language deliberately does very little formatting. The scripting form of the same plugin gives you the pages as data and lets you build the table yourself, which means you can produce a proper file link with the embed flag set, generate an HTML element, or handle a missing image with a placeholder instead of an empty cell.

That last point is what usually pushes people over: in a declarative query, a note with no cover produces a broken embed. In the scripting form you write one conditional and it produces a blank cell.

A practical note on external images. If your covers are remote URLs rather than files in the vault, they will render but every table view fetches them, which is slow and leaks what you are reading to whoever hosts them. Downloading the covers into the vault once is worth it for a list you look at often.

On sizing, since it is the difference between a usable table and a wall of pictures: the embed syntax accepts a width, and you want something small — thumbnail scale.

Also be aware that a table of many images is genuinely heavy to render. Fifty covers in one view is noticeably slow to open on a phone, and if you keep the view pinned it recomputes when the vault changes.

Paginate it, filter it to a subset, or accept the delay. A book list is usually better as "currently reading" plus a separate archive query nobody opens daily.

The storing-it-as-a-link advice is the one I would follow, and it generalises well beyond images.

A field holding a real link participates in everything — backlinks, the graph, rename propagation. A field holding a path string participates in nothing, and the day you reorganise your folders every one of those strings is silently wrong, with no warning and no way to find them except a full text search.

So the rule I use: if it points at something in the vault, store it as a link. If it points outside, store it as a URL. Never store a bare path.

Costs nothing at writing time and saves a reorganisation from becoming a data loss event.