Possibility of using SMILES to obtain the structure of a molecule directly?

[tryptophawa]

Feature Request

Since it is possible to use SMILES to get the structure data of a molecule, is it possible to add a feature that has an input of SMILES and automatically parse it into a molecule structure?

[rice8y]

Thanks @tryptophawa for the suggestion. This seems feasible, but it would need a SMILES-to-layout step rather than just another parser.

Currently, molchemist works with Molfile / SDF data, which already contains 2D coordinates. SMILES mainly describes molecular connectivity, so supporting it properly would require generating a 2D layout first and then passing that into the existing rendering pipeline.

So I think this is possible, but it is more involved than simply adding another input format. I’m marking this as a feature request for now.

My background is mainly in natural language processing rather than chemistry, so I do not yet have much domain knowledge about SMILES notation or the best way to support it. If you have suggestions, references, or ideas about how this should be implemented, I would be very happy to hear them.

[tryptophawa]

What I'm thinking of is using tools like sci-form-cli or RDKit.js to convert SMILES to SDF, then input the SDF into the current workflow. More specifically, I consider using RDKit since it is smaller and seems easier to use, though it uses a BSD license rather than the MIT license.

[rice8y]

Thanks, this is very helpful.

Converting SMILES to Molfile/SDF first and then feeding that into the current pipeline also seems like the most natural direction to me.

After looking into it a bit more, I think the main question is less about adding another parser and more about finding a good way to generate reliable 2D coordinates within the current Typst/WASM plugin workflow.

At the moment, RDKit and Indigo both look like promising candidates for that. By contrast, sci-form seems more focused on 3D conformer generation, so it may not be the best fit for this particular use case.

For RDKit, my main concern is integration complexity. RDKit.js looks convenient at first glance, but the current package uses a Typst-compatible WASM plugin rather than a JavaScript runtime, so I am not sure yet how cleanly that would fit into the existing architecture. There is also the question of package size and build complexity.

For Indigo, the main attraction is that it appears to support both SMILES parsing and 2D layout generation, but I still need to confirm whether it can be packaged cleanly for this workflow and whether the generated Molfile/SDF output would integrate smoothly with the current parser and renderer.

So I think this is still feasible, but I would want to confirm the integration path with a small proof of concept first. In any case, your suggestion helps narrow down a realistic implementation direction quite a bit.

[rice8y]

I went ahead and implemented a first version of SMILES support on the feat/support-smiles branch.

I did not end up using RDKit or Indigo directly. Their chemistry functionality looks strong, but integrating them cleanly into Typst’s built-in WASM plugin workflow turned out to be more complicated than I expected.

The current implementation uses:

• opensmiles for SMILES parsing
• CoordgenLibs for 2D coordinate generation
• a Rust/WASM plugin plus a small companion WASM plugin for the Typst integration

So the pipeline is now:

SMILES -> molecular graph -> 2D layout -> existing rendering AST -> alchemist

This works, but there are still some remaining issues. In particular, some double bonds in ring systems are not rendered ideally yet, so that part still needs improvement. Dense structures can also still be challenging depending on the rendering mode.

Testing is also still quite limited at this stage, so further validation and edge-case coverage will be needed.

[Ants-Aare]

this is looking pretty good! I checked out the feature branch and it's already kind of working. I'm currently trying to implement open babel's SMILES parser into typsium-smiles. and it's going okay as well. I'm not sure about user experience though. Do people want/need the intermediate coordinates? or do they just care about the final structure? How to allow annotation using arrows etc? Also on another note, you're generating alchemist ASTs, do you need specific API calls? we could help with making a package interface that is a bit more computer friendly and less user friendly, etc.

[rice8y]

Thanks, this is very helpful.

I did not know about typsium-smiles, so that is very interesting to hear. It is also good to know that your Open Babel-based approach is going reasonably well so far.

My current feeling is that intermediate coordinates are useful, mainly because they make more flexible layout control possible. But I am not fully sure how much of that should be exposed in the user-facing API. For many users, the final rendered structure is probably the main thing they care about.

I agree that annotation is still an open design problem as well. Things like arrows, highlights, or additional labels would likely need a lower-level interface than a simple render-smiles(...) function.

Yes, that would be very helpful. Right now I am effectively generating alchemist AST-like structures, so if you would be open to helping with a package interface that is more computer-friendly and less directly user-facing, I would really appreciate that.

[rice8y]

@tryptophawa @Ants-Aare

After making progress on SMILES compatibility, I’ve released version 0.1.2.
Please bear with us as we continue working toward merging into Typst Universe.

[Ants-Aare]

congrats! I'll check it out!