Maintenance release

["J.Pietschmann" <j3...@yahoo.de>]

Hi all,
we should think about getting 0.20.5 out of the door.
Yes, I know I'm behind with the doc, I really promise to
get it ready this weekend...

As for the Bugs to be fixed, what should get in?
Choices:
1. Improved DocBook compatiblity
- linefeed-treatment (easy)
- recognise percentages in table column width (dunno)
- recognize font-family selections (though I thought
   Olegs patch for this has been committed...)
- use text-align-last for last lines and lines
   forced by LF (medium, perhaps easy
2. Some easy niceties:
- move leader geneartion to LineArea.align() for
   properly stretched leaders
   (should be easy, needs a new LeaderArea)
- redo LineArea.align in case there was an
   unresolved page-number-citation before rendering
   (or do this generally just before rendering)
   (should be easy, perhaps at the cost of a pointer
   more in LineArea)
- proper text decoration and links for
   page-number-citations (very easy)
3. Harder stuff
- Links for non-text inlines(tried and failed: the
   link was misplaced, I think I know why but may still
   need some time)
- Links in static content (no idea)
4. Reduced memory consumption by lazy creation of the
   children vector and moving all instance variables
   of FONode to FObj (reduced size of FOText).
5. Add automatic build of FOPServlet (with the correct
   web.xml) and autodetection and -fix for Java 1.4.

Additions? Preferences?

J.Pietschmann


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

Re: Maintenance release

["J.Pietschmann" <j3...@yahoo.de>]

Christian Geisert wrote:
> Another docbook incombatibility are ids on page-sequences (bug #635)

O well, this is *really* hard to fix in general. Actually,
I think ids on page-sequences and flows should be outlawed.
Can anybody tell me what's the area the id should be attached
to if the first page is forced to be a blank? Apart from this,
I still don't know how to pass down the id to a point where
an area is generated conveniently.

>  > - redo LineArea.align in case there was an
>  >   unresolved page-number-citation before rendering
> If it's no big deal..
It's not a big deal to move the method call. I worry about
unintended side effects...

>  > 5. Add automatic build of FOPServlet (with the correct
>  >   web.xml) and autodetection and -fix for Java 1.4.
> 
> Does the stuff in contrib/servlet not work?
Contrib/servlet is not distributed, instead, the Java source
and a war file is in docs/examples/embedding. The war file
in the current distribution has still an old invalid web.xml
in it.

> Timeframe?
Yesterday, as usual :-)

J.Pietschmann



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

Re: Maintenance release

[Christian Geisert <ch...@isu-gmbh.de>]

J.Pietschmann schrieb:
 > Hi all,

[Yes I'm a bit late..]

 > we should think about getting 0.20.5 out of the door.
 > Yes, I know I'm behind with the doc, I really promise to
 > get it ready this weekend...

;-)

 > As for the Bugs to be fixed, what should get in?
 > Choices:
 > 1. Improved DocBook compatiblity
 > - linefeed-treatment (easy)
 > - recognise percentages in table column width (dunno)
 > - recognize font-family selections (though I thought
 >   Olegs patch for this has been committed...)
 > - use text-align-last for last lines and lines
 >   forced by LF (medium, perhaps easy

Improved DocBook compatibility would be a good thing
(speaking as a occasional docbook-apps-digest reader)

Another docbook incombatibility are ids on page-sequences (bug #635)
My plan was to have a look at this and then work on ids in MAIN
(but meanwhile I've seen a commit from Keiron here..)

 > 2. Some easy niceties:
 > - move leader geneartion to LineArea.align() for
 >   properly stretched leaders
 >   (should be easy, needs a new LeaderArea)
 > - redo LineArea.align in case there was an
 >   unresolved page-number-citation before rendering
 >   (or do this generally just before rendering)
 >   (should be easy, perhaps at the cost of a pointer
 >   more in LineArea)

If it's no big deal..

 > - proper text decoration and links for
 >   page-number-citations (very easy)
 > 3. Harder stuff
 > - Links for non-text inlines(tried and failed: the
 >   link was misplaced, I think I know why but may still
 >   need some time)

IMHO not that important

 > - Links in static content (no idea)

I think Arved volunteered here ;-)

And there's still the problem with the hotspot offset..

 > 4. Reduced memory consumption by lazy creation of the
 >   children vector and moving all instance variables
 >   of FONode to FObj (reduced size of FOText).

IMHO low priority

 > 5. Add automatic build of FOPServlet (with the correct
 >   web.xml) and autodetection and -fix for Java 1.4.

Does the stuff in contrib/servlet not work?

 > Additions? Preferences?

I think it's important get the documentation done with forrest
(add information about development direction, patchqueue,
CheckStyle etc.)

-check uncommitted patches
I'll try to do that on the weekend

-problem with basedir
soething with null, I will look at this

-Jar updates
there a new versions of xalan/xerces/batik

Timeframe?


Christian



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

Re: Maintenance release: improvements to basic-link

[Karen Lease <kl...@club-internet.fr>]

Hi all,

I haven't seen anything about the next maintenance release for about a 
week now, but I noticed that there had been some discussion about 
basic-link problems.
In the meantime, I have improved the basic-link positioning and also 
made it work for external-graphic and foreign-inline-object, since I 
needed it for a project at work. It now works correctly when links are 
inside blocks and tables with before and/or after padding and borders; 
it also works inside list items in tables. The X positioning is corrected.
Nothing else seems to be broken. :-)

I've also changed the default behavior to make all the words into a 
single link rectangle; the current behavior can be forced by defining 
the system property "links.merge" to "no".

If there are no objections, I will commit this to the maintenance branch.

-Karen

J.Pietschmann wrote:

> Hi all,
> we should think about getting 0.20.5 out of the door.
> Yes, I know I'm behind with the doc, I really promise to
> get it ready this weekend...
> 
> As for the Bugs to be fixed, what should get in?
> Choices:
<SNIP/>
> 3. Harder stuff
> - Links for non-text inlines(tried and failed: the
>   link was misplaced, I think I know why but may still
>   need some time)
> - Links in static content (no idea)
<SNIP/>
> J.Pietschmann
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
> 
> 



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

RE: Maintenance release

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

> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: August 24, 2002 3:09 PM
> To: fop-dev@xml.apache.org
> Subject: Re: Maintenance release
>
> Arved Sandstrom wrote:
> >>- Links in static content (no idea)
> > What is the main problem here? That is, provide me some context and I'll
> > take a look at it. :-)
>
> Area offsets seems to be incorrectly applied, which can mean
> not applied at all or applied multiple times. There is a bug
> pending in bugzilla for this, including a demo file.
> In general, the code has problems if there are some oddly
> nested areas with reference areas (tables) and lists mixed
> in. (Each time I look at it, I wonder why it works at all :-)
>
> One of the interesting problems is that areas are stacked
> and absolute coordinates are computed only immediately before
> rendering, while link rectangles get some absolute coordinates
> which are corrected by some obscure offsets which represent
> more or less relative placements of the area to the parent
> before rendering. This is really confusing. I would have
> thought areas are either placed absolutely (block-container)
> or relative to the parent, and restacking would mean recomputing
> the placement offsets (admittedly more complicated than just
> changing the size).

OK, I'll look at this and see what might be the best approach. I think
probably a return to first principles - a complete rework - might be best.
The basic-link code (originally simple-link code) goes back a long way - it
started with code I wrote that James Tauber committed, and it was based on a
much smaller codebase. We were basically happy to have any PDF hyperlink
capability at all. It would be fair to say that assumptions that made sense
when the original code was written no longer hold; unfortunately later code
has probably overlaid the original. It's better to start from scratch.

Regards,
Arved


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

Re: Maintenance release

["J.Pietschmann" <j3...@yahoo.de>]

Arved Sandstrom wrote:
>>- Links in static content (no idea)
> What is the main problem here? That is, provide me some context and I'll
> take a look at it. :-)

Area offsets seems to be incorrectly applied, which can mean
not applied at all or applied multiple times. There is a bug
pending in bugzilla for this, including a demo file.
In general, the code has problems if there are some oddly
nested areas with reference areas (tables) and lists mixed
in. (Each time I look at it, I wonder why it works at all :-)

One of the interesting problems is that areas are stacked
and absolute coordinates are computed only immediately before
rendering, while link rectangles get some absolute coordinates
which are corrected by some obscure offsets which represent
more or less relative placements of the area to the parent
before rendering. This is really confusing. I would have
thought areas are either placed absolutely (block-container)
or relative to the parent, and restacking would mean recomputing
the placement offsets (admittedly more complicated than just
changing the size).

BTW does someone know why the weekly bug report is no longer
posted to the list? It was a bit more usable than the bugzilla
report when ticking off bugs to fix (or already fixed).

J.Pietschmann


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

RE: Maintenance release

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

> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: August 23, 2002 5:16 PM
> To: fop dev
> Subject: Maintenance release
>
[ SNIP ]
> - Links in static content (no idea)
[ SNIP ]

What is the main problem here? That is, provide me some context and I'll
take a look at it. :-)

Regards,
Arved


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