Building Filee's own document engine: the story so far (with pictures)

[KnifeLemon]

Building Filee's own document engine: where we are

Filee turns HWP / HWPX (and later DOCX and others) into PDF with rhwp today, and sends harder documents to LibreOffice. Both are separate programs. For the past days we have been building an engine of Filee's own that lays out and draws documents in-process, on every platform Filee runs on.

This post tells the story so far, step by step, with pictures. Your comments are very welcome: which documents break for you today, which features matter most, and anything that looks wrong below.

Note

The engine is not in a release yet. It lives on the builtin-engines branch and is tracked on the Filee: built-in engines board. Today's converters are unchanged until the engine is wired in.

How to read the pictures

Each picture shows the same document three times:

Left	Middle	Right
Hancom Hangul (한글) exported it to PDF. This is the reference.	rhwp, the engine Filee uses today.	Filee's new engine.

Most documents come from the test matrix, which is written in code: there are no sample files in the repository. Hangul's PDFs were made by driving Hangul itself through automation. The rest come from files attached to our issues.

---

1. The groundwork

PDF output and font subsetting (#683)

The first question was how to write PDF. We tried two ways on one mixed page (Korean, Latin, Arabic, Devanagari):

• A: Skia's PDF backend, with fonts subset by Filee.
• B: a page writer of our own on PDFsharp.

Both gave about the same size, so we kept A. Filee's own subsetter keeps only the glyphs a document uses:

• Malgun Gothic, a 13.5 MB font, becomes a 72.7 KB PDF for that page.
• CFF fonts (Pretendard, S-Core Dream) are converted to TrueType outlines on the way.
• Found on the way: CID-keyed CFF fonts such as Pretendard converted to TTF with glyphs 1000× too small. That is fixed too.

Fonts, shaping and Unicode (#695)

• Shaping is HarfBuzz, which Filee already ships.
• Unicode tables (line breaking, bidi classes, scripts, widths) are generated from the Unicode Character Database 16.0, the version .NET 10 uses.
• Font names: Hangul's Korean names are matched to the English ones (함초롬바탕 ↔ HCR Batang, 맑은 고딕, the HY and Nanum fonts). Hangul's built-in fonts go to their HY TrueType twins, and Arial / Calibri go to metric-compatible fonts where they are missing.
• Nothing is downloaded or bundled: the installed fonts are used.

A way to measure (#693)

Before writing layout code, we built the yardstick:

• A feature matrix written in code: line spacing, tabs, lists, tables, headers and footers, notes, columns, floating objects, equations, and paragraphs in Korean, Chinese, Japanese, Arabic, Hebrew, Devanagari, Gujarati and Thai.
• Read-back checks on every PDF: the text round-trips, no glyphs overlap, nothing leaves the page, every font is embedded and subset.
• A differential compare against rhwp: line breaks, baselines and picture similarity (SSIM).
• Thresholds: a check that gets worse fails the build.

It also showed where rhwp falls short today:

• floating objects lose their text wrap;
• right-to-left and Indic text is drawn unshaped;
• Chinese and Japanese punctuation is sometimes drawn over the next character.

---

2. Paragraphs and lines (#834, #839)

Line breaking

• Lines break by Unicode's line breaking rules (UAX Add e-book conversion, a built-in HTML reader and a calibre package #14). The engine passes all 16,672 cases of Unicode's own test file.
• Hangul's own settings are followed:
  • 어절: keep Korean words whole;
  • 글자: break between syllables;
  • breaking Latin words, and the characters a document forbids at the start or end of a line.
• Paragraphs: justify and distribute, tabs with leaders, indents, and every Hangul line spacing rule (percent, fixed, at least, between lines).

Following Hangul's own lines

An HWPX that Hangul saved stores every line of every paragraph, and Hangul draws from those lines when it opens the file. Filee now uses them too, when the fonts are installed.

• On the consent form from PPT/한글(HWP) -> PDF 이런 변환은 글자 배열이 틀어지네요. #49, line agreement with Hangul went from 46% to 82%, and every line of body text matched.
• Where the stored lines can't be used, Filee breaks the paragraph itself.

---

3. Pages, tables and columns (#840, #842, #845)

Page composer

• Sections, paper and margins.
• Keep-with-next, keep-together, widows and orphans.
• Headers and footers for both, odd or even pages.
• Page numbers and total-page fields.

Tables

• Spanning cells, Hangul's cell padding and row heights (within 0.02 pt of Hangul's).
• Line styles, fills and captions.
• Tables splitting across pages, with header rows repeated.

The two forms from #49 were the hardest test. Against Hangul's own PDFs:

Document from #49	Lines matching Hangul	Pages
Consent form (행정정보 공동이용 사전동의서)	82% → 100%	1 of 1
Instructor card (강사카드)	32% → 97%	1 of 1 (was 2)

In the instructor card, rhwp draws the consent sentence and the line under it on top of each other. Filee keeps them apart, as Hangul does. (Personal details in the file were already replaced by its author; the signature is blurred here.)

Columns, footnotes and endnotes

• Newspaper columns with their separator line.
• Column changes on a page, balanced the way Hangul balances them.
• Footnotes at the foot of the page, measured against Hangul: note spacing and the separator's length codes.
• Endnotes on a page after the body, or right after the text when the section says so.

---

4. Floating objects (#847)

Pictures, shapes and text boxes anchored to the paper, the page, the column or the paragraph go where Hangul puts them. On a probe file with one anchor per page, every anchor lands within 0.7 pt of Hangul's.

• Text wraps around objects, and goes above and below them.
• Shapes: rectangles, ellipses, lines, polygons, curves and arcs, with gradients, rotation and mirroring.
• Text boxes with their paragraphs and tables inside.
• Seals placed against the paper, beside a paragraph or inside a table cell, the kind of case hwp to pdf 에서 도장, 직인이 변환이 안됩니다. #384 reports.

rhwp loses the wrap and draws two paragraphs on one line. Filee matches Hangul's export of the same file.

---

5. Equations (#848)

Hangul's equation script is read the way Hangul reads it, then laid out and drawn:

• over, sqrt, root … of, LEFT … RIGHT, matrices, cases, sums and integrals;
• italic variables, upright numbers and functions;
• each equation keeps the box and baseline Hangul gave it.

Two exam papers from our issue files, with 488 and 249 equations, were the test bed.

---

6. Chinese, Japanese and Korean typography (#849)

• In Hangul's 어절 setting, Chinese and Japanese runs are kept together like Korean words. Hangul does exactly this, and the Chinese and Korean samples now break on Hangul's lines.
• Quotes, corner brackets and book title marks no longer overlap.

#280: a table of contents twice as long

In #280's Word document, every page number of the table of contents wrapped onto a line of its own. Word measures tab stops from the margin, Hangul from the paragraph's indent, and that difference pushed the right tab past the margin. Now the numbers stay on their lines at the right margin.

#237: quotes drawn over the text

#237's document showed Chinese quotes drawn over the next character. Filee draws them in place.

---

7. Right-to-left text and complex scripts (#861)

Bidirectional text

The full Unicode Bidirectional Algorithm (UAX #9) now runs: embeddings, isolates, numbers and brackets. It passes all 861,948 cases of Unicode's two test files.

• rhwp draws right-to-left text left to right, letter by letter.
• Hangul keeps every letter right, but puts some Hebrew words of a line in reverse order. There, Filee follows the Unicode standard rather than Hangul.

Shaping

Arabic joining, Indic conjuncts and vowel signs, and Thai, Lao, Khmer and Myanmar marks all come out shaped (#185, #202, #216).

Lines without spaces

Thai, Lao, Khmer and Myanmar put no spaces between words, so lines need a dictionary to know where a word ends. Filee carries ICU's word lists, about 500 KB for the four scripts. Where a document says how to break, Hangul's setting wins:

• 어절: a run without spaces stays whole;
• 글자: lines break between any two characters.

---

What's next

Roughly in this order:

1. PDF compression (in progress): re-subset the fonts of existing PDFs and write object streams, so the built-in compressor gets close to Ghostscript.
2. Wire the engine into the converters, with a check of what it can handle and a preview setting.
3. An HWP 5.0 reader, so binary .hwp files take the same path as HWPX.
4. Make the engine the default for documents → PDF, then remove rhwp.
5. Later: more readers (ODT, RTF, e-books), archives in-process, and EMF/WMF drawings.

Not done yet: kashida justification for Arabic, vertical text, CJK punctuation compression, and Word's document grid.

We'd love your input

• Do you have a document that comes out wrong today? Attach it to an issue, or say here what kind it is.
• Which features matter most in your files: tables, equations, forms, columns, a script?
• Anything in the pictures that looks off?

[KnifeLemon]

Update: what landed since this post

Six more pieces are in the builtin-engines branch. They're still not in a release.

PDF compression: fonts subset again, object streams (#895)

Compress PDF now shrinks the fonts a PDF embeds down to the glyphs its pages draw. That helps most with fonts embedded whole, and with pages split off a long document. It also packs the file's objects into object streams.

Against Ghostscript's /ebook, on PDFs generated in the tests:

PDF	Original	Filee	Ghostscript
Noto Sans + Noto Sans KR embedded whole	5.89 MB	269 KB	377 KB
Photo report (3 pages)	11.9 MB	6 KB	312 KB
All 18 test PDFs	18.2 MB	599 KB	995 KB

On PDFs that are already compact, Ghostscript stays 2–12 % smaller, because it rewrites their page content more tightly. So Also try Ghostscript stays as an option.

The new engine is a setting now (#899, #900)

Settings → Engines → Use the Filee renderer (preview), off by default.

• With it on: HWPX, Word documents, ODT, RTF, text, Markdown, HTML and e-books go to PDF through Filee's own engine. Pictures of the pages come from the same layout.
• With it off: nothing changes.
• Before converting, the engine looks through the file. If it holds something the engine doesn't draw yet (charts and OLE objects, vertical text, form controls, SmartArt), the file keeps its usual route.

macOS: a false alarm (#896)

A font test that skipped on macOS turned out to be a test problem, not a rendering one. macOS reports "no outline" for the space character, which has none. The test now runs on macOS too.

RTF without Pandoc (#904)

RTF → DOCX, HWPX, PDF, HTML, Markdown is built in now.

• Text in older code pages reads right, so Korean, Chinese and Japanese RTF works.
• Styles, headings, lists, tables with merged cells, pictures, footnotes, links, headers and footers, and page setup all carry over.

Checked with RTF that 한글 itself saved, and with Pandoc's.

ODT without Pandoc or LibreOffice (#907)

ODT is read and written by Filee itself:

• reading: styles, lists, tables, frames, pictures, notes and page layout;
• writing: ODT from anything Filee reads.

Coming next: an EMF / WMF renderer that works on every platform (clip art in HWP files, Word's EMF pictures), and Filee's own HWP 5.0 reader.

[KnifeLemon]

Update: HWP files and EMF / WMF pictures

Two more pieces are in the builtin-engines branch. They're still not in a release.

Filee reads HWP files itself (#909)

.hwp (HWP 5.0) is now read by Filee's own code, written from Hancom's published format document. The file is turned into the same HWPX package 한글 saves, and the existing HWPX reader takes it from there.

What changes:

• HWP → DOCX, ODT, EPUB, HTML, Markdown no longer need rhwp.
• HWP → HWPX is Filee's own conversion now. rhwp's stays as a fallback.
• HWP → PDF stays with rhwp by default. With Use the Filee renderer (preview) on, it goes through Filee's layout engine.
• Password, DRM and distribution (배포용) documents are refused with a message, and HWP 3.x files too. None of them are decrypted.

To check it, every HWP was compared with the HWPX that 한글 saves from the same file, field by field:

Files	Read the same as 한글's HWPX
41 public sample HWP files (hwplib)	33 / 41
46 HWP files saved by 한글 next to their HWPX	44 / 46
24 feature documents (tables, columns, floating objects, equations, scripts)	24 / 24
HWP / HWPX pairs attached to our issues	2 / 2

Most of the remaining differences are the document title. When a file has no summary information, 한글's HWPX names it after its first line of text; Filee leaves it empty. The rest is one dropped field result, one distribution document (refused on purpose) and two test artefacts.

21 HWPX files written this way were opened in 한글, and all of them open with the same page count as the original HWP.

EMF / WMF pictures on every platform (#908)

EMF and WMF are the picture formats of HWP clip art and older Word documents. Until now only Windows could draw them, through GDI+. Filee now has its own EMF / WMF renderer, so they work the same on Windows, Linux and macOS:

• EMF / WMF → PNG, JPG and the other image formats;
• EMF / WMF → PDF as vectors (sharp at any zoom);
• inside documents, the layout engine draws them as vectors into the page.

Left GDI+, right Filee. The metafiles were recorded on Windows with GDI and GDI+:

The one visible difference is the thin dotted line at the top right, which comes out as a grey line. That's on the list.

Measured with SSIM (1.0 = identical):

Recorded with	SSIM
GDI: shapes, pens, brushes	0.990
GDI: bitmaps, paths, clipping, transforms	0.989
GDI → WMF	0.987
GDI+: shapes, gradient, rotation	0.983
GDI+: text	0.967
GDI: text	0.921

Text scores lowest because GDI snaps letters to the pixel grid and Filee doesn't.

Not drawn yet: EMF+ only files (made by GDI+ without an EMF fallback). On Windows those still go to GDI+.

Coming next: making the Filee renderer the default, and then removing rhwp.

[KnifeLemon]

Update: Markdown → PowerPoint without Pandoc

Filee now writes PPTX itself (#932, in the builtin-engines branch, not in a release yet). Until now, Markdown → PPTX needed Pandoc.

The new writer takes anything Filee can read as a document: Markdown, HTML, DOCX, ODT, HWP / HWPX, EPUB, and the Pandoc formats when Pandoc is installed.

How the slides are split

The rules are Pandoc's, so a deck you already make with Pandoc splits the same way:

• each heading at the slide level starts a slide; higher headings get a section slide;
• --- ends a slide;
• the YAML block (title, subtitle, author, date) becomes the title slide;
• ::: notes becomes speaker notes, and footnotes go on a closing "Notes" slide.

On a slide: bullet and numbered lists keep their levels, tables get a header row and banding, pictures are scaled to fit (never enlarged), and code goes in a monospace box.

When a slide is full

Text isn't shrunk to fit. It goes on to a new slide with the same title, like PowerPoint's Continue on a new slide. Lists keep their numbering, and long tables repeat their header row.

Checks

• Every deck in the tests passes the Open XML SDK validator (Microsoft 365 rules).
• Each deck is read back by Filee's PPTX reader, and the text is all there.

Not yet

• Pandoc's two-column layouts (::: columns)
• incremental lists
• slide numbers and footers
• syntax highlighting
• using your own deck as a template

Coming next: Filee's own slide renderer, so PPTX → PDF / PNG no longer needs LibreOffice.

[KnifeLemon]

Update: old e-books and Kindle output without calibre

Two more pieces are in the builtin-engines branch (#931, #937). They're still not in a release.

Reading CHM, PDB, PML, TCR, RB, SNB and OEB (#931)

These formats needed calibre. Filee now reads them itself, so they convert to EPUB, PDF, DOCX, ODT, HWPX, PPTX, TXT and Markdown without calibre.

• CHM (Windows help files): Filee has its own LZX decompressor. Pages follow the book's table of contents. Pages without a declared character set are read in the code page of the book's language, so Korean, Russian and Japanese help files come out right.
• PDB: PalmDOC and zTXT books. eReader books are refused with a message, since most of them carry DRM.
• PML, TCR, RB, SNB, OEB: read directly. RB books with encryption are refused as DRM.

Three real help files on Windows converted cleanly to EPUB and Markdown: 7-Zip's, PuTTY's, and Python 3.10's (9 MB, 974 pages, 954 pictures).

A Korean CHM built in code, converted to PDF with neither calibre nor rhwp installed:

The missing space under the table is a bug in the Filee renderer, not in the CHM reader. It's on the list for the renderer work.

Writing AZW3 and MOBI (#937)

Filee now writes Kindle books itself, from the same XHTML it uses for EPUB. A book gets:

• chapters, the style sheet and embedded pictures;

• working internal links;

• a table of contents from the top two heading levels;

• title, author and cover.

• AZW3 is KF8 only, the format current Kindles use.

• MOBI is a combined file, the way Amazon's KindleGen made it: an old-format part for Kindles from before 2011, then the same KF8 part. Older readers lose the CSS styling but keep headings, bold and italic, lists, tables, pictures and links.

Every book Filee writes is read back with Filee's own MOBI reader and compared with the EPUB of the same book.

40-chapter book, 600,000 characters	Size	Write time
EPUB	41 KB	0.6 s
AZW3	298 KB	0.8 s
MOBI	541 KB	1.5 s

These AZW3 and MOBI files haven't been opened in Kindle Previewer or on a Kindle yet. If you try one, a report in this thread helps.

What calibre is still for

• reading LIT and LRF;
• writing the old formats (LIT, LRF, PDB, PML, RB, SNB, TCR).

If you rank calibre first in the engine order, it still writes AZW3 and MOBI.

Coming next: the built-in slide renderer (PPTX → PDF / PNG without LibreOffice).

[KnifeLemon]

Update: Unhwp, H2Orestart and Java are gone

Three more pieces are in the builtin-engines branch (#929, #934, #938). They're still not in a release.

HWP / HWPX → TXT, Markdown, HTML with Filee's own code (#929)

These conversions used Unhwp, a native library. Filee now reads the file itself and writes the text with the same writers it uses for every other document. Because it's all managed code, it works the same on Windows ARM64 and Linux arm64, where Unhwp needed its own builds.

What's better than before:

• lists keep their numbers and bullets, as 한글 shows them;
• headings keep their real levels in Markdown;
• equations, note markers and text after a text box are no longer dropped.

Measured on 30 documents built in code, before Unhwp was removed:

	Documents
Same text as Unhwp	22 / 30
All of Unhwp's text, in the same order, plus what Unhwp dropped	27 / 30
The rest	3 / 30

The last 3 differ on purpose: Filee's TXT leaves out headers, footers, page numbers and tracked deletions, and puts notes at the end.

LibreOffice without H2Orestart and Java (#934)

LibreOffice used to read HWP through H2Orestart, which needs a Java runtime. Filee now reads HWP itself, so LibreOffice no longer opens HWP files. The one target that still needs another engine is RTF: Filee writes a DOCX first and Pandoc or LibreOffice turns it into RTF.

• The LibreOffice download is 50 MB smaller (423 → 373 MB), and Java is no longer downloaded.
• The Java and H2Orestart folders an earlier Filee installed are removed when the app starts.
• The setting Use LibreOffice for HWP → PDF is gone. If you had it on, Filee switches on Use the Filee renderer (preview) instead, which also avoids rhwp.

EMF / WMF inside HWPX on every platform (#938)

When Filee writes an HWPX, EMF and WMF pictures are now turned into PNG with Filee's own metafile renderer (#908), on Linux and macOS too.

Coming next: Filee's own HWP writer, so HWP output no longer needs rhwp.

[KnifeLemon]

Update: Filee writes HWP files itself

Filee now saves .hwp (HWP 5.0) with its own code (#948, in the builtin-engines branch, not in a release yet). Until now, any conversion to HWP went through rhwp.

The writer is the reverse of the HWP reader from #909. It turns the same HWPX package 한글 saves into HWP records, using Hancom's published format document. Everything the package holds is carried over, including what Filee's document model doesn't keep:

• the stored line layout, master pages, headers, footers and notes;
• tables, pictures, equations, fields and bookmarks;
• shapes: groups, connectors, text art and OLE objects.

Where the format document leaves a value open, it was matched against HWP files that 한글 saved from the same HWPX, record by record.

A file Filee wrote, opened in 한글 2024 (left) and drawn by Filee's renderer (right). The picture, the text flowing around it and the text boxes sit where 한글 puts them:

Checks

Check	Result
HWPX saved by 한글 → Filee's HWP → read back	46 / 46 read the same as the original
Opened in 한글 2024	15 / 15 open without a dialog, with the original's page count
Saved again as HWPX by 한글, compared with the original saved again	16 / 16 the same
Opened with rhwp	all open, same text

Eight more test documents (tables, tabs, line spacing, several scripts) still need opening in 한글. The PC was too busy for 한글's automation to start. That check comes next.

rhwp stays as a fallback for now.

Coming next: with HWP reading (#909) and writing both built in, what's left before rhwp can go is making the Filee renderer the default for HWP → PDF.

[KnifeLemon]

Update: less Pandoc, less 7-Zip

Two more pieces are in the builtin-engines branch. They're still not in a release.

Seven markup languages without Pandoc (#936, #939, #943, #947)

Filee now reads and writes these itself:

Format	Notes
Jupyter notebooks (.ipynb)	Markdown cells, code cells and their outputs: printed text, tables, pictures, error tracebacks
reStructuredText	Section titles, grid and simple tables with spans, footnotes, the common directives
Org	Drawers, check boxes, #+BEGIN_ blocks
MediaWiki	Templates ({{…}}) are kept as written, not expanded
Textile
OPML
DocBook 4 and 5	No DTD is ever loaded; files that need one are refused

Each converts to and from Markdown, HTML and TXT, and to DOCX, ODT, HWPX, PPTX and PDF. With these in, Pandoc is only needed for LaTeX, AsciiDoc, Typst and man pages.

A notebook built in code (left) and the PDF Filee made from it, with neither Pandoc nor LaTeX installed:

The spacing around code and under the table in that picture has since been fixed in the renderer (#946, #949).

Every reader was fuzzed with random and damaged input, and none failed. The fuzzer also caught a regular expression in Textile that took minutes on a line of 73 dashes; that is fixed.

Unpacking archives without 7-Zip (#950)

Filee now unpacks the common archive formats inside the app instead of starting 7-Zip:

• ZIP, 7z, RAR 4 and 5 (read only), TAR, and gzip, bzip2, xz, LZMA and zstd streams;
• .Z, ar / DEB, cpio, RPM, ISO 9660, and split volumes (.001), with Filee's own readers.

The same safety checks apply to every format: password-protected entries, paths that leave the folder, links, archive bombs and too many entries are refused. If an archive uses something the built-in reader doesn't handle, 7-Zip tries it next. A refused archive is never handed on.

Unpacking 100 MB in 100 files, compared with the bundled 7-Zip (lower is better):

ZIP, TAR, TAR.GZ and TAR.XZ are as fast as 7-Zip or close to it. Solid 7z and bzip2 are much slower. For solid 7z archives with many files, Filee still hands the archive to 7-Zip when it's installed.

7-Zip is still needed to write 7z, XZ and BZ2, and to read CAB, UDF disc images, DMG, LHA and ARJ.

[KnifeLemon]

Update: the Filee renderer now beats rhwp on HWP → PDF

The Filee renderer, Filee's own layout engine (Use the Filee renderer (preview)), now draws more of what 한글 prints. Fourteen fixes are in the builtin-engines branch (#916–#925, #941, #945, #946, #949). They're still not in a release.

What it draws now

• 바탕쪽 (master pages), page borders and page backgrounds;
• page numbers where, how and when 한글 prints them: their style's font, their number format, hidden page numbers, and new numbering mid-section;
• captions on floating pictures, shapes and text boxes;
• OLE objects and charts, drawn from the picture stored inside them;
• form controls, drawn as boxes with their text;
• groups of shapes, with every scale applied;
• click-here fields nobody filled in: their guide text is no longer printed;
• floating objects go on the page of the line that holds them, and text stays on both sides of an object;
• code from Markdown, notebooks and other formats is set in a monospace font, without gaps between lines.

Measured against 한글's own PDFs

Each document was compared with the PDF 한글 prints. The columns are pages that match, line breaks that match, and median SSIM (a picture similarity score, 1.0 = identical):

	Pages	Lines	SSIM
HWPX (85 documents), rhwp	94.1 %	83.8 %	0.683
HWPX, Filee before	97.6 %	78.4 %	0.665
HWPX, Filee now	97.6 %	87.2 %	0.786
HWP (41 documents), rhwp	95.1 %	79.8 %	0.784
HWP, Filee now	100 %	84.6 %	0.898

No document got worse.

SSIM can't get close to 1.0 against these PDFs. When 한글 exports to PDF, it draws all 함초롬바탕 text in the bold face, even where the document doesn't ask for bold. That happens in 44 of the 89 PDFs.

What's next

Filee is now ahead of rhwp on every measure, so the next step is making the Filee renderer the default for HWP and HWPX → PDF. rhwp can be removed after that.

Still missing: 덧말 (ruby text), line numbers, overlapping characters (글자 겹치기), text art, and some equations.

[KnifeLemon]

Update: slides, spreadsheets and Word 97–2003 without LibreOffice

Three more pieces are in the builtin-engines branch (#942, #951, #953). They're still not in a release.

Slides to PDF and pictures (#942)

With Use the Filee renderer (preview) on, PPTX, PPTM, POTX and PPSX now go to PDF, PNG and JPG with Filee's own slide renderer. The renderer draws:

• masters, layouts and themes;
• 107 preset shapes, custom shapes, connectors and arrowheads;
• gradients, pattern and picture fills, cropping and recolouring;
• text: shrink to fit, columns, bullets and numbering, right-to-left;
• tables with PowerPoint's default style;
• SmartArt and charts, from the drawing stored in the file.

A deck with something it doesn't draw yet (shadows and other effects, 3D, WordArt warps, charts without a stored picture) still goes to LibreOffice.

Filee on the left, LibreOffice on the right:

A 10-slide deck takes 4–6 seconds. LibreOffice takes about a minute when it starts with a fresh profile.

Spreadsheets printed the way Excel prints them (#951)

XLSX, XLS and ODS now go to PDF with Filee's own print engine, which follows Excel's page logic:

• paper, orientation, margins, scaling and fit to N × M pages;
• print areas, repeated title rows and columns, manual page breaks and page order;
• column widths and row heights in Excel's units, hidden rows and columns, merged cells;
• number formats (with [Red] and #### when a number doesn't fit), alignment, rotation, wrapping, shrinking, borders and fills;
• conditional formats that only change colour, including 2- and 3-colour scales;
• headers and footers with their codes (&P, &N, &D, &F, &A, pictures).

On 12 test workbooks, page counts and page breaks matched values worked out by hand in Excel's units. Compared with LibreOffice, most break the same way. Where they differ, LibreOffice measures its default column width and its row heights in a different way from Excel.

Spreadsheets → PDF through LibreOffice stays in the settings for anyone who prefers it. Charts, shapes and comments aren't printed yet.

Word 97–2003 documents (#953)

.doc, .dot and WPS .wps are now read by Filee itself, so they convert to DOCX, PDF, HWPX, ODT, PPTX, TXT and Markdown without LibreOffice. The reader handles:

• text with character and paragraph formatting, and styles;
• sections, lists and tables;
• fields, headers and footers, and footnotes;
• pictures and simple text boxes.

Password-protected files are refused with a message. Word 6.0 / 95 and Works files still go to LibreOffice.

Filee's renderer (left) and LibreOffice (right), from the same DOC:

Comments, tracked changes and grouped shapes aren't read yet.

Coming next: PPT, ODP / ODG and Visio readers on top of the slide renderer.