Re: Incremental vs rewrite

2004-05-20 Thread 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

2004-05-20 Thread 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

2004-05-20 Thread 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

2004-05-20 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=28706.
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

2004-05-20 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=29099.
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-userm=106140830410154w=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

2004-05-20 Thread 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

2004-05-20 Thread 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

2004-05-20 Thread 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

2004-05-20 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=29124.
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, etc. are most welcome!

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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 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=29124.
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

2004-05-20 Thread 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

2004-05-20 Thread Andreas L. Delmelle
 -Original Message-
 From: Chris Bowditch [mailto:[EMAIL PROTECTED]



Hi Chris,

snip /
 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

2004-05-20 Thread 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
http://www.powerup.com.au/~pbwest/resume.html



Re: Incremental vs rewrite

2004-05-20 Thread 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-devm=108180706211726w=2

Glen



Re: Justification and line breaking

2004-05-20 Thread 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

2004-05-20 Thread Andreas L. Delmelle
 -Original Message-
 From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]

snip /
 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

2004-05-20 Thread 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-devm=108180706211726w=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