Alex, I'm proud to say I have worked on TLF with Harbs and so I know a lot on this subject. Well, that's not true, Harbs did all the work while I poked and prodded and wrote code he had to rewrite. :P However, in my opinion it was one of the more difficult frameworks I've seen because of a lot of new concepts. It was like learning Flex from scratch without any immediate payoff.
It's doable in my opinion but it will take a major amount of work. I was reading up on tinytlf and one of the points the author made was that TLF was written by the InDesign guys. It was made to reproduce print on the web. At many points it was difficult to extend or modify which is why he wrote TinyTLF. Having worked with TLF it clicked one day and it is possible to extend and improve but it would take some work. The international parts are where it gets difficult for me. I'm familiar with typography (took classes on it) Ligitures, ascenders, descenders, etc but it's non en_us that I don't know where you would get training on this. How did the TLF engineers figure this out? Things like RTL, LTR, hebrew, japanese vertical. What tests can you run to verify that what you do won't break it? Mustella? I think there needs to be an effort to make it work with across browsers. We need a team on this. I think maybe we should start a #pixelperfecttext project. It could take a year to fully research and then start to convert over into the browsers. Maybe Adobe could see value in translating TLF to HTML5. That's from my perspective. Someone else might be more optimistic. If we could get the font outlines, do the measurements and then draw out the fonts on a canvas, webgl layer, svg or something similar we could probably start there. I've done some work exporting to SVG and FXG and I was able to export nearly pixel perfect SVG text but it was simple text formatting. Like Harbs said, there are: 1. canvas 2d context 2. webgl 3. svg 4. dom One possible simple hack is writing to the dom and then doing a pixel comparison. See how much the difference is and then adjusting for that in css. In one case I found a value that I needed to multiply by to get the text to line up. I then applied a margin-top:-3px; and the text lined up. It was something like fontsize*thisvalue but it didn't always work the math was off a bit. If we talked to the browser manufacturers we might be able to find out how they are handling positioning text. Maybe they could add a mode that matches FTE? In my opinion SVG would be the best but from what I've read there are some things it doesn't quite support. On Thursday, November 5, 2015, Harbs <harbs.li...@gmail.com> wrote: > I’m planning on trying to make txtjs work for me. I like the fact that it > has complete control of font loading, and text effects is an important > feature for me. > > It would be an interesting exercise to compare performance of the various > rendering methods. txtjs has some performance testing, and it works OK, but > based on my preliminary testing, performance on old tablet devices starts > to break down with a lot of text. > > Either way, I have a lot of work before me before I really get into the > nitty gritty of javascript text rendering… > > On Nov 5, 2015, at 6:05 PM, Alex Harui <aha...@adobe.com> wrote: > > > Thanks Harbs. > > > > That’s a really great set of information. It is one reason we are trying > > not to lock FlexJS to any particular text rendering mechanism. Can you > > tell us more about which choice you are going to make for your apps? > > > > -Alex > > > > On 11/5/15, 5:06 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > > >> There’s two parts to performance. With Flash TLF, the bottleneck is > >> really in the TLF code. The FTE composition is pretty low level. With > JS, > >> everything is going to be high level. It remains to be seen how the > >> performance of the FTE part will be in javascript. Of course, there’s > the > >> chance that things can be improved in TLF as well. > >> > >> Anyway, as far as rendering of text goes, there’s 4 options that I know > >> of: > >> 1. Native DOM > >> 2. DOM manipulation > >> 3. SVG manipulation > >> 4. Canvas manipulation > >> > >> Each approach has pros and cons. > >> > >> 1: > >> For at least 90% of use cases, native DOM should be fine. By native DOM, > >> I mean simple HTML markup inside a div using standard CSS for > formatting. > >> Some edge cases might need a bit of javascript for browser differences, > >> but by-and-large, you get good optimized internationalized rendering of > >> text out the box. This is fine for any text which does not need to be > >> pixel perfect and some text reflow is okay. This should include: labels, > >> basic text areas, normal item renderers, etc. AFAIK, standard DOM text > >> falls short in two/three applications. One is text with effects. While > >> it’s possible to apply simple effects to DOM text, you do not have the > >> level that we’re used to in Flesh. To get really fancy, you need Canvas. > >> The second issue is text which must render in a completely predictable > >> way. Text scaling is a no-no, text reflow is a no-no, and lines must > >> always break in exactly the same place. The third quasy-case is text in > >> the context of SVG and Canvas. standard DOM can be very hard to sandwich > >> between such elements. > >> > >> 2: > >> Problem 2 can be solved by breaking text into tiny span elements (on the > >> character or word level) and position these spans using absolute > >> positioning. This approach is used by Google Docs and works pretty well. > >> It has the same problem vis a vis text effects as approach #1. > >> > >> Both approach 1 and 2 require using standard web fonts which can be an > >> advantage or a disadvantage. It’s pretty hard to know if web fonts are > >> available — especially if you are dealing with unknown fonts. > >> > >> 3. > >> Using SVG fonts and breaking characters/words into separate SVG elements > >> has a lot of similarities to approach #2 with the exception of SVG fonts > >> (maybe?) Apple’s Pages app uses this approach > >> > >> 3.5: > >> It’s probably possible to break fonts down into paths and draw the paths > >> using SVG as well. > >> > >> 4: > >> Probably the best illustration of this approach is txtjs[1]. Font > loading > >> is an interesting problem and ted solved it in an interesting way... > >> > >> If we could abstract the rendering using these different methods, they > >> could theoretically be “hot-swappable”. > >> > >> [1]http://txtjs.com > >> > >> On Nov 2, 2015, at 6:31 PM, Alex Harui <aha...@adobe.com> wrote: > >> > >>> Renaming the thread to see if we can get more opinions.. > >>> > >>> There is some evidence that “hot” JS code runs better than “hot” AS > >>> code. > >>> So one consideration is the coding patterns themselves. That’s why > >>> FlexJS > >>> prefers composition over subclassing, so shared code lives in one place > >>> so > >>> it can get “hotter”. > >>> > >>> I don’t know what your “must haves” are. It sounds like there isn’t a > >>> “ready-to-go” JS candidate yet. If the opentype project is > >>> well-written, > >>> so that whatever GSUB and GPOS is can be swapped out and upgraded or > >>> plugged-in later, then that might be the right starting point. > >>> > >>> TLF as we know is a beast. I dumped the list of Flash classes it uses > >>> and > >>> posted it below. It may not be too big a project to emulate most of > >>> these > >>> classes or comment out temporarily the sections of code that rely on > >>> some > >>> of these classes. For example, faking up the event classes is easy. > >>> Commenting out the use of stage and accessibility shouldn’t break tons > >>> of > >>> stuff. So I think it does come down to abstracting out TextLine and > the > >>> other FTE classes, and I don’t know how hard that is. > >>> > >>> Another data point is that I still foresee the need for better > “mocking” > >>> of HTML in AS. If the FlexJS workflow, where you run your app in SWF > >>> form > >>> to get most of the bugs out (because of the verifier and better > >>> integration between debuggers and IDEs) remains the preferred workflow, > >>> folks will eventually have chunks of “rich text” in the form of HTML > >>> they > >>> will want to see in the SWF version, and having a reasonable rendering > >>> of > >>> HTML will become more important. TextField can so some things, > >>> TextLine/TLF can do more, but it might be important to put together an > >>> HTML rendering library. If I were to somehow find the time, I would > >>> also > >>> use a plug-in architecture so that each HTML tag can be incrementally > >>> added over time. It is an interesting problem of “what are the > >>> fundamentals of the rendering engine such that each HTML tag is > >>> independent or loosely-coupled from the engine”. I prototyped > something > >>> like this years ago here: > >>> http://blogs.adobe.com/aharui/2008/01/html_and_flex_1.html > >>> > >>> The thing is: once you have AS code that places text widgets, then that > >>> code should give you consistent placement in JS once it is > >>> cross-compiled, > >>> assuming you can get consistent text metrics. > >>> > >>> So, I have no idea what recommendations to make yet, just providing > more > >>> information and thoughts. > >>> > >>> -Alex > >>> > >>> flash.accessibility:Accessibility > >>> flash.accessibility:AccessibilityImplementation > >>> flash.accessibility:AccessibilityProperties > >>> flash.desktop:Clipboard > >>> flash.desktop:ClipboardFormats > >>> flash.display:BitmapData > >>> flash.display:BlendMode > >>> flash.display:CapsStyle > >>> flash.display:DisplayObject > >>> flash.display:DisplayObjectContainer > >>> flash.display:Graphics > >>> flash.display:GraphicsPathCommand > >>> flash.display:GraphicsPathWinding > >>> flash.display:InteractiveObject > >>> flash.display:Loader > >>> flash.display:LoaderInfo > >>> flash.display:MovieClip > >>> flash.display:Shape > >>> flash.display:Sprite > >>> flash.display:Stage > >>> flash.errors:IllegalOperationError > >>> flash.events:ContextMenuEvent > >>> flash.events:ErrorEvent > >>> flash.events:Event > >>> flash.events:EventDispatcher > >>> flash.events:FocusEvent > >>> flash.events:IEventDispatcher > >>> flash.events:IMEEvent > >>> flash.events:IOErrorEvent > >>> flash.events:KeyboardEvent > >>> flash.events:MouseEvent > >>> flash.events:TextEvent > >>> flash.events:TimerEvent > >>> flash.geom:Matrix > >>> flash.geom:Point > >>> flash.geom:Rectangle > >>> flash.net:URLRequest > >>> flash.net:navigateToURL > >>> flash.system:Capabilities > >>> flash.system:IME > >>> flash.system:Security > >>> flash.system:System > >>> flash.text.engine:BreakOpportunity > >>> flash.text.engine:CFFHinting > >>> flash.text.engine:ContentElement > >>> flash.text.engine:DigitCase > >>> flash.text.engine:DigitWidth > >>> flash.text.engine:EastAsianJustifier > >>> flash.text.engine:ElementFormat > >>> flash.text.engine:FontDescription > >>> flash.text.engine:FontLookup > >>> flash.text.engine:FontMetrics > >>> flash.text.engine:FontPosture > >>> flash.text.engine:FontWeight > >>> flash.text.engine:GraphicElement > >>> flash.text.engine:GroupElement > >>> flash.text.engine:JustificationStyle > >>> flash.text.engine:Kerning > >>> flash.text.engine:LigatureLevel > >>> flash.text.engine:LineJustification > >>> flash.text.engine:RenderingMode > >>> flash.text.engine:SpaceJustifier > >>> flash.text.engine:TabAlignment > >>> flash.text.engine:TabStop > >>> flash.text.engine:TextBaseline > >>> flash.text.engine:TextBlock > >>> flash.text.engine:TextElement > >>> flash.text.engine:TextLine > >>> flash.text.engine:TextLineCreationResult > >>> flash.text.engine:TextLineValidity > >>> flash.text.engine:TextRotation > >>> flash.text.engine:TypographicCase > >>> flash.text.ime:CompositionAttributeRange > >>> flash.text.ime:IIMEClient > >>> flash.ui:ContextMenu > >>> flash.ui:ContextMenuClipboardItems > >>> flash.ui:Keyboard > >>> flash.ui:Mouse > >>> flash.ui:MouseCursor > >>> flash.ui:MouseCursorData > >>> flash.utils:Dictionary > >>> flash.utils:Timer > >>> flash.utils:getDefinitionByName > >>> flash.utils:getQualifiedClassName > >>> > >>> > >>> On 11/1/15, 11:34 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >>> > >>>> I don’t remember the list off-hand, but a lot is related to language > >>>> specific features. There’s also 3 or 4 levels of ligatures. There were > >>>> some features I wished it supported (maybe it was contextual > >>>> alternates?), but the OpenType support in general is not bad. There’s > >>>> definitely missing pieces in Japanese composition, but there’s also a > >>>> lot > >>>> of support. > >>>> > >>>> I think native browser support is pretty good, and for basic text > >>>> rendering you can probably fall back to default browser support and > for > >>>> text in FlexJS components that’s the way to go, but for pixel-perfect > >>>> composition, browser rendering of text is not going to cut it. > >>>> > >>>> There’s been some efforts to do some OpenType rendering using > >>>> Javascript, > >>>> most notably Bram Stein's work[1] There’s also opentype.js[2]. But, > >>>> everything that I’ve found which was done to date is really basic. Any > >>>> of > >>>> the more advanced OpenType features are not supported at all. Some > GSUB > >>>> support, but not even basic GPOS support, etc. > >>>> > >>>> It’s kind of scary how hard it’s going to be to really do text right > in > >>>> the browser. Getting even close to FTE is really hard. And I haven’t a > >>>> clue what performance is going to be like in JS. I would have to guess > >>>> that it’s going to be a sore point… > >>>> > >>>> [1]https://github.com/bramstein/opentype > >>>> [2]https://github.com/nodebox/opentype.js > >>>> > >>>> On Nov 2, 2015, at 3:07 AM, Alex Harui <aha...@adobe.com> wrote: > >>>> > >>>>> > >>>>> > >>>>> On 11/1/15, 10:26 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >>>>> > >>>>>> Not just RTL. There’s an awful lot of OpenType features that it > >>>>>> supports. > >>>>>> (Of course It would be great to support even more…) ;-) > >>>>> > >>>>> I wasn’t aware of that. What kinds of things and how do the browsers > >>>>> do > >>>>> it? > >>>>> > >>>>> -Alex > >>>>> > >>>> > >>> > >> > > > >
