Re: [VOTE] Properties API

[Peter B. West]

Victor Mote wrote:
Peter B. West wrote:
...

The topic at hand is what API is needed for the FO Tree to be able to pass
property values to its clients.
Ok.  The trouble is that the relationship between FO Tree and Area Tree 
is, for me, still very much an unresolved question.  When we start 
talking about these things, I go back to thinking about the details of 
the interaction between FO Nodes and Areas in the Area Tree.

Isn't part of your rationale in this "get" method to provide for the 
feedback of FO data to the Areas?  At what points do you see the method 
being invoked?

1) markers
I have a pretty well-developed idea of how to implement the FO tree
building side of this in alt.design.  It involves
static-content-specific changes to the current FO tree building
algorithm, and a slight generalization of the SyncedFoXmlEventsBuffer
class to allow events to be read from a variety of sources.  In a word,
grafting.


OK, I have addressed this.

We do have very different grafting methodologies.


2) Area tree dependencies for FO expressions.  Basically, length
calculations involving percentages.


OK, I proposed passing the relevant Area to the "get" method.
Is this happening when an area is looking for information about its 
generating FO?

2a) Handling the expressions.


This can all be done within the FO Tree.

But, if I understand you correctly, only with reference to the Area Tree 
(via the passing of Area parameters in the "get" method.)

2b) Designing the interaction between the FO builder and the Area tree
builder.


OK. I proposed the following, which you have not addressed:


Your experience and insight on this issue are extremely important. If Areas
know how to find their FOTree heritage as well as their AreaTree heritage,
can you think of any concept that is missing to do Property resolution,
assuming that the relevant Area is passed to the "get" method on the FOTree
side?

This seems to me to be begging the question to some extent.  Rather than 
the Areas knowing how to find their FOTree heritage, isn't it necessary 
for the FOs to be able to find the AreaTree ancestry of the Areas that 
the FOs are generating?  Isn't that what passing the relevant area in 
the "get" is all about?  At the same time, however, it does get us 
thinking about the precise nature of this interaction.


3) Layout look-ahead and backtracking.  Closely related to 2b.


AFACT, these would become simply re-"get"ting the value from the FO Tree,
passing a new Area as a parameter.

4) Managing the association out-of-line areas (footnotes and floats)
with the FONode/Area in which it was defined and the higher-level areas
(e.g.  before-float-reference-area, footnote-reference-area,
main-reference-area) which are juggled as a result of the lower-level
contents.


Is this not just a specialized case for the general case #2 above?
Very specialized.  These things can force re-layout of the existing 
page, and can even ramify to previous pages, as we move towards a more 
"intelligent" layout strategy.  There are two problematical aspects:

Layout look-ahead, to determine layout "errors" (e.g. footnote overflow, 
last page), and

Layout lookahead to determine actual dimensions ("auto" table layout.)

Peter
--
Peter B. West 

Re: [VOTE] Properties API

[Peter B. West]

J.Pietschmann wrote:
Footnotes are basically float-after areas. Both float before and footnotes
are not much of a problem except for multi column layout (and, well, in
tables). In multi-column layouts, the equal width of the column should
allow reassigning content after decreasing column height without doing a
complete re-layout.
Side floats, of course, are a real pain, especially if you want to do
conflict resolution properly.
I'm still attached to my proposed footnote processing method as 
described in the alt.design notes.
http://xml.apache.org/fop/design/alt.design/footnotes.html

I'm looking at extending it to cope with footnotes in tables within columns.

Peter
--
Peter B. West 

Re: FOP logo update

[Clay Leeds]

Victor Mote wrote:
Clay Leeds wrote:

I was unable to make much progress on this topic. I am unable to get
SVG and/or vector versions of the logo. We do, however, have a JPG
version.
Thanks for your efforts here. I'll work on creating an svg version.
I just checked in src/documentation/resources/images/logo2.svg, which is the
first pass at an svg version of the new logo. Please let me know if you have
any comments, even if you think that it is OK as is. I know some wanted to
tweak it, and this is probably not a perfect image of the original design
anyway. Also, does it make sense to check in the Adobe Illustrator file that
was used to create it? That might make editing it easier.
Victor Mote
I think it makes sense to check in the Illustrator file used to create 
the file. I'll check it out and let you know what I think.

Web Maestro Clay

Re: [VOTE] Properties API

[J.Pietschmann]

Peter B. West wrote:
4) Managing the association out-of-line areas (footnotes and floats) 
with the FONode/Area in which it was defined and the higher-level areas 
(e.g.  before-float-reference-area, footnote-reference-area, 
main-reference-area) which are juggled as a result of the lower-level 
contents.
Footnotes are basically float-after areas. Both float before and footnotes
are not much of a problem except for multi column layout (and, well, in
tables). In multi-column layouts, the equal width of the column should
allow reassigning content after decreasing column height without doing a
complete re-layout.
Side floats, of course, are a real pain, especially if you want to do
conflict resolution properly.
J.Pietschmann

RE: FOP logo update

[Victor Mote]

Victor Mote wrote:

> Clay Leeds wrote:
>
> > I was unable to make much progress on this topic. I am unable to get
> > SVG and/or vector versions of the logo. We do, however, have a JPG
> > version.
>
> Thanks for your efforts here. I'll work on creating an svg version.

I just checked in src/documentation/resources/images/logo2.svg, which is the
first pass at an svg version of the new logo. Please let me know if you have
any comments, even if you think that it is OK as is. I know some wanted to
tweak it, and this is probably not a perfect image of the original design
anyway. Also, does it make sense to check in the Adobe Illustrator file that
was used to create it? That might make editing it easier.

Victor Mote

cvs commit: xml-fop/src/documentation/resources/images logo2.svg

[vmote]

vmote   2003/12/05 11:13:06

  Added:   src/documentation/resources/images logo2.svg
  Log:
  add svg image for new FOP logo
  
  Revision  ChangesPath
  1.1  xml-fop/src/documentation/resources/images/logo2.svg
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/documentation/resources/images/logo2.svg?rev=1.1
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Properties API

[Victor Mote]

Peter B. West wrote:

> >>>Yes, this is the real issue.
> >>
> >>Only one of the real issues, I'm afraid.
> >
> >
> > OK, what are the others?
> >
>
> The thorns that immediately stick in my finger are

The topic at hand is what API is needed for the FO Tree to be able to pass
property values to its clients.

> 1) markers
> I have a pretty well-developed idea of how to implement the FO tree
> building side of this in alt.design.  It involves
> static-content-specific changes to the current FO tree building
> algorithm, and a slight generalization of the SyncedFoXmlEventsBuffer
> class to allow events to be read from a variety of sources.  In a word,
> grafting.

OK, I have addressed this.

> 2) Area tree dependencies for FO expressions.  Basically, length
> calculations involving percentages.

OK, I proposed passing the relevant Area to the "get" method.

> 2a) Handling the expressions.

This can all be done within the FO Tree.

> 2b) Designing the interaction between the FO builder and the Area tree
> builder.

OK. I proposed the following, which you have not addressed:


Your experience and insight on this issue are extremely important. If Areas
know how to find their FOTree heritage as well as their AreaTree heritage,
can you think of any concept that is missing to do Property resolution,
assuming that the relevant Area is passed to the "get" method on the FOTree
side?


> 3) Layout look-ahead and backtracking.  Closely related to 2b.

AFACT, these would become simply re-"get"ting the value from the FO Tree,
passing a new Area as a parameter.

> 4) Managing the association out-of-line areas (footnotes and floats)
> with the FONode/Area in which it was defined and the higher-level areas
> (e.g.  before-float-reference-area, footnote-reference-area,
> main-reference-area) which are juggled as a result of the lower-level
> contents.

Is this not just a specialized case for the general case #2 above?

Victor Mote

Re: Java 2D code generator

[Glen Mazza]

--- Chris Williams <[EMAIL PROTECTED]> wrote:
> I was wondering if within Batik there was a code
> generator to convert 
> SVG documents into java 2d code (actual code, not
> rendered). I know 
> SVGCanvas2D will render it, but i am looking to
> generate the actual 
> code, so i can package that up.
> 
> Any ideas?
> 

Yes, ask the Batik-Users list.

Glen


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

DO NOT REPLY [Bug 25248] New: - XSL Parameter passing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25248

XSL Parameter passing

   Summary: XSL Parameter passing
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I would be very helpful, if Apache FOP could handle XSL parameters (like 
XALAN's -PARAM attribute). I have some stylesheets with params, I'd like to 
process directly calling FOP without double handling (Transforming the XSL 
Stylesheet with XALAN first and pass the result to FOP):


http://www.w3.org/1999/XSL/Transform"; 
xmlns:fo="http://www.w3.org/1999/XSL/Format"; 
xmlns:n1="http://www.agere.com/qm/process"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
   

...

The primitive call/usage could be something like this (copied from XALAN 
syntax):

java org.apache.fop.apps.Fop -xml xmlfile.xml -xsl xslfile.xsl -pdf 
pdffile.pdf -param base.dir "C:/base/dir"

Java 2D code generator

[Chris Williams]

I was wondering if within Batik there was a code generator to convert 
SVG documents into java 2d code (actual code, not rendered). I know 
SVGCanvas2D will render it, but i am looking to generate the actual 
code, so i can package that up.

Any ideas?

Chris Williams