to post messages and comments.

Ага. Стало понятно теперь, почему в TLF от Adobe такая убогая непредсказуемая отрисовка underline, в то время как в TinyTLF всегда красивая и черточка не прилеплена к тексту. Вся штука в том, что FTE это хорошая тема, и в руки нам дается прекрасный API. API этот, в частности, позволяет спросить у element format FontMetrics, а вот FontMetrics как и содержит "suggested vertical offset from the Roman baseline for an underline.".

Видимо, авторы TLF, как всегда, забыли, что Flash Player при отрисовке чего-то, заданного float (а underlineOffset может быть равен 0.451171875) subpixel rendering не осуществляет.

TinyTLF — почувствуй себя велосипедистом, летящим вниз с моста ранней питерской весной и обгоняемого фурой, сигналящей на 15 секунде попытки обгона при условии пробки на далеко не последних метрах спуска. Это никак не опровержение моего ответа на вопрос после доклада на последнем rafpug.

При написании собственного TextBlockFactory учитывайте тот нюанс, что вы ответственны за очистку кеша textBlocks в TextEngineAnalytics в случае повторной установки data.

Рекомендуемая, прекрасная (без иронии — инженеры Adobe сосут, а вот в tinytlf это решение очень удобно и дает очень легкий для реализации и использования низкоуровневого API) и стандартная реализация getTextBlock(index:int):TextBlock — engine.analytics.getBlockAt(index) и возврат его сразу без генерации нового, если результат вызова не null. И вот если вы не очистите кеш в preRender():void, то, соответственно, вы гарантированно получите устаревший textBlock (TextBlockFactoryBase не имеет никакой реализации для, а в EditableBlockFactory иной алгоритм, то есть сами рулите).

Ядро отвечает только и только за очиcтку out of bounds indices (то есть все textBlocks с индексом менее startIndex или более endIndex автоматически идут в кеш нулевого уровня (object pool, вам нужно о нем знать только то, что вы должны рожать textBlock не через оператор new, а посредством TextBlockUtil.checkOut())).

Кто-нибудь еще сомневается, что можно иметь что-то общее с этими отмороженными дебилами (медицинский термин, ага) #1179963 ?

Технически инженер из Adobe прав ( forums.adobe.com ). Прав на 100%.
Есть только два нюансы — мы, черт возьми, люди.

Два вопроса:
1) Какого черта оно после прокрутки до упора вниз (key down) и прокрутки взад до упора вверх (key up) не восстанавливает позицию (текст будет прилеплен)?
2) АУ! На дворе чертов 2011 год, романтика программирования ушла и канула в лету, откройте тот же Interface Builder да накидайте вы TextView и посмотрите как оно себя ведет. Что, тоже торкает как оно аккуратно рассчитывает середину текста и плавно откручивает при достижении viewHeight ровнехонько на -viewHeight/2 с сохранением позиции курсора (вопрос номер три – какого черта оно при достижении конца переносит мой курсор в конец строки (все правильно) и потом забывает вернуть взад?).

Между прочим, TinyTLF скоро будет поддерживать редактирование, а уже сейчас дает с в разы меньшими вложениями в разы более нормальное (читай как в твоей ОСи, а не как в мозгу обкуренных не той травой "инженеров" Adobe) поведение (+как плюшка производительность, но в нашей то ситуации дай бог сделать нормально и в срок).

Если контент обновляется с частотой 2 секунды, и при этом юзер водит мышкой над текстом, то сыплются исключения. А если еще ресазить и скролить контент, то вообще жопа.

Что дальше?
1. Модифицировать TinyTLF под свои нужды?
2. Пыться подобрать костыли к TLF?
3. Попробовать старый mx:TextArea и его убогое html форматирование?
4. Гибридное flash-html приложение?

Наверное лучше 3й вариант. Того убогого форматирования мне хватит. Да и жили мы с ним как-то в предыдущих проектах, и нормально было.

Первое знакомство не прошло гладко. Скачаные Examples собрались и заработали.

Сверстал свой контент, вкинул — исключение. Полазил по исходинкам, откуда оно идет. И понял, что у контента должен быть корневой узел (которого я не сделал). Добавил корневой узел — заработало.

Со статичным контентом все ок. Но мне нужен динамичный, часто обновляемый контент. Начал менять контент и перерисовывать — сыплются исключения. Опять лажу в исходниках, разбираюсь :(

Замучался сражаться с TLF. Уперся в пару мелких проблем, которые сложно решить, но которые сводят на нет всю юзабельность продукта.

Ну что ж, давно хотел пощупать TinyTLF github.com видимо пришло время.

Еще одним несомненным плюсом tinytlf является отсутствие такого маразма как TextFlow. Моделью выступают непосредственно классы Flash Player — ContentElement (see guyinthechair.com Model Agnosticism). При этом вы не обязаны предоставить движку (да, да, движку, что невозможно сказать в отношении TLF, то в случае tinytlf именно text engine) сразу всю модель — можно как поток, посредством реализации ITextBlockFactory — спросили у вас nextBlock — отдали. Это абсолютно не имеет смысла, если вам нужно просто отобразить некий статический текст, но ведь, черт возьми, это ведь text engine — оно должно давать удобный API в том случае, если текст у вас строится динамически.

В отличие от идиотов в Adobe, автор tinytlf нормальный, в tinytlf нет никакого asdoc в классах реализации — только в интерфейсах.
Понятный и удобный API (если мне нужно установить только ширину, я explicitWidth = newW, а не setCompositionSize(newW, NaN)).

Минусы только по оформлению кода — явно видно, что автор пользуется блокнотом/Flash Builder, а не IntelliJ IDEA.

Черт возьми, впервые за 5 лет испытал удовольствие от работы со сторонней библиотекой на ActionScript (mate не в счет). По привычке порывался при использовании писать свое, но чудо — интерфейсы тут не только для галочки. И даже абстрактные классы можно использовать как базовые (с Flex SDK и TLF это невозможно — интерфейсы не используются, типы параметров/свойств конкретные, а в случае с tlf добавляется еще и tlf_internal). Да — если в неком коде используются пространства имен — разработчика кастрировать, а также всех сопричастных (в моей библиотеке Cocoa используется пространство имен ui для ui component skin parts, но это лишь от бедности — все время не найду написать compiler extension для ast генерации в compile time — то бишь в runtime этот namespace никак не является частью API/рабочего кода). Использование пространств имен это отличный индикатор убожества архитектуры. Потому что с ними все эти высокотеоретические выкладки об ООП смываются и размываются — это даже не прострелить себе ногу. И отсутствие поддержки пространств имен для интерфейсов это показатель, да.

Помимо пула для textLine (reuse на уровне плеера, добавление/удаление из пула на уровне as), также есть пул для textBlock (только на уровне as, при написании своей реализации ITextBlockFactory, нужно знать об этом пуле и использовать его) — вот этого в tlf нет.

Есть хитрый момент с инвалидацией. TextEngine принимает необязательный параметр stage. Stage ему нужен как раз для валидации — как во флексе, отрисовка происходит не на каждое изменение данных, а в определенный момент времени. И tinytlf вешается на ENTER_FRAME и RENDER (какой раньше придет — пришел — отписались от обоих и render). Если мы используем tinytlf во флекс-приложении, где уже есть свой LayoutManager, делающий ту же работу, то нужно ли нам передавать tinytlf stage? Если текст не интерактивный — можно всю валидацию осуществлять в host component — он на updateDisplayList вызывает у textEngine render и все (тема встраивания text engine во flex component lifecycle (типа measure) обширна и в этот топик не входит, могу лишь сказать, что тут tlf sucks, а tinytlf берет пирожок). А вот если интерактивный — то ничего работать не будет (то бишь никакой отрисовки в ответ на действия пользователя) — ведь он будет ждать, пока его отвалидируют. Интересно, что в реализации RichTextField данный момент никак не решен (тупо передается stage — то есть возможен сценарий гонки — когда оно отрисуется до updateDisplayList). Решается написанием своего (патч автору еще не отправил).

А gestures — это песня. Вам не нужен ParagraphSelectionBehavior? Ну так не мапьте его — оставьте только CharacterSelectionBehavior и WordSelectionBehavior. Впрочем — управление курсором вкупе со ссылками из разных блоков — получается порнография. Потому что стека курсора нет, получается гонка и как результат вы на второй ссылке получите auto вместо button/ibeam. Вряд ли автор tinytlf поправит это (невоспроизводимо на обычных текстах), пока что на это забил.

Нерваное выделение текста, как и должно быть в Mac OS X — juick.com

Черт возьми, оно умеет отрисовывать подчеркивания не как путь всегда обкуренных сотрудников Adobe домой — то прилеплено к глифам, то нет, а нормально — всегда с отступом.

И, да, кайфую от того, что когда-то исправил компилятор таким образом, что вектор созданный в виде литерала, является фиксированным ( juick.com ).