Timelines

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

Hi, all (committers, actually)

With the year drawing to a close, I'd like to highlight the fact that we have
the XSL-FO CR period terminating at the end of February, and make a few
suggestions, that probably don't need to be voted on.

Number one, Fotis provided a gap analysis (I think against Basic conformance).
We should all revisit that, and try to plan our work accordingly. If you have a
separate area of expertise, like Keiron does with SVG, then this is not quite
relevant, but for the rest of us it would be cool if 75%+ of what we do is
devoted to FOP 1.0, which must be a Basic conformance release, at a minimum.
This is me in cheerleading mode. :-)

I don't want to propose a hard schedule for a FOP 1.0 release, but OTOH I think
we have got to start thinking about a target "month", plus or minus one. I'd
like to suggest that all the committers, and other developers, look at the gaps
and try to come up with an effort estimate. This will be a really rough
figure, I know, but it's something we can put on the table and sort of plan
with.

On a related note, I want to use the New Year to ramp up the energy, and I
propose to do that by having releases come out no less often than twice a
month, and possibly once a week, with release versioning driven by how much
has changed. I think this will help pump us up. I'm not suggesting that we've
slacked - I'm really impressed by the last 6 months - but why not notch it up?
:-)

I'd like to get as much comment as possible from committers and developers and
users about where and how you think FOP should be headed in the next 6 months.

Also - this is my final plug - let's try to really beef up our examples. I
think that not all of the examples necessarily have to be ones that FOP handles
properly - yet - but it would be cool if we had test FO files that cover
everything that FOP 1.0 should be able to do. We could put those into a "dev-FO"
directory, perhaps, and as FOP matures to handle them, they could migrate over
into straightforward examples. Contributions from all are welcome.

Enough of the rah-rah for now. :-) Hope everyone had good holidays, and best
wishes for the upcoming New Year.

Regards,
Arved Sandstrom

5.3.2 Margin, Space, and Indent Properties

["Peter B. West" <pb...@powerup.com.au>]

The above section seems to define the relationship between, say,
end-indent and padding/border/space-end shown in the diagram
RectsForModel.gif in 4.4.1 Stacked Block-areas.  I.e., end-indent =
padding-end + border-end + space-end, where, according to 5.3.2,
space-end has a corresponding margin property.  5.3.2 has
end-indent = margin-corresponding + padding-end + border-end-width

What does this do to the following announcement in 4.4.1?

   1. For each block-area B which is a descendant of P, the following
hold
      ....
    * the end-edge of its allocation-rectangle is parallel to the
end-edge
      of the content-rectangle of R, and offset from it inward by a
      distance equal to the block-area's end-indent plus its
      end-intrusion-adjustment (as defined below), minus its border-end,
      padding-end, and space-end value

Isn't that saying, "...a distance equal to the block-area's end-indent
plus its end-intrusion-adjustment minus its end-indent"?  That's what
the diagram seemed to indicate when I first read 4.4.1, and now, having
just read 5.3.2 (I'm a slow reader of specifications) that initial
impression is confirmed.  What am I missing?

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

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

Re: Timelines

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

At 12:11 PM 12/27/00 +0100, Fotis Jannidis wrote:
>
>The work which has to be done for the Fop 1.0 release includes 
>changing the basic layout classes to really implement all rules and 
>constraints of stacking blocks and line areas, p.e. handling of 
>reference areas (Karen has pointed out these problems). 

Yes, I recall Karen mentioning this. This is a good point, one I missed - we 
want to really tighten up on the nuts and bolts. I remember someone in the 
last few weeks complaining that our line-stacking strategy was unclear, 
which is likely true, for example. I believe Karen also mentioned that this 
includes making sure that areas at all levels of the hierarchy have the 
traits that they are supposed to have, and that all areas actually fill 
well-understood positions in a well-understood hierarchy.

This all goes hand-in-hand with improved commenting aimed at understanding 
what current variables and methods do. I don't know about anyone else, but 
in some source files I am a bit nervous about changing some instance 
variables because I'm not absolutely positive on what they represent.

IMO we also need to do region-start and region-end. Having left and right 
margins is pretty important. Let's face it, all of the 4 outside regions are 
Extended, so if we have 2 of them, why not all 4. If we are reviewing layout 
anyhow, then this is the right time to make adjustments for region-start and 
region-end.

Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia