Re: Markers

[Chris Bowditch]

Andreas L. Delmelle wrote:
Just gathering my thoughts here...
Thanks for your feedback. I need all the help I can get!
If I interpret the related code in BLM correctly, then the childLMs are all
created (and call their addAreas() ) after the first marker has been added
( line 265: addMarkers(true,true); )
addMarkers( true, true ); translates to
parentLM.addMarkerMap( markers, true, true ); (see
AbstractLayoutManager.java line 360 )
This latter stops at page-level, in PageLayoutManager, it becomes:
curPage.addMarkerMap( markers, true, true );
So, IIC, this makes it conceivable that a marker is added to page 1, then
subsequently the childLMs signal a BP, maybe breaking the page, but
certainly leaving the marker where it was initially added.
No, because as you say above addAreas is being called and this doesnt not 
generate BPs, BPs are generated by the getNextBreakPoss method on each LM. 
This is why I am puzzled, the page boundaries are decided when the 
getNextBreakPoss methods are called. By the time, addArea methods are called, 
the page boundaries have already been decided


Chris

Re: FOray integration to FOP

[Chris Bowditch]

Victor Mote wrote:
FOP Devs:
I apologize for intruding again. After thrashing around for a bit, I
No need to apologize, your input is welcome.
concluded that there were an overwhelming number of good reasons for me to
import the entire FOP maintenance branch into the FOray repository, then
delete and modify as necessary for FOray integration. One of the biggest
benefits is that it will greatly simplify any integration that FOP decides
to do with Foray. Specifically, I don't have to be in the business of trying
to coordinate such integration, and you don't have to listen to me trying to
do that. Just come get it if you want it. The good news is that I will
essentially be doing the maintenance branch integration for you -- there
shouldn't be much to do except decide whether you want it or not. I have
posted greater detail here:
http://foray.sourceforge.net/fop/index.html
This approach allows FOray and FOP to ignore each other most of the time.
However, I obviously hope that you will check in from time to time to see
whether we have anything useful for you. Please let me know if I can help in
any way.
This approach makes a lot of sense.
I will probably unsubscribe fop-dev in the next few days, so if I don't
respond here, contact me off-line or through FOray.
I will check up on FOrays progress from time to time, to see if theres 
anything that we need to do.

I wish you every success with FOray.
Chris

Re: Justification and line breaking

[Chris Bowditch]

Hi Luca,
May I start by thanking you for your hard work in submitting the patch for 
Knuth's Line breaking algorithm.

I'm just starting to look at your patch now. First thing that strikes me, and 
this was pointed out to me before I became a committer. Please try to avoid 
commenting out large chunks of code. If the code is no longer needed please 
delete it. If we need to go back to the old code, we can always get the 
previous versions from CVS.

Second thing, are you just ignoring word spacing and letter spacing at the 
moment? I think one of the other FOP Dev's hit the problem of "how do we tell 
if property was specified or is it just the default" before? Hopefully they 
will speak up with a work around. If we do go without the letter spacing 
property, then they really ought to stay as NotYetImplemented in the 
FOPropertyMapping and just put come comments into the code to explain why it 
cant be implemented ATM.

I'll comment again once Ive done some testing. Thanks,
Chris

Announcement: Unified Typesetting API

[Christian Z.]

Dear list,
after several months of work I want to announce the first release of the
Unified Typesetting API.

The Unified Typesetting API (UTA) is an attempt to unify the typesetting
process needed by every text handling application. Currently it provides
a reference implementation in Java available under the Mozilla Public
License.

Features:
 * line-breaking model similar to TeX's to allow global optimizing
   line-break algorithms (stable)
 * modular and extensible design to allow simple as well as high quality
   implementations
 * support for new scripts can easily be added (in progress)
 * quality management component to retrieve information about the 
   internals of a typesetter (stable)
 * fully documented
 * open source

Source and documentation is available under

  http://inghuimische.drhuim.de/uta


Christian Ziesemer

Applying Large Patches (was Re: Justification and line breaking)

[Chris Bowditch]

FOP Devs,
I'm trying to apply Luca's patch and running into problems. The hunks in the 
first 9/10 files get applied okay, but when the patch program gets to 
LineLayoutManager, it only reconises 6 hunks, the seventh is very big and for 
some reason the patch program thinks it has found the start of another file 
and errors with "File not found. Skip this file [n]: "

Has anyone else got any experience of working with such large and patches? Any 
advice on how to proceed would be appreciated.

Thanks,
Chris

Re: Applying Large Patches (was Re: Justification and line breaking)

[Jeremias Maerki]

Chris,

I've just upgraded my sources and tried to apply the same patch within
Eclipse to see what happens. I get two parts of the patch that Eclipse
claims to be unable to apply correctly. But this only makes up a few
lines in all. Maybe if Luca would send you the whole
LineLayoutManager.java, too, you could sort out the rest manually.

Eclipse IMO has a very good patch facility. You'd probably get farther
that way.

On the other side, I've got no idea why the patch doesn't work 100%.
Luca seems to have used the latest sources when doing the patch.

On 21.05.2004 14:05:29 Chris Bowditch wrote:
> FOP Devs,
> 
> I'm trying to apply Luca's patch and running into problems. The hunks in the 
> first 9/10 files get applied okay, but when the patch program gets to 
> LineLayoutManager, it only reconises 6 hunks, the seventh is very big and for 
> some reason the patch program thinks it has found the start of another file 
> and errors with "File not found. Skip this file [n]: "
> 
> Has anyone else got any experience of working with such large and patches? Any 
> advice on how to proceed would be appreciated.



Jeremias Maerki

Re: Java text handling

[Christian Z.]

Hi Peter!

> Do any of the list denizens have experience with Java font handling and 
> 2D text layout?  I'm new to it, and would like to be able to bounce 
> questions off someone further up the food chain, on or off-line.

The typesetting is done Font.layoutGlyphVector and
java.awt.font.GlyphVector.performDefaultLayout. Currently TrueType is
supported and therefore the philosophy 'do everything within the font'.
This makes the Java API very hard to extend and not very modular. Cause
OpenType follows the philosophy 'do as much of the typesetting within
the application' it's hard to support both the same time. There are
typesetting issues which are font dependent and some which are not.

My advice: Use UTA and provide a wrapper around the Java font class in
form of a Script [1]. ;-)

Regards,
Christian Ziesemer

[1]
http://inghuimische.drhuim.de/uta/javadoc/de/inghuimische/uta/typeset/Script.html

Re: Applying Large Patches (was Re: Justification and line breaking)

[Chris Bowditch]

Jeremias Maerki wrote:
Chris,
I've just upgraded my sources and tried to apply the same patch within
Eclipse to see what happens. I get two parts of the patch that Eclipse
claims to be unable to apply correctly. But this only makes up a few
lines in all. Maybe if Luca would send you the whole
LineLayoutManager.java, too, you could sort out the rest manually.
Eclipse IMO has a very good patch facility. You'd probably get farther
that way.
On the other side, I've got no idea why the patch doesn't work 100%.
Luca seems to have used the latest sources when doing the patch.
Thanks for the quick reply Jeremias. I think the easiest solution will be for 
Luca to supply his complete LineLayoutManager.java and TextLayoutManager.java 
(the two files that have more than 1000 lines changed) Would you mind 
attaching them to the patch Luca?

Thanks,
Chris

Re: Java text handling

[Jeremias Maerki]

There might be a problem: UTA uses JGraphT which is LGPL. FOP cannot
depend on LGPL software (Apache licence policy).

There is a "graph" subproject inside Jakarta Commons. Maybe this could
be used instead of JGraphT.

Anyway, how does UTA relate to Luca's recent patch on line breaking?

On 21.05.2004 17:27:35 Christian Z. wrote:
> My advice: Use UTA and provide a wrapper around the Java font class in
> form of a Script [1]. ;-)



Jeremias Maerki

Re: FOray integration to FOP

[Clay Leeds]

Victor,
On May 21, 2004, at 2:53 AM, Chris Bowditch wrote:
Victor Mote wrote:
FOP Devs:
I apologize for intruding again. After thrashing around for a bit, I
No need to apologize, your input is welcome.
That goes double for me (if that's possible... :-))
concluded that there were an overwhelming number of good reasons for 
me to
import the entire FOP maintenance branch into the FOray repository, 
then
delete and modify as necessary for FOray integration. One of the 
biggest
benefits is that it will greatly simplify any integration that FOP 
decides
to do with Foray. Specifically, I don't have to be in the business of 
trying
to coordinate such integration, and you don't have to listen to me 
trying to
do that. Just come get it if you want it. The good news is that I will
essentially be doing the maintenance branch integration for you -- 
there
shouldn't be much to do except decide whether you want it or not. I 
have
posted greater detail here:
http://foray.sourceforge.net/fop/index.html
This approach allows FOray and FOP to ignore each other most of the 
time.
However, I obviously hope that you will check in from time to time to 
see
whether we have anything useful for you. Please let me know if I can 
help in
any way.
This approach makes a lot of sense.
I will probably unsubscribe fop-dev in the next few days, so if I 
don't
respond here, contact me off-line or through FOray.
I will check up on FOrays progress from time to time, to see if theres 
anything that we need to do.
As my company (and probably most others as well) is already using the 
FOP-maintain branch in production, it makes sense to check in from time 
to time, to see what FOray has cooking as well. In fact, once you get 
some usable enhancements from FOray, it might make sense for FOP to add 
FOray to the Resources Page (assuming there are no objections).

I wish you every success with FOray.
Chris
Ditto Chris's eloquence for me...
Web Maestro Clay

Re: FOray integration to FOP

[Clay Leeds]

Victor,
As you're aware, the Apache Software License 2.0 makes it more 
cumbersome to include/bundle software that is not ASL. Would you 
comment on the FOray 'license' and how it will be affected and/or 
interact with ASL?

Thanks!
Web Maestro Clay
On May 21, 2004, at 7:23 AM, Clay Leeds wrote:
Victor,
On May 21, 2004, at 2:53 AM, Chris Bowditch wrote:
Victor Mote wrote:
FOP Devs:
I apologize for intruding again. After thrashing around for a bit, I
No need to apologize, your input is welcome.
That goes double for me (if that's possible... :-))
concluded that there were an overwhelming number of good reasons for 
me to
import the entire FOP maintenance branch into the FOray repository, 
then
delete and modify as necessary for FOray integration. One of the 
biggest
benefits is that it will greatly simplify any integration that FOP 
decides
to do with Foray. Specifically, I don't have to be in the business 
of trying
to coordinate such integration, and you don't have to listen to me 
trying to
do that. Just come get it if you want it. The good news is that I 
will
essentially be doing the maintenance branch integration for you -- 
there
shouldn't be much to do except decide whether you want it or not. I 
have
posted greater detail here:
http://foray.sourceforge.net/fop/index.html
This approach allows FOray and FOP to ignore each other most of the 
time.
However, I obviously hope that you will check in from time to time 
to see
whether we have anything useful for you. Please let me know if I can 
help in
any way.
This approach makes a lot of sense.
I will probably unsubscribe fop-dev in the next few days, so if I 
don't
respond here, contact me off-line or through FOray.
I will check up on FOrays progress from time to time, to see if 
theres anything that we need to do.
As my company (and probably most others as well) is already using the 
FOP-maintain branch in production, it makes sense to check in from 
time to time, to see what FOray has cooking as well. In fact, once you 
get some usable enhancements from FOray, it might make sense for FOP 
to add FOray to the Resources Page (assuming there are no objections).

I wish you every success with FOray.
Chris
Ditto Chris's eloquence for me...
Web Maestro Clay

ASL 2.0

[Clay Leeds]

Howdy folks,
When doing a minute of research, I noticed that the FOP License page[1] 
still references ASL 1.1. Is there anything special we need to do with 
that page, or should I just replace it with the contents of ASL 2.0? In 
other words, should I:

a. pre-pend ASL 2.0 (put it at the top) and leave ASL 1.1 to follow?
b. replace ASL 1.1 with ASL 2.0 (ASL 1.1 would no longer be accessible 
from that page)
c. rename license.html => license1.1.html and have a new license.html w 
ASL 2.0
d. something else?

Thanks!
Web Maestro Clay
[1]
http://xml.apache.org/fop/license.html

Re: ASL 2.0

[Jeremias Maerki]

Clay,

our current version 0.20.5 was released under the Apache licence 1.1, so
I think the AL 1.1 should stay. (a) would be best but adding a short
paragraph at the top of the page explaining the applicability of each
licence would be great. Thank you!

On 21.05.2004 16:39:04 Clay Leeds wrote:
> Howdy folks,
> 
> When doing a minute of research, I noticed that the FOP License page[1] 
> still references ASL 1.1. Is there anything special we need to do with 
> that page, or should I just replace it with the contents of ASL 2.0? In 
> other words, should I:
> 
> a. pre-pend ASL 2.0 (put it at the top) and leave ASL 1.1 to follow?
> b. replace ASL 1.1 with ASL 2.0 (ASL 1.1 would no longer be accessible 
> from that page)
> c. rename license.html => license1.1.html and have a new license.html w 
> ASL 2.0
> d. something else?
> 
> Thanks!
> 
> Web Maestro Clay
> 
> [1]
> http://xml.apache.org/fop/license.html



Jeremias Maerki

RE: FOray integration to FOP

[Victor Mote]

Clay Leeds wrote:

> As you're aware, the Apache Software License 2.0 makes it 
> more cumbersome to include/bundle software that is not ASL. 
> Would you comment on the FOray 'license' and how it will be 
> affected and/or interact with ASL?

FOray officially uses the Apache License 2.0. ATM, all files still have the
1.1 boilerplate.

Victor Mote

Re: FOray integration to FOP

[Clay Leeds]

Thanks for clearing this issue up.  I wanted to be sure this 
information was in the list archives.

It might be good to put this on the FOray web site (I looked for 
licensing info and didn't find any :-)).

Web Maestro Clay
On May 21, 2004, at 8:12 AM, Victor Mote wrote:
Clay Leeds wrote:
As you're aware, the Apache Software License 2.0 makes it
more cumbersome to include/bundle software that is not ASL.
Would you comment on the FOray 'license' and how it will be
affected and/or interact with ASL?
FOray officially uses the Apache License 2.0. ATM, all files still 
have the
1.1 boilerplate.

Victor Mote

Re: Java text handling

[Christian Z.]

Hi Jeremias!

> There is a "graph" subproject inside Jakarta Commons. Maybe this could
> be used instead of JGraphT.

I'll have a look at it, thanks.

> Anyway, how does UTA relate to Luca's recent patch on line breaking?

In no way. While Luca seems to have reimplemented the glue/box/penalty
model, I have a generalization/simplification. I think it is similar to
what Knuth mentions in the Addendum in Digital Typography, Breaking
Paragraphs into Lines, as socalled kerfs model. In UTA there are only
Items. A break is allowed behind every item, an item has a penalty and
different widths depending on its position.

Christian Ziesemer

Re: Applying Large Patches (was Re: Justification and line breaking)

[Luca Furini]

Chris Bowditch wrote:

> I think the easiest solution will be for
> Luca to supply his complete LineLayoutManager.java and
> TextLayoutManager.java (the two files that have more than
> 1000 lines changed) Would you mind attaching them to the patch Luca?

Ok, I'm going to do it.
By the way, the code I was working on was not the latest one, but I did not
modify files changed later (maybe the XMLrenderer, but it's a small change).

Luca

DO NOT REPLY [Bug 29124] - New line breaking algorithm

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

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-05-21 17:21 ---
Created an attachment (id=11625)
LineLayoutManager.java

DO NOT REPLY [Bug 29124] - New line breaking algorithm

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

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-05-21 17:22 ---
Created an attachment (id=11626)
TextLayoutManager.java

Re: Justification and line breaking

[Luca Furini]

Chris Bowditch wrote:

> I'm just starting to look at your patch now. First thing that strikes
> me, and this was pointed out to me before I became a committer. Please
> try to avoid commenting out large chunks of code. If the code is no
> longer needed please delete it. If we need to go back to the old code,
> we can always get the previous versions from CVS.

Ok, sorry.

> Second thing, are you just ignoring word spacing and letter spacing at the
> moment? I think one of the other FOP Dev's hit the problem of "how do we
> tell if property was specified or is it just the default" before? Hopefully
> they will speak up with a work around. If we do go without the letter
> spacing property, then they really ought to stay as NotYetImplemented in the
> FOPropertyMapping and just put come comments into the code to explain why
> it cant be implemented ATM.

No, both properties are implemented (the letter spacing only partially).
When the word spacing is not .min == .max == 0 it is used to define the
inline progression dimension of a space; otherwise, a default value is used
instead.
Letter spacing is used too, but at the moment only its .opt value is used,
so letter spacing will be the same in every line of the paragraph. The
problem is that Knuth's algorithm doesn't explicitly take into account
letter space.

Luca

RE: FOray integration to FOP

[Victor Mote]

Clay Leeds wrote:

> It might be good to put this on the FOray web site (I looked 
> for licensing info and didn't find any :-)).

Good idea. I just added it to the home page. You can also find it by
following the menu item "SourceForge Project Page", which will take you
here:
http://sourceforge.net/projects/foray/

Victor Mote