Re: commenting the Knuth code/centering issue

[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

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

[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

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

[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://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: XMLGraphics temp site up (was Re: Can we please disable the Wiki on Nagoya?)

[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:

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/

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

[Clay Leeds]

On Oct 9, 2004, at 1:30 AM, Jeremias Maerki wrote:

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. - 
PGP Public Key: 

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

[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

Re: commenting the Knuth code/centering issue

[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))

[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

[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

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

[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

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

[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://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.

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

[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://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-dev&m=109956963917611&w=2

Re: AreaFactory patch (once again ;-)

[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

AreaFactory patch (once again ;-)

[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

Tibor's AreaFactory patch (Re: AreaFactory patch)

[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

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

[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://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

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

[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://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