mirror of
https://github.com/storytold/wordcraft.git
synced 2026-10-24 10:27:44 -06:00
de3db3f02cf6d8c235f2dcc9dbfc955fb37a12c9
18
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 NaxvogandClaude Opus 5.5
|
de3db3f02c |
Hyphenation: German patterns in NOTICE; pattern files skip \message
Review follow-ups: the German patterns' MIT notice goes into NOTICE with
the other pattern sets; the pattern reader skips other commands'
arguments, so hyph-de-1996.tex's \message{} line no longer adds junk
patterns and exception words; a load test for the German set; the
status bar names a bare "de" tag; the docs list the languages with
their own hyphenation.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
||
|
NaxvogandClaude Opus 5.5
|
0fa438c7d1 |
Hyphenation: German text follows the German patterns
Runs in German (de, de-DE, de-AT, de-CH) hyphenated with the English patterns, giving breaks such as "unterlieg-ende" and "rechtli-cher". They now use hyph-utf8's German patterns for the reformed spelling (MIT, bundled unmodified as assets/hyphenation/de.pat). German gets a ProofLang of its own that, like Bulgarian, hyphenates only: no spelling or grammar marks yet (#1564). Portuguese, Italian and German share one pattern lookup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
|
0128e117b3 |
Layout: table rows share their cell margins and split across pages like Word (#1177)
- Every cell in a row gets the row's largest top and bottom cell margin, so a cell without its own margins lines up with its neighbours. - An exact row height covers the top border, top margin and text; the bottom margin comes on top. Dragging a row border, or drawing a line through an exact row, accounts for it. - A row split across pages must keep its cells' bottom margin, border and last paragraph's space after on the first page, and widow/orphan control applies to the paragraphs in its cells. A row whose text fits but whose margin doesn't no longer moves to the next page whole. - Each cell of a split row goes on at the top of the continuation (one cell's widow line no longer pushes its neighbours down), and the continuation is as tall as the cell needing the most room, and at least the rest of the row (a minimum row height holds over the pages). - A nested table's cell the page bottom cuts through goes on from the cut with what is left of it, and the text after it stays below it. - A row of an exact height never splits: it moves to the next page whole. Co-authored-by: Naxvog <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
37193a14ba |
Layout: a paragraph ending with a page break leaves its space after on the old page (#1168)
A paragraph whose last line holds the page break keeps its mark on the old page, but its space after was still added after the break, so the next page started that much too low (and the next paragraph lost its "no space before after a page-break mark" treatment). Word adds none of it there, in compatibility modes 12, 14 and 15 alike. Co-authored-by: Naxvog <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
d6723153cc |
Drawings: VML text boxes keep their margins, fit and alignment; hidden drawings are kept but not shown (#1118)
* Text boxes: VML text boxes keep their internal margins, fit to their text and alignment
A VML text box's inset ("l,t,r,b", ECMA-376 Part 4 §19.1.2.22) was ignored,
so its text sat Word's default 7.2 pt in and 3.6 pt down even where the file
says 0,0,0,0, which is how letterheads and form headers place address blocks
exactly. It's now read like DrawingML's lIns/tIns/rIns/bIns: each value left
out keeps the default, a bare number is in EMUs, o:insetmode="auto" leaves
the defaults. mso-fit-shape-to-text (VML's "Resize shape to fit text") is read
as auto-fit, like a:spAutoFit, and the shape's v-text-anchor as the text's
vertical alignment. In a group, a member's margins go with that member's
text.
The reader feeds layout, so the editor, PDF and page images all change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: hidden shapes and pictures are kept but not shown
A drawing marked hidden (VML visibility:hidden, floating or inline;
DrawingML wp:docPr/@hidden, or a group member's cNvPr/@hidden) was drawn,
took room and wrapped text. Word for Windows shows it in no view; it's now
kept and saved hidden, but left out of layout: not placed, no wrap area, no
room in its line, nothing drawn, its text box's notes not placed. Exports to
other formats and copies leave it out, the accessibility checker no longer
asks for its alt text, and the selection pane says it's hidden.
Word for Mac draws hidden VML shapes; Windows follows the markup.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Naxvog <4963183+naxvog@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
|
||
|
|
927a305943 |
Layout: a picture after a content control's start stays on its line (regression from #392) (#1102)
Since content controls are kept (#392), a picture content control puts a zero-width start marker before its picture. Line breaking keeps a line's first item even when it doesn't fit, but counted the marker as that item, so a picture a little wider than its line wrapped onto a second line, leaving a marker-only line above it; in a fixed-height text box the picture's line was then cut off. A logo in a header text box (which 0.5.0 drew) disappeared. Markers before an item no longer count, as a display equation's check already does. Co-authored-by: Naxvog <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
|
e75ff36251 |
Layout: an inline picture wider than the text keeps its size, like Word (#745)
* Layout: an inline picture wider than the text keeps its size, like Word WordCraft shrank an inline picture, chart or shape that is wider than its line to the line's width, height with it. Word draws it at its own size: it runs past the margin and the page edge clips it, and the line is as tall as the picture. In docxide-pdf's fixtures that moved the rest of the page up (case179: a 1014 x 100 pt picture became 468 x 46 pt) and shrank a header's 1014 pt logo strip to fit (alfies_arc). All page outputs already clip at the page: the PDF page box, and the page bitmaps the rasteriser and the editor draw. Text boxes don't clip what runs past their sides yet, so a picture wider than a text box is still fitted to the box rather than spilling over the page (ParaEnv::fit_objects, part of the paragraph cache key). On the 390 fixtures: case179 SSIM 70.9 -> 99.9%, alfies_arc 18.4 -> 74.8%, case178 98.0 -> 99.9%, nabl_lab 33.2 -> 36.8%; no fixture got worse. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Review fixes for #745: fit imported and pasted pictures to the text width Layout no longer shrinks oversized inline pictures, so pictures that come at their pixel size are fitted when they enter the document, as Insert › Pictures already does: - opening HTML (also from a path), Markdown, ODT, RTF and other formats-crate imports (io::fit_pictures, against the narrowest section text width); - pasting HTML/RTF (paste::adopt, against our text width). Only inline pictures wider than the text are scaled, proportionally. DOCX keeps its sizes. Test: tests::imported_pictures_fit_the_text_width. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Naxvog <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
37318985b5 |
Layout: multiple line spacing adds its leading below the text, like Word (#719)
Benchmarked against docxide-pdf's 390 Word-referenced fixtures, the largest systematic gap was the vertical position of text: WordCraft put the baseline one descent above the bottom of the line box, so all the extra leading of 1.15 or double spacing went above the text (1.8pt at 1.15-spaced 12pt). Word keeps the text one ascent below the line top and puts the extra leading below it; below single spacing it shrinks the whole box. The hhea line gap now counts toward the ascent instead of being split half above, half below. Line heights stay the same, but every descent is half a line gap smaller, so text in exact, at-least and grid-snapped lines (which keep the descent below the baseline or centre the glyph box) sits up to half a line gap lower: 0.25pt for 12pt Times New Roman. On the suite that brings those lines closer to Word as well (exact: 5 fixtures better, 1 worse; at-least: 5 better, none worse). On the suite: mean Jaccard 29.2 -> 33.5%, SSIM 49.4 -> 50.3%, median baseline offset from Word +0.68 -> -0.06pt, documents within 1pt 35 -> 51%. Co-authored-by: Naxvog <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
05679497ea |
Pictures: WMF drawings fill their frame like Word plays them (#739)
Word plays a WMF into the picture's box the way a GDI player does: the placeable header's bounds are only the first window, mapped onto a viewport of the picture's size, and the file's own SETWINDOWORG and SETWINDOWEXT records replace that window. WordCraft mapped the header's bounds through the file's final mapping instead, which broke three pictures in docxide-pdf's fixtures: - bulgarian_farmland_allocation_order: the coat of arms draws in a window centred on the origin, nowhere near the header's bounds, so the lion was blown up into a solid black box. - ukrainian_municipal_heating_resolution: a portrait window replaced the landscape bounds, so the emblem was drawn at a fifth of its size. - A plain WMF in anisotropic mode that sets a window but no viewport kept the 1 x 1 default viewport and shrank to a point; its first window is now its target. Files that set their own viewport, or use the fixed-scale map modes, are read as before. SETROP2 is now read too: with R2_NOP, shapes and paths draw nothing (the coat of arms first draws its bounding rectangle that way, which showed as an outline). The mode is saved and restored with the DC. Co-authored-by: Naxvog <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
c0bbcbac24 |
Charts and SmartArt: draw them instead of dropping them (#292)
A chart or SmartArt diagram in a DOCX was dropped on import: it took no room, so the text after it moved up (five of the six chart documents in docxide-pdf's fixtures came out a page short), and nothing was drawn. They are now an InlineObject::Graphic: it takes its room, floats and wraps like a picture, and draws a list of neutral items (shapes, paths, one-line texts, pictures) that layout scales to the object's box. - Charts (read/chart.rs) are drawn from the values the chart part caches: clustered, stacked and 100% bar and column charts, line, area, pie, doughnut and scatter charts, with title, legend, gridlines, axis labels and Excel number and date formats. - SmartArt (read/diagram.rs) is drawn from the drawing Word stores beside the diagram: preset shapes, theme colours, text and pictures. - Theme colour handling is shared (read/drawing_color.rs). - Each chart or diagram part is read once, only through a relationship of its type, under a per-file budget of items. - Tagged PDF tags them as figures with their alternative text, and the accessibility check reports charts without one. Not yet: charts and diagrams aren't written back when saving a DOCX (they weren't before either), so the editor doesn't let you move or resize them. Radar, stock, 3-D and combination charts draw their first supported chart type only; SmartArt pictures aren't clipped to their shape. docxide-pdf bench (365 documents, vs main + #135): page counts right 320 -> 326 (all five chart documents and one SmartArt document), Jaccard passes 208 -> 215, SSIM passes 76 -> 79; eight documents better, none worse. Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
e9a38a88ca |
Pictures: draw WMF and EMF pictures instead of a grey box (#293)
Windows metafiles (WMF, EMF), common for logos, crests and diagrams in older documents, couldn't be decoded and showed as grey boxes, on screen and in PDF. The new crate wordcraft-metafile (layer 1) reads them from the public [MS-WMF] and [MS-EMF] specifications into paths and bitmaps, and places them in a picture's box; render and pdf paint the result as vectors. It covers the drawing records Office pictures use (lines, polygons, curves, rectangles, ellipses, arcs, path brackets), pens and brushes, the mapping modes and world transforms, and bitmaps in DIB form with the usual raster operations. Input is treated as hostile: every read is bounded, and a byte budget caps what one picture may allocate. Not yet: text records (ExtTextOut) and EMF+ records are skipped, so a metafile whose content is mostly text shows only its lines and fills. docxide-pdf bench (365 documents, vs main + #135): the twelve documents with WMF/EMF pictures show them; the pictures are a small part of their pages, so the scores move little (Jaccard passes 208 -> 209, five documents up to 3 SSIM points better, none worse). Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
|
23395e7fc0 |
Tables: autofit by content, and floating tables inside cells (#291)
Word sizes the columns of a table that may follow its content (tblLayout
not fixed) from what is in them; we kept the stored grid as it was:
- A table with no preferred width anywhere (no tblW, no tcW: what
generators write) now gets its columns from their content: each its
widest line if all fit, else shared out between longest word and
widest line, as Word does (case51: a nested table no longer fills its
cell, and the document is two pages like Word's).
- In other autofit tables no column is narrower than its longest word;
the columns with room give up the difference ("ON" no longer breaks
into "O/N" in case91).
Floating tables (w:tblpPr) inside a table cell were laid out in the
text flow. They now stand at their position in the cell and take no
room; the text after them wraps around them, a table that may not
overlap goes below the ones in its way, and the cell grows to hold
them. A row whose lines all fit but whose nested floating table runs
past the page bottom splits there instead of moving to the next page.
Text now flows beside a floating object into gaps of 20pt or more
(was 36pt): Word puts a paragraph beside a floating table in a 21.3pt
gap but not in an 18.6pt one (docxide-pdf case139-148 vary just that).
docxide-pdf bench (365 documents, vs main + #135): Jaccard passes
208 -> 227, SSIM passes 76 -> 86, page counts right 320 -> 324; three
documents slightly worse (case149 -4 SSIM: Word moves the whole floating
table to the next page, we split it; two others -1 or less).
Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
|
||
|
|
7c951a5490 |
Layout: picture line heights, body top below the header, table row heights (#138)
* Layout: picture line heights, body top below the header, effect extents Headers with a logo or rule picture put the body in the wrong place in Word documents, for three reasons: - A line holding only a picture was exactly as tall as the picture. Word keeps the run's font ascent and descent: the picture stands on the baseline and the line is the taller of the font's line and the picture plus the font's descent. Multiple line spacing scales the font's line height only, never the picture (a 144pt picture at 1.15 made a 165.6pt line; Word's is 146.4pt). - The body started 6pt below a header that reaches past the top margin. Word starts it right where the header ends. - wp:effectExtent (room Word keeps around a picture for its shadow or glow) was dropped. It is now kept on Float::effect, read and written, and inline pictures reserve it in their line and are drawn inside it. The reader also takes w:lineRule (and w:hRule) case-insensitively, as Word does: `atleast` was read as multiple spacing. Measured against the Word reference PDFs of docxide-pdf's corpus (365 documents, same open fonts for every run): mean SSIM 39.3% -> 42.1%, documents passing SSIM 37 -> 51, mean ink overlap 19.5% -> 22.3%, page count right 301 -> 304; 52 documents better, 6 worse (one header built from nested tables had its own height error hidden by the old 6pt gap). Tests: picture lines are the picture plus the font's descent under 1.15 spacing; the body starts where a tall header ends; effect extents grow the picture's line box and the picture is drawn inside them; effect extents round-trip through .docx; `atleast` and `EXACT` line rules read. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Layout: table rows keep their cell margins and border bands like Word Word sizes a table row from the inside of its borders out: the cell's text starts below the top border and the top margin, and an at-least row height gets the cells' top and bottom margins and border widths on top (a 30pt row with 5pt margins and 0.5pt borders steps 40.5pt). We drew the text at the top margin and took an at-least height as the whole row, so rows came out short and tables, and headers built from tables, ended early: a form's header table ended 6pt above where Word starts the body. Each row now reserves its cells' top border width above their text (the last row also the bottom border below it), and an at-least height adds the tallest margins plus border bands in the row. Exact heights are unchanged. Measured against the Word reference PDFs of docxide-pdf's corpus (365 documents, same open fonts), on top of the previous commit: mean SSIM 42.1% -> 42.8%, documents passing SSIM 51 -> 54, mean ink overlap 22.3% -> 23.3%, mean line-break agreement 63.0% -> 63.5%; 42 documents better, 28 worse, mostly by a few points where an earlier offset had cancelled the short rows. Test: two 30pt at-least rows with 5pt margins and 0.5pt borders step 40.5pt (was 36.3), with the first cell's text 5.5pt below the table top. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Layout: note the known limit of the picture-line rule The space Word leaves below a line of only pictures is less than the font's full descent we give it; two rules tried against docxide-pdf's Word references (no descent, only the text's descent) each fixed some documents and broke others. A shortcut: comment records the measured cases so the rule isn't changed again without Word probes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
6e73fe40e3 |
Tables: Word 2013 table edge, and floating tables (w:tblpPr) (#137)
* Layout: place floating pictures and shapes the way Word does Pictures and shapes anchored in a .docx often landed in the wrong place: the reader folded every margin-relative position into "margin", ignored <wp:align>, and kept only distL as the distance from text. Floats in headers, footers and table cells were not drawn at all. Document model (doc): - Anchor gains the left/right/top/bottom/inside/outside margin areas, the anchor character and the anchor line - Float gains h_align/v_align (FloatAlign: start, center, end, inside, outside), which take precedence over the offsets, and separate dist_top/dist_bottom (dist stays the left/right distance) DOCX (docx): read and write wp:align, every relativeFrom value and distT/distB/distL/distR. Layout (layout): - float_rect positions against each reference area, with alignment - floats in headers, footers, table cells and text boxes are placed, drawn (behind-text ones under the text) and wrapped around; headers and footers get a page frame so page-relative floats land in page coordinates, also when the header's height is measured for the body top - a paragraph's first line pushed below a top-and-bottom float is drawn (and hit-tested) where it was laid out - floats follow their paragraph to a new column or page, and are placed at the paragraph's actual top (space before counted once, contextual spacing respected) - wrap areas use each distance as given; the old 9pt minimum is gone, so a float with distance 0 now touches its text as in Word - a list item's label is counted once (Ctx::next_label) and passed into every layout of its paragraph (Ctx::para_labelled), so laying it out again around floats doesn't advance the list counters twice; a paragraph whose top moved is only laid out again when the page has something to wrap around Engine: switching an inline object to a wrapping style gives it Word's default 9pt side distance; the position presets clear any alignment. Approximations: inside/outside margins and alignments ignore mirrored margins (treated as left/right); character- and line-relative positions fall back to the column and the paragraph top. Tests: docx fixture and round trip for alignment, reference areas and distances; layout tests for alignment, the pushed-down first line, floats moving to page two (with space before), header and cell floats, header floats not changing the body top, hostile distances, and list items counted once when laid out again (contextual spacing, page break before, beside a float in a table cell). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tables: place a table's edge by the document's Word compatibility mode Word 2013 and later (compatibilityMode 15) put a left-aligned table's border at the margin plus its indent, moved in by half the first cell's left border; earlier modes line the first cell's text up with the margin instead, the border one cell margin further out. We always did the latter, so in Word 2013+ documents (43% of docxide-pdf's Word reference corpus) every table and its text sat a cell margin (usually 5.4pt) too far left. Settings::compat_mode keeps the document's mode: read from w:compat/w:compatSetting, 12 when a document has no settings or doesn't state one (as Word treats it), 15 for new documents, and written back instead of a fixed 15. The legacy shift now uses the first cell's own left margin. Measured against docxide-pdf's corpus (365 documents, same open fonts): mean SSIM 40.4% -> 42.1%, documents passing SSIM 40 -> 50, passing ink overlap 142 -> 154; 71 documents better, 6 worse (tables nested in a cell whose text Word puts at the outer cell's edge, which docxide-pdf doesn't match either). Tests: a mode-15 table's text sits a cell margin and half a border inside the margin, a mode-12 table's at it; the mode round-trips through .docx and defaults to 12 without settings. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Layout: floating tables (w:tblpPr) stand at their position, text wraps Floating tables were read as ordinary tables: laid out in the text flow with no regard to their position, and the text after them waited below instead of running beside them. 71 of the 382 documents in docxide-pdf's Word reference corpus have them, typically forms anchored to the text and the margin. TableProps::float (TableFloat) keeps w:tblpPr and w:tblOverlap: what x and y are measured from (column, margin or page; text, margin or page), offsets or alignments, distances from text and whether it may overlap other floating tables. The .docx reader and writer carry it. A floating table at the top level of the body is placed at its position (tblpY below the text where it stands, by default) and takes no room in the flow; its area plus its distances from text joins the page's wrap areas, so the following text runs beside it or below it. One that may not overlap moves below the floating tables in its way, keeping (in Word 2013+ layout) its distance from the text's left edge; in earlier modes an offset places the first cell's text, as an indent does. A table in the flow starts below the floating objects in its way. Floating tables inside table cells and headers are still laid out in their flow. Measured against docxide-pdf's corpus (365 documents, same open fonts), on top of the compatibility-mode commit: mean SSIM 42.1% -> 43.9%, mean line-break agreement 63.5% -> 66.6%, documents passing SSIM 50 -> 55, page count right 303 -> 305; 33 documents better, 4 worse by at most 3.1 points. Tests: a full-width and a narrow floating table that may not overlap stack, the narrow one keeping 9pt from the text edge, and the next paragraph runs beside it; floating table positions round-trip through .docx. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Layout: a floating table taller than a page runs across pages A floating table was always placed whole at its position, so one taller than the page's body ran past the bottom margin and its rows were lost: a Bulgarian programme whose whole body is one floating table came out as 3 pages instead of Word's 6. Such a table now flows across pages like a table in the text (rows splitting and header rows repeating as usual), from the floating table's own left edge; the position is worked out by float_table_x, which the whole-table placement shares. In docxide-pdf's Word reference corpus that document has Word's page count again with all its rows; nothing else changes. Test: an 80-row floating table runs onto a second page, every row drawn above the bottom margin from the table's left edge (was one page). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tidy floating-table code: one alignment helper, named steps, shared mappings No change in behaviour; makes the floating-table code easier to read. - FloatAlign::from_ooxml/ooxml (added with floating pictures) replace the copies of the same mapping in the w:tblpPr reader and writer, and TableFloat::dist_from_text the copies of its clamping. - place_floating_table and float_table_x place by offset or alignment with align_in, like floating pictures do, instead of their own copies. - The overlap rule uses Rect::inset/intersects and names its condition (keeps_text_distance) instead of a one-line chain of comparisons. - below_floats names the step that starts a table in the flow below the floating objects in its way. - The floating-table functions move next to place_table, which calls them, from after `mod tests;` at the end of the file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
c7efead47b |
Layout: place floating pictures and shapes the way Word does (#136)
Pictures and shapes anchored in a .docx often landed in the wrong place: the reader folded every margin-relative position into "margin", ignored <wp:align>, and kept only distL as the distance from text. Floats in headers, footers and table cells were not drawn at all. Document model (doc): - Anchor gains the left/right/top/bottom/inside/outside margin areas, the anchor character and the anchor line - Float gains h_align/v_align (FloatAlign: start, center, end, inside, outside), which take precedence over the offsets, and separate dist_top/dist_bottom (dist stays the left/right distance) DOCX (docx): read and write wp:align, every relativeFrom value and distT/distB/distL/distR. Layout (layout): - float_rect positions against each reference area, with alignment - floats in headers, footers, table cells and text boxes are placed, drawn (behind-text ones under the text) and wrapped around; headers and footers get a page frame so page-relative floats land in page coordinates, also when the header's height is measured for the body top - a paragraph's first line pushed below a top-and-bottom float is drawn (and hit-tested) where it was laid out - floats follow their paragraph to a new column or page, and are placed at the paragraph's actual top (space before counted once, contextual spacing respected) - wrap areas use each distance as given; the old 9pt minimum is gone, so a float with distance 0 now touches its text as in Word - a list item's label is counted once (Ctx::next_label) and passed into every layout of its paragraph (Ctx::para_labelled), so laying it out again around floats doesn't advance the list counters twice; a paragraph whose top moved is only laid out again when the page has something to wrap around Engine: switching an inline object to a wrapping style gives it Word's default 9pt side distance; the position presets clear any alignment. Approximations: inside/outside margins and alignments ignore mirrored margins (treated as left/right); character- and line-relative positions fall back to the column and the paragraph top. Tests: docx fixture and round trip for alignment, reference areas and distances; layout tests for alignment, the pushed-down first line, floats moving to page two (with space before), header and cell floats, header floats not changing the body top, hostile distances, and list items counted once when laid out again (contextual spacing, page break before, beside a float in a table cell). Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
bb88278b98 |
PDF: put the shown text of fields and note numbers in the text layer (#133)
* PDF: fields and note numbers put their shown text in the text layer A field, a note reference or an equation is shaped as one cluster that stands for the object's placeholder character (U+FFFC) in the paragraph text. The display list took a glyph run's text from the paragraph, so a footer's "Page 1 of 5" went into the PDF's text layer as "Page  of ": copying, search and screen readers got the placeholder. 76 of the 365 PDFs written from docxide-pdf's Word reference corpus had it; Word's have none. ParaLayout::shown keeps, by cluster index, the text such a cluster draws (filled by Builder::shape_atomic), and the display list takes that text for those clusters. The drawing doesn't change. Now none of the 365 PDFs carries the placeholder; mean line-break agreement with Word 62.9% -> 63.4% (the scorer reads the text layer). Test: a footer's PAGE and NUMPAGES fields read "Page 1 of 2" and "Page 2 of 2" in the exported PDF's text (was "Page  of "). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tests: a REF field's result is extractable PDF text (from #112 by @LloydNicholson) Co-Authored-By: LloydNicholson <LloydNicholson@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
3fcc1e2694 |
Lists: honour a list's own level definitions (w:lvlOverride/w:lvl) (#134)
A w:num can redefine any of its abstract list's levels with a whole
w:lvl inside w:lvlOverride. We kept only the start value from it and
numbered with the abstract list's levels, so documents that rely on it
showed the wrong labels: a construction specification (SpecLink) read
"A. PART 1 GENERAL" and "I. SECTION INCLUDES" where Word shows "PART 1
GENERAL" and "1.01 SECTION INCLUDES". Saving such a document also
dropped the definitions, so Word showed the wrong labels afterwards.
Num::level_overrides keeps them; Numbering::level and the list counters
prefer them over the abstract list's levels; the .docx reader reads them
with the abstract levels' parser and the writer writes them back (one
w:lvlOverride per level with its startOverride and/or lvl).
In docxide-pdf's Word reference corpus 6 of 382 documents carry such
definitions; the specification's SSIM goes 13% -> 41%, the others
restate their abstract lists and are unchanged.
Tests: counters use a list's own levels ("" and "%2.%3" in decimalZero
give "1.01", "1.02", "2.01") and fall back to the abstract list for the
rest; level overrides round-trip through .docx beside start overrides.
Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
|
||
|
|
fbb688657d |
PDF: draw fonts krilla can't subset as outlines instead of failing (#132)
krilla subsets fonts only when the document is finished, so one font its
subsetter rejects ("failed to subset font: malformed font") failed the
whole PDF export. Two of the 365 documents in docxide-pdf's Word
reference corpus hit this on Linux: Caladea Italic and Bold Italic
(ttf-caladea, our metric-compatible stand-in for Cambria) and Noto Sans
New Tai Lue Bold.
When finishing fails on a font, the exporter finds the face krilla
names, logs a warning and writes the document again with that face's
glyphs drawn as filled outlines (FontDb::outline), including in the
watermark; every other font is still embedded as selectable text. At
most 32 faces fall back before the export gives up with the error.
kurbo moves from dev-dependencies to dependencies of wordcraft-pdf (it
was already in the workspace).
Test: a copy of the bundled Source Sans 3 with one glyph turned into a
truncated composite fails the old export exactly as the corpus documents
did; it now exports, with no text glyphs from that font and its glyphs
drawn as paths.
Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
|