Re: Incremental vs rewrite

[Chris Bowditch]

Simon Pepping wrote:
That was basic work. The basis of the property subsystem is good,
and shorthands all work, I think. But it is another question which
properties are really implemented w.r.t. their effect on the layout. I
do not think we have a good overview. See Glen's experimental
approach: Transform a set of documents and see what you think is not
right, which is the best we seem to be able to do right now.
Thanks for the confirmation Simon. Transforming documents and seeing what 
doesnt work is the approach I have been taking. Currently trying to see why 
markers dont work properly.

Chris

Re: Incremental vs rewrite

[Chris Bowditch]

Peter B. West wrote:
My understanding is that thanks to the property work earlier this year 
by Glen, Finn and Simon, that properties are 95% there, including 
shorthands. Admittely I didnt follow their work very closely, so could 
be wrong about this. Im sure Glen will interject and correct me on 
this if I'm wrong.

I do get burned when the work on properties is mentioned without any 
acknowledgment of the influence that alt-design has had on HEAD's 
properties development.
Sorry Peter,
Chris

Re: Just do it

[Chris Bowditch]

Jeremias Maerki wrote:
Guys,
my comment on this is: Commit it if you think it's an improvement. It
may be a bit different if it concerned design questions, but with small
fixed and improvements I'd rather you guys "just did it". If it turns
out to be a mistake it can easily be corrected. That's why we have peer
review here. You guys block yourselves with this strategy and Arnd gets
even more of a head-start. :-)
Hi Jeremias,
you are right of course. I was just worried I might have broken something 
else, but I'm sure that will show up in time. It certainly works for the 
documents I have tested. Now committed 

Chris

DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

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

[PATCH] More justification problems





--- Additional Comments From [EMAIL PROTECTED]  2004-05-20 08:25 ---
Thanks for the link Simon.

Although this patch may be redundant now with Luca's proposal on the way.

DO NOT REPLY [Bug 29099] - pdf images does not appear in https

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

pdf images does not appear in https





--- Additional Comments From [EMAIL PROTECTED]  2004-05-20 08:32 ---
This issue has been discussed many times in the archives. Here is a link to 
one such thread:

http://marc.theaimsgroup.com/?l=fop-user&m=106140830410154&w=2

It would appear that this issue may be related to the JDK. You may want to do 
a search yourself and review other answers.

Polite Request: When facing problems such as this, could you please raise it 
on the user mailing list before raising a bug.

Re: Trait.ID_AREA

[Chris Bowditch]

Tibor Vyletel wrote:
Hi guys,
 
In previous versions (builds) of FOP areas have had set ID_AREA trait in 
order to allow identification of original FONodes (and XML elements) 
they had been created from. Why is this feature missing in recent builds 
(1.0DEV)? Is there any other possibility how to connect Area --> FONode 
--> XML Element data entities?
I suspect that the ID_AREA property has been removed from FObj as a result of 
the property re-work. Perhaps one of the property gurus will be able to 
comment further.

Polite request: please dont post to the list in HTML, its considered bad 
etiquette.

Chris

RE: Trait.ID_AREA

[Andreas L. Delmelle]

> -Original Message-
> From: Tibor Vyletel [mailto:[EMAIL PROTECTED]


Hi,

> In previous versions (builds) of FOP areas have had set ID_AREA trait
> in order to allow identification of original FONodes (and XML elements)
> they had been created from.
> Why is this feature missing in recent builds (1.0DEV)?

This, I think, is because in HEAD, the Layout Managers are responsible for
adding the Areas based on the FOBjs that were used to create them.

> Is there any other possibility how to connect Area -->
> FONode --> XML Element data entities?

AFAICT, the LM doesn't provide a way to allow other objects to talk to its
FObj directly. For instance, there is a setFObj() method, but no getFObj()
that returns it (--and, come to think of it, this shouldn't be necessary)
IIC, then it should be possible to trace it up to the point where the Area
gets added to the AreaTree by the LM ( addArea() or addChild() ) Maybe you
can insert a few steps there to pass the FONode / FObj id to the Area.


Hope this offers a bit of help


Cheers,

Andreas

Re: Justification and line breaking

[Luca Furini]

Peter wrote:

> Do you know of a web-accessible version of the paper, or summary of the
> algorithm?

Unfortunately I don't.
In the bugzilla issue I'm going to try and summarize it.

Regards
Luca

DO NOT REPLY [Bug 29124] New: - 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

   Summary: New line breaking algorithm
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Ok, so here is the patch I was talking about in the fop-dev mailing list.
I'm going to attach:
- the patch concerning existing files
- 5 new .java files (diff did not consider them)
- a few test fo files showing some properties (text-indent, text-align-last, 
word-spacing & letter-spacing)
- an fo file with some long paragraphs, which can be used to make space width 
comparison; for example, HEAD and xep have very large spaces in some lines of 
the first paragraph.

I try to summarize briefly the algorithm, but I'm not so sure I can be both 
clear and exhaustive :-) 

The first step in the algorithm is converting the paragraph into a sequence of 
elements; there are 3 kind of elements:
- "box" elements, representing words or whatever else; a box has a width
- "glue" elements, representing adjustable spaces between boxes; a glue has an 
optimal width, a potential stretch and a potential shrink, i.e. its length is 
in the range [width - shrink, width + stretch]
- "penalty" items represents positions in which a line could be broken; a 
penalty has a width (i.e. the "-" width when hyphenating), a penalty value and 
a boolean; the penalty value is a kind of "aesthetic cost", and it could be a 
finite number, +infinite (where there can't be a break) or -infinite (a forced 
break); penalties with value = 0 can be omitted

For example, the text "life is beautiful" will generate the sequence:

 box - glue - box - glue - box - penalty - box - penalty - box
  ^^^   ^   ^   ^   ^
  |||   |   |   |   |
 life is   beau -   ti  -  ful

Then, the algorithm finds the breaking points:
For each element in the paragraph, it verifies if this element is a "feasible 
break", i.e. there is a previous "active" feasible break such that the 
elements between the two break can fill a line, using the available stretch 
and shrink.
If the element is a feasible break, the algorithm computes a "score" depending 
on the needed adjustment and the penalty (the lower is the score, the better 
is the break), and create a structure representing this element as an active 
feasible break.
Note that the number of active feasible break at each moment is quite small, 
as feasible breaks are deactivated if they are too close to the new one.

Some implementation notes:
1)
In order to minimize changes in other files, the LLM interacts with the TLM 
calling brand new methods that I added to the LayoutManager interface, 
providing null implementation in the AbstractLayoutManager. I also added a 
KnuthPossPosIter, which is almost a clone of BreakPossPosIter.
I think a much more elegant solution would be having the LLM call 
getNextBreakPoss, and casting the returned object to KnuthElement. Maybe 
BreakPoss and KnuthElement could be subclasses of a same class, abstract, 
containing only a Position object and the method to access it:

BreakPoss (same name, but a different class)
|
 ---
 | |
 KnuthElementTheClassPreviouslyKnownAsBreakPoss

All LM call getNextBreakPoss, but the LLM casts to KnuthElement and the other 
LM cast to "TheClassPreviouslyKnownAsBreakPoss"

2)
The letter space is at the moment set to .min = .opt and .max = .opt as there 
are a few problems with adjustable letter space (Knuth's original algorithm 
does not handle letter space); I also have some problems in counting the 
letter spaces in a hyphenated word.

3)
The LLM tries the first time to find breaking point without word hyphenation; 
only if it doesn't find a set of break points, it calls again the algorithm 
after having hyphenated all words, so this patch includes the ones concerning 
hyphenation (bug 27773) and hyphenation of word with punctuation marks (bug 
28431).
I tried to use the old information (about the whole words) as much as 
possible, but I don't know whether this saves some time or it is just an 
unneeded complication.

4)
Concerning word and letter spacing, one problem is that at the moment I see no 
way to decide whether the fo property letter-spacing (or word-spacing) was set 
to 0 (and fop should respect this value), or it wasn't set and 0 is its 
default value (and fop could modify it in order to justify).

Comments, suggestions, 

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-20 15:31 ---
Created an attachment (id=11602)
patch to existing files

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-20 15:31 ---
Created an attachment (id=11603)
KnuthElement.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-20 15:32 ---
Created an attachment (id=11604)
KnuthBox.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-20 15:32 ---
Created an attachment (id=11605)
KnuthGlue.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-20 15:32 ---
Created an attachment (id=11606)
KnuthPenalty.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-20 15:33 ---
Created an attachment (id=11607)
KnuthPossPosIter.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-20 15:34 ---
Created an attachment (id=11608)
fo test file (text-indent)

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-20 15:34 ---
Created an attachment (id=11609)
fo test file (text-align-last)

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-20 15:35 ---
Created an attachment (id=11610)
fo test file (word-spacing and letter-spacing)

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-20 15:36 ---
Created an attachment (id=11611)
fo test file (long paragraphs of text)

Markers

[Chris Bowditch]

FOP Devs,
I'm currently trying to get Markers working. The problem I have is that the 
first marker on page 2 is actually being added to the markers on Page 1.

the markers are added to pageViewport in the BLM.addAreas method. Now my 
understanding is that addAreas are called once the BPs have been processed and 
the areas are about to be rendered. So how is this possible?

Any thoughts will be appreciated?
Thanks,
Chris

RE: Markers

[Andreas L. Delmelle]

> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>


Hi Chris,


> the markers are added to pageViewport in the BLM.addAreas method. Now my
> understanding is that addAreas are called once the BPs have been
> processed and the areas are about to be rendered. So how is this possible?
>
> Any thoughts will be appreciated?
>

Just gathering my thoughts here...

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.

Maybe sheds some light on the situation. As to what needs to be done to fix
it... no particular idea for the moment.


Cheers,

Andreas

Re: Java text handling

[Glen Mazza]

Perhaps these links may be of help:

>From the Java tutorials:

http://java.sun.com/docs/books/tutorial/2d/textandfonts/index.html

http://java.sun.com/developer/onlineTraining/Media/2DText/
(Warning:  very old, from 1998)

Forums for questions:

http://forum.java.sun.com/forum.jsp?forum=20

Glen


--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> 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.
> 
> Peter
> -- 
> Peter B. West

Re: Incremental vs rewrite

[Glen Mazza]

--- Clay Leeds <[EMAIL PROTECTED]> wrote:
>
> However, I do understand the format itself pretty
> well, so if you can 
> give me 'before' and after (or a diff would be fine,
> I can commit the 
> necessary changes--committership has its
> privileges... don't worry, I 
> won't touch JAVA code 'til I've spent some time
> hashing things through!)
> 

You can commit now?  Congratulations--I guess that
means you got the CLA finished!


> Otherwise, you could always just edit the XML source
> files the way you 
> like. That should work just as well. Once the edits
> have been committed, 
> running forrestbot should do the rest (of course
> we'll have to replace 
> breadcrumb.js--D'oh!--as I think it still gets
> clobbered when forrestbot 
> runs).
> 

Yes--just replace with the earlier version:

http://marc.theaimsgroup.com/?l=fop-dev&m=108180706211726&w=2

Glen

Re: Justification and line breaking

[J.Pietschmann]

Peter B. West wrote:
Do you know of a web-accessible version of the paper, or summary of the 
algorithm?
Try the TeX book, available as TeX-source from your nearest
CTAN server. The description is, umm, somewhat obscure, you
should get the commented TeX source (the .web files) as well.
J.Pietschmann

RE: Markers

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>

> Maybe sheds some light on the situation. As to what needs to be
> done to fix it... no particular idea for the moment.
>
>

Just ran a few tests of my own, with FOP's examples/fo/markers/hide.fo, and
I could be mistaken, but looking at the code, it seems the break-before
property is broken as well ...?


Greetz,

Andreas

Re: Incremental vs rewrite

[Clay Leeds]

On May 20, 2004, at 1:13 PM, Glen Mazza wrote:
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
You can commit now?  Congratulations--I guess that
means you got the CLA finished!
Yeah... Thanks! My company took about a month to sign & FAX the 
necessary Corporate CLA, and I couldn't FAX mine in 'til it was in.

Otherwise, you could always just edit the XML source
files the way you
like. That should work just as well. Once the edits
have been committed,
running forrestbot should do the rest (of course
we'll have to replace
breadcrumb.js--D'oh!--as I think it still gets
clobbered when forrestbot
runs).
Yes--just replace with the earlier version:
http://marc.theaimsgroup.com/?l=fop-dev&m=108180706211726&w=2
Glen
Yup! that's what I figured. Then again, since I sent it... BTW, I just 
updated the issue:

http://issues.cocoondev.org/jira/secure/ViewIssue.jspa?id=10234
Web Maestro Clay

FOray integration to FOP

[Victor Mote]

FOP Devs:

I apologize for intruding again. After thrashing around for a bit, I
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.

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.

Victor Mote