CJK: full-width punctuation renders as annotations, and half-width numbers/words get truncated to "…"

Đang mở
  • Có gì không ổn?
#128 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

@lllwwwyyy đang làm issue này rồi.

Từ ngày 22/10/2026.

  • #139 của @lllwwwyyy — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
74/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
swift
Lĩnh vực
desktop

Hướng nghiên cứu

Start in MarqueeTextView.swift, especially splitTextIntoWords and buildLines, and reproduce the issue with the provided Chinese sample at varying notch widths or font sizes. Check that full-width punctuation is not treated as annotations and that half-width numbers or Latin words are not truncated; verify the rendered line against the expected script.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

In Chinese scripts, full-width punctuation (，。：「」！？（）…) is rendered wrong, and half-width numbers or Latin words on the same line can be squeezed into … and disappear. Both come from the same root cause in MarqueeTextView.swift.

Environment

  • Textream 1.7.1 (Homebrew cask), macOS 26.6.2, Apple Silicon
  • Font: Sans, size LG, overlay: Pinned (notch width 410), mode: Word Tracking, speech locale: zh-TW

Steps to reproduce

  1. Paste this script: 那一年他 36 歲，搬到新的城市，而且換過三份工作。
  2. Start the prompter.

Expected: 那一年他 36 歲，搬到新的城市，而且換過三份工作。
Actual: 那一年他 ...歲，搬到新的城市，而且換過三份工作。 The 36 is replaced by an ellipsis, and every full-width punctuation mark is shown italic, dimmed, and preceded by an extra space.

Whether a number disappears depends on how full the line is, so it comes and goes when the notch width or font size changes.

Root cause

1. Full-width punctuation becomes a standalone "annotation" word.
Unicode.Scalar.isCJK does not cover CJK Symbols and Punctuation (U+3000–303F) or Halfwidth and Fullwidth Forms (U+FF00–FFEF). So splitTextIntoWords emits each punctuation mark as its own word, and isAnnotationWord flags it because it has no letters or numbers. It is then rendered with the annotation style (italic, cueUnreadOpacity).

Tokenizer output for the sample (〔〕 = flagged as annotation):

那|一|年|他|36|歲|〔，〕|搬|到|新|的|城|市|〔，〕|而|且|換|過|三|份|工|作|〔。〕

2. buildLines underestimates line width, so SwiftUI truncates a word.
buildLines measures each word with NSString.size(withAttributes:), but each word is rendered as a separate SwiftUI Text(word + " "). For a standalone full-width punctuation mark, the two disagree a lot. Measured on this machine with NSFont.systemFont(ofSize: 20, weight: .semibold):

Word NSString width (+ space) SwiftUI Text width Difference
CJK character, e.g. 年 23.72 24.00 +0.28
36 29.71 30.00 +0.29
， or 。 (standalone) 14.32 25.00 +10.68
Whole sample line 523.4 561.0 +37.6

When the real width exceeds containerWidth, the HStack compresses its children. Single CJK characters can't shrink, so the only multi-character word on the line (36, or a Latin word like Claude) is truncated to …. I reproduced this outside the app by rendering the same HStack(spacing: 0) of Text(word + " ") views, with .lineLimit(1), at the width buildLines computed. The result matches what the prompter shows: 那一年他 ...歲，…

Suggested fix

  • In splitTextIntoWords, attach punctuation to the preceding CJK character (e.g. 歲，) instead of emitting it as its own word. At minimum, add U+3000–303F and U+FF00–FFEF to the CJK handling, so these marks are never treated as annotations.
  • In buildLines, measure words the same way they are rendered, or round each word width up (ceil) and keep a small safety margin, so accumulated per-word rounding can't overflow the line.
  • Optionally, add .fixedSize() to the word Text, so an overflow wraps to the next line instead of silently hiding script text.

Related: #60, #95 (other Chinese support issues).

Ngôn ngữ chính
Swift
Star
4.2k
Fork
296
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của f/textream

Tất cả issue của f/textream

Issue tương tự

Thêm issue về Swift

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.