Re: Eclipse Ant SerializeHyphPattern failure

[Peter B. West]

Jeremias,

I'll try it and commit if it works.
Peter
Jeremias Maerki wrote:
Hmm, I've given up running Ant under Eclipse. Gave me too much of a
headache and it works well for me outside of Eclipse.
But I think the trick is to use "${basedir}" instead of "." in build.xml
because Eclipse has to set the base directory so everything is ok. I
have done some other changes locally that I cannot commit, yet, because
I'm blocked on an issue. So I can't commit my build.xml. Can you do it,
please?
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: alt-design merits (WAS: Nomination of Glen Mazza as committer)

[Peter B. West]

Victor,

Trying to answer your latest questions on this topic has absorbed a deal 
of my time, exposed a contradiction in my thinking, and made me think 
through in more detail some of the fuzzy bits.  I am still working on 
it, and I will get back to you.  Thanks for the interrogation.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: startup refactoring

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> On 17.06.2003 21:28:29 Glen Mazza wrote:
> > Instinctively, I wouldn't trust any code in the
> > package root of org.apache.fop -- we wouldn't have
> a
> > very modularized design that way (knowing FOP's
> > current coding style, the main FOP API would then
> be
> > accessing objects all through the packages,
> 
> Well, the public API has to have
> some way to control
> the whole show. 

You don't mean that literally--e.g.., a servlet
programmer does not need useThisRenderer() and
attachAreaTree() functions in a public API.  (i.e.,
the public (embedded) API would be a strict subset of
the functions available to the supervising octopus
running the show)

> This will automatically lead to a
> little octopus if the
> code is in ...fop or ...fop.api. But no problem with
> another package.
> 

For my discussion, apps=api (they're both supervising
octopi).  (Although I'm sure your package would be
orders-of-magnitude cleaner and simpler!)

> > FOP is more a pipeline to me:
> > 
> > APPs package (CLI, TRAX/XSLTInputHandler,
> Avalonized
> > API, Victor's ideas) --> 
> FOTreeBuilder/Layout/Area
> > Tree creation --> Rendering.
> 
> Uh, thanks for that one. It's a very nice show why
> the current apps
> package is a mess. 

I agree with you that the apps package is hideous--but
a pipeline may cleanup nearly all of it, providing it
enforces the rules I mentioned earlier:  

a.) The only access between apps/api and the rest of
the packages is via FOTreeBuilder and its "three"
functions.
b.) FOP is designed such that FOTreeBuilder *can* be
directly instantiated via a servlet (even if we don't
allow it).
c.) Once so instantiated, no code within apps/api
packages can be referenced.

Via these rules, look at what gets removed from apps:
(a) structure and layout handler are gone (those are
past the FOTreeBuilder)
(b) AWTStarter and PrintStarter are gone (those
processing decisions are either handled by
FOTreeBuilder or something that it delegates to.)
(c) App class has *no* knowledge of renderers, element
mappings, area trees, structure handlers.
(d) Business logic is kept with each object, and not
shared in multiple places.

> > IMO FOTreeBuilder should just expose three
> functions
> > (perhaps another one for logging):
> 
> It's best to talk about
> lifestyle primarily and
> leave the lifecycle (instantiation, logging,
> configuration,
> initialization) to a different discussion. Helps
> keeping the focus, I
> believe.

Excellent!  We can leave that distraction out of the
discussion.  (Although they, in addition to threading
issues, *do* appear to strengthen your argument on the
need for a supervising class.)

> > 1.) SetXSLFOStream() (file or stream)
> > 2.) SetRenderType()  (those constants currently in
> > Driver or CommandLineStarter)
> > 3.) Run(). (returns a stream or file)
> 
> This mixes concerns. A render type does not belong
> in a class called
> FOTreeBuilder. 

I think it does, because it needs to know whether or
not to generate an Area Tree, *which type* of
structure handler, etc., also, since the Area Tree
needs to know the render type, FOTreeBuilder will need
to pass that information on to it via the pipeline. 
(Peter had said and you confirmed that the Area Tree
still needs to know the rendering type for font sizes,
etc.)

Furthermore a different implementation of
FOTreeBuilder may make different Area Tree decisions
based on its render_type.

> It should have nothing to
> do with the
> rendering aspect, especially since FO tree building
> is independant of
> the output format (wrt Renderers). 

Indeed, nothing to do with *rendering* but it does
need to know the render_type as mentioned above.
APPS/API knows nothing but FOTreeBuilder, which knows
nothing but AreaTree, which knows nothing but the
Renderers.

So I also agree with you that FOTreeBuilder doesn't
need to know about the Renderers.  (but it could be so
redesigned in the future, depending on the pluggable
implementation of FOTreeBuilder, and this design more
easily allows for that type of change.)


> The render type
> is better placed in a
> class such as a
> RenderingRun/Document/.

Sure, providing they pass that information on to
FOTreeBuilder.  ;)

> The FO
> tree
> builder is (to me) a service that simply accepts a
> SAX stream and builds
> the FO tree. 

IMHO FOTreeBuilder is an object (C++/Java), not a
service (C).

> The layout engine, another (coarse
> grained) service, will
> then access the FO tree to do the layout. This is
> all kept together by a
> "supervising" class. 

If we were doing C programming--my fear is that the
supervising class is going to end up eating FOP's
object-oriented design and splitting the business
logic too much in multiple places (just like apps
currently does).  (I guess I'll just have to trust the
team to be disciplined in this regard!  ;)

> 
> The FOTreeBuilder should remain an inner service to
> FOP, not exposed in
> the public API, if you ask me. 

OK,

RE: [RTF] Jfor integration

[Victor Mote]

Jeremias Maerki wrote:

> +1 for working on JFOR integration.
>
> If JFOR's sources should go into CVS, I think from the licensing point
> of view, Bertrand will have to do the initial import of the sources. I
> believe, this performs an implicit grant process because of his
> committer license agreement.

It sure can't hurt. That sounds like a good idea.

> Victor, I don't want to draw you away from the API stuff with my
> earlier comments. I promise to come up with constructive thoughts within
> the next few days. My brain is already working on it.

Not at all -- I understand the process. I think we are probably after much
the same thing, just viewing it from different angles -- you from API, I
from control of the processing. I have a lot to learn on the multithreading
issues, but AFAIK, the two are completely compatible, and in fact
complementary. On the RTF stuff, it is rare that I can string enough time
together to do any coding, so I hate to waste it when it is there.

Victor Mote



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

Re: [RTF] Jfor integration

[Jeremias Maerki]

+1 for working on JFOR integration.

If JFOR's sources should go into CVS, I think from the licensing point
of view, Bertrand will have to do the initial import of the sources. I
believe, this performs an implicit grant process because of his
committer license agreement.

Victor, I don't want to draw you away from the API stuff with my
earlier comments. I promise to come up with constructive thoughts within
the next few days. My brain is already working on it.

On 18.06.2003 19:09:01 Victor Mote wrote:
> I am
> tempted to go ahead and drop the jfor source code into the FOP repository &
> start hacking away. What do you think? The wiki made me think that maybe you
> were wanting to keep your options open. I guess the other issues that raises
> are 1) dropping in the Apache license (looks like no problem), and some
> style issues. What are your thoughts on all of this?


Jeremias Maerki


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

[RTF] Jfor integration

[Victor Mote]

Bertrand et al:

I did a little work in RTFHandler yesterday (after reading the wiki &
related email messages on the topic), committing a change to implement
text-align for paragraphs, mostly just to get a feel for what is going on
there. I was using examples/fo/basic/normal.fo as my test document, so the
next thing I thought I would mess with was paragraph shading
(background-color). It looked like that was not implemented in the jfor
libs, so I was trying to set up my IDE to use the jfor source & watch it in
the debugger. Some of the source files contain non-ASCII characters (see
main/JForVersionInfo.java, line 67, for example), but are encoded as ASCII
(instead of UTF-8), so the IDE was choking. This is easy to fix, and I am
tempted to go ahead and drop the jfor source code into the FOP repository &
start hacking away. What do you think? The wiki made me think that maybe you
were wanting to keep your options open. I guess the other issues that raises
are 1) dropping in the Apache license (looks like no problem), and some
style issues. What are your thoughts on all of this?

Victor Mote


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

DO NOT REPLY [Bug 20868] - max external graphic height depends on region-body

[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=20868

max external graphic height depends on region-body





--- Additional Comments From [EMAIL PROTECTED]  2003-06-18 17:07 ---
Oops, ignore attachment. Wrong bug.

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

DO NOT REPLY [Bug 20879] - Leader is broken in PS Renderer

[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=20879

Leader is broken in PS Renderer





--- Additional Comments From [EMAIL PROTECTED]  2003-06-18 17:06 ---
Created an attachment (id=6875)
Proposed patch

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

DO NOT REPLY [Bug 20868] - max external graphic height depends on region-body

[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=20868

max external graphic height depends on region-body





--- Additional Comments From [EMAIL PROTECTED]  2003-06-18 17:05 ---
Created an attachment (id=6874)
Proposed patch

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

DO NOT REPLY [Bug 20879] - Leader is broken in PS Renderer

[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=20879

Leader is broken in PS Renderer





--- Additional Comments From [EMAIL PROTECTED]  2003-06-18 17:05 ---
I am attaching a patch that seems to fix it. I'm not sure
why though. Just reverting a previous change.

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

DO NOT REPLY [Bug 20879] New: - Leader is broken in PS Renderer

[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=20879

Leader is broken in PS Renderer

   Summary: Leader is broken in PS Renderer
   Product: Fop
   Version: 0.20.5
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The postscript renderer produces broken output when trying to
render a leader. I'm not a postscript expert but comparing
0.20.4 (where it works) to 0.20.5rc3a (where it's broken) it
looks like a couple of moveto's are missing. The FO below
will produce the bad postscript. PDF rendering works fine.


http://www.w3.org/1999/XSL/Format";>
  

  

  
  

  

  

  


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

DO NOT REPLY [Bug 20868] New: - max external graphic height depends on region-body

[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=20868

max external graphic height depends on region-body

   Summary: max external graphic height depends on region-body
   Product: Fop
   Version: 0.20.5
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I try to produce a Spare Parts List PDF with Apache FOP 0.20.5rc3a. On even 
pages I just have a static explosion drawing and on odd pages a table with 
spare parts, that can spread over multiple pages. To do this I use repeatable-
page-master-alternatives. To get nice page breaks, I have a pseudo region-body 
with a height of 1mm on the even pages (the flow is the table, the explosion 
drawing is on a static-content-area).

Unfortunately I had to find out, that the external graphic on the static 
content area cannot be higher than the height of the region-body. Since I only 
have a pseudo region-body of 1mm height, the image is rendered far too small ;)

I do not think that this is desired behaviour. So I stepped into the source 
code (I start to love open source).

And in org.apache.fop.fo.flow.ExternalGraphic.layout(Area area) in line 209 I 
found out that the maximum height of the external graphic is indeed dependent 
on "area.getPage().getBody().getMaxHeight()". But this class is used for static 
content areas, too.

I changed this to "area.spaceLeft()".

For my special rendering this works fine. Of course, I do not have a clue, if 
this is a solution for any boundary condition.

I would really appreciate if you could have a look at it.

Thanks,

FloH

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

Re: new Logo

[Oleg Tkachenko]

Christian Geisert wrote:

What's going on with the new logo?
The logo #30 [1] won the contest. It's by Tobias Muller, modified by Scott 
Hofmann. Some of us talked about additional tweaking and Scott said [2] he's 
ready to go for it. That's it afaik.
I propose to put an end to this - let's discuss additional tweaking and get 
finally new logo (we need also SVG version).

[1] http://www.tkachenko.com/fop/logocontest/fop_logo-revised-Tobias-Muller.jpg
[2] http://marc.theaimsgroup.com/?l=fop-dev&m=105361141331672&w=2
--
Oleg Tkachenko
http://www.tkachenko.com/blog
Multiconn Technologies, Israel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Nomination of Glen Mazza as committer

[Jeremias Maerki]

Can do.

Here's the new account request form that we need to fill:
New account request form:

 To: [EMAIL PROTECTED]
 Cc: pmc@.apache.org, [EMAIL PROTECTED]
 Subject: Apache account request

 Full name:...
 Preferred userid: ...
 Forwarding email address: ...

 Requested karma:  [/] ...

[Vote: link to mail archive for PMC bookkeeping]


On 18.06.2003 10:21:42 Christian Geisert wrote:
> Clearly enough +1 and no -1, congratulations Glen!
> 
> According to http://www.apache.org/dev/pmc.html the account
> request should be handled by the PMC - so Jeremias or Peter
> would you please take care of this?


Jeremias Maerki


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

Re: [VOTE] Nomination of Glen Mazza as committer

[Christian Geisert]

Christian Geisert schrieb:
Oleg Tkachenko schrieb:

Jeremias Maerki wrote:

I agree, so +1 from me.
Here is my +1.
+1
Clearly enough +1 and no -1, congratulations Glen!

According to http://www.apache.org/dev/pmc.html the account
request should be handled by the PMC - so Jeremias or Peter
would you please take care of this?
Glen, what userid would you like?

Some infos for the start: http://www.apache.org/dev/committers.html

Christian

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