On Sun, 11 Jul 2010 11:03:05 +0300 Tom Hacohen <tom.haco...@partner.samsung.com> said:
woo. bidi/shaping... languages i just don't know. so i can't comment there. :) but as for your content... where do you want paragrpahs? as such textblock has 3 layers. 1. markup <-> format/text node abstract collection. this simply takes the markup or nodes AS IS and "parses" for you. for format stuff it handles conversion/mapping to and from the textblock style. any form,at string is looked up in in the style table and converted to/from that mapped string and then stuck in the nodes ro taken out. it also will take text and look for &escape; - ie html-like escaping of things like < etc. when producing text nodes (and do the reverse coming out). i don't see that this needs to change as its really a 1:1 mapping to and from markup. it's also an optional api and the programmer can drop down to the direct node api when doing things like an entry box etc. 2. nodes <-> layout - THIS is i think where you want your changes to go. it's entirely internal and up to evas textblock to do whatever makes sense here. this is where you want more layers than are there now. right now it's a list of lines and lines have items going from left to right. this is where you want to now have a list of paragraphs - right? and a paragraph is a list of lines where each is a list of items etc. - what each item is and its formatting style (font, size, bold, text content, location etc.) is determined by the layout code logic. there is a reverse mapping kept here so given any layout item or line you can map back to the format node it came from or text node + offset. so it is #2 that you want to rip around the guts of - right? (that'd be the right place to do it). > Hey all, > > As some of you know, I'm working on adding complete BiDi, Hebrew and > Arabic support to EFL; While working on the textblock object I noticed > the current internal design does not play nicely with BiDi. > > Here are a couple of examples showing exactly that: > (I will mark RTL text with Latin capital letters and won't handle > internal text reordering in these examples, just to keep everything > simple). > 1. Consider the text "BOLD REG1 REG2", it should be drawn like this: > "REG2 REG1 BOLD" but it will draw like this: "BOLD REG2 REG1" because > the current algorithm splits the text according to formatting. One could > suggest to just reorder the items for display when creating them, but > then a second problem arises: > 2. In this example I will use Markup for better clarity, again, capital > letters mean RTL regular mean LTR. Consider the text: > "<b>text1 TEXT2</b> TEXT3 TEXT4" normally, it should be drawn like this: > "<b>text1</b> TEXT4 TEXT3 <b>TEXT2</b>" but it will draw like this: > "<b>text1 TEXT2</b> TEXT4 TEXT3". This can also be solved by splitting > nodes to text runs (direction changes should break runs), but this is no > simple deal, as we'll have to copy the text, process it per paragraph > (as this is how BiDi handling works) decide the order, and then work > hard to create visual items from it. This is far from fast/clean. > > I suggest a different solution, I think we should keep the general ideas > used in the current textblock's internals, but instead of splitting to > nodes to FORMAT|TEXT|FORMAT|TEXT (i.e format delimited splitting) I > suggest we split to paragraphs (which also helps BiDi handling) and use > a chain of format nodes to point to different positions in each > paragraph. This will let us manage BiDi text easily, while maintaining > speed and simplicity. > Apart from helping with BiDi handling, I think this design is more > suitable because it is content oriented and not format oriented, and > languages are all about content. > > I wrote this e-mail with the assumption the recipients (or at least the > ones that will care to read it) know textblock object's internals and > are familiar with the issues of handling BiDi text, so I may have left > some things unclear. Please feel free to ask for clarifications or > additional info/background where you see fit. > > Waiting to hear your thoughts, > Tom. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
