@genomdev/pptx

The document-wide `Environment`: fonts, and the styles a text box inherits. The presentation's own defaults live here rather than on a master, which is the opposite of where the modern format puts them — `p:defaultTextStyle` is on the presentation part and `p:txStyles` on the master, and a `.ppt` has it the other way round for the pair that matter.

The document's shared tables: the fonts, and the masters' typography. A run of text in a `.ppt` names its typeface by number. The number is a position in this collection and means nothing without it — "font 3" is Verdana in one presentation and 宋体 in the next — so the collection has to be read before any slide can say what it is set in.

The first child of a type.

Every child of a type, immediate children only.

A four-byte colour field, which is two different things told apart by a byte. The high byte is not part of the colour. `0xFE` means the three below it are a literal `RGB`; `0x00`–`0x07` mean they are to be ignored and the byte is an index into the colour scheme; `0xFF` means the field says nothing at all. Reading the whole word as a colour gives a deck whose every text run is one of eight shades of near-black, which looks plausible enough to ship.

The offset the `Current User` stream points at, if it can be believed. The stream *is* the atom — its eight-byte record header is the first thing in it, with no length in front — and the four bytes after that header are the atom's own stated size rather than anything to read. Both of those are easy to get wrong by one field, and being wrong by one field here reads the header token as a version number, fails the check, and silently falls back to scanning for the last save.

Whether the `Current User` stream says the presentation is enciphered.

Every record of a type at any depth, the record itself included.

Содержимое презентации — без зонтика и без чужих форматов в графе. Для того, кто знает, какой у него файл. Принимает и уже открытый документ: вьюверу незачем разбирать файл второй раз, чтобы поискать в нём.

The first record of a type at any depth.

A flag out of a bit-mask property, distinguishing "off" from "not stated". The whole subtlety of the format is in this function. `bold` is bit 0 of the `flags` field, and that field is *itself* selected by bits 0-15 of the mask — so a run whose mask has bit 0 set and whose flags have bit 0 clear says "not bold" and overrides the master, while a run whose mask lacks bit 0 says nothing and inherits. Collapsing the two makes every inherited bold run plain, which on a template that bolds its titles is the whole deck.

The levels stated for a kind of text, falling back the way PowerPoint does. A master states the kinds its design uses and no others, so asking for the centred body of a deck that has none must give the body rather than nothing: nothing means the browser's default face at the browser's default size, which is never what the deck looks like.

The master's typography for one role at one outline level. The `.ppt` half of the ladder a paragraph climbs. In the modern format the rungs are the run, the shape's list style, the layout's and the master's; in this one there is no layout, so the ladder is shorter — the run's own properties over the master's level style — but the master's rung carries exactly the same information and matters exactly as much. A title in a deck of this age states nothing about itself at all: not its size, not its colour, not its face. All of that is here, and a reader that skips it renders every presentation ever made in Times New Roman at twelve points.

Opens a PowerPoint presentation. Reads the table of contents: slide order and canvas size. Each slide is a separate package part and is therefore parsed on demand: showing the first slide need not touch the other ninety-nine.

Reads `p:cSld/p:bg`: what the slide, layout or master is drawn on. Two spellings. `p:bgPr` states the fill outright; `p:bgRef` names an entry of the theme's background list and the colour to fill its placeholder with, exactly as a shape's `a:fillRef` does — so the same resolution serves both, and the reference is returned as a solid fill of the referenced colour when the theme is not at hand.

The shapes of a SmartArt drawing, as slide shapes. A `dsp:sp` is a `p:sp` under another namespace — same transform, same geometry, same text body — so a deck needs no second renderer for SmartArt: the shapes go through the one that draws everything else, and inherit its text layout and its effects with them. That is why this is not `parseDiagramDrawing` from `@genomdev/office-core`, which reads the same part into a model of its own. A document and a workbook have no general shape renderer to hand the result to; a deck does, and using it draws more rather than less.

Reads `p:graphicFrame`: a chart, a table or a diagram on a slide. Only the chart is followed further, because only the chart has a renderer already — the frame itself is read whatever it holds, so that the space it takes is not silently lost. Exported because a `.ppt` needs it and has no slide to reach it through. PowerPoint 2007 and later hide the modern form of a table or a diagram inside a binary presentation as a small package of their own, whose one part holds a `p:E2oFrame` — a graphic frame under another name, with the same children in the same namespace. `@genomdev/pptx` opens the package and hands the element here, so the table it holds is the same `SlideTable` a `.pptx` would have produced and everything above is unchanged.

Reads nine `a:lvlNpPr` out of a list style. The same nine levels appear in four places — the master's `p:txStyles`, a layout placeholder's `a:lstStyle`, the shape's own, and the presentation's default — and a paragraph takes the first answer it finds walking outwards. One reader serves all four.

Reads a sequence of records filling a range. Stops at the first header that cannot be believed. Continuing past one is worse than stopping: the reader would be somewhere inside a payload, where every eight bytes look like a header and the records it invents are indexed by the same code that indexes real ones.

Parses a slide part (`ppt/slides/slideN.xml`). Shapes nest inside groups (`p:grpSp`), so the walk is recursive. Inheritance from the layout and master is deliberately not resolved here: that is a separate layer which needs access to the whole package, and it belongs to rendering rather than to parsing.

Reads the part into a lookup by style id, braces and all.

The placeholder name a story's kind stands for, `title` and friends.

Reads a `ColorSchemeAtom`. Eight four-byte values, each `red, green, blue, unused` — so the bytes are in the opposite order from the hex a person writes, and a reader that takes the low three bytes as `RGB` renders every deck in its own complement.

The records the directory names, read once and indexed by persist identifier. Reading them eagerly rather than on demand is deliberate and cheap: a presentation is a few megabytes at most, the records are already in memory, and the alternative — parsing a slide the first time somebody looks at it — would have to keep the stream alive anyway. What *is* deferred is the work above a record: turning it into shapes and paragraphs, which is where the time actually goes.

Reads a slide's drawing into shapes. The top of the tree is one group holding everything, and its own shape is the slide's canvas rather than something drawn — it is skipped, or the deck gets one full-slide rectangle in front of every slide.

`TxMasterStyleAtom`: the deck's typography, one entry per outline level. The master's answer to `p:txStyles`, and the same information — but written as pairs, a paragraph exception and a character exception per level, and with one quirk that has to be got right. The record's instance number says which kind of text these levels describe, and the styles for a *centred* body and everything numbered above it write the level number before each pair, while a title's and a plain body's do not. Read the wrong way the two bytes are taken for the top half of the next mask, and the whole master comes out unformatted.

Reads the `TxMasterStyleAtom`s a master carries. Which kind an atom describes comes from its instance number and from nothing else: the atoms sit side by side in the master with no marker between them, so taking the first as the title and the second as the body by position happens to work for most files and fails for exactly those whose master states only one of the two.

Reads the persist directory by walking the chain of saves. Each `UserEditAtom` is visited once. The guard matters more than it looks: a file whose chain loops — and fuzzers produce them, as do a few real files whose last save was interrupted — would otherwise be read until memory ran out, and the presentation is perfectly readable from the part of the chain that came before the loop.

Reads the record at an offset, and its children if it has any. A length running past the end of the stream is clamped rather than refused: a `.ppt` truncated by whatever copied it is common enough that losing the whole presentation over the last record would be the wrong trade. What is not clamped is a *nested* length — see {@link parseRecords}.

Splits a run of records into stories. Driven by the headers rather than by container structure, because there is no container: `[header][chars][styles][header][chars][styles]` is one list, and a reader that groups by anything else pairs the second story's characters with the first story's styles.

`StyleTextPropAtom`: the paragraph runs, then the character runs. Both lists cover the same text and neither states where it starts — each run says only how many characters it covers, so position is the running sum. The two lists are read one after the other out of one payload, which is why the character list cannot be read without the paragraph list being read correctly first: there is no offset to seek to. The text length is passed in because the atom does not carry it. The stated lengths are checked against it — a run claiming more characters than the story holds is a corrupt file, and believing it walks the reader off the end of a list that has no terminator.

The header at an offset, without reading the payload.

A scheme slot as a theme reference, for the places that state an index.

Collects all shape text of a slide, for search and previews.

Whether a part draws the master's own shapes. `showMasterSp="0"` on a layout or a slide means "my design, not the one behind me" — 88 parts of the corpus say so, and drawing the master's logo over a layout that turned it off is worse than not drawing it at all.

Turns a story into the paragraphs the modern model uses. Three lists have to be walked at once and none of them is indexed: the characters, the paragraph runs and the character runs each say only how long they are. The walk below keeps one cursor over the text and consumes from the other two as it passes them, which is the only way to pair them — and it is why a single wrong length earlier in the file misformats everything after it rather than one run.

Which of the master's three lists describes a placeholder's text. Only three kinds of text exist as far as `p:txStyles` is concerned: a title, the body of a slide, and everything else.

The scheme as a theme, so that everything above this line stays unchanged. The renderer resolves `accent1` through a `Theme`, and a presentation that cannot hand it one is a presentation drawn without colours. The twelve slots are filled from the eight: the four the scheme has no opinion about take the value of the slot they are nearest to, which is what PowerPoint does when it converts a deck of this age.

Every top-level record of the stream, for the tools rather than the reader. The reader has no use for this — a record not named by the directory is by definition not part of the presentation — but a person looking at a file that disagrees with PowerPoint does, and so does the dump tool.

Reading a deck as content. Simpler than a document in one way and harder in another. A slide *is* a page, so there is no pagination to be honest about and the section structure is given. But a slide has no reading order: it is a bag of shapes at coordinates, and the order they appear in the file is the order they were drawn, which is z-order and not the order anybody reads them in. So shapes are sorted before they are walked — title first because it is the title, then top to bottom and left to right. A deck extracted in file order routinely puts the page number before the heading, and every chunk from it starts with "4".

A slide's drawing, read into the shapes the modern model uses. This is the part of a `.ppt` that is *not* peculiar to it. Everything a slide shows is an Office Art tree — the same tree a `.doc` anchors to its text and an `.xls` floats over its grid — so the walk below is the third of three, and the record layer under it is shared. What is peculiar is where the words are, and there are two answers rather than one. A text box carries its own story inside the shape, in a record that Office Art treats as opaque bytes and that turns out to hold PowerPoint records. A *placeholder* — the title and the bullets, which is most of the text in most decks — carries nothing at all: its words are in the document's outline list, and the shape names them by number. A reader that handles only the first shows every deck as its pictures and its captions with the title and the body missing, which is a plausible-looking presentation of nothing.

A master's typography, by kind of text and outline level. The `.ppt` counterpart of `p:txStyles`, and it is finer-grained than the modern format's three lists: a master carries one `TxMasterStyleAtom` per *text kind*, and there are nine of them. The title and the body are the two everyone knows about; the interesting one is the fifth, the centred body, which is what a subtitle on a title slide is. Collapsing the nine into three was worth exactly one visible bug and it is the kind to remember: a subtitle taking the body's style is a subtitle with a bullet in front of it, on the first slide of every deck built from the shipped template. Nothing about the number was wrong — the size, the face and the colour were all the body's, and the body's are nearly the subtitle's.

The presentation's picture store. The same Office Art store the other two binary formats keep, found in a different place and pointing somewhere else again. A `.ppt` puts the store in the document's `PPDrawingGroup` record and the *bytes* in a stream of their own, called `Pictures`, which each entry names by offset. So the store looks empty on inspection and the pictures are in a stream nothing else refers to — the same shape of trap Word sets by keeping them among its text, and it costs the whole deck's imagery when missed. Names are invented rather than read. The model addresses a picture by package part name and relationship id, because that is what the modern format gives it; a binary presentation has neither. `ppt/media/image3.png` is therefore a name this module makes up and answers to, which is what keeps the renderer, the extractor and the addressing scheme identical for both generations.

Finding out which bytes of the stream are the presentation. This is the one structure a `.ppt` has that neither of its siblings does, and it exists because PowerPoint saved incrementally. Editing a slide appended a new copy of it to the end of the stream and left the old one where it was; a file of forty slides may hold four hundred, most of them superseded. Nothing in the stream marks a record as dead. What decides is a chain, and it is read backwards: `Current User`, a stream of its own, points at the *last* `UserEditAtom`. A `UserEditAtom` points at the persist directory of its own save, and at the `UserEditAtom` of the save before it. A persist directory maps *persist identifiers* — small numbers a slide is named by — to byte offsets. Walking the chain from the last save to the first, and letting each earlier directory fill only the identifiers no later one claimed, gives the current offset for every object. A reader that instead takes the first match walking forwards shows the presentation as it was when it was created.

A rectangle in EMUs, the DrawingML coordinate system.

A shape holding text or a picture.

A background, and the part whose relationships resolve its picture.

The document's outline: which slides there are, in which order, and what their placeholders say. `SlideListWithText` is two things at once and that is the whole of its awkwardness. It is the presentation's table of contents — a `SlidePersistAtom` per slide, naming the record that holds it — and it is *also* where the text of every outline placeholder lives, as stories following the atom they belong to. So a slide's title is not in the slide; it is here, and the slide's title shape merely points back at it by number. There are three of these lists and they are told apart by the record's instance number, not by their position among the document's children: the masters, the slides, the notes. Taking them by position puts the masters' text on the slides for any file whose lists are not all present.

A table on a slide: column widths and rows of cells.

One run of a style atom: how many characters it covers, and what it says.

A rule, stated outright or as a reference into the theme's line list.

One part of a table style: the whole table, a band, a header row.

A whole table style: the parts, in the order they override each other. PowerPoint applies them from the least specific to the most: the whole table, then the banding, then the first and last rows and columns. A cell in the header row of a banded table is painted by three of them in turn.

What a story needs from the deck to become paragraphs. The colour scheme because a run's colour is usually an index into it, and the font collection because a run's typeface is an index too — a `.ppt` states "font seven", and only the document knows that font seven is Verdana.

What the master sets for one outline level of one kind of placeholder. `p:txStyles` is the deck's typography: it says a title is 40pt, bold, and coloured `tx2`, and a first-level bullet 20pt in `tx1`. Reading only the size out of it — which is where this started — gives every deck the right scale in the wrong colour.

A paragraph of a text body (`a:p`).

The values a mask named, by property name, and which bits were set.

Formatting of a text fragment (`a:rPr`).

A spacing, as a share of the type size or as an absolute measure.

A text story, and turning one into paragraphs. A story is a run of records rather than a container: a `TextHeaderAtom` saying what kind of text follows, then the characters — as bytes or as UTF-16, never both — then the styles that cover them. They sit side by side in whatever holds them, a slide's drawing or the document's outline list, and a story ends where the next header begins. The characters are one string with `\r` between paragraphs. Nothing marks a paragraph otherwise; the styles are stated as runs over that string, so a paragraph's formatting is found by counting characters, not by looking it up.

One outline level's typography: the paragraph's and the run's.

Bits of the paragraph `bulletFlags` field.

Bits of the character `flags` field.

Where the pointer to the most recent edit is kept, outside the document.

Slide size when a document states none: the 10 by 7.5 inch default of 1997.

Default slide size: widescreen 16:9, 13.333 by 7.5 inches.

`a:bodyPr` insets when the file states none, in EMUs. A tenth of an inch left and right, a twentieth top and bottom — PowerPoint's defaults, and not zero, so text never touches the edge of its shape.

The streams a presentation may live in. `PowerPoint Document` is the one every version since 97 writes. The second is a curiosity worth handling: a file saved by PowerPoint 95 for compatibility keeps *both* generations side by side, and the modern stream is the one to read — but some tools keep only the old name.

Master units to EMUs. A `.ppt` measures in 576ths of an inch and a `.pptx` in 914 400ths; the ratio is exact, which is the only reason the two models can share a rectangle type without either side rounding.

`OEPlaceholderAtom`'s identifier as the placeholder name `.pptx` uses.

The text kind translated into the placeholder name the modern format uses. The whole point of the exercise: once a story says `ctrTitle` rather than `6`, the typography ladder, the extractor and the renderer built for `.pptx` treat it as the title it is, with no code anywhere that knows the deck came out of PowerPoint 97.

`OEPlaceholderAtom`'s placeholder identifiers. A superset of the text kinds above: it also names the three things that are placeholders but hold no outline text — the date, the footer and the slide number — which is exactly the set a renderer must not draw as body text.

PowerPoint presentations, both generations, as one module. Recognition is stated as data so the registry can pick this module out of six without loading any of them: an OPC package announces its main part's content type, and that is the only thing that tells the three OOXML formats apart. The compound file is the case rules cannot settle — a `.doc`, an `.xls` and a `.ppt` share one signature — so it shortlists itself and `canOpen` reads the directory to be sure. One module rather than two because the binary reader produces the same model: nothing above here has to know which generation it was handed.

The record types a PowerPoint 97-2003 stream is made of. Numbered rather than named — a `.ppt` has no XML and no vocabulary, only these numbers — and grouped the way the format groups them: the document and its slides in the 1000s, the collections in the 2000s, text in the 4000s. Only the types this reader acts on are listed; everything else is stepped over by its stated length, which is what lets a reader written against PowerPoint 97 walk a file PowerPoint 2003 saved.

The eight slots, in the order the atom writes them.

Which of a `SlideListWithText`'s three roles this one holds. The instance number of the record says it, and the three are not interchangeable: the first lists the masters, the second the slides in their presentation order, the third the notes pages. A reader that takes them by position among the document's children gets the masters and the slides the right way round only by luck.

What kind of text a story holds, from `TextHeaderAtom`. The nearest thing the binary format has to `p:ph/@type`, and it is what turns a box of words into a title: the outline placeholders are numbered here and the renderer asks the master for a title's typography by this number.

Renders a presentation: one slide on screen plus navigation. A slide is built by positioning shapes absolutely from their EMU coordinates, scaled to the actual canvas size. That preserves the original composition, which flow layout cannot reproduce. Inheritance from the layout and master is not implemented yet: a shape with no explicit parameters is drawn with defaults. It shows mostly in the size and colour of title fonts.

What the host may ask of the presentation view beyond the common options. The built-in toolbar exists so that the view is usable on its own — dropped into a page with nothing around it, it must still be possible to reach slide seven. An application that has its own navigator (the playground's toolbar counts slides for every format alike) turns it off and drives `goTo` itself, and then wants to be told when the slide changes so its counter agrees.

PowerPoint presentations with its renderer attached. What `@genomdev/pptx/view` exports and what an application passes to the viewer. The universal half is the same object — the renderer is a field on it, not a second registration — so a format either brings a way to draw itself or it does not, and nothing has to pair them up by hand.