История изменений
Исправление wandrien, (текущая версия) :
Также по прочтении стало интересно, а как же поступают для добропорядочной вставки строк на иврите в код? Сначала добавляют энное количество пробелов с расчётом на будущий текст, а потом пишут сам текст?
Проблема не в этом. По-моему, они там криво всё объяснили.
Расскажу, как сам думаю.
В памяти все данные идут «от начала к концу» во всех языках. Вот только визуальное положение положение «начала» и «конца» у разных языков разное. Вот что получается:
Допустим, у нас есть последовательность байт: «abcde ABCDE xyz». При этом заглавные буквы в этом примере означают какие-то буквы иврита.
Движок видит, что начало абзаца идёт в направлении LTR. Он начинает выстраивать глифы по порядку: «abcde».
Потом он встречает «A» и понимает, что нужно переключиться на RTL. Она заглядывает дальше и смотрит, сколько их там: «ABCDE». Кончились.
Теперь он рассчитывает глифы. Получает визуально слово: «EDCBA».
Добавляет его к уже построенной строке глифов: «abcde EDCBA».
Дальше идёт переключение на LTR.
В результате получается: «abcde EDCBA xyz».
Это правильный результат рендеринга. Никакого бага — последовательность символов на экране не соответствует порядку в файле. Так и задумано!
А теперь — проблема. Используя коды принудительной смены направления, можно в наши «ABCDE» из примера загнать самые разные символы, а не только буквы иврита!
Вот и получится что визуально кусок текста будет, например, закомментирован. А на самом деле — нет!
Исправление wandrien, :
Также по прочтении стало интересно, а как же поступают для добропорядочной вставки строк на иврите в код? Сначала добавляют энное количество пробелов с расчётом на будущий текст, а потом пишут сам текст?
Проблема не в этом. По-моему, они там криво всё объяснили.
Расскажу, как сам думаю.
В памяти все данные идут «от начала к концу» во всех языках. Вот только визуальное положение положение «начала» и «конца» у разных языков разное. Вот что получается:
Допустим, у нас есть последовательность байт: «abcde ABCDE xyz». При этом заглавные буквы в этом примере означают какие-то буквы иврита.
Движок видит, что начало абзаца идёт в направлении LTR. Он начинает выстраивать глифы по порядку: «abcde».
Потом он встречает «A» и понимает, что нужно переключиться на RTL. Она заглядывает дальше и смотрит, сколько из там: «ABCDE».
Теперь он рассчитывает глифы. Получает визуально слово: «EDCBA».
Добавляет его к уже построенной строке глифов: «abcde EDCBA».
Дальше идёт переключение на LTR.
В результате получается: «abcde EDCBA xyz».
Это правильный результат рендеринга. Никакого бага — последовательность символов на экране не соответствует порядку в файле. Так и задумано!
А теперь — проблема. Используя коды принудительной смены направления, можно в наши «ABCDE» из примера загнать самые разные символы, а не только буквы иврита!
Вот и получится что визуально кусок текста будет, например, закомментирован. А на самом деле — нет!
Исправление wandrien, :
Также по прочтении стало интересно, а как же поступают для добропорядочной вставки строк на иврите в код? Сначала добавляют энное количество пробелов с расчётом на будущий текст, а потом пишут сам текст?
Проблема не в этом. По-моему, они там криво всё объяснили.
Расскажу, как сам думаю.
В памяти все данные идут «от начала к концу» во всех языках. Вот только визуальное положение положение «начала» и «конца» у разных языков разное. Вот что получается:
Допустим, у нас есть последовательность байт: «abcde ABCDE xyz». При этом заглавные буквы в этом примере означают какие-то буквы иврита.
Движок видит, что начало абзаца идёт в направлении LTR. Он начинает выстраивать глифы по порядку: «abcde».
Потом он встречает «A» и понимает, что нужно переключиться на RTL. Она заглядывает дальше и смотрит, сколько из там: «ABCDE».
Теперь он рассчитывает глифы. Получает визуально слово: «EDCBA».
Добавляет его к уже построенной строке глифов: «abcde EDCBA».
Дальше идёт переключение на LTR.
В результате получается: «abcde EDCBA xyz».
Это правильный результат рендеринга. Никакого бага — последовательность символов на экране не соответствует порядку в файле. Так и задумано!
А теперь — проблема. Используя коды принудительной смены направления, можно в наши «ABCDE» из примера загнать любые небуквенные символы! Пунктуацию, пробелы и т.п.
Вот и получится что визуально кусок текста будет, например, закомментирован. А на самом деле — нет!
Исходная версия wandrien, :
Также по прочтении стало интересно, а как же поступают для добропорядочной вставки строк на иврите в код? Сначала добавляют энное количество пробелов с расчётом на будущий текст, а потом пишут сам текст?
Проблема не в этом. По-моему, они там криво всё объяснили. В памяти все денные идут «от начала к концу» во всех языках. Вот только визуальное положение положение «начала» и «конца» у разных языков разное. Вот что получается:
Допустим, у нас есть последовательность байт: «abcde ABCDE xyz». При этом заглавные буквы в этом примере означают какие-то буквы иврита.
Движок видит, что начало абзаца идёт в направлении LTR. Он начинает выстраивать глифы по порядку: «abcde».
Потом он встречает «A» и понимает, что нужно переключиться на RTL. Она заглядывает дальше и смотрит, сколько из там: «ABCDE».
Теперь он рассчитывает глифы. Получает визуально слово: «EDCBA».
Добавляет его к уже построенной строке глифов: «abcde EDCBA».
Дальше идёт переключение на LTR.
В результате получается: «abcde EDCBA xyz».
Это правильный результат рендеринга. Никакого бага — последовательность символов на экране не соответствует порядку в файле. Так и задумано!
А теперь — проблема. Используя коды принудительной смены направления, можно в наши «ABCDE» из примера загнать любые небуквенные символы! Пунктуацию, пробелы и т.п.
Вот и получится что визуально кусок текста будет, например, закомментирован. А на самом деле — нет!