Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#128 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
swift
Ambito
desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).

Lingua principale
Swift
Stelle
4.1k
Fork
285
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di f/textream

Tutte le issue di f/textream

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.