Re: question

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

At 12:05 PM 8/11/00 +0200, you wrote:
>Arved,
>
>you are the master of Fop's architecture ;-) and I don't have enough 
>experience as a programmer to solve the following problem. The 
>method addText in class LineArea is a monster (more than 200 
>lines) and will get even bigger as soon as we have some 
>hyphenation capabilities or implement the glyph area. 
>I guess, we need some redesign. I thought about something like a 
>glyphArea class (which includes the fontstate, baseline information, 
>width etc.) and a word class, which is a vector of glyphAreas + 
>width. this class could also implement a hyphenation method and 
>return just parts of the word, if the full word doesn't fit into the rest of 
>line area and hyphenation is on. 
>But I see 2 problems with this approach: it generates quite an 
>amount of objects and it doesn't mix so good with the area tree, 
>because suddenly a line-area can have as children inline-areas, 
>glyphs and words. Maybe word class should inherit from inline-
>area? 
>Maybe you could look into this or give me some advice? 

Hi, Fotis

Just some preliminary thoughts.

I'm actually working on getting some high-level architectural documents out 
so we all have a good picture of stuff like this. I think we are at the 
stage where we must start accounting for writing modes, and different 
character sets, and so our understanding of areas has to be sound.

If you run XMLRenderer on a typical FO and view the generated XML, you'll 
note that words already are InlineAreas. That is, a sentence is a LineArea, 
and the children are InlineAreas and InlineSpaces. If we continue this then 
what we are really talking about is the implementation of hyphenation-aware 
InlineAreas.

There is probably some existing logic in LineArea.addText() which could 
really be in InlineArea, also.

You bring up another good point, which is that we must implement 
fo:character. In terms of some of the problems you mention, I am inevitably 
drawn to the Flyweight object structural pattern in Design Patterns, which 
actually uses characters as an example. For us, too, most of the state is 
intrinsic and I think Flyweight makes sense. I need to read it carefully, 
though.

My focus over the next month is going to be architectural support - 
uploading a bunch of design documents: diagrams, discussions, notes. In 
conjunction with that I think that we ought to create a number of "target" 
FO files that exercise all Basic/Extended area traits, so that we will have 
a focus for development. I hope to get a few of them uploaded this week. 
Maybe we can put them into docs/design/reference, or something like that.

It is also worth pointing out that I have been discussing (and am
continuing to 
discuss) what role implementors (FOP, RenderX, pdfTeX) can play in 
supporting the CR process. This is with the XSL WG.

I hope that in short order some mechanism will be 
established that allows us (all concerned) to submit FO files for review 
under the CR.
I will keep everyone informed. In connection with this I should point out
that 
just because we submit an FO file it does not mean that the implementation 
must yet format it into a correct area tree; this would be Stage 2. Just the 
FO files themselves are also of considerable value.

Finally, I have been tossing around the idea of doing up a simple 
AreaTreeRenderer back-end that draws up a CAD-style diagram of dimensioned 
and labelled rectangles, depicting the area tree resulting from an FO. The 
information it would operate on would be not much different from what 
XMLRenderer currently produces. If there is interest in this then I'll put 
some extra effort into it.

Arved

Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"