SlideSCI: a PowerPoint add-in for research progress decks

The PowerPoint gaps SlideSCI was written to close

The README opens with a list of complaints rather than a feature list. Four of them define the project's scope: PowerPoint cannot attach a caption to an image the way Word can, it cannot copy one element's position and paste it onto another, it has no automatic grid arrangement for a batch of inserted images, and it has no native way to insert a code block or a LaTeX formula. The author describes producing a weekly graduate research progress report, wanting fast insertion and clear content rather than a beautiful deck, and building the plugin around those four gaps.

That framing matters when you evaluate it. SlideSCI is not a general presentation toolkit and does not try to be. The feature set maps almost one to one onto the complaints: batch image captions, batch image labels, copy and paste of position, size, text and shape format, group format, image auto-arrangement, Markdown insertion, LaTeX insertion, an asset library for shapes, and page export to images or PDF. If your deck-building pain is somewhere else, this plugin probably does not touch it.

The audience is narrow and stated: people who write scientific figures and progress reports in PowerPoint. The README also points to the author's separate Adobe Illustrator plugin for scientific figure composition, which suggests the intended workflow is figure assembly elsewhere and slide assembly here.

How the plugin is put together and where LaTeX conversion happens

The repository is a C# solution. The top level holds SlideSCI.sln, a SlideSCI/ project directory, a packages/ directory, and the usual documentation files: README.md, README.en.md, CHANGELOG.md, CONTRIBUTE.md and LICENSE. That layout is the classic shape of a VSTO-style Office add-in: a .sln you open in Visual Studio, a project that produces the add-in assembly, and packages/ for restored dependencies. The README does not publish a build or installation procedure, so what you get from the repository is source, not a documented deployment path.

The one component with a documented architecture is LaTeX rendering. SlideSCI offers three paths. Insert Markdown handles mixed text and inline math. Insert LaTeX text inserts an editable formula. Insert LaTeX svg renders through Node.js for formulas that PowerPoint's native math cannot express. The README states the SVG path needs only a Node.js environment, and contrasts this with IguanaTeX, which it says requires a LaTeX environment plus additional plugins. The converter lives in a latex-converter folder inside the add-in install directory, described as %APPDATA%\Achuan-2\SlideSCI\latex-converter, and you run npm install there. Inserted SVG images keep the original LaTeX source in their tooltip text, so you can edit and re-insert. That detail is the most useful design decision in the project: the rendered artifact stays traceable to its source.

The AI assistant is configured with an API address and an API key, and the system prompt is editable. The README does not name a provider or a default endpoint, so treat it as bring-your-own-API.

Installing SlideSCI and running a first batch of image captions

The README does not give an installation procedure for the add-in itself. It links to GitHub and describes features, but the only setup instructions it contains are for the LaTeX SVG converter. If you want to try the plugin, the source route is to clone the repository and open SlideSCI.sln, and the README's own pointer is the GitHub address. Do not expect a documented installer from the documentation as written.

The LaTeX SVG path is the exception, and the README spells it out. First install Node.js. Then find the latex-converter folder inside the add-in install directory:

cd "%APPDATA%\Achuan-2\SlideSCI\latex-converter"
npm install

After npm install completes, the Insert LaTeX svg command becomes usable. The README does not state what happens if Node.js is missing or if npm install fails; the command is simply described as unavailable until configured.

For a first real use, the workflow the README describes is batch captioning: select several images on a slide, then apply batch add image captions, which inserts a centered caption below each image. The README says you can also choose whether image and caption are automatically grouped. A related command, batch add image labels, is aimed at scientific figures and offers templates A, a, A), a), 1 and 1), with Arial as the default label font. Neither command is shown with a menu path in the README, so the exact ribbon location has to be found in the add-in after it loads.

Image auto-arrangement: the options and what they assume

Image auto-arrangement is the most parameterized feature in the README, and the parameters reveal what the author expects from the workflow. You can set sort order, arrangement mode, images per column, column spacing, row spacing (which defaults to the column spacing when left empty), and image width and height.

Sort order has two modes. By position, which infers order from the rough placement you already made by hand, and by multi-select order, which uses the order in which you selected the images. The first assumes you have dragged things approximately into place first; the second assumes you can click in the sequence you want. Both are reasonable, and both shift work onto you before the command runs.

The three arrangement modes encode three different layout intentions. Column maximum width placement arranges by the widest element in each column to preserve a table-like grid, which is what the README recommends for scientific figure layout. Uniform height and uniform width waterfall do what their names say. In both uniform modes, if you do not set the dimension, the first image's height or width is used as the common value. That is a real constraint worth knowing: the first image silently becomes the reference, so a stray oversized or undersized image at the head of your selection will propagate through the whole arrangement.

Where SlideSCI is the wrong tool

The plugin is Windows-and-PowerPoint shaped. The documented install path is a %APPDATA% location, the project is a C# solution, and nothing in the README describes macOS, Linux, LibreOffice Impress, Google Slides or Keynote support. If your lab standardizes on Google Slides, none of this applies.

The Markdown insertion is also a one-way operation. The README describes pasting a whole Markdown note into PowerPoint and preserving inline formats (bold, underline, superscript, subscript, italic, links, inline code, inline math) and block-level styles, but it does not describe converting the slide back to Markdown. Treat the slide as the destination, not as a round-trip format.

The LaTeX SVG route adds an external runtime. Node.js has to be installed and npm install has to succeed in the converter folder. That is lighter than a full LaTeX distribution, as the README argues, but it is still a second toolchain sitting behind one feature. On a locked-down machine where you cannot run npm install, the SVG path is unavailable and you fall back to native PowerPoint math.

Finally, the README states that the plugin's code was largely AI-generated. That is not a defect by itself, but it is a signal about documentation depth: the README is a feature tour, not a reference. It does not document error states, rollback, or what happens to existing slides when a batch operation runs.

Alternatives and the difference in approach

The README names one alternative directly: IguanaTeX, for LaTeX in PowerPoint. The stated difference is setup weight. IguanaTeX, according to the README, requires a LaTeX environment plus a number of additional plugins before it can convert LaTeX to SVG. SlideSCI's SVG path requires only Node.js and one npm install in the latex-converter folder. If LaTeX rendering is the only thing you need, IguanaTeX is the more established and more narrowly focused choice; if you want the caption, arrangement and position-copying features in the same add-in, SlideSCI bundles them.

For the asset-library and template side, the natural comparison is PowerPoint's own Slide Master and the built-in shape library. SlideSCI's asset library stores shapes taken from the current deck, supports folders, search, and import/export so assets can be shared between people. Slide Master is the right mechanism for deck-wide defaults; SlideSCI's library is for reusing individual shapes across decks and across machines. They solve different problems and do not really compete.

For Markdown-to-slides conversion, the alternative is a generator such as Marp or Pandoc, which produce slides from a Markdown source file. The difference in approach is fundamental: generators treat Markdown as the source of truth and PowerPoint as output, while SlideSCI treats an existing PowerPoint deck as the source of truth and Markdown as pasted content. If you want reproducible decks built from text, a generator fits better. If you are already maintaining a .pptx and want to drop a note into it, SlideSCI fits better.

Maintenance, licence and what upgrading costs you

The repository is not archived. The last push was on 2026-09-06, and the most recent release listed is v1.9.1 on 2026-08-21, preceded by v1.9.0 on 2026-08-16 and v1.8.0 on 2026-06-11. The cadence visible in those three releases is roughly one minor version every one to two months, with a patch shortly after the last minor. There is a CHANGELOG.md at the repository root, so release-to-release changes are tracked in the repository rather than only in release notes.

What the README does not give you is a compatibility statement. It does not say which PowerPoint versions or which Windows versions are supported, and it does not describe an upgrade procedure or a rollback path for the add-in. Since the LaTeX converter lives under %APPDATA%\Achuan-2\SlideSCI\latex-converter and is set up with npm install, an upgrade that touches that folder may require re-running npm install. That is an inference from the documented path, not something the README states.

The licence is AGPL-3.0. For an add-in you install and use internally, that is usually unremarkable. The network-copyleft clause matters if you modify SlideSCI and let users interact with the modified version over a network: AGPL-3.0 requires offering the corresponding source to those users. If you only redistribute the unmodified add-in, the obligations are the usual ones for conveying AGPL code. This is a description of the licence's shape, not legal advice; check your own distribution plan with someone qualified.

Editorial conclusion

Adopt SlideSCI if you build research progress decks in PowerPoint and want batch image captions, position and format copying, and Markdown or LaTeX insertion without leaving the slide. Skip it if you need a cross-platform editor, a hosted service, or a maintained plugin ecosystem with documented versioning; the README describes Windows-oriented installation paths and the repository ships no compatibility matrix. Verify first whether your PowerPoint build loads the .sln output, whether the latex-converter folder under %APPDATA%\Achuan-2\SlideSCI resolves on your machine, and how the AGPL-3.0 licence applies to your distribution.

Frequently asked questions

Official sources

1. Achuan-2/SlideSCI on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases