bidi wiki

[Victor Mote <vi...@outfitr.com>]

Oleg:

I just added a comment on your bidi wiki, in the "Reordering the text"
section, regarding the line-by-line nature of reordering Middle-Eastern
language text. This is something you no doubt already know, but was not
clear to me until recently, and it may be helpful. The comments might be
expanded to a more general statement by someone who knows more.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: bidi wiki

[Victor Mote <vi...@outfitr.com>]

Oleg Tkachenko wrote:

> elaborate it further in implementation section. My problem is
> that I still
> doesn't have clear bidi implementation design in my mind, moreover the
> processing model as described in the spec sounds too quirky to
> me, all that
> fo-tree manipulation and directionality explicitiveness confuses
> me because I
> was grown on a principle that text must always be preserved in
> logical order
> up to the latest stage - rendering. And all bidi processing
> should be done by
> *renderer*, btw AWT renderer, which is bidi-aware on its own does render
> Hebrew ok even in the branch code!

Wow -- I have never read through that section of the standard before. I am
surprised that they require actually changing the FO tree. It also seems
that this is another case where our layout-before-knowing-context model
bites us. We don't really have a "refinement" stage in our model. The only
other place where I have felt like I needed one is text-transform. Using the
work that you did as a starting place, I was able to sneak text-transform
functionality in as part of the FOText object constructor (this was in the
branch, and I haven't had a chance to bring it over to the trunk). This was
the /only/ place after seeing the input and before it was getting laid out
in lines. The reason the refinement stage is important is because some of
these things require a knowledge of the context. I implemented
text-transform by looking at only preceding text in the same block, but was
worried that we would find some aspect of text-transform that needed to know
what came after -- if so, there is no clean way to handle it. It seems like
this might fall into that same category.

As far as whether reordering should get done at layout or rendering time, I
think that the standard lumps these two concepts, distinct to us, into one
super-concept that they call formatting. So (and I may be wrong) it seems
that you are free to implement that in the renderers. If I understood the
standard, we just need to slide the appropriate Unicode bidi codes into the
text during the formatting stage that effectively implement the net effect
all of the directionality information. I think you are right that any text
reordering must be done by the renderers (or perhaps the RenderingContext
that has been discussed in another thread). Not just AWT, but probably PDF,
now or in the future, will handle the reordering. Its search routines need
to have the text in logical order as well.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: bidi wiki

[Oleg Tkachenko <ol...@multiconn.com>]

Victor Mote wrote:

> I just added a comment on your bidi wiki, in the "Reordering the text"
> section, regarding the line-by-line nature of reordering Middle-Eastern
> language text. This is something you no doubt already know, but was not
> clear to me until recently, and it may be helpful.
Well done, Victor. I just forgot to mention it as it's obvious to me :)

> The comments might be
> expanded to a more general statement by someone who knows more.
I have generalized it a little bit, I think it's enough for a while. We'll 
elaborate it further in implementation section. My problem is that I still 
doesn't have clear bidi implementation design in my mind, moreover the 
processing model as described in the spec sounds too quirky to me, all that 
fo-tree manipulation and directionality explicitiveness confuses me because I 
was grown on a principle that text must always be preserved in logical order 
up to the latest stage - rendering. And all bidi processing should be done by 
*renderer*, btw AWT renderer, which is bidi-aware on its own does render 
Hebrew ok even in the branch code!

-- 
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org