That was an awesome list! Thanks. Just curious, can text layout end up affecting more than two lines back? I still think it boils down to rectangles on a path but the path may not be a straight horizontal line or always going left-to-right, and you sometimes have to go back a bit.
-Alex On 11/6/15, 1:46 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >> 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
