https://issues.apache.org/bugzilla/show_bug.cgi?id=32789
--- Comment #14 from Simon Pepping <spepp...@apache.org> 2010-02-12 19:48:16 UTC --- You touch many complicated points. I will try to give some hints regarding item 4) Move Arabic form shaping and BIDI algorithm to layout manager. Since I worked with this code a while ago, I go with what I remember. The relevant layout managers are lineLayoutManager and textLayoutManager. LineLM initiates the linebreaking algorithm. Input is the string, which is converted into boxes using font width info. Here the rl text must be presented in boxes in the proper order. In fully Arabic paragraphs this could be rl order, but then the breakpoints must be interpreted as breaks at the lhs. In mixed paragraphs lr order may be best, unless lhs breaks are again used. The algorithm itself is basically writing order agnostic. In LM.addAreas the areas for the words and lines are created. I suppose they contain the string to be rendered, so that the renderers can insert glyphs. The linebreaking algorithm needs to know pre-break, post-break and no-break pieces. In Western texts this is done using penalty widths. I think we did something with post-break pieces, but I do not remember precisely. You should find out whether the outcome of the linebreaking algorithm, esp. the stretch of a line, contains sufficient information for Arabic rendering. On further points: If we can use work done by ICU, then by all means let us do that. I am a bit confused about the options to use either ICU or OpenType font info. The latter is more focussed to that particular font, I would guess. But if ICU's string transformation does the trick for all fonts, we can use it. Most of all, let us go with a good solution. Better is the enemy of good. I would rather have a good solution than the best but not yet available solution. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
