DO NOT REPLY [Bug 37579] footnotes within tables and listsl get lost

2008-05-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579





--- Comment #49 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-05-27 
14:01:26 PST ---
(In reply to comment #48)
> 
> AFAIU the reason why FootnoteBodyLM is re-parented is that it put its areas at
> the right place (as children of the footnote-reference-area, instead of the
> block containing the footnote). Simply moving the setParent call after the 
> call
> to getNextKnuthElements makes the warnings disappear, and doesn't break any
> test.
> Confirmation from specialists of this part of the code would be appreciated 
> ;-)

Seems reasonable to me. Cleaner than overriding getParent() anyway.

In the meantime, I've also been playing with adding an interface
FootnoteCitationHolder. Such an interface could then be implemented by
KnuthBlockBox and ActiveCell. The interface methods can be used by
LineLayoutManager, PageBreaker, ListItemLayoutManager, TableStepper...

The methods would roughly be:
hasAnchors()
getFootnoteBodyLMs()
addFootnotes(List)
addFootnotes(FootnoteCitationHolder)
addFootnote(FootnoteCitationHolder.Citation)
expandFootnotes(LayoutManager, LayoutContext, int)

While this would still leave the related portions of code distributed over
those classes, the interface makes it a bit easier to locate them in an IDE,
and makes those pieces of code a bit more uniform.

Most of the loops we see now, would move to KnuthBlockBox, as the only complete
implementation. ActiveCell would only implement what is needed to make the
citations accessible to the box created by TableStepper. Slight compromise in
comparison to the last patch is that, in the iteration over the active cells,
we would only create a temporary list with those having citations. If the list
is empty, we create a regular box. If not, then we iterate over that temporary
list of cells, and instruct the created KnuthBlockBox to add the citations from
those cells. The same pattern can be used by ListItemLayoutManager:

- create a temporary list of FootnoteCitationHolders for which hasAnchors()
returns true
- if non-empty, iterate over that temporary list
- for each element, ask the higher level FootnoteCitationHolder (KnuthBlockBox)
to extract the citations, and add them to its own list.

I'll see if I can attach a patch to demonstrate one of these days.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.


Re: ZapfDingbats and Symbol not found whereas they are not needed

2008-05-27 Thread Max Berger

Andreas,

indeed. To support proper character auto-selection I've modified the  
default to include the symbol and zapf-dingbats fonts, as they contain  
many characters normally not found in the default fonts.


I hope I'll have time to continue this work soon (can't promise  
anything atm)


Max

Am 27.05.2008 um 17:23 schrieb Andreas Delmelle:


On May 27, 2008, at 17:05, Vincent Hennebert wrote:


If I run FOP Trunk on the attached FO file, I get the two following
warnings:
WARNING: Font "Symbol,normal,700" not found. Substituting with  
"Symbol,normal,400".
WARNING: Font "ZapfDingbats,normal,700" not found. Substituting  
with "ZapfDingbats,normal,400".


Seems to be a result of Max changing the default value for the font- 
family property (see r655281)


Cheers

Andreas