We just shipped Algeo SDK 2.6.0.
Algeo SDK is one of the open capabilities Dino-GSP exposes to other products. The goal has never been a standalone editor. It is a geometry capability you can pull into an education product, an AI math product, a question bank, or a teaching research tool: it can draw, present, interact, and flow into your own content and business processes.
Over the past few months, when we have talked with teams building education products, AI math products, and question bank systems, the feedback has been quite practical.
People rarely ask only about which APIs the SDK exposes. More often, they ask:
- Can the figure a teacher draws go straight into slides, handouts, and exam papers?
- When a student opens a problem, will the board occasionally fail to load?
- Can AI-generated geometry steps be exported as explanation diagrams or report images?
- Can the same geometry asset be both interactive and a reusable piece of content inside the platform?
- When something goes wrong during integration, can the SDK clean up after itself instead of leaving the host to deal with it?
These questions sound simple, but for a product that has to ship, every one of them matters.
So this release focuses on two things: adding slide image export and improving the reliability of embedded initialization. We have also refreshed the examples and documentation, so development teams have a smoother experience while debugging locally, writing demos, and validating before launch.
If you want to try it directly, use @dajiaoai/[email protected]. The slide image export demo is already public: Export Slide Image Demo.
If your product handles geometry problems, geometry courseware, AI solving, question bank editing, homework reports, or teaching research content, the scenarios below should feel familiar.
Scenario 1: figures a teacher creates can go straight into slides and handouts
Many education products want to give teachers an interactive geometry board.
But a teacher's real workflow does not end at the board. She may need to push the figure into a slide deck, a handout, an exam paper, an after-class solution explanation, or even a WeChat article or school resource library.
For years there was a wall between the dynamic figure and the static content around it. The board could move, but exporting meant taking a screenshot; the screenshot worked, but resolution, sizing, batch processing, and reuse were all fragile.
Algeo SDK 2.6.0 adds slide image export, so product teams can export the content of a geometry board as an image and feed it into their own slides, handouts, exams, reports, and content management systems.
That means the geometry assets a teacher creates inside your product are no longer just an "online board state". They can become a publishable, archivable, and shareable teaching asset.
For education product teams, this capability is very concrete:
- Courseware tools can drop a geometry figure straight into a slide
- Question banks can generate standard problem images and explanation images
- Teaching research platforms can derive a static preview from a dynamic asset
- Homework systems can surface key figures in the report
- Content teams can use one geometry asset across multiple distribution channels
Geometry content is no longer only "interactive". It can also enter a real content production pipeline.
We have a working demo for the export, so you can check the result before evaluating the workflow: 12-export-slide-image.html.
Scenario 2: question banks and homework systems need a more reliable embedded experience
Question bank, homework, and assessment systems set a high bar for reliability.
When a student opens a problem, the geometry figure cannot occasionally fail to load. When a teacher grades, the board cannot get stuck during initialization. When an operations team configures content, they cannot rely on refreshing the page until something works.
Algeo SDK 2.6.0 makes the embedded initialization flow more reliable, particularly around iframe loading, timeout handling, and exception cleanup, which are the parts that most often break during integration.
These changes may not be visible to end users, but they matter a lot to product teams.
In a real product, a geometry component does not just open once on a demo page. It shows up across many pages, on different networks, on different devices, under different permission states, and inside complex single-page application routes.
A more reliable embedded experience means:
- Student-side loading of geometry content becomes more predictable
- Teacher-side editing is interrupted less often by error states
- Platform teams get a clearer path when debugging
- Products can comfortably place the geometry component on critical paths
For an education platform, reliability is not a polish item. It is the precondition for geometry to enter the main workflow at all.
Scenario 3: AI math products do not only need to solve, they need to present
AI math products are moving from "give the answer" to "give the process".
This is especially true for geometry. What a student really needs is not a sentence like "connect point A and draw an auxiliary line". They need to see why the line goes there, how the relationships change after it appears, and how different configurations connect.
Once AI can generate geometry steps, the next problem is presentation:
- Can the generated figure be embedded reliably on the solving page?
- Can a multi-step explanation be split into separate boards or steps?
- Can each step be exported as an image for explanations, reports, or share pages?
- Can the student and teacher continue to edit, review, and remix the same geometry content?
The improvements in Algeo SDK 2.6.0 to "embedded reliability" and "slide image export" close exactly this loop.
AI-generated geometry content no longer has to live in a one-time page render. It can enter a more complete product loop: generate, present, interact, export, archive, reuse.
For AI math products, this directly affects how users feel about the product.
Users do not care which model is behind the scenes, and they do not care how the board initializes. They only feel one thing: is this geometry problem explained clearly, does the figure open, do the steps make sense, can the content be taken away.
Scenario 4: teaching research and content teams need geometry assets to become managed assets
In many schools, institutions, and content companies, geometry assets have lived for years as scattered files.
Some live on individual teacher computers. Some live inside PowerPoint files. Some are screenshots. Some are source files from old desktop software. Some sit in question banks but are not reusable.
That creates one very concrete problem: geometry content is hard to turn into an asset.
The value of Algeo SDK is not only embedding a board into your product. It is opening up the dynamic geometry capability Dino-GSP has built up so geometry assets can join your own business system:
- Who created the asset
- Which grade, chapter, and knowledge point it belongs to
- Which teachers can edit it
- Which content can be published to students
- Which figures can be exported into handouts and exam papers
- Which assets can enter AI generation or recommendation flows
The 2.6.0 improvements to the export and embedded paths make this assetization process smoother.
Content teams can author geometry figures inside their own CMS and export standard images for publishing and distribution. Teaching research platforms can generate a preview image for every dynamic geometry asset. Question bank systems can let the same content serve the editor, the student client, and the print pipeline at once.
Geometry is no longer "side illustration work". It becomes a first-class asset inside the platform's data model and content workflow.
Scenario 5: what product teams really want is fewer things to worry about
For a team preparing to ship, choosing an SDK looks like choosing a set of capabilities. In practice, it is choosing a long-term relationship.
Of course you care whether it can draw points, lines, and circles, whether it can edit, whether it can display, and whether it talks well with your business system.
But after launch, you care about more:
- Whether it stays stable when users open it
- Whether problems are handled correctly when they happen
- Whether examples and documentation keep up
- Whether a new teammate can pick it up
- Whether future versions will keep filling the gaps that real product scenarios surface
Algeo SDK 2.6.0 also refreshes examples, configuration support, and documentation, so the integration experience is closer to a real project rather than the simplest possible demo.
That sounds like a small thing. It is also a critical one.
An SDK is not something an engineer only "takes a look at". It eventually has to enter a product team's collaboration: PMs confirm the scenario, the front end integrates the component, the back end handles data ownership, operations configures content, customer success explains what the feature does.
The closer the docs and examples are to a real workflow, the shorter the path from integration to launch.
Which teams should pay attention to Algeo SDK 2.6.0
If any of these scenarios already exists in your product, Algeo SDK is worth a closer look:
- Online education platforms that want to add dynamic geometry to courses, question banks, homework, or classroom tools
- AI math products that want to move geometry problems from text explanations to visual, interactive solving
- Question banks and assessment systems that want geometry problems to stop being static images and become editable, presentable, reusable data
- Teaching research collaboration platforms where teachers co-create, reuse, and manage geometry teaching assets
- Educational publishing and content production teams that want to improve the production efficiency of geometry illustrations, courseware figures, handout figures, and exam paper figures
- EdTech SaaS vendors that want to add professional geometry capabilities without building a board from scratch
In short: if your product needs to handle "geometry content" in any form, Algeo SDK can bring the open capabilities of Dino-GSP into your underlying workflow.
In closing
Algeo SDK 2.0 made it possible to embed the geometry board inside another product.
Algeo SDK 2.6.0 takes that one step further: embedding is more reliable, content is easier to export, and examples and documentation are closer to the work product teams actually do.
This is not an update aimed at technical specifications. It is an update aimed at product delivery.
An education product does not need an isolated tool. It needs a geometry capability that can join the business workflow: usable by teachers, openable by students, reusable by content teams, generatable by AI, manageable by platforms, and reliable at the moments that matter.
Algeo SDK 2.6.0 is officially available.
If you are filling out the geometry capability of your education product, this is a good version to start the integration. Use @dajiaoai/[email protected] directly.
Release notes: github.com/dajiaoai/algeo-sdk/releases/tag/2.6.0
Image export demo: dajiaoai.github.io/algeo-sdk/examples/12-export-slide-image.html
SDK repository: github.com/dajiaoai/algeo-sdk
Bring the open capabilities of Dino-GSP into your product, so every geometry problem is more than just an image.