Cause: since #3742 place_each measures a line's spacing from the file's
own widths, so tracking is only the file's Tc/Tw/TJ. Where the widths
are systematically off the installed font's advances (up to the 1% that
still counts as the same font), those differences add up along a line
and nothing made up for them. With no kerning and every tracking value
0, place_each returned the untracked layout early, without the 0.02 em
placement check (CodeRabbit's review of #3742): a line of embedded
Source Sans 3 with /Widths 0.8% wide opened 3.7 pt off. With the early
return removed the check rejects the line and the line-wide fit takes
over: one whole-thousandth tracking value with the font's kerning,
0.30 pt off (as before #3715). Before #3742 main placed it exactly but
with a run per character (49 and 62 runs).
Change: the early return is gone; every line goes through the check.
Before it, on_course() keeps the file's spacing where the glyphs stay
within 0.01 em of the file's; otherwise each stretch of the line takes
one share after every character (the longest stretch one share keeps
within 0.01 em), so ordinary text stays one run, and a line whose
differences change course (30 m then 30 i) takes a run per stretch (2).
Verification: new test
a_long_line_of_widths_a_little_off_the_fonts_advances_lands_in_one_run
(embedded Source Sans 3, widths x1.008 and x0.992, a kerned and an
unkerned line): one run each, glyphs under 0.24 pt (0.02 em) from where
the file draws them. Without on_course it fails after #3742, with and
without the early return ("glyphs 0.300 pt"); before #3742 it fails on
the run count. It replaces an Inter test drafted for the review: Inter
isn't embedded there, so the file's outlines are the interpreter's
stand-in stretched to the widths, not Inter, and the contours differ by
0.6 pt even with exact widths. tests_text_placement and
text_becomes_point_type pass; cargo xtask ci: all 10 steps passed.
Thanks to the CodeRabbit review on #3742 for the early-return finding.
Cause: place_each (crates/pdf/src/import_text.rs, #3715) works out each
character's tracking as the file's distance between glyph origins minus
the installed font's advance. A PDF gives widths to the thousandth of an
em (the standard-14 AFM metrics or /Widths), so with a font of 2048 units
an em (Helvetica on macOS) every character is a hair (~0.0002 em) off.
When the line isn't evenly spaced as a whole (a TJ word gap, a space read
from a gap), `even` keeps every character's own value, rounding noise
included, and restyled() splits the line into a run per character.
text_becomes_point_type failed on macOS; Linux CI passed because Helvetica
isn't installed there, its stand-in's widths differ by more than 1% and
place_each falls back to the line-wide fit.
Change: measure the spacing from the file's own widths: each character's
pen is moved by how much wider the file says the characters before it are
than the font's advances, where the file gives the character's width and
the layout sets it as a glyph of its own. The tracking is then the file's
(Tc, Tw, TJ), whatever font is installed; the layout check that the glyphs
land within 0.02 em of the file's places is unchanged.
Verification: text_becomes_point_type and all of tests_text_placement pass
on macOS. New test widths_rounded_off_the_installed_fonts_advances_keep_one_tracking
uses built-in Inter (non-embedded, widths rounded to thousandths), so it
doesn't depend on system fonts; without the fix it fails on any platform
with runs N/e/x/t/ /li/n/e/ /h/e/re. cargo xtask ci: all 10 steps passed.
PDF import measured each gap between two glyphs against the larger of
the line's first glyph size and the next glyph's. A word set beside a
much larger one, apart by positioning and no space glyph (a browser's
margin between two sizes), stayed under a fifth of that em: "≤ 4" at
20 pt and "hours" at 8 pt, 3.4 pt apart, came in as "≤ 4hours".
A gap is now measured against the smaller of the two glyphs beside it.
Lines in one size read their gaps as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Glyphs placed one by one with even gaps could be letters set apart or
words of one letter each, and a file's positions can't tell them apart.
The spacing a line's letters share is now taken off its gaps only when
the line also shows where its words break: with spaces it draws (as
with Tc), or with gaps wider than the rest (tracked words placed glyph
by glyph). Otherwise every gap past a fifth of an em is a space, as
before, so A, B, C and D placed with ordinary word spaces between them
still come in as "A B C D".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A line whose shared gap is over half an em is no longer read as letter
spaced: capping that gap at half an em left glyphs set 0.55 em apart
with no spaces. The regression now covers 0.55, 0.75 and 1 em.
Whether a line is right to left is now known before its gaps are read,
from its logical order: the paragraph direction is only set afterwards,
so right-to-left lines were read for letter spacing too.
The revision-history row moves out of the Headline table, where it had
been put by mistake.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts:
# docs/target-app-parity.md
PDF import read every gap wider than a fifth of an em between two
glyphs as a space. Letter-spaced type (Tc, or glyphs placed one by one
with tracking) has such a gap between every pair of letters, so
"OPEN DAILY" came in as "O P E N D A I L Y".
A line now records every gap between its glyphs and decides which are
spaces when it finishes: the spacing its letters share (the gap a third
of the way up from the narrowest, when the line has three or more) is
taken off each gap first. That shared spacing is at most half an em, so
glyphs set wider apart, such as figures in columns, keep their spaces.
Right-to-left lines and glyphs along a curve read their gaps as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PDF import gives a space read from a gap between two glyphs tracking of
its own when the line's tracking cannot place the glyphs after it. A
space glyph that the file draws was not measured this way: the gap
before or after it was spread over the whole line as one tracking
value, so the words after it moved. VectorCraft's own PDF export draws
a tracked space and leaves its tracking after it.
A space the file draws between two glyphs on a line is now measured
from the end of the glyph before it to the start of the glyph after it,
and takes tracking of its own on the same terms as a space read from a
gap. Two or more spaces in a row, and a space at the start or end of a
line, keep the line's tracking. The tracking calculation builds a map
of the line's laid-out advances by byte offset once.
A wrapped line whose spaces each have tracking of their own, within a
fiftieth of an em of the first space's tracking, can still come back as
part of justified area type. Wrapped lines whose spaces' trackings
differ by more than that stay point type with their words in place.
Text drawn in rendering mode 3 (3 Tr), which is how a scanned page carries
its recognized OCR text, was left out on open (since #2988, with a warning),
so a scanned PDF opened and saved again lost its searchable text.
Import: an invisible glyph now comes in as type with neither fill nor
stroke. It skips the glyph-outline checks that guard how visible type looks,
and it joins only other invisible text on a line (Look::takes no longer
lets it into a stroke-only run). INVISIBLE_TEXT_NOTE now only reports text
that can't be type (text opened as outlines, Type 3 fonts), and
tests_reader_compat::invisible_text_is_reported_when_left_out expects the
invisible line as unpainted type when text opens as type.
Export and print: characters with no fill and no stroke are written as real
text inside a form marked Mark::Invisible; forms::finish sets that form's
text rendering mode to 3, so it draws nothing but stays selectable and
searchable (PDF/X-1a and PDF/A-2b too). The writer has no invisible mode of
its own, so this reuses the marked-form mechanism used for layers and
overprint.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PDF import reads a gap wider than a fifth of an em between two glyphs
as a space, and a space that the line's tracking cannot place gets
tracking of its own. That tracking was clamped to 1000 thousandths of
an em, while type takes tracking from -1000 to 10000. A gap wider than
an em plus the width of a space came in short by the excess, so the
words after it sat to the left of where the file put them, and each
further wide gap added to the shift.
The tracking that import sets for such a space, and for the line around
it, now has the same range as type's.
Type on a path is written glyph by glyph, and a stroke added to it as each
glyph's outline stroked right after the glyph. The path in between ended the
line, so each glyph came in as its own text object. Such a stroke, in the
glyph's own paint, is now held with the line and written after it, where it
becomes the type's stroke as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts:
# crates/pdf/src/tests_import_lines.rs
Straight type takes the tracking that keeps its length as the file set
it; type on a path took none, so letter-spaced type on a curve came back
closed up to the font's advances (an "OFFICIAL ISSUED" badge sat to one
side of its band, a condensed title ran off the end of its path). Type on
a path now takes the same tracking, its length measured along the path
from the first glyph to the end of the last.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Character tightening and optical kerning space each glyph differently, as
Japanese titles often are. The importer evened a line out with one
tracking value (type on a path took none), leaving glyphs up to an eighth
of an em out of place. When the file's font is installed and one value
can't place every glyph, each character now keeps its own tracking,
measured along the baseline (along the path for type on a path).
Glyphs closed up by up to half an em (the proportional widths of CJK
punctuation) also continue their line instead of starting another.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A font library can hold two versions of one family and style (a new
Montserrat-Bold.ttf beside an old montserrat.ttf). The font database kept
only the first one loaded, so type set in the other couldn't be matched
when a PDF or .ai was opened: it came in as outlines. Now every version
loads (the first stays the one family and style resolve to), PDF import
tries the other versions when the glyphs differ, and type set in a version
the family and style alone wouldn't pick names it in CharStyle::font_version
(left out when None, so documents without it are unchanged). Layout,
shaping, the substituted-glyph highlight, Find Font, Package and Document
Info follow it; changing the font clears it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A text matrix that shears the glyphs (type turned and slanted as a whole)
came in as point type turned by the baseline's angle only: the glyphs stood
square on the baseline, so the type drew somewhere else (60 pt type leaning
by 0.25 came back about 10 pt off its outlines). The placement now keeps the
slant (the em's lean along the baseline per unit of its height, the height
measured across the baseline), lines only join glyphs with the same slant,
and the type object's transform shears by it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Document symbols placed inline in a run of type (beyond Illustrator; like
InDesign inline anchored objects): TextRun.inline holds the symbol, scale and
shift; the run is one U+FFFC laid out as a glyph sized to the art, centred on
the cap height. text.insertInline and Type > Insert Inline Symbol; editing
keeps the graphic whole; canvas, SVG (<use>) and PDF draw the art; Create
Outlines turns it into a symbol instance.
- Type left unfinished when a layer's marked content ends, and a clip that closes in a later layer,
stay in their own layer (no stray "Page N" layer, no art moved to the next layer).
- Top-level layers stack as the pages mark them, so a layer whose art starts on a later page keeps its
place; layers marked with no art come in empty.
- A stroke written as each glyph's outline stroked, right after (or before) the type, becomes the type
object's stroke above (or below) its characters: the type stays one editable object.
- Spaces read from gaps wider than a space get their own tracking where even tracking would put the
glyphs after them more than a tenth of an em off (barcode digit groups); lines are measured to their
last visible glyph, so a wrapped line's trailing space no longer spreads into the tracking.
- Lines wrapped in a frame (each wrapped line ending in a space, one left edge, font, size and leading,
with an optional paragraph spacing) come back as one area type object, left aligned or justified,
only where laying it out breaks the lines exactly where the file does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Type on a path could only be repositioned by Type on a Path Options, whose menu item sent
`{start: 0}`, so OK threw the text to the start of its path; nothing showed or dragged its
brackets. Now, as in Illustrator:
- Type on a path flows between a start and an end bracket (`TextKind::OnPath { end }`, None:
the end of the path or once round a closed one; `TextKind::path_span`). Flipping
(`TextObject::flip_on_path`) reverses the path keeping a closed path's first anchor and swaps
the brackets, so the type keeps its stretch of the path.
- Type on a Path Options gains Align to Path (ascender, descender, center, baseline) and
Spacing (glyphs spaced as if set that far above the path: closed up round the outside of
curves, opened up round the inside), laid out by the text engine.
- `type.pathOptions {start?, end?, flip?, effect?, alignToPath?, spacing?, ids?}` sets them in
one undo step; with none of them it queries. The menu item opens the dialog with the selected
type's Effect, Flip, Align to Path and Spacing (dropdowns for the choices) and leaves the
brackets alone, so OK as opened changes nothing.
- The Selection and Direct Selection tools show selected type on a path's path and its start,
centre and end brackets (`tools::pathtype`, with a bracket cursor): dragging the start or end
bracket sets where the type runs, dragging the centre bracket slides it along the path and,
across the path, flips it (Cmd/Ctrl held: it only slides). Each drag is one undo step.
- Arc-length measuring moved to `vectorcraft_geom::ArcPath` (layout, the tools and
`text.createInPath` share it). SVG export outlines path type whose end bracket, alignment or
spacing `<textPath>` can't express.
- docs/mcp.md documents the command and the drags; ROADMAP updated; dialog strings translated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Illustrator sets a paragraph's direction (Left-to-Right / Right-to-Left
Paragraph Direction in the Paragraph panel, with the Middle Eastern
options) and keeps its alignment buttons physical; it has no automatic
alignment toggle. So:
- ParaStyle.direction (None: from each paragraph's first strong
character, as before; written only when set), the Paragraph panel's two
direction buttons with Show Indic Options (original icons), and
text.setFormat {direction: "auto"|"leftToRight"|"rightToLeft"}. The
layout uses it as the base direction.
- The Automatic alignment check box is gone. Justify::Auto stays as the
start of the paragraph's direction, set on new type only (text.create,
the Type tools, with the mojikumi default in one new_type_para()):
TextObject::point is Left again, so importers (PDF, SVG, DXF, EMF) keep
their own alignment. The alignment buttons show what Auto resolves to.
- Bidi only where there is something right to left: plain paragraphs skip
the algorithm (no per-layout allocation), it runs once per paragraph
(shaping takes the paragraph's levels instead of recomputing them; path
type computed it four times), and the shaper keeps Han, Hiragana,
Katakana and Bopomofo in one segment (splitting at every change of
script cost Japanese text a shaper call per kana-kanji switch).
- Vertical type keeps its logical order, so its glyphs and lines are not
marked right to left (the caret no longer runs backwards down a column).
- PDF import puts Hebrew and Arabic, which PDFs (and VectorCraft's own
export) draw in visual order, back in logical order with the direction
that shows it as drawn; with bidi layout it came back mirrored.
- SVG import pins the direction SVG implies (left to right unless
direction: rtl); SVG export also outlines right-to-left paragraphs.
- Docs (development.md), ROADMAP (folded into the Type entry, Type core
row) and README updated; catalog rows for the new labels.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Text in fonts that aren't installed comes in as live type in the fallback font again, named as
before (Helvetica-Bold → Helvetica Bold), not outlines plus pink copies on a non-printing layer.
- The installed face that matches a PDF font is decided once per font from its first comparable
glyph, not per glyph (loading up to 64 faces each time, and switching style mid-line).
- Kangxi radicals are unified only for text from Adobe's CID tables, not ToUnicode maps.
- A line is laid out again only when tracking changed it.
- CidText::of is tested on data that isn't a CID-keyed CFF (embedded fonts are untrusted).
- NOTICE: Adobe CMap resources (BSD-3-Clause) bundled through hayro-cmap.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Japanese PDFs and PDF-compatible .ai files often set text in CID fonts
with no ToUnicode map, in vertical columns, and in fonts the reader
doesn't have. They came in as outlines (or as the wrong characters).
- CID fonts without ToUnicode: the character comes from the font's CFF
charset through the standard CMaps (hayro's `embed-cmaps`); Kangxi
radicals that some generators map to are unified with their ideographs
(⿓ → 龍).
- A glyph becomes live type only when the installed font draws the same
glyph: compared by box with the font of the PDF's PostScript name, or
the closest style of its family (a variable font's named instances),
whose style the type then takes. Otherwise it keeps its outline.
- Vertical columns (WMode 1, glyphs with no horizontal advance) come back
as vertical type, letter spacing as tracking; a single upright glyph is
vertical type too. Horizontal lines get tracking from the glyph
positions the same way.
- Text in a font that isn't installed keeps its outlines (what prints),
with an editable copy in a substitute font, drawn pink, on a
non-printing layer named after the missing fonts (stroke-only glyphs
included).
- Marked content other than a layer's (spans with actual text,
artifacts) no longer ends a line of type: 篳篥・龍笛・笙 came back as
three objects when one character was in a span.
- Tests in tests_live_text.rs and tests_realtext.rs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The path rebuilt through the glyphs ended where the last glyph ends, so
rounding in the spacing could push that glyph past the end, where type on
a path stops ("OFFICIAL ISSUED" lost its D). The path now runs an em
further.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Apps write type on a path one glyph at a time, each placed and turned along the
curve. The importer joined glyphs into a line only while they kept the first
glyph's direction. Type on a gentle curve was flattened into straight lines, and
type on a tighter curve fell apart into one object per glyph.
A glyph that starts about where the previous one ends, turned a little from it
(under about 20°), now continues the line. A line whose baseline turned more than
about 3° becomes type on a path: its path is a smooth curve (Catmull-Rom as cubic
Béziers) through the glyphs' baseline origins and the end of the last glyph.
Spaces between words are measured along the last glyph. Straight type, rotated or
not, imports as before.
Test: "ARCHING" written glyph by glyph along an arc imports as one
type-on-a-path object with that text and a curved path; slightly rotated straight
type stays point type.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A document names its fonts by PostScript name, which the importer split at the
first hyphen into family and style. A family with hyphens in its name was never
found: "Rounded-X-Mplus-1c-black" became family "rounded", style
"x-mplus-1c-black", and the text fell back to another font. Common Japanese
families have hyphens in their names.
The system font scan now also indexes each installed face's PostScript name
(read from the same name table it already reads). The importer asks for the face
with that exact name first (`FontDb::by_postscript_name`) and splits the name only
when no installed face has it.
Test: installed faces are found by PostScript name, in any case.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Luminosity soft masks become opacity masks (alpha masks as a white copy of
their art; backdrop colour gives Clip, an inverting transfer function Invert;
the PDF export's backdrop and Difference covers read back as the options; a
constant alpha mask is opacity). Transparency groups keep their /I and /K
flags (read by walking the content as the interpreter does). Tiling patterns
become pattern swatches (one per colour for uncoloured ones). Text becomes
point type, one object per line with a run per font and paint, fonts named
from the file (document.open textAs: text | outlines). Patch and triangle
mesh shadings become gradient meshes; gradients drawn through their grey
opacity mask get stop opacity back; shadings that don't extend clip the art.
A rectangular clip around all its art (a form's box) is dropped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
