Building an AI presentation generator that actually handles Arabic (RTL) right

Most "AI presentation maker" tools fall apart the moment you type Arabic. Text drifts to the wrong side, bullet points flip, punctuation jumps to the end of the line, and the exported file looks broken. That single problem is why I ended up building DoocuAI — an AI tool that turns a topic or a PDF into a full, editable PowerPoint deck, with right-to-left support treated as a first-class citizen instead of an afterthought.

This post is about the parts that were actually hard, and what I learned shipping it for real students.

The problem I was actually solving

I'm building for university students in Iraq and the wider Arab world. A typical "seminar" (a graded classroom presentation) eats 2–5 hours of a student's time — and almost none of that time is spent thinking. It goes into:

• Reading scattered sources and pulling out the key points
• Rewriting paragraphs into short bullet lines
• Picking a template, fixing colors, aligning boxes on every slide
• Fighting RTL layout in tools that were never designed for it

The insight was simple: the thinking is the student's job, the mechanical formatting is not. So the tool should collapse the mechanical part to seconds and hand back an editable file — not a locked image, not a screenshot, an actual .pptx the student owns.

The stack (kept deliberately boring)

• Firebase — Hosting, Firestore, and Auth. Boring on purpose: I wanted to ship, not to run infrastructure.
• A thin API layer in front of the model calls, so the model provider and prompts can change without touching the client.
• An LLM for content generation — structuring the deck, writing each slide, keeping it academic rather than fluffy.
• Server-side deck generation producing standard .pptx output that opens in PowerPoint, Google Slides, Keynote, or LibreOffice.
• 60+ themeable templates so the same generated content can be re-skinned instantly.

Nothing here is exotic. The interesting engineering was almost entirely in two places: making the LLM output a deck instead of an essay, and RTL.

Getting an LLM to output a deck, not prose

An LLM will happily write you five paragraphs about photosynthesis. That's the opposite of a good slide. A good slide is one idea, a few short lines, and a title.

Two things helped the most:

1. Generate the structure first, content second. Ask the model for a slide outline (cover → intro → objectives → main axes → results → conclusion → references), validate it, then fill each slide. Splitting it stopped the "wall of text on slide 3" problem.
2. Constrain aggressively at the slide level. Hard limits on bullet count and line length in the prompt, plus a post-processing pass that trims anything that slips through. The model is much better at rewriting-to-fit than at self-limiting up front.

The academic structure being fixed and predictable turned out to be a feature, not a limitation — it's exactly what a grading committee expects to see.

RTL is where tools quietly break

Here's the part I underestimated. Rendering Arabic on a web page is mostly solved (dir="rtl", unicode-bidi, a decent font). Rendering Arabic inside a generated presentation file is a different world:

• Mixed content. A single line might be Arabic with an English acronym and a number: نظام ECTS بنسبة 40%. Naive RTL flips the whole run and the 40% lands in the wrong place. You need proper bidirectional handling (the Unicode Bidi algorithm), not a blanket "reverse the string."
• Alignment ≠ direction. Setting text to right-aligned is not the same as setting the paragraph direction to RTL. Get one without the other and bullets, indentation, and list markers end up on the wrong side.
• Punctuation and parentheses. Brackets and quotation marks are direction-aware. (محتوى) has to keep its parentheses wrapping the right side, which "just reverse it" gets wrong every time.
• Fonts. Plenty of otherwise-nice fonts have weak or broken Arabic glyphs, so template choice has to be validated against the actual script, not eyeballed in Latin.

The fix wasn't one clever trick — it was refusing to treat RTL as a toggle. Direction, alignment, list markers, and numeral shaping each get set explicitly per paragraph, and templates are tested with real Arabic content before they ship. Unglamorous, but it's the difference between a file a student can hand in and one they have to redo by hand.

Lessons that generalized

• Boring infrastructure buys you speed. Every hour not spent on servers went into the two problems that actually mattered.
• Structure-then-fill beats one-shot generation for anything that has a required shape — decks, reports, forms.
• i18n is not a feature you add at the end. If RTL isn't designed in from slide one, you rebuild. Ask me how I know.
• Give users the real file. Handing back an editable .pptx instead of a locked export changed how people trusted the tool. Ownership matters.

Try it / poke holes in it

It's live and free to start at doocuai.com — type a topic (or upload a PDF), pick a template, and you get an editable deck in seconds. If you work with RTL languages and want to tell me everything I still got wrong, I genuinely want to hear it — that feedback loop is how the Arabic handling got good in the first place.

If you're building anything that generates documents from LLM output, I'm happy to go deeper on the structure-first prompting or the bidi handling in the comments.