Troika: 오른쪽에서 왼쪽으로 쓰는 텍스트 레이아웃 지원

먼저 이 작업에 대해 깊은 감사를 드립니다. 아랍어 및 RTL 레이아웃을 지원하는 것은 많은 사람들에게 유용할 것입니다.
나는 몇 가지 첫 번째 테스트를 했습니다. 표준 아랍어 텍스트는 대부분 카이로, Lemonada, Scheherazade 글꼴(Tachkil 없음)에서 잘 지원됩니다.

나는 아랍어에 대해 다음 2가지 규칙을 테스트하고 있었습니다.

1. 3가지 형태의 글자가 괜찮은지(처음, 중간, 끝)과 연결(합자).
2. ُ َ ً ٌ 발음 표시의 집합인 Tachkil (드문 경우를 제외하고는 인터넷에서 찾을 수 있는 대부분의 텍스트에서 사용되지 않음)

mirza에서 일부 내부 문자가 연결되지 않음(문자의 끝 형태가 내부 문자 대신 삽입되거나 그렇지 않음)

tachkil을 사용하면 일부 글꼴은 제대로 작동하는 반면 다른 글꼴은 옆에 있는 문자의 형태를 변경했습니다. 일부는 내가 상자에 쓴 텍스트로 작업했지만 복사한 텍스트로는 작업하지 않았습니다.

괄호 "(", ")"와 같은 비 아랍어 문자를 사용하는 경우 전환됩니다(반전해야 함).

이것은 내가 만든 빠른 테스트입니다. 더 많은 것을 확인하고 상황이 이상해지는 부분에 대해 더 자세한 정보를 제공해야 합니다. (글꼴도 확인해야 합니다. 일부 글꼴은 필요한 문자를 제공하지 않습니다.)

좋아요, 감사합니다! 시작이 순조롭다니 기쁩니다.

단어 위치 대체에 대한 결과가 글꼴에 따라 다르다는 것이 흥미롭습니다. Typr의 단어 위치 감지 논리 는 항상 동일하므로 해당 글꼴이 Typr이 처리하지 않는 대체를 인코딩하는 방식에 뭔가 다른 것이 있어야 합니다. 차이점을 확인할 수 있는지 확인하기 위해 구체적으로 Mirza를 살펴보겠습니다.

이 문자를 모르기 때문에 올바른지 틀린지를 스스로 결정할 수 없으므로 다음과 같은 한 단어로 예상되는 결과가 포함된 일부 대상 테스트 사례를 제공할 수 있다면 대단히 도움이 될 것입니다.

입력 텍스트: xxx
다음과 같아야 합니다. [이미지]
글꼴 A에서 올바르게 보입니다. [이미지]
글꼴 B에서 잘못된 모양: [이미지]

괄호에 관해서는 그것이 Bidi 알고리즘의 Paired Brackets 부분이라고 생각합니다. 혼자서 해결할 수 있을지는 아직 확실하지 않지만 확실히 조사해 보겠습니다.

대략적인 양방향 레이아웃 지원으로 코드를 푸시했습니다. 지금은 방향 범위를 정의하기 위해 LRO/RLO/PDF 제어 문자를 사용하는 순전히 수동입니다. 완전 자동 bidi는 훨씬 더 복잡하고 여전히 범위를 둘러싸고 있지만 범위를 배치할 수 있는 것(라인 래핑 및 선택 포함!)은 중요한 시작입니다.

어제 피드백을 올리지 못해서 정말 죄송합니다. 주말에 전체 테스트를 해볼 생각이었지만 단계적으로 하는 것이 더 낫다고 생각합니다.
잘 작동하는 글꼴부터 시작하겠습니다(일부 글꼴에는 문제가 있을 수 있음). 저는 Scheherazade 글꼴을 사용했지만 Cairo와 Lemonada는 동일한 결과를 제공합니다.
Mirza 및 Amiri 글꼴은 항상 연결이 끊긴 문자를 표시합니다.
Noto Sans, Roboto 글꼴이 전혀 작동하지 않습니다.

아래 그림에서 빨간색을 사용하여 잘못된 형태의 글자를 의미하고 녹색이 올바른 형태를 의미합니다.
문제는 Tachkil(성악 음표) 또는 라틴어 또는 숫자 문자가 있는 경우에만 나타납니다.

1. 최종 형식 대신 내부 형식이 있습니다.
2. 단어 내부에 시작 형식 대신 내부 형식이 있습니다. (단어 내에서 일부 문자에는 합자가 없습니다)
3. 단어 바로 뒤에 숫자가 있으면 (كم2) 끝 형태를 유지합니다.
4. 숫자가 반전됩니다.

내가 사용한 텍스트:
2.
2
بِسم اللَّه الرحمن الرحيم
بِسمِ اللَّهِ الرَّحمٰنِ الرَّحيمِ

이 답변에는 글자를 그리는 방법에 대한 그림이 포함되어 있습니다.
https://www.quora.com/How-can-anyone-read-Arabic-as-the-letters-are-all-connected-to-each-other/answer/Hashem-Mohamed-4

이 마크업된 테스트 케이스에 대해 대단히 감사합니다. 매우 도움이 됩니다!!! 그것은 내가 사물을 이해하는 데 정말 도움이 됩니다.

단어 위치를 감지하는 Typr의 논리는 확실히 잘못되었습니다. 나는 그것을 opentype.js 에서 채택한 로직으로 재정의했고 결과는 이제 훨씬 좋아 보입니다.

추가 테스트 후 해당 Typr 수정 사항을 업스트림에 다시 제공하겠습니다.

"숫자가 반전되었습니다" 문제는 내가 시작한 BiDi 작업으로 처리됩니다. 지금은 명시적 LRO/PDF 문자로 해결할 수 있습니다.

이러한 종류의 테스트 케이스를 계속 제공하십시오! 🤩

그것은 빨랐다.
글쎄, 나는 당신이 언급한 BiDi 작업을 사용하여 수행할 수 있는 것(숫자와 괄호는 아랍어 텍스트와 함께 널리 사용될 수 있음)을 제외하고 더 수정이 필요한 것을 찾지 못했습니다.
LRO/PDF 문자를 사용하는 방법에 대한 예를 보여줄 수 있습니까? 혼합 텍스트 예제를 직접 재현할 수 없었습니다.

아랍어 텍스트와 관련이 없지만 SDF 렌더링과 관련이 있을 수 있는 마지막 사항은 여기와 같이 2개의 문자가 함께 연결될 때 일부 문자의 내부가 검은색이라는 것입니다.


때로는 같은 캐릭터 내에서

이것은 Lemonda 글꼴에서만 볼 수 있습니다. Scheherazade, Cairo는 잘 작동합니다(캐릭터가 올바른 위치에 연결되기 때문일 수 있음).
(벡터 렌더링 도구의 부울 연산처럼 보입니다.)

그리고 다시 한 번 노고에 감사드립니다.

감사 해요! 나는 현재 당신이 지금까지 설명한 다른 모든 문제를 해결해야 한다고 생각하는 완전한 bidi 알고리즘 구현을 추가하는 작업을 하고 있습니다.

예의 드롭다운에 있는 "BiDi 1" 텍스트에는 LRO/PDF의 예가 있지만 지금은 그것에 대해 걱정하지 마십시오. 단지 임시방편일 뿐이고 실제로 정확하지 않습니다. 진정한 비디가 더 좋을 것입니다.

해당 글꼴의 부울 채우기 문제는 #57에서 논의한 것과 같습니다.

이제 완전한 bidi 지원이 제공됩니다!

예제 페이지에는 몇 개의 bidi 스니펫이 있지만 고유한 rtl+ltr 혼합 텍스트로 테스트해 보십시오.

이것은 내가 토끼굴로 내려가는 전형적인 예가 되었습니다. 적절한 JS bidi 구현을 찾지 못했고 fribidi.wasm을 가져오고 싶지 않았기 때문에 새로운 JS 구현을 야간 및 주말 프로젝트로 사용하기로 결정했습니다. https://github.com/lojjic/bidi-js를 보십시오! 거기에 몇 가지 문서를 추가해야 하지만 공식 bidi 테스트에 따라 완전히 호환되며(~10kb) 꽤 작고 속도가 더 빠르지만 아마도 더 최적화될 수 있습니다.

나는 이 솔루션과 그것이 번들 크기에 얼마나 적은 양만 추가되는지에 대해 정말 만족하고 있습니다. 나는 우리가 이제 완전한 RTL 지원에 매우 근접했다고 생각합니다. 결합 양식 논리를 다시 방문해야 하지만 opentype.js에서 채택한 논리가 아랍어 스크립트만 처리하고 결합도 수행하는 다른 논리는 처리하지 않는다는 것을 깨달았습니다.

조인 유형 감지의 더 완전한 구현을 추진했습니다. Opentype.js에서 채택한 논리는 불완전한 것으로 판명되었습니다. 새로운 구현은 실제로 유니코드 결합 유형 정의 의 고도로 압축된 버전을 포함하므로 이제 아랍어 및 기타 언어로 결합 가능한 모든 문자를 처리해야 합니다. 또한 Typr 코드보다 적절한 속도 범프를 제공합니다.

@MichaelHazani 히브리어 테스트를 자원하셨기 때문에 이제 준비가 된 것 같습니다. "글꼴" 드롭다운에 몇 가지 히브리어 글꼴을 추가한 이 테스트 페이지 를 사용할 수 있으며 자신의 텍스트를 입력할 수 있습니다. 감사 해요!

좋아 보인다!
("글쎄요, 테스트가 성공한 것 같습니다. 구두점은 있어야 할 위치에 있습니다. 오른쪽 정렬이 좋아 보입니다. 두 글꼴 모두 히브리어를 표시되어야 하는 방식으로 표시합니다. 영어, 즉 이 단어로 전환해도 정렬이 깨지지 않습니다. 잘 했어!")

여기까지 작업한 v0.41.0을 릴리스했습니다. 의심할 여지 없이 추가로 전문화된 처리가 필요한 다른 RTL 스크립트가 있지만 이는 사례별로 처리할 수 있다고 생각하기에 충분히 견고한 기준선을 제공합니다. 그리고 좀 더 고급/불분명한 경우에 대해 선택적 Harfbuzz 플러그인(#91)을 허용할 가능성이 항상 있습니다.

소중한 도움을 주신 @boulabiar 와 @MichaelHazani 에게 다시 한 번 감사드립니다!!! 🎉