> > What isn’t clear to me is that there is something about text layout to be > “figured out”. I’m not convinced there is a “best practice” for text > layout that covers international, effects, character positioning that > isn’t on a horizontal line, etc. Many of the folks who worked on Adobe > InDesign came from Adobe/Aldus PageMaker and had learned a lot, probably > the hard way, about text layout. And while lots of those lessons were > carried over to InDesign and TLF, it isn’t clear that TLF is the best > possible implementation of text layout. Like you said it has some strange > concepts (at least to me) like Slugs and Parcels. Maybe traditional > type-setters used those concepts, maybe not.
I think the answer is “sort of”. Traditional typesetting did have slugs (which were basically pieces of lead). Not sure about parcels. The concept of slugs and parcels makes sense when you are dealing with the problems of typesetting. When I was studying it, it “clicked” for me. I’m not deep into it right now, so I’m not sure my explanation will be the best but basically it is designed to cover the following problems (and probably more): There needs to be a mechanism to fit variable blocks of text into a variable space which might have a height which is a moving target. This layout might need a second or third pass as well, so there needs to be a way of addressing that. There might be multiple levels of composition and an inner level might effect an outer level, and these composition changes must be collected in a logical manner. There needs to be a separation of the “real” text container and the “virtual” text containers. Parcels are the “virtual” containers. There is not necessarily a 1 to 1 relationship between parcels and containers, and parcels can be nested inside other parcels. There’s a great document in the InDesign SDK which explains text Wax. It’s highly recommended reading for anyone who wants to understand the concepts behind composition. The terms are a bit different, but the concepts are largely the same. > It isn’t clear the TLF truly > took into account the need to render HTML. Look at the struggles in > trying to implement Table support in TLF. TLF takes a very different approach than standard HTML. Standard type-settting is a very different paradigm. Personally, I relate to the classic approach better than the HTML approach. The advantage of FlexJS on the js side is that we can get classic HTML composition more-or-less for free. > I believe there is still a > performance issue related to the table work. The table work broke your patch to the problem (your patch was not applied to my code when I was working on tables), but the problem appears to have been introduced some time before Adobe donated the TLF code. Unfortunately, we do not have that history, so it’s hard to know exactly when/where it broke. My guess is that text is being marked as dirty too aggressively which is causing too many recursive composition calls, but I’m not sure. > Anyway, for FlexJS, the only thing I really want regarding text layout is > for the customer to have choices. There should be multiple text layout > SWCS that have various trade-offs along the lines that Harbs described. > We don’t want to require a particular text layout library. > > I still don’t understand why text layout isn’t a “simple” > rectangles-on-a-path problem. But that’s probably just me. Simple text layout is. Complex text layout is not. The basic theme of the problem with complex layout is that the “rectangles” are a moving target. Here’s some tough areas: 1. Paragraph composition. tex was probably the first text composition to implement a “paragraph” composer. The basic algorithm was published by Knuth and Plass[1]. This was implemented by other systems including InDesign (although the exact algorithm which InDesign uses is copyrighted). With multi-line compisition, an earlier line can be changed due to a later one. 2. Keeping accurate track of text damage is essential for efficient text composition. You do not want to recalculate more than necessary. 3. Even simple things like kerning makes the rectangles a moving target. 4. Hyphenation makes word rectangles a moving target. 5. Text wrap 6. non-rectangular text ares — The line width can change as text is composed. 7. Nested content: This can be tables nested inside text or even one text flow nested inside another. 8. Contextual GSUB replacements 9. Contextual GPOS 10. Some writing scripts have conditional reversal of glyph placement. (Devanagari has some really tough situations.) 11 bidi composition can get tough. Especially when you add neutral glyphs to the mess. 12 Asian composiiton has some complex spacing and line breaking rules 13 Asian composition has “text attached to text” in the form of Ruby and Kenten. 14 Vertical Japanese text. 15 Horizontal text within vertical Japanese text runs. This list was composed off the top of my head, so there’s probably some inaccuracies here and I’m probably missing issues, but it should give a general idea of the problems… [1]https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap
