You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Text: breaking before the full stop. Similarly, the Chinese localization, 我们正在测试文本换行和分段功能,看看浏览器如何处理它。, worked lawlessly even inside tightly constrained flexbox containers.
Same for Thai text (width 350): Thai text, which requires dictionary-based line breaking, was also verified: นี่คือข้อความภาษาไทยสำหรับการทดสอบการตัดคำ.
Width: 610
Functions: prepareWithSegments() + layoutNextLine(), but layoutWithLines() and walkLineRanges() are also broken.
Text: They remain hyper-focused on delivering a best-in-class experience (even when dealing with nested [bracketed {and heavily punctuated}] data!). Whether the user is typing in English, sending a 👩🚀 emoji, formatting currency like £3,450.75, or reading Thai (ทดสอบ), the layout engine must hold strong.
Assuming the implementation of the diff tool in https://pretext-diff.replit.app/ is correct (https://replit.com/@bmwhsnrr/Pretext-Diff), I'm reporting the following cases with mismatches between Pretext and CSS:
16px Inter, system-ui, sans-serifprepareWithSegments()+layoutNextLine().prepareWithSegments()+layoutNextLine().layoutWithLines()andwalkLineRanges()seem to get it right, but they are skipping words: Bug: layoutNextLine() produces different line breaks than layoutWithLines() on mixed-script text (CJK + RTL + emoji) #50.prepareWithSegments()+layoutNextLine().word-break: keep-allfor CJK text #74, but I think it should be by default for CJK to match CSS?prepareWithSegments()+layoutNextLine(), butlayoutWithLines()andwalkLineRanges()are also broken.