이 프로젝트는 정말 인상적임
웹페이지에서 텍스트를 실제로 렌더링하지 않고도 줄바꿈된 텍스트의 높이를 효율적으로 계산하는 문제를 해결함
단어 단위로 분할된 세그먼트의 폭과 높이를 캐싱하고, 브라우저의 줄바꿈 알고리즘을 직접 구현함
하이픈, 이모지, 중국어 등 다양한 문자 처리와 브라우저별 렌더링 차이(Safari 포함) 때문에 매우 어려운 작업임
실제 브라우저와 비교 테스트를 위해 corpora 데이터셋과 accuracy 테스트 페이지를 사용함
나도 비슷한 걸 만든 적이 있음. uWrap.js라는 2KB짜리 단순 버전인데, AI 없이 구현했음
ASCII 텍스트 기준으로 내 코드는 80ms, pretext는 2200ms 걸림
정확도는 아직 테스트 안 했지만 오늘 밤 해볼 예정임 이슈 #18에 성능 개선 PR들이 이미 열려 있음
텍스트 레이아웃 엔진은 정말 악명 높게 어려움
나도 예전에 canvas에서 멀티라인 텍스트를 렌더링하려다 고생했음
이 프로젝트는 DOM과 직접 연결되어 있어서 훨씬 유용함
예시: Scrawl 데모
설명을 보면, 실제로는 세그먼트를 canvas에 렌더링해서 측정하는 방식 같음
네이티브 API보다 느릴 수 있고, 브라우저의 비-canvas 렌더링과 동일한 로직을 쓴다고 보장할 수 없음
사실상 브라우저의 텍스트 렌더링 알고리즘을 직접 구현한 건 아님
canvas에 렌더링 후 측정하는 방식이며, 단순히 텍스트 레이아웃 분석용 API를 제공하는 수준임
Remotion 비디오용 동적 자막 만들 때 텍스트 높이 계산 때문에 고생했는데, 이 라이브러리가 큰 도움이 될 것 같음
이건 정말 오랫동안 기다려온 기능임
예전부터 반응형 아코디언 같은 걸 제대로 구현하기 어려웠음
웹 발전 패턴은 항상 ① 복잡한 요구 등장 → ② JS/CSS 해킹 → ③ 표준화로 이어졌음
이번엔 해킹이 아닌, 제대로 된 2단계라고 생각함 RESEARCH.md를 보면 브라우저별 이모지 측정 차이까지 세세히 연구했음
유지보수는 힘들겠지만, 웹 발전에 큰 전환점이 될 것 같음
반응형 아코디언은 이제 CSS로 가능하지만, 여전히 이런 API는 필요했음
이번엔 AI가 개발 과정에 적극 활용된 게 흥미로움. Cursor 에이전트를 이용해 대부분 구현된 듯함
라이브러리 저자에 따르면, Claude Code와 Codex에게 브라우저의 ground truth 데이터를 학습시켜 여러 주차에 걸쳐 반복 측정했다고 함 관련 트윗 참고
Autoresearch도 일부 사용된 듯함
shape 기반 리플로우 예제가 특히 마음에 들었음
Ensō(enso.sonnet.io)에 적용해보고 싶었지만 단순함을 유지하려고 참았음 아코디언 예제는 CSS의 interpolate-size로도 구현 가능함 Josh Comeau의 글 참고 텍스트 버블 예제는 text-wrap: balance | pretty로 유사하게 구현 가능함
하지만 balance나 pretty로는 완전한 해결이 안 됨
줄 길이를 균등하게 만드는 건 원하지 않는 경우가 많음
관련 CSSWG 이슈: #191
text-wrap은 줄당 단어 수를 맞추는 데 도움은 되지만, 오른쪽 여백 문제는 여전히 남음
pretext는 canvas.measureText를 직접 쓰지 않고, 텍스트와 속성을 JS API로 넘기면 자동으로 레이아웃을 계산해줌
예전엔 measureText를 직접 쓰거나 harfbuzz를 브라우저로 옮겨야 했음
기술적 돌파구라기보다, 기존 요소들을 잘 조합한 결과 같음
다만 Skia-wasm / Canvaskit과의 차이가 궁금함
차이는 단순함. pretext는 wasm이 아님
Skia는 거대한 렌더링 엔진임. Flutter처럼 디바이스 독립적 렌더링 API를 제공함
pretext는 AI로 순수 Typescript 기반 글리프 렌더링을 구현한 점이 다름
ffmpeg를 C로 직접 구현한 것과 Dart에서 호출하는 것의 차이처럼 느껴짐
이런 시도가 클라이언트 사이드 FOSS의 새로운 가능성을 보여줌
만약 저자가 맞다면, 이건 웹 GUI 프레임워크와 리치 텍스트 에디터에 큰 변화를 줄 것임
작년에 HTML로 인쇄용 브로셔 조판 시스템을 만들었는데, 줄바꿈과 고아줄 방지를 위해 Selection API로 박스 경계를 반복 계산했음
지금도 잘 돌아가지만, 이유를 모르는 off-by-one 해킹이 있음
pretext의 반복적 줄 생성 기능은 정말 반가운 기능임
Hacker News 의견들
이 프로젝트는 정말 인상적임
웹페이지에서 텍스트를 실제로 렌더링하지 않고도 줄바꿈된 텍스트의 높이를 효율적으로 계산하는 문제를 해결함
단어 단위로 분할된 세그먼트의 폭과 높이를 캐싱하고, 브라우저의 줄바꿈 알고리즘을 직접 구현함
하이픈, 이모지, 중국어 등 다양한 문자 처리와 브라우저별 렌더링 차이(Safari 포함) 때문에 매우 어려운 작업임
실제 브라우저와 비교 테스트를 위해 corpora 데이터셋과 accuracy 테스트 페이지를 사용함
ASCII 텍스트 기준으로 내 코드는 80ms, pretext는 2200ms 걸림
정확도는 아직 테스트 안 했지만 오늘 밤 해볼 예정임
이슈 #18에 성능 개선 PR들이 이미 열려 있음
나도 예전에 canvas에서 멀티라인 텍스트를 렌더링하려다 고생했음
이 프로젝트는 DOM과 직접 연결되어 있어서 훨씬 유용함
예시: Scrawl 데모
네이티브 API보다 느릴 수 있고, 브라우저의 비-canvas 렌더링과 동일한 로직을 쓴다고 보장할 수 없음
canvas에 렌더링 후 측정하는 방식이며, 단순히 텍스트 레이아웃 분석용 API를 제공하는 수준임
이건 정말 오랫동안 기다려온 기능임
예전부터 반응형 아코디언 같은 걸 제대로 구현하기 어려웠음
웹 발전 패턴은 항상 ① 복잡한 요구 등장 → ② JS/CSS 해킹 → ③ 표준화로 이어졌음
이번엔 해킹이 아닌, 제대로 된 2단계라고 생각함
RESEARCH.md를 보면 브라우저별 이모지 측정 차이까지 세세히 연구했음
유지보수는 힘들겠지만, 웹 발전에 큰 전환점이 될 것 같음
이번엔 AI가 개발 과정에 적극 활용된 게 흥미로움. Cursor 에이전트를 이용해 대부분 구현된 듯함
라이브러리 저자에 따르면, Claude Code와 Codex에게 브라우저의 ground truth 데이터를 학습시켜 여러 주차에 걸쳐 반복 측정했다고 함
관련 트윗 참고
Autoresearch도 일부 사용된 듯함
shape 기반 리플로우 예제가 특히 마음에 들었음
Ensō(enso.sonnet.io)에 적용해보고 싶었지만 단순함을 유지하려고 참았음
아코디언 예제는 CSS의
interpolate-size로도 구현 가능함Josh Comeau의 글 참고
텍스트 버블 예제는
text-wrap: balance | pretty로 유사하게 구현 가능함balance나pretty로는 완전한 해결이 안 됨줄 길이를 균등하게 만드는 건 원하지 않는 경우가 많음
관련 CSSWG 이슈: #191
text-wrap은 줄당 단어 수를 맞추는 데 도움은 되지만, 오른쪽 여백 문제는 여전히 남음pretext는 canvas.measureText를 직접 쓰지 않고, 텍스트와 속성을 JS API로 넘기면 자동으로 레이아웃을 계산해줌
예전엔 measureText를 직접 쓰거나 harfbuzz를 브라우저로 옮겨야 했음
기술적 돌파구라기보다, 기존 요소들을 잘 조합한 결과 같음
다만 Skia-wasm / Canvaskit과의 차이가 궁금함
pretext는 AI로 순수 Typescript 기반 글리프 렌더링을 구현한 점이 다름
ffmpeg를 C로 직접 구현한 것과 Dart에서 호출하는 것의 차이처럼 느껴짐
이런 시도가 클라이언트 사이드 FOSS의 새로운 가능성을 보여줌
작년에 HTML로 인쇄용 브로셔 조판 시스템을 만들었는데, 줄바꿈과 고아줄 방지를 위해 Selection API로 박스 경계를 반복 계산했음
지금도 잘 돌아가지만, 이유를 모르는 off-by-one 해킹이 있음
pretext의 반복적 줄 생성 기능은 정말 반가운 기능임
Fedora + Firefox 환경에서 데모가 전부 깨져 보임
예: 스크린샷
이런 기능은 사실 브라우저 표준 API로 제공되어야 함
W3C에 기능 요청을 하려면 어떻게 해야 하는지, 커뮤니티 투표 같은 게 가능한지 궁금함
하지만 브라우저 벤더들이 우선순위를 두지 않음
현재 Chrome은 AI 관련 API에 더 집중하고 있음
Sciter 엔진에는 이미 Graphics.Text 기능이 있음
CSS 스타일을 그대로 적용할 수 있는 캔버스 기반 텍스트 렌더링 요소임
브라우저의 텍스트 검색(Ctrl+F) 이 가상 스크롤 리스트에서는 제대로 작동하지 않음
이런 문제를 해결하려면 JS가 아닌 새로운 “Search” API가 필요할지도 모름
관련 프로젝트: Display Locking, MDN 문서
가상화된 리스트의 오프스크린 항목은 DOM에 없으므로 검색 불가임
이를 해결하려면 선택, 포커스, 스크롤 위치, 매치 탐색까지 통합된 새로운 브라우저 계약이 필요함
하지만 사이트들이 일관되게 사용할 가능성은 낮음