Repository navigation
Conversation
airmang
left a comment
There was a problem hiding this comment.
Reviewed exact head 0ec34bb, field/highlight eligibility and logical-to-Hancom offset calculation. Verified successful CI workflow head and inspected logs (6,931 passed, 18 skipped, 1 xfailed; lint/types/hygiene pass). A valid multi-child hp:ctrl containing fieldBegin and fieldEnd is admitted but counted once, producing shifted line starts in a new cache. Hold for the inline reproduction; no actual Hancom program analysis was used. COMMENT because this account owns the PR.
| elif (name == "secPr" and first or name == "ctrl" and _takes_no_room(child, first)) and not length: | ||
| places.append(length) # before the text only: one among it was seen to break the line elsewhere | ||
| elif name == "ctrl" and not first and _field_mark(child): | ||
| places.append(length) |
There was a problem hiding this comment.
[P1] Count each accepted field mark rather than each ctrl wrapper. _field_mark accepts multiple fieldBegin/fieldEnd children, and the OWPML ctrl choice has maxOccurs='unbounded', but this branch appends only one position. Each mark takes eight logical positions (the HWP writer also emits each ctrl child individually). Reproduced on this exact head: add a non-first paragraph with '가나다 '*40 and one ctrl containing DATE fieldBegin plus its fieldEnd before the text; write_line_caches writes starts [0,56,104,152] with counted places [0]. With two semantic field marks the starts must be [0,64,112,160]. Extend by one position per mark (or reject grouped wrappers), and test a wrapper with multiple marks, including marks at a line boundary.
0ec34bb to
58824cc
Compare
airmang
left a comment
There was a problem hiding this comment.
Re-reviewed exact new head 58824cc and surrounding code. The updated head retains the previously reviewed implementation while incorporating the latest base and fixture/changelog merges. The unresolved grouped-field mark offset finding remains. A DATE fieldBegin+fieldEnd in one ctrl is counted once; exact-head reproduction still writes [0,56,104,152] instead of [0,64,112,160]. No new inline duplicate.
All 56 related local tests passed. All 13 exact-head CI checks pass; verified workflow head SHA and inspected logs (6,934 passed, 18 skipped, 1 xfailed plus lint/type/hygiene gates). Passing checks do not cover the reproduced issue; hold remains. COMMENT because this account owns the PR.
58824cc to
c5c7c4e
Compare
airmang
left a comment
There was a problem hiding this comment.
Re-reviewed exact new head c5c7c4e and its range-diff against the prior review. Changes are base/CHANGELOG or fixture-list integration; the implementation underlying the existing unresolved inline finding is unchanged.
A grouped DATE fieldBegin+fieldEnd still counts once; the exact-head reproduction writes [0,56,104,152] instead of [0,64,112,160]. Hold remains; no duplicate inline thread added.
All 57 related local tests pass. All 13 exact-head CI checks pass; workflow head SHA verified and test/lint/type/hygiene logs inspected (6,939 passed, 18 skipped, 1 xfailed). Those checks do not cover the reproduced finding. COMMENT because this account owns the PR.
…lights Hancom lays a field's start and end (a hyperlink, a click-here field, a date, a mail merge field) out taking no room on a line and eight characters each in a line's text position, wherever they stand; one standing where a line breaks starts the next line. A highlight's marks take neither. Paragraphs holding them were left for Hancom; they now get a cache like any other paragraph of text. The check that left a paragraph whose line starts at a control is gone: the page controls it guarded stand before the text only, so no line after the first starts at one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ds for Hancom Hancom saved a memo's field and a click-here field in a section's first paragraph without a line cache; only the field kinds and places it was seen to lay out are written. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The vendored corpus holds no MAILMERGE field on purpose (the deviation probe DEV-046 checks it); the fixture's four other field kinds and its highlight cover the same layout. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
c5c7c4e to
05a1490
Compare
airmang
left a comment
There was a problem hiding this comment.
Revalidated exact rebased head 05a1490. Read the range-diff and surrounding affected code; changes since the prior review are base/CHANGELOG or fixture-test placement only. Re-ran the existing targeted reproduction at this exact head. The unresolved grouped field-control offset remains: DATE fieldBegin+fieldEnd counts once and writes [0,56,104,152] instead of [0,64,112,160].
All 13 current CI checks pass; verified the successful workflow's head SHA and read its test/lint/type/hygiene log (6,946 passed, 18 skipped, 1 xfailed; coverage 90.06%). The existing inline finding remains unresolved; hold remains and no duplicate inline thread is added. COMMENT because this account owns the PR.
무엇
(실험 기능) 줄 배치 정보 쓰기(
write_line_caches)가 글 사이에 필드나 형광펜이 든 문단을 건너뛰었다. 한/글은:어디에 있든 같고, 줄이 나뉘는 자리에 있으면 다음 줄이 그 표시로 시작한다.
그래서 그런 문단에도 쓴다. 메모 필드와 구역 첫 문단의 필드는 한/글이 배치 정보 없이 저장한 것을 봤으므로 계속 건너뛴다.
문단 첫 줄 밖에서 컨트롤로 시작하는 줄을 건너뛰던 검사는 지웠다: 그 검사가 지키던 쪽 컨트롤은 글 앞에만 있어 해당하는 줄이 없다.
시험
HANCOM_LAID_OUT에 한/글이 저장한line_cache_fields.hwpx(하이퍼링크·누름틀 채움·빈 누름틀·날짜 필드 + 형광펜, 필드가 줄 처음·끝에 오는 문단 포함) 추가.test_a_paragraph_holding_fields_or_a_highlight_gets_a_cache: 필드·형광펜 문단에 쓰고, 여러 줄 문단 포함, 한/글 것과 같다(고치기 전 실패).🤖 Generated with Claude Code