Чтобы добавлять сообщения и комментарии, .

@develar:
develar

Ага. Стало понятно теперь, почему в 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 не осуществляет.

@develar:
develar

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

@develar:
develar

При написании собственного 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())).

@develar:
develar

Последние билды имеют глюк с выдачей totalheight github.com

@develar:
develar

С TinyTLF отключил к чертям (изначально писалось на базе убогого TLF) кеш готовых textBlocks на своей стороне и все работает также прекрасно и быстро.

@develar:
develar

Совсем скоро можно будет закопать TLF от Adobe и забыть об этом ужасе — сейчас TinyTLF не умеет редактировать, но github.com :)

@develar:
develar

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

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

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

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

@develar:
develar

drinkability — twitter.com "tinytlf dev tonight. Finally motivated again. Also, to hell with size, I now aim for modularity, speed, and drinkability"

@yzh44yzh:
yzh44yzh

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

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

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

@yzh44yzh:
yzh44yzh

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

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

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

@yzh44yzh:
yzh44yzh

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

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

@werdn:
werdn

я не понял слегка, tinytlf только под 10.1 плеер работает или кем?

@develar:
develar

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

@develar:
develar

В отличие от идиотов в 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 ).

@develar:
develar

Еще не работал, но уже чувствую, что Adobe должна уволить весь TLF team и нанять guyinthechair.com <guyinthechair.com> You can grab mavenized project github.com (just open in IntelliJ IDEA and get configured ide project).