Yup. Pixel perfect text layout is the kicker. There’s currently three approaches to this problem that I know of:
1) Google Docs separates words (and sometimes letters) into separate divs and places each div separately. Selection rectangles and cursors are separate divs that are imposed over the text. 2) Apple Pages uses a similar approach, but the text atoms are broken down into separate SVG text objects rather than divs. 3) Other companies (plural? I’ve only found one public available example) use an approach of writing the text to Canvas (and custom handling of selections, etc.) Any one of these three approaches requires writing a text engine from scratch and the effort is probably measured in man-years. This is why there are so few examples of HTML apps with decent text handling and rendering (beyond the simple embeddable text editor widgets). An open source HTML text engine would be awesome, but I don’t see anyone with the funds stepping forward. TLF might be a good platform for interacting with that engine. (i.e. the engine would interface similar to how the FTE interfaces with TLF. But my gut tells me that it might be easier to redo TLF from scratch specifically for HTML possibly modeling it after the original TLF. Parts of TLF have become very hard to follow. Especially things like selections could probably use a redo. On Aug 28, 2014, at 6:13 PM, Joel Marks <j...@workiva.com> wrote: > Thanks for the reply Mike. Sorry I didn't realize how well documented the > "open source parts of Flash" argument is. > > Applications that rely on pixel perfect text layout can not use the browser > DOM because most everything in the browser world it is dependent on what > browser and OS you use. This has led companies like Prezi, who is trying > to get off FP, to use Emscripten for HarfBuzz in the browser then they > completely wrote their own paragraph layout engine. > > > On Wed, Aug 27, 2014 at 6:13 PM, Michael A. Labriola < > labri...@digitalprimates.net> wrote: > >>> Long story short we are trying to do what the Flash Player does outside >> of Flash. We have seen other companies have success using Emscripten and >> asm.js so if Adobe could open source parts of the Flash Player then we >> could get some of the Flash Player functionality in javascript. FTE and the >> Core Text Services C library (documentation < >> http://www.adobe.com/cn/devnet/flash/articles/tlf-overview.html>) inside >> of the Flash Player are of particular interest to me and anyone else that >> was using TLF in their Flex application. This also has potential of making >> the effort for Flex JS easier. >> >> Joel, >> >> I am not going to address the why won't adobe open source flash part of >> this, there are too many threads on that in this forum to count already. >> However, just want to point out that a lot of what FTE was trying to >> accomplish is bringing the rendering capabilities of the browser into Flash >> Player. So, porting something that does browser rendering in the player >> back to the browser is a bit circular if not redundant. We have found that >> everything FTE could do is generally available, faster and easier in the >> browser DOM today. This isn’t a comment on Flex versus JS in general, just >> on text rendering. >> >> Just something to think about, >> Mike >> >> >>
