Files
pdfcraft/parity
358e33a307 M7: replacing a line keeps the source font for the words it can show (#2378, re-lands #2955) (#6842)
* M7: replacing a line keeps the source font for the words it can show (#2378) (#2955)

* Fit #2955's line edit to #4514's /ActualText spaces

Since #4514, source_show wraps a run whose spaces the subset lacks in a
/Span /ActualText BDC ... EMC, so the moves standing in for those spaces
read back. #2955's two-font /PCEdLine path writes its source runs through
source_show, so they now carry that span too. Three of its tests were
written against the operator stream from before that:

- replacing_a_mixed_font_line_again_replaces_its_sequence counted BMC and
  EMC as the /PCEdLine sequences alone. It now also counts each edit's
  own /ActualText spans (BDC, and EMC = sequences + spans), so a sequence
  that nests or survives a re-edit still fails it.
- a_leading_space_does_not_make_a_source_font_run looked for the leading
  move right after the Tf; it now sits inside the run's span.
- a_row_replaced_inside_a_shared_sequence_starts_in_its_own_font put its
  second row before the first EMC, which is now the span's: the row was
  read as part of the span's text. It now goes before the EMC that closes
  /PCEdLine, the case the test describes. A paragraph rewrite drops an
  /ActualText span with its line (the span's BDC and EMC are among the
  line's operators), so it never leaves a row inside one.

The code needs no change: re-editing drops the spans inside a /PCEdLine
sequence with it (BDC/EMC are in the dropped set), and a span's merged
run keeps the sequence it is in, so the line still reads back as one.
Also drops the same_font import lines.rs no longer uses.

* Tests: fit #2955's three line-edit tests to #4514's /ActualText spans

* Tests: the replaced sequence's check allows the new text's own /ActualText span

---------

Co-authored-by: mtlcl410 <2368091+mtlcl410@users.noreply.github.com>
Co-authored-by: FredApps <FredApps@users.noreply.github.com>
2026-11-14 13:25:27 +01:00
..