DO NOT REPLY [Bug 32054] New: - Pluggable area creation: AreaFactory

2004-11-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32054.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32054

Pluggable area creation: AreaFactory

   Summary: Pluggable area creation: AreaFactory
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Creation of area objects was moved from LMs to classes implementing
org.apache.fop.area.AreaFactory interface. This interface provides a set of
create methods for different types of area objects.
Default implementation of this interface is in class called DefaultAreaFactory.

Additional changes:
+ FOUserAgent - getter  setter for AreaFactory
+ AbstractLayoutManager - getAreaFactory() -- convenience method for accesing
current area factory in layout manager
+ Default constructor was added to several area classes


DO NOT REPLY [Bug 32054] - Pluggable area creation: AreaFactory

2004-11-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32054.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32054

Pluggable area creation: AreaFactory





--- Additional Comments From [EMAIL PROTECTED]  2004-11-04 11:32 ---
Created an attachment (id=13325)
AreaFactory patch


Tibor's AreaFactory patch (Re: AreaFactory patch)

2004-11-04 Thread Glen Mazza
--- Finn Bock [EMAIL PROTECTED] wrote:
 
 I only see a need for plugable LMs, but the
 AreaFactory patch is so 
 small that I see no problem with throwing a bone to
 Tibor.
 
 regards,
 finn
 

OK, that opinion was what I was trying to get at. 
Someone else to second Andreas' feelings on the issue.


Tibor, you may wish to try again with a Bugzilla patch
but incorporate Finn's two suggestions.  Also, you
were completely correct as to the purpose of
FOUserAgent, so if you can have the getAreaFactory()
implemented somewhere else outside of that class (LM
package, perhaps, or other places) that would a good
idea.  (FOUserAgent.*set*AreaFactory() is still fine.)

Please place it in Bugzilla, and we can have the rest
of the team comment on it.  I see nothing vetoable
myself, so it will be on how others feel.  No
guarantees, but hopefully another team member
(Andreas?) will apply it for you.  I, however, will be
taking myself out of this issue.

If however, you're really fine with just Pluggable
LM's, another option is to modify Finn's patch on the
issue: 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30500
It's a bit out of date due to other changes in the
code (namely, I moved layout code out of the former
AddLMVisitor and into new LM classes after this patch
was done.)  But that would also be helpful for others.

Thanks,
Glen



AreaFactory patch (once again ;-)

2004-11-04 Thread Tibor Vyletel
Hello fopsters,

so I have finished (and published in bugzilla) the patch which have aroused
quite a discussion around here.

Just a short description:
1) org.apache.fop.area.AreaFactory
- now contains specific create method for each (used) subclass of Area. The
generic Area create(FObj, LayoutManager) method was left in the interface
to, although its usage in client code is not recommended.
- ATM, all the create method have the same argument signature. I think, that
this is a place which can undergo changes in future (TextArea creation is a
good example). This will be dependent on the amount of work which might be
shifted from LMs to AreaFactories...

2) org.apache.fop.area.DefaultAreaFactory
- basic implementation; in most cases just default constructor of an area
subtype is called

3) FOUserAgent
- getAreaFactory()/setAreaFactory() method pair - same as in the example
sent before

4) AbstractLayoutManager
- I added convenience method getAreaFactory() to this class. So the actual
area creation in LMs is usually limited to:
curBlockArea = getAreaFactory().createBlock(fobj, this);

5) Default constructors
- I changed several Area classes, too. In particular those which have not
had a default constructor, yet.

So, that's it. Thanks to those who have supported this refactoring. It's in
the bugzilla now, so it's up to you what you will do with it. Anyway, please
send me any comment you have. I don't say that this is a finished and
non-changeable piece of code (such things don't exists in SW development, do
they? ;) any further suggestions/correction i am going to implement.

Greets,

Tibor Vyletel
ICQ# 79458455



Re: AreaFactory patch (once again ;-)

2004-11-04 Thread Glen Mazza

--- Tibor Vyletel [EMAIL PROTECTED] wrote:

 Hello fopsters,
 
 so I have finished (and published in bugzilla) the
 patch which have aroused
 quite a discussion around here.
 
 Just a short description:
 1) org.apache.fop.area.AreaFactory
 - now contains specific create method for each
 (used) subclass of Area. 

I like the results of this change in particular.

Glen




DO NOT REPLY [Bug 32054] - Pluggable area creation: AreaFactory

2004-11-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32054.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32054

Pluggable area creation: AreaFactory





--- Additional Comments From [EMAIL PROTECTED]  2004-11-04 16:47 ---
A more complete 'brief' description of this is in this POST to fop-dev:

http://marc.theaimsgroup.com/?l=fop-devm=109956963917611w=2


DO NOT REPLY [Bug 32054] - Pluggable area creation: AreaFactory

2004-11-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32054.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32054

Pluggable area creation: AreaFactory





--- Additional Comments From [EMAIL PROTECTED]  2004-11-04 20:34 ---
In AbstractLayoutManager:

+protected AreaFactory getAreaFactory() {
+return (userAgent != null) ? userAgent.getAreaFactory() : null;
+}

BTW, we can make AreaFactory a ThreadLocal in AbstractLayoutManager, correct?  
That way we can avoid .getAreaFactory() in FOUserAgent, also save the function 
call.

I understand we couldn't do ThreadLocal for FOEventHandler (potentially 
recursive FO documents within the same process would need a different instances 
of FOEventHandler) but this may be a good use-case for ThreadLocal here.


aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-04 Thread Victor Mote
Finn Bock wrote:

 Do you mean that the 3 different processors should ideally 
 report the same validation errors in the same manner? That 
 can only happen after someone standardize a SAFO API (Simple 
 API for FO parsing). Until then all implementation will throw 
 different exceptions, which is fine by me.

I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
already taken, but at the time I registered the axsl.org domain, and I
finally went ahead yesterday and opened up a SourceForge project for it.
There isn't much content there now, and I doubt that anyone wants to spend
much time on it ATM, but we have a place to talk about such things for those
who are interested -- I think Joerg at least will appreciate it being
somewhere else, and I know there are others who are not interested as well.
It deals with more than just parsing and exceptions, but those are (or could
be) parts of it. Here is the website:
www.aXSL.org

If FOP is interested, you are welcome to send a delegate, who will
automatically become a committer. Also, Peter West is welcome to be a
committer -- if we can accommodate his design, we'll sure try. I'll
eventually invite the commercial developers too, if it looks like there is
anything here that helps.

Victor Mote



Re: commenting the Knuth code/centering issue

2004-11-04 Thread Luca Furini
Glen Mazza wrote:

 The title centers correctly in 0.20.5, but is left-justified in 1.0.
 [...]
 Luca, are you looking at this issue of text alignment in general?

Yes, this happens when the text is short and the algorithm is not able to
find a set of breaking points: the fallback method can't compute the
needed indent, and the text is left-aligned instead of centered.

One way to solve this problem is to use, instead of the constant
DEFAULT_SPACE_WIDTH, a value computed according to the line width and the
maximum acceptable adjustment; this would prevent the algorithm from
failing. This value should be computed by the LineLM, and the InlineLMs
have to know it.

Another way is to use, instead of considerLegalBreak(), a different method
to evaluate a possible break point if no breakpoints are found: this
alternative method would be much simpler, and would re-create the
behaviour of the old getNextBreakPoss method (add content to the existing
line if possible, otherwise start another line).

I think this could be a much better solution:
- it's simpler: it's just another private method in the LineLM
- it would solve not only this issue with centered text, but also the
other situations in which the Knuth's algorithm fails (for example, when
there is a word larger than the line: see Simon's test file id=12494 for
bug 29124)

I have already done it, so if you agree I could create a patch in a short
time.

 Also, any chance we can get the Knuth classes commented so we have a
 better idea what KnuthBox, KnuthPenalty, KnuthGlue, etc. are for?

Sure, I should have done this before!
I'll try and comment these files as soon as possible.

Regards,
Luca




Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-04 Thread Glen Mazza
I am impressed by your seemingly boundless dedication
to XSL and its related fields.

Glen

--- Victor Mote [EMAIL PROTECTED] wrote:

 I actually toyed with this idea about two weeks ago.
 IIRC, the SAFO name is
 already taken, but at the time I registered the
 axsl.org domain, and I
 finally went ahead yesterday and opened up a
 SourceForge project for it.



Re: commenting the Knuth code/centering issue

2004-11-04 Thread Glen Mazza
--- Luca Furini [EMAIL PROTECTED] wrote:

 Another way is to use, instead of
 considerLegalBreak(), a different method
 to evaluate a possible break point if no breakpoints
 are found: this
 alternative method would be much simpler, and would
 re-create the
 behaviour of the old getNextBreakPoss method (add
 content to the existing
 line if possible, otherwise start another line).
 
 I think this could be a much better solution:
 - it's simpler: it's just another private method in
 the LineLM
 - it would solve not only this issue with centered
 text, but also the
 other situations in which the Knuth's algorithm
 fails (for example, when
 there is a word larger than the line: see Simon's
 test file id=12494 for
 bug 29124)
 
 I have already done it, so if you agree I could
 create a patch in a short
 time.
 

Please do--this solution sounds great!  (BTW, you have
write access already, correct?)


  Also, any chance we can get the Knuth classes
 commented so we have a
  better idea what KnuthBox, KnuthPenalty,
 KnuthGlue, etc. are for?
 
 Sure, I should have done this before!
 I'll try and comment these files as soon as
 possible.
 

Much appreciated--30 minutes or so of aggressive
commenting of the Knuth classes on your part would
make a *wonderful* grokkability improvement to this
important area of the code.  (Please do the commenting
in English though, as I'm three generations removed
from understanding Italian. ;)

[BTW, I'm considering getting that Digital Typography
book by Knuth you had mentioned earlier.  Do you
recommend it?  (I was thinking that given all the time
I spend on FOP I should start looking a little more at
the scientific aspects of this work.)]

Thanks,
Glen



Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-04 Thread Peter B. West
Victor Mote wrote:
Finn Bock wrote:

Do you mean that the 3 different processors should ideally 
report the same validation errors in the same manner? That 
can only happen after someone standardize a SAFO API (Simple 
API for FO parsing). Until then all implementation will throw 
different exceptions, which is fine by me.

I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
already taken, but at the time I registered the axsl.org domain, and I
finally went ahead yesterday and opened up a SourceForge project for it.
There isn't much content there now, and I doubt that anyone wants to spend
much time on it ATM, but we have a place to talk about such things for those
who are interested -- I think Joerg at least will appreciate it being
somewhere else, and I know there are others who are not interested as well.
It deals with more than just parsing and exceptions, but those are (or could
be) parts of it. Here is the website:
www.aXSL.org
If FOP is interested, you are welcome to send a delegate, who will
automatically become a committer. Also, Peter West is welcome to be a
committer -- if we can accommodate his design, we'll sure try. I'll
eventually invite the commercial developers too, if it looks like there is
anything here that helps.
Victor,
Thanks, I'll keep an eye on it.  I'll drop by the forum as soon as I get 
a chance. (Busy with Defoe atm)

Peter


XMLGraphics temp site up (was Re: Can we please disable the Wiki on Nagoya?)

2004-11-04 Thread Clay Leeds
On Oct 9, 2004, at 1:30 AM, Jeremias Maerki wrote:
snip what=wiki-stuff
While we're talking about volunteers, when the resolution passes we 
will
have some work to do, creating a charter, setting up a website for XML
Graphics which will link to the two existing websites under XML and a
few other things. I intent to do a good part of this but I hope I will
get some help.
I've placed a temporary xmlgraphics.apache.org site live on my 
homepage. Please take a look and provide feedback and comments:

http://homepage.mac.com/webmaestro/xml-fop/xml-graphics/
A couple of things to note:
- this 'site' is only one page and links to current FOP  Batik sites
- breadcrumb is Javascript, based on path/to/dir/ so it looks funny
- I'm open to suggestions!
A couple of ideas for enhancement:
- tabs for Apache.org  xml.apache.org (others?)
- links page (although FOP  Batik probably have that covered)
- PMC page
- other xmlgraphics-related pages?
Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Webmaster/Developer - Medata, Inc. - http://www.medata.com/
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


Re: XMLGraphics temp site up (was Re: Can we please disable the Wiki on Nagoya?)

2004-11-04 Thread Glen Mazza
Very nice--I like the xmlgraphics logo, and the layout of the text is 
well done.  I think in general having fewer pages but of higher quality 
is preferable. 

Glen
Clay Leeds wrote:
On Oct 9, 2004, at 1:30 AM, Jeremias Maerki wrote:
snip what=wiki-stuff
While we're talking about volunteers, when the resolution passes we will
have some work to do, creating a charter, setting up a website for XML
Graphics which will link to the two existing websites under XML and a
few other things. I intent to do a good part of this but I hope I will
get some help.

I've placed a temporary xmlgraphics.apache.org site live on my 
homepage. Please take a look and provide feedback and comments:

http://homepage.mac.com/webmaestro/xml-fop/xml-graphics/



DO NOT REPLY [Bug 5001] - content-width and content-height ignored?

2004-11-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=5001.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=5001

content-width and content-height ignored?





--- Additional Comments From [EMAIL PROTECTED]  2004-11-05 07:06 ---
We had the same problem. Using width instead of content-width seems to fix the
problem...


Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-04 Thread Jeremias Maerki
Victor,

from the website I don't quite get the scope of the project. That might
have to be made clearer. Anyway, I didn't want to talk about it just yet,
because it's not ready, but recently I started writing a JAXP-like API
for XSL-FO processors (I called in JAFOP for now). It basically
implements the ideas we came up with in the API discussion over a year
ago. In the next few months I will probably need to integrate several
different FO-processors and want to have a common API for all.
Especially having a uniform API between FOP maintenance branch and HEAD
is important to me because I need to get FOP 0.20.5 set up for PDF
output and I will most probably need the RTF output of FOP HEAD quite
soon (all in the same VM, of course). Also, the fact that we got 4
OS-FO-processors screams for a common API so they can be used
interchangeably.

Can it be that we had the same idea at the same time again? :-) Of
course, having standardized validation messages and such goes a bit
beyond what I imagined, but that's ok.

On 04.11.2004 22:58:39 Victor Mote wrote:
 Finn Bock wrote:
 
  Do you mean that the 3 different processors should ideally 
  report the same validation errors in the same manner? That 
  can only happen after someone standardize a SAFO API (Simple 
  API for FO parsing). Until then all implementation will throw 
  different exceptions, which is fine by me.
 
 I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
 already taken, but at the time I registered the axsl.org domain, and I
 finally went ahead yesterday and opened up a SourceForge project for it.
 There isn't much content there now, and I doubt that anyone wants to spend
 much time on it ATM, but we have a place to talk about such things for those
 who are interested -- I think Joerg at least will appreciate it being
 somewhere else, and I know there are others who are not interested as well.
 It deals with more than just parsing and exceptions, but those are (or could
 be) parts of it. Here is the website:
 www.aXSL.org
 
 If FOP is interested, you are welcome to send a delegate, who will
 automatically become a committer. Also, Peter West is welcome to be a
 committer -- if we can accommodate his design, we'll sure try. I'll
 eventually invite the commercial developers too, if it looks like there is
 anything here that helps.



Jeremias Maerki



Re: commenting the Knuth code/centering issue

2004-11-04 Thread Jeremias Maerki
No, I don't think Luca has write access, yet. I know by now that the CLA
is recorded but the account hasn't been created, yet, although I've
already sent a reminder.

On 04.11.2004 23:59:52 Glen Mazza wrote:
 Please do--this solution sounds great!  (BTW, you have
 write access already, correct?)


Jeremias Maerki