DEV Community: Yuuki Yamashita

Generating animated LINE-style chat slides with python-pptx + raw XML (and shipping it on Vercel)

Yuuki Yamashita — Tue, 02 Jun 2026 15:20:32 +0000

I was putting together a talk and had one of those half-baked ideas that you can't shake off: what if I showed an iPhone with a LINE chat screen, and the messages popped in one by one, like a real conversation happening live? The problem is, building that by hand in PowerPoint sounds miserable — laying out every bubble, then setting up an entrance animation for each one, one at a time. So instead I built a little tool that takes a chunk of conversation text and spits out a .pptx, and then I turned it into a web app and put it on Vercel.

This post focuses on the three things that actually gave me trouble:

Building an iPhone / LINE-style UI out of nothing but shapes in python-pptx
Working around the fact that python-pptx has no animation support — by hand-writing the timing XML and injecting it into the slide
Wiring up "conversation in, pptx out" with a static HTML front end and a Vercel serverless function (including the deploy that bit me)

Here's what came out of it:

And the slides it generates look like this:

The overall shape of it

It's nothing fancy. This is the whole file list:

.
├─ index.html        front end (input form + live preview)
├─ api/generate.py   conversation JSON → pptx (build_pptx) + handler
├─ requirements.txt  python-pptx
├─ vercel.json       builds (static + @vercel/python)
└─ dev_server.py     for local testing

All the real generation logic lives in Python (python-pptx), and the front end is plain HTML/CSS/JS. On Vercel, api/generate.py runs as a serverless function and index.html is served as a static file.

Building the iPhone / LINE UI out of shapes

Set the slide to a tall 9:16 aspect ratio, and from there it's just a matter of stacking rounded rectangles, ellipses, and text boxes.

SLIDE_W = Inches(7.5)
SLIDE_H = Inches(13.333)   # 7.5 : 13.333 = 9 : 16
prs.slide_width  = SLIDE_W
prs.slide_height = SLIDE_H

The stacking order goes: phone frame (black rounded rect) → screen (chat background) → green header → Dynamic Island → status bar (clock, signal, battery) → input bar. For something like the Dynamic Island, a black rectangle with its corner roundness (adjustment) cranked up to 0.5 already reads as the real thing.

isl = slide.shapes.add_shape(MSO_SHAPE.ROUNDED_RECTANGLE, ...)
isl.adjustments[0] = 0.5   # fully rounded into a "pill" shape

For the header and the input bar, I used ROUND_2_SAME_RECTANGLE ("rounded on the top two corners only" / "bottom two only") so they don't fight with the rounded corners of the screen. The input bar is just rotated 180° so its rounded side faces down.

One thing that quietly mattered: Japanese fonts. If you only set a:latin, Japanese text can fall back to some other font, so I push the same typeface into a:ea (East Asian) as well. That kept things consistent.

rPr = run._r.get_or_add_rPr()
for tag in ("a:latin", "a:ea", "a:cs"):
    el = rPr.find(qn(tag)) or rPr.makeelement(qn(tag), {})
    el.set("typeface", "Hiragino Sans")

Sizing the bubbles by guesswork

Each bubble gets a width and height estimated from its text, then placed. python-pptx can't measure rendered text, so I just approximate the display width as full-width characters = 1.0 and half-width = 0.5: short lines get a one-line width, longer ones wrap at a maximum width. Pretty crude, but it works.

def measure_bubble(text):
    char_w = BUBBLE_FONT_PT / 72.0           # one full-width char ≈ 0.208in
    cap = int((MAX_BUBBLE_W - PAD*2) / (char_w * 1.06))  # full-width chars per line
    ...
    if longest <= cap and "\n" not in text:
        width = longest * char_w + PAD*2 + 0.18   # slack so it doesn't wrap
        lines = 1
    else:
        width = MAX_BUBBLE_W
        lines = ceil(longest / cap)
    height = lines * LINE_H + PAD_Y*2 + 0.06
    return width, height, lines

At first I didn't add the slack (that trailing + 0.18) and used the exact width. The result: a short phrase like おつかれさま！ ("hey, nice work today!") would wrap onto two lines and look weirdly stretched. The actual rendered character width comes out a bit wider than my estimate, so giving it a little breathing room settled things down.

For the arrangement I copied real LINE and made "bottom-aligned" the default (newest message sits right above the input bar). I just sum up the height of the whole conversation first and set the start position to CHAT_BOTTOM - block_h.

The main event: no animation API, so write the XML yourself

This is where I got stuck the longest. python-pptx can create shapes and text just fine, but it gives you no way to touch animations (entrance effects and the like) through its API. So what do you do? Animations are stored as an OOXML element called <p:timing>, so I build that element myself and append it to the end of an already-generated slide.

PowerPoint animations are a tree of time nodes. Under mainSeq (the sequence that advances on click), you hang a <p:par> for each effect. What I wanted was "on click, bubbles appear one after another at 0.8s intervals," so:

The first effect is nodeType="clickEffect" (fires on click)
Every effect after that is nodeType="withEffect" with a delay, staggered in time

There's also an "After Previous" option, but it works by waiting for the previous effect to finish, and the behavior felt flaky. So I leaned on absolute offsets of i × 800ms instead. That turned out to be both more predictable and, honestly, less work.

The effect on each bubble is "Float In" — it fades in while drifting up slightly from below. I use <p:set> to make it visible, <p:anim> to move ppt_y (vertical position) from a touch below up to its real spot, and <p:animEffect filter="fade"> to fade it in, all running together.

def _effect_par(eid, spid, delay, node_type, grp):
    return f'''<p:par ...>
  <p:cTn id="{eid}" presetID="42" presetClass="entr" presetSubtype="8"
         fill="hold" grpId="{grp}" nodeType="{node_type}">
    <p:stCondLst><p:cond delay="{delay}"/></p:stCondLst>
    <p:childTnLst>
      <p:set> ... style.visibility=visible ... </p:set>
      <p:anim calcmode="lin" valueType="num">
        <p:cBhvr additive="base">
          <p:cTn id="{eid+2}" dur="{EFFECT_MS}" fill="hold"/>
          <p:tgtEl><p:spTgt spid="{spid}"/></p:tgtEl>
          <p:attrNameLst><p:attrName>ppt_y</p:attrName></p:attrNameLst>
        </p:cBhvr>
        <p:tavLst>
          <p:tav tm="0"><p:val><p:strVal val="ppt_y+0.04"/></p:val></p:tav>
          <p:tav tm="100000"><p:val><p:strVal val="ppt_y"/></p:val></p:tav>
        </p:tavLst>
      </p:anim>
      <p:animEffect transition="in" filter="fade"> ... </p:animEffect>
    </p:childTnLst>
  </p:cTn>
</p:par>'''

spid is shape.shape_id. For an incoming message I wanted the bubble and the avatar to appear together, so I give them the same grpId and the same delay. Once the <p:timing> string is assembled, I parse it with lxml and just append it to the slide.

timing = etree.fromstring(timing_xml.encode("utf-8"))
slide._element.append(timing)

A nice bonus: once a shape has an entrance effect, PowerPoint handles "keep it hidden until it fires" on its own. So I didn't have to write any code to hide the initial state myself.

One more note on checking my work. I was eyeballing layout by exporting to PDF with LibreOffice — but LibreOffice's PDF export only renders the final state of an animation. It's perfectly fine for catching layout problems, but to verify the motion itself I had to fall back to running an actual slideshow in PowerPoint/Keynote.

Turning it into a web app

Because I'd already factored the generation into a single build_pptx(data) -> bytes function, the web side only needed to POST the conversation as JSON. I wrote the serverless function with the standard-library BaseHTTPRequestHandler and return the bytes from build_pptx directly.

class handler(BaseHTTPRequestHandler):
    def do_POST(self):
        data = json.loads(self.rfile.read(length) or b"{}")
        pptx = build_pptx(data)
        self.send_response(200)
        self.send_header("Content-Type",
            "application/vnd.openxmlformats-officedocument.presentationml.presentation")
        self.send_header("Content-Disposition", 'attachment; filename="line_chat.pptx"')
        self.end_headers()
        self.wfile.write(pptx)

Input is just one text area

I didn't get clever with the input UI — it's a single text area. The only rules are "L: is the other person, R: is you, a blank line starts a new slide." Keeping it this loose is actually what makes it pleasant: you just dump in whatever conversation pops into your head.

L: Hey, nice work today!
L: There's something I want to run by you
R: What's up?

L: This thing's been eating up my time lately
R: Oh, I totally get that

Parsing is a regex applied line by line. Any line without an L:/R: prefix gets joined onto the previous bubble with a newline (i.e. multi-line bubbles).

const m = /^([LRlr])[:：]\s?(.*)$/.exec(raw);
if (m) { last = {side: m[1].toUpperCase(), text: m[2]}; slide.push(last); }
else if (last) { last.text += "\n" + raw.trim(); }   // multi-line bubble

A live preview in the browser

Having to download the file just to see the result is a miserable loop, so I rebuilt the same look in HTML/CSS and added a preview-and-play feature right in the browser. The colors and the bottom-alignment match the generated pptx, and for playback I just add CSS transitions (opacity and translateY) one after another with setTimeout. It ends up feeling about the same as the animation inside the pptx.

Two things that bit me on deploy

A requirements.txt makes Vercel think it's a "Python app"

My very first vercel --prod died immediately with this:

The pattern "api/generate.py" defined in `functions`
doesn't match any Serverless Functions inside the `api` directory.

The cause was the requirements.txt sitting at the project root. With that present, Vercel decides the whole project is a "Python app" and stops picking up api/generate.py as an individual function. I fixed it by spelling out builds in vercel.json, telling Vercel to build the static HTML and the Python function separately.

{
  "version": 2,
  "builds": [
    { "src": "index.html",      "use": "@vercel/static" },
    { "src": "api/generate.py", "use": "@vercel/python" }
  ],
  "routes": [
    { "src": "/api/generate", "dest": "/api/generate.py" },
    { "src": "/",             "dest": "/index.html" }
  ]
}

After that, python-pptx installed itself from requirements.txt, and both the function and the static serving worked exactly as I'd hoped.

You can't protect production on the free plan

Once it was live, I wanted to put it behind some access control, so I tried enabling ssoProtection (Vercel Authentication) via Vercel's REST API. This came back:

{ "code": "invalid_sso_protection",
  "message": "Vercel Authentication is not available on your plan for production deployments" }

Turns out the Hobby (free) plan doesn't let you put Vercel Authentication / Password Protection on production deployments (you need Pro). Preview deployments can be protected on the free plan. If you want to keep production hidden while staying free, you're looking at rolling your own gate — Edge Middleware, or Basic auth inside the Python function. For now I left it open.

Wrapping up

After doing all this, the part I'm most glad I pushed through was writing the animation XML by hand. I'd nearly written off animations as impossible with python-pptx, but it turns out that hand-assembling a <p:timing> element and appending it is all it takes to get bubbles floating in, one by one, on a real PowerPoint. And the dead-simple withEffect + absolute delay approach was more than enough.

Factoring the generation into a single function also paid off more than I expected — moving from a CLI to a web app was basically copy-paste.

Being able to type out a conversation and get an animated chat slide back made prepping for talks noticeably less of a chore. The code is up on GitHub if you want to poke around — happy to hear what you'd build with it.

Building Diagram AI: From Natural Language (and Screenshots) to AWS Architecture Diagrams

Yuuki Yamashita — Tue, 02 Jun 2026 13:59:18 +0000

Drawing architecture diagrams by hand is tedious. You drag boxes around, align icons, fix arrows, and then your design changes and you do it all again. I wanted something where I could just describe an architecture in plain English — or paste an existing diagram — and get a clean, AWS-style diagram back.

This post is the story of building Diagram AI: a browser app that turns natural language and images into architecture diagrams. It runs on Vercel, uses Amazon Bedrock (Claude Haiku 4.5) for the language understanding, and renders the actual diagrams with AWS's open-source diagram-as-code tool. I'll be honest about the parts that didn't go smoothly, because that's where the real lessons were.

The core idea

The pipeline is simple to describe:

[User input: text or a diagram screenshot]
        │
        ▼
[Vercel · Next.js]
   ├─ /api/generate-yaml  → Bedrock Claude Haiku 4.5 → diagram-as-code YAML
   └─ /api/render         → AWS Lambda (Function URL) → awsdac → PNG
        │
        ▼
[Browser: live preview + PNG download]

The clever part is the middle layer. Instead of asking an LLM to "draw a diagram" (which it can't do reliably), I ask it to write YAML in the diagram-as-code schema. A deterministic CLI then renders that YAML into a real, standards-compliant AWS diagram. The LLM does the understanding; a proven tool does the drawing.

Why diagram-as-code?

diagram-as-code (the awsdac CLI) is an AWS Labs project that generates architecture diagrams from human-readable YAML. It ships official AWS service icons and follows AWS diagram conventions. Crucially, it's extensible: you can add your own definition files to draw non-AWS services too. That extensibility became important later.

First wall: you can't just `import` it

My initial plan was elegant on paper: diagram-as-code is written in Go, so I'd compile it into a Vercel Go Serverless Function and call it as a library. Clean, all-in-one, no extra infrastructure.

Then I read the source. Almost all of the core logic lives under Go's internal/ directory — internal/ctl, internal/types, internal/definition, and so on. Go's language rules forbid importing internal/ packages from outside the module. The library-import approach was simply impossible.

So I pivoted: run awsdac as a CLI inside AWS Lambda, exposed via a Function URL, and have the Vercel app call it over HTTPS. Vercel handles the frontend and the LLM; Lambda handles the rendering.

Second wall: no Docker, no Go on the machine

The plan was to package the Lambda as a container image. But the build machine had neither Docker nor Go installed. Rather than fight that, I switched to a zip-based Lambda on the Python 3.12 runtime:

Download the official prebuilt awsdac Linux binary from the GitHub releases.
Write a tiny Python handler that shells out to the binary.
Zip the two together and upload. No Docker, no Go build step.

The handler is small — receive YAML, write it to /tmp, run awsdac, return the PNG as base64:

proc = subprocess.run(
    [AWSDAC_PATH, "--allow-untrusted-definitions", in_path, "-o", out_path],
    capture_output=True, text=True, env={**os.environ, "HOME": "/tmp"}, timeout=25,
)

Third wall: a 403 that wasn't in any policy

With the function deployed, direct aws lambda invoke worked perfectly — a clean PNG came back. But calling the Function URL over HTTPS returned 403 Forbidden / AccessDeniedException.

The auth type was NONE. The resource policy granted lambda:InvokeFunctionUrl to *. Everything looked right. I checked for org-level SCPs and RCPs — none.

The answer was in a documentation note: since October 2025, public function URLs require two permissions — both lambda:InvokeFunctionUrl and lambda:InvokeFunction. I only had the first. Adding the second statement fixed it instantly:

aws lambda add-permission --function-name diagram-ai-render \
  --statement-id FunctionURLAllowInvoke \
  --action lambda:InvokeFunction --principal "*" \
  --invoked-via-function-url --region us-east-1

Lesson: when a 403 makes no sense, check whether the platform's rules changed recently, not just your own config.

Making the LLM output good diagrams

Getting valid YAML was the easy half. Getting good-looking diagrams took several rounds of prompt engineering, each driven by an ugly output:

Arrows piercing containers. The LLM would draw an arrow from User straight to an ALB deep inside a VPC, slicing through the "AWS Cloud" and "VPC" boxes. Fix: a hard rule that any external→internal arrow must route through an Internet Gateway placed on the VPC's border (BorderChildren), exactly like AWS's own reference diagrams.
Arrows overlapping label text. diagram-as-code pins each label directly under its icon and routes arrows through the icon's center, so vertical flows always crossed the text. After testing four layout strategies, the winner was horizontal flow (Direction: horizontal): horizontal arrows pass through the icon's mid-height and clear the labels below.
Invented resource types. Asked for a "box," the model confidently produced AWS::Diagram::Container — a type that doesn't exist. I added an explicit list of safe AWS types plus a rule: never invent types; fall back to a generic resource if unsure.

Each fix went straight into the system prompt with a concrete good/bad example. The prompt grew long, but the outputs got dramatically cleaner.

Going beyond AWS

diagram-as-code is AWS-first, but its definition-file mechanism lets you add arbitrary icons. I wanted hybrid diagrams — "GitHub → Vercel → AWS Lambda" — to look right.

I built a small pipeline: pull SVGs from simple-icons, tint them with each brand's color, and convert to 128×128 PNGs with sharp. That produced 19 external service icons (Vercel, Netlify, Cloudflare, GitHub, Supabase, Auth0, OpenAI, Anthropic, Stripe, and more), bundled into an icons.zip plus an external-icons.yaml definition file that maps types like External::Vercel to the icons.

One subtlety: awsdac refuses to load definition files from URLs outside the official repo unless you pass --allow-untrusted-definitions. And I originally hosted the icons on GitHub Releases, but a private-repo mix-up left GitHub's CDN serving cached 404s. The robust fix was to serve the definition file and icon zip from Vercel's own /public folder — same origin as the app, instantly updatable on each deploy.

I also added Type: Group definitions so you can draw a branded container — e.g. a "Vercel Platform" box with the Vercel logo in the corner, holding child resources inside.

Reading existing diagrams

The feature I'm happiest with: upload a screenshot of an existing diagram and regenerate it. Claude Haiku 4.5 on Bedrock is multimodal, so I extended the API to accept an image (base64) alongside or instead of text.

Three modes fall out of this naturally:

Image only → read the diagram and reproduce an equivalent YAML.
Image + text → transform it: "take this diagram but swap Cloudflare for Vercel and EC2 for ECS."
Text only → the original behavior.

One build-time gotcha worth noting: the Bedrock client was being constructed at module load. During next build's page-data collection (which runs without AWS env vars) that threw Region is missing. Moving the client into a lazy, request-time factory fixed it — and it's a good pattern regardless.

The frontend supports paste (⌘V), drag-and-drop, and file selection, with a 5 MB cap.

Shipping it: CI/CD

Finally, I wired up automatic deploys. Connecting Vercel's GitHub App via CLI didn't work (it needs a browser step for repo access), so I used GitHub Actions + the Vercel CLI instead: on every push to main, the workflow runs vercel pull / build / deploy --prebuilt --prod with a token stored in GitHub Secrets.

The one hiccup: the Vercel token expired mid-way, producing The token provided via --token argument is not valid. Regenerating it (with no expiry) and re-registering the secret got the pipeline green. Now git push is all it takes to ship.

What I'd tell my past self

Read the source before committing to an integration strategy. The internal/ package issue would have saved a day if I'd caught it on day one.
When auth fails inexplicably, suspect recent platform changes. The dual-permission Lambda URL requirement was invisible in my own config.
For LLM-generated structured output, encode taste as rules with examples. "Don't pierce labels" only worked once it became a concrete layout rule with a good/bad sample.
Same-origin hosting beats clever CDN tricks when you control the deploy anyway.

The stack, in one line

Next.js on Vercel · Amazon Bedrock (Claude Haiku 4.5, text + vision) · AWS Lambda (zip, Python 3.12) running the awsdac CLI · simple-icons + sharp for non-AWS icons · GitHub Actions for CI/CD.