← All posts tagged tlf

develar
tinytlf tlf Ага. Стало понятно теперь, почему в 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
tinytlf tlf Adobe Кто-нибудь еще сомневается, что можно иметь что-то общее с этими отмороженными дебилами (медицинский термин, ага) #1179963 ?

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

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

Между прочим, TinyTLF скоро будет поддерживать редактирование, а уже сейчас дает с в разы меньшими вложениями в разы более нормальное (читай как в твоей ОСи, а не как в мозгу обкуренных не той травой "инженеров" Adobe) поведение (+как плюшка производительность, но в нашей то ситуации дай бог сделать нормально и в срок).
develar
tinytlf tlf Еще одним несомненным плюсом tinytlf является отсутствие такого маразма как TextFlow. Моделью выступают непосредственно классы Flash Player — ContentElement (see guyinthechair.com Model Agnosticism). При этом вы не обязаны предоставить движку (да, да, движку, что невозможно сказать в отношении TLF, то в случае tinytlf именно text engine) сразу всю модель — можно как поток, посредством реализации ITextBlockFactory — спросили у вас nextBlock — отдали. Это абсолютно не имеет смысла, если вам нужно просто отобразить некий статический текст, но ведь, черт возьми, это ведь text engine — оно должно давать удобный API в том случае, если текст у вас строится динамически.
develar
tinytlf tlf В отличие от идиотов в 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
tlf Профилировал juick.com FB профайлер тормозной (IDEA берет те же данные гораздо быстрее, вот только показывает она их не так удобно — видимо, тут ошибка Adobe в том, что они перенесли/реализовали часть вычисления на сторону flash player, а по сути правильно отправить лишние несколько метров на сторону java и пусть она сама считает) — при наведении на ссылку он подвисает, а потом можно видеть в таблице результатов — TLF честно полностью композирует весь TextFlow (flowComposer.updateAllControllers()). В моем случае оно честно вызывает 198 раз createTextLine. Правильно, а вдруг в новом формате ссылки новый fontSize? Только, сцуко, не в их наркотическом бреду, а в реальной жизни у нас меняется только и только цвет у ссылки (а то и вовсе — подчеркивание, то есть даже и одного вызова recreateTextLine не будет — тупо удостовериться, что sprite для отрисовки уже добавлен в существующий textLine, и отрисоваться в нем) — и нет никаких проблем проверить эти два условия (и только в худшем случае recompose all)).
develar
tlf Есть у меня 30 штук spans со ссылками. И вот при перемещении мышкой по этим ссылках оно явно тормозит (курсор и подчеркивание с задержкой) на i7 процессоре. Кто работал с TLF — это нормально? Придется опять профилировщиком смотреть и фиксить.
develar
tlf Сборки TLF для мавена, как уже писалось, можно брать тут — repository.flyti.org

Опубликовал немного дополненную 2.0.189-de1 (192 билд). У FlowGroupElement

public function set children(chidlren:Vector.<FlowElement>):void

и

public function set child(child:FlowElement):void

Для чего? Если вам надо добавить в параграф 100 span, то использование addChild (100 раз) повлечет за собой вызов replaceChildren. А там мама роди меня обратно. Логичнее иметь некий инициализирующий сеттер для childArray.

И у textFlow свойство skipNormalization. Если у вас руки не дрожат и вы сами инициализируете textFlow и оно не editable, то даром не нужно нормализовывать. Тем более, что оно там есть интересные моменты — если вы установите interactionManager до добавления контента, то оно... отнормализует его — добавит span в пустой параграф (а вы будете мучиться паранойей, откуда в новом параграфе дети и почему numChildren не равен 0 изначально).
develar
tlf А можете ли подтвердить криворукость разработчиков TLF касательно "FTE performance will degrade on a large paragraph"? Это цитата из RichEditableText. Опуская неграмотность того, кто написал этот комментарий (FTE оперирует только строками, то есть тут имелся ввиду именно TLF, а не FTE), был ли у вас печальный опыт (tlf это один большой печальный опыт, но имеется ввиду именно падение производительности при куче span в одном параграфе)?
develar
tlf TLF вообще тестировался в Adobe? Есть текст, используется device font. И он подчеркнут. Так эта самая линия подчеркивания то имеет отступ от текста, то прилипает к буквам. Понятно, почему так происходит, но разработчики TLF могли бы, раз уж так получилось, тоже пойти к флешерам и спросить.

И не надо потом спрашивать, а почему вы не используете флекс напрямую, а только как базу для собственых компонент — juick.com .
develar
tlf Убогий TLF. Есть span, текст которого содержит возврат каретки — "\n". Все работает — перенос строки есть. Но если установить у параграфа или самого span BreakOpportunity.ANY, то переноса строки нет — все в одну строчку toFit. Какого черта? Какое отношение BreakOpportunity имеет к символу \n?
develar
Flash tlf За три дня от разных производителей ненужного информационного шума (и по направлению) куча постов WTF о шрифтах (как вершина айсберга, лакмусовая бумажка) и убогости текстовой подсистемы флеша (+tlf, как бы идиотам в Adobe не хотелось отгородить его). Да. Adobe умеют доставить. Но я уже проникся философией @Constantiner ;) Поэтому будем радоваться просто, что мы все олени. Все-таки зима скоро.
develar
tlf В тему juick.com — трава — "The factory and the composer produce slightly different results which can confuse the scroller." — если для RichEditableText есть скроллер, то он в любом случае будет конвертировать текст в textFlow. По логике, надо было разбираться почему slightly different results.
develar
Flex tlf В тему juick.com . Предположим, вы решили не патчить TLF для решения этого идиотизма, а грустно вспомнили что вы проститутка и решили просто таскать с собой textFlow. Вы думаете, все проблемы решены? Трава. Если вы установили textFlow для RichEditableText, то не надо думать, что вам позволят сохранить ссылку на него — вы обязаны всегда теперь таскаться с instance RichEditableText, потому что в textContainerManager_damageHandler он может тупо _textFlow = textContainerManager.getTextFlow(); — то есть если вы у вашего textFlow смените fontFamily, то ничего не произойдет, так как TLF оперирует уже другим. Adobe, когда ты сменишь поставщика травы?
develar
tlf Трава. Как уже писалось, идиоты в Adobe спроектировали TFL так, что textFlow не может быть расшарен. Есть еще один нюанс — если вы скармливаете textFlow некий textFormat, то он:

if (_format is TextLayoutFormat || _format is TextLayoutFormat)
useFormat = _format;
else
useFormat = new TextLayoutFormat(_format);
_computedPrototypeFormat = FlowElement.createTextLayoutFormatPrototype(useFormat,null);

То есть вы никак не можете динамически стилизовать textFlow. Чтобы установить новый font family, у вас есть два пути — 1) непосредственно у textFlow установить свойство fontFamily 2) клонировать свой формат (тот же instance не покатит) и присвоить ему новое значение (на perfomance мы уже давно положили болт и о нем даже речи нет). Казалось бы, — установи ты свойство напрямую у textFlow и не выпендривайся. Это покатит в простом приложении. В сложном возникает ряд нюансов — этот формат нужен не только TLF, но и высокоуровневому ui-control textArea для расчета char metrics (посчитать тот же height in lines). Если вы делаете Font Panel (то есть даете пользователю некий тул типа как в MS Office для кастомизации шрифта, цвета и прочего), то для Font Panel в разы удобнее работать именно с некой моделью простой, а не с textFlow (тем более, что она не должна быть зависима от TLF — может мне хватит формата и я отрисую текст посредством flash text engine напрямую). Черт возьми, ну как можно так проектировать? Какие к черту митинги и обсуждения, если это не rocket science?
develar
tlf Вышла новая сборка TLF. Ох, явно не ту траву они курят — "API Change: ISelectionManager functions getCommonCharacterFormat, getCommonParagraphFormat and getCommonContainerFormat now return a

TextLayoutFormat instead of an ITextLayoutFormat. This change is backwards compatible with current code because TextLayoutFormat

implements ITextLayoutFormat." Правильно, интерфейсы эта такая штука, она для красоты.
develar
Flex tlf TLF ведет себя совершенно не в соответствии с Mac OS X. Если в Windows при выделении текста в textArea правый край рваный, то в маке он ровненький — аккурат по text rect (за исключением последней строки). Вроде бы мелочь, но при работе с реальным приложением чувствуешь себя не в своей тарелке.
develar
tlf по умолчанию воспринимает cmd+ стрелка вправо как перенос курсора на слово, в то время как в Mac OS X все приложения переносят в конец строки. Как с этим в линуксе и windows?
develar
tlf Если вы используете TextContainerManager в неком текстовом компоненте, поддерживающем выделение (к примеру, Spark RET), и требуемый для отображения текст устанавливаете посредством setText (то есть просто строку), то textFlow не будет создан — будет использован StringTextLineFactory и все. А вот когда произойдет mouseDown — то TextContainerManager будет вынужден сделать textFlow, так как за обработку выделения отвечает SelectionManager, а ему требуется именно textFlow, а не вектор textLines.
develar
Maven tlf Если кому нужны ночные сборки TLF 2.0, то в известном репозитории есть 126 билд. другие билды будут появляться нерегулярно, но если надо, разумеется, после пинка будет.