Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Finn Bock
[me]

If an expression reference another expression in a parent fo, the 
parent fo expression must be evaluated against the LayoutContext that 
was in effect for the parent fo and *not* against the child fo 
LayoutContext.

fo:block id=a border-start-width=10%
   fo:block id=b border-start-width=inherit
   /fo:block
/fo:block
It must be the LayoutContex for 'a' that is used when we evaluate the 
10% even when we call:
propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.
[J.Pietschmann]

Well, I used to believe the 10% has been evaluated already, and the
inherited property can grab the absolute value immediately.
If it is evaluated already where would the evaluated value be stored? In 
the propertyList (aka the FO tree)? And then the value should be 
reverted to the expression when the base value changes due to breaks.

Storing the resolved value would IMO remove all the benefits from 
passing in a context parameter to getValue().

Perhaps it can be done that way too, but it is very different from my 
proposal.

regards,
finn


DO NOT REPLY [Bug 27107] New: - TTF Reader fails

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27107

TTF Reader fails

   Summary: TTF Reader fails
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Reading fonts/BERLIN.TTF...

Number of glyphs in font: 119
Unicode cmap table not present
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:507)
at java.util.ArrayList.get(ArrayList.java:324)
at org.apache.fop.fonts.TTFFile.createCMaps(TTFFile.java:449)
at org.apache.fop.fonts.TTFFile.readFont(TTFFile.java:439)
at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:222)
at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:184)


I found that the TrueType file contains a cmap table with platformID=3 and
encodingId=0 (Windows Symbol encoding, or whatever).

TTFReader expects encodingId = 1. However, the table contains readable data in
the correct format (format 4). After patching TTFFile.java, it created a
perfectly valid metrics file.

I might suggest that you apply this patch to org.apache.fop.fonts.TTFFile, line 185:

   if (cmap_pid == 3  (cmap_eid == 1 || cmap_eid == 0))


DO NOT REPLY [Bug 27107] - TTF Reader fails

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27107

TTF Reader fails





--- Additional Comments From [EMAIL PROTECTED]  2004-02-20 12:31 ---
Created an attachment (id=10453)
TrueType font with cmap (3,0)


DO NOT REPLY [Bug 27111] New: - basic-link after some elements/attributes does not render hyperlink in output PDF

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27111

basic-link after some elements/attributes does not render hyperlink in output PDF

   Summary: basic-link after some elements/attributes does not
render hyperlink in output PDF
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A) normal example (under flow):

fo:block-container border-color=#E0F0E0 background-color=#F0F0F0 border-
style=solid/
fo:block
fo:basic-link color=green external-destination=url
('http://xml.apache.org/fop')http://xml.apache.org/fop/fo:basic-link
/fo:block

...in output PDF is all OK - WEB link is working.

B) problem example modification (under flow):

I add only one attribute padding=1cm to fo:block-container element...

fo:block-container border-color=#E0F0E0 background-color=#F0F0F0 border-
style=solid padding=1cm/
fo:block
fo:basic-link color=green external-destination=url
('http://xml.apache.org/fop')http://xml.apache.org/fop/fo:basic-link
/fo:block

...and the link in output PDF not work now!

Leos


Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread J.Pietschmann
Finn Bock wrote:
If it is evaluated already where would the evaluated value be stored?
The layout context for the child LM could be an appropriate place.

And then the value should be 
reverted to the expression when the base value changes due to breaks.
No problem, this is known at the place where a new Layout context is
created for getting BP from the child LM.
J.Pietschmann


Re: Java thory and proctice: Garbase collection and performance

2004-02-20 Thread J.Pietschmann
John Austin wrote:
Isn't allocation the only unseen part of construction ? Everything
else is visible in the code and surely a few assignments are never
expensive. Any other expensive operations will stand out in
measurements of code execution.
That's correct. However, the article seemed to shout Don't
worry about creating as much objects as you want, which I
wouldn't support if taken literally. You are right that
proper tools should uncover any additional overhead though.
Moore's law is another optimization we sell in advance
all the time.
*bg*
Twenty years ago, I had to work on a 8008 driven computer
with 4k RAM and 12k ROM. That's enough to run a program
which nicely prints formatted and justified text (25 lines
a 80 characters). We went a lng way since then.
J.Pietschmann



Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Finn Bock
If it is evaluated already where would the evaluated value be stored?
[J.Pietschmann]

The layout context for the child LM could be an appropriate place.
The resolved property values of the parents should be stored in the 
layout context? I must be missing something here!

And then the value should be reverted to the expression when the base 
value changes due to breaks.
No problem, this is known at the place where a new Layout context is
created for getting BP from the child LM.
I don't understand how you propose to solve any of this, but I hope it 
would be Ok to commit the straight forward solution I propose. Then you 
can change it at a later time to pass in the LayoutContext as a 
parameter to Length.getValue().

regards,
finn


DO NOT REPLY [Bug 23509] - Problem with marker 'first-starting-within-page'

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23509

Problem with marker 'first-starting-within-page'

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|Other   |Medium



--- Additional Comments From [EMAIL PROTECTED]  2004-02-20 21:32 ---
Same problem with retrieve-marker first-including-carryover, seem to start 
with the second marker. 

You can test it with the glossary.xml exemple that come with FOP. The first 
retrieve-marker on line 31 of the glossary.xsl file retrieve the same marker 
either with first-including-carryover or first-starting-within-page. 

Blaise Garant


Re: Java thory and proctice: Garbase collection and performance

2004-02-20 Thread John Austin
On Fri, 2004-02-20 at 15:46, J.Pietschmann wrote:

 *bg*
 Twenty years ago, I had to work on a 8008 driven computer
 with 4k RAM and 12k ROM. That's enough to run a program
 which nicely prints formatted and justified text (25 lines
 a 80 characters). We went a lng way since then.

I went to a presentation on the Mars Rover's at the St John's GeoCentre
which is one of the sites that NASA has granted access to the FTP site
for fresh Images ...

Comparing the old Mars projects to the new stuff ...

That was FORTRAN ... This is Java.


I recall hearing about a court case in which the Canadian Military were 
suing a supplier about something as trivial nowadays as 8K of memory.

-- 
John Austin [EMAIL PROTECTED]


Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Simon Pepping
On Thu, Feb 19, 2004 at 08:52:41AM +0100, Finn Bock wrote:
 If an expression reference another expression in a parent fo, the parent 
 fo expression must be evaluated against the LayoutContext that was in 
 effect for the parent fo and *not* against the child fo LayoutContext.
 
 fo:block id=a border-start-width=10%
fo:block id=b border-start-width=inherit
 
/fo:block
 /fo:block
 
 It must be the LayoutContex for 'a' that is used when we evaluate the 
 10% even when we call:
 propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
 with the layout context for 'b'.

The present code contains a partial implementation of percent based
properties, e.g. in fo:leader, leader-length. This implementation
indeed uses the context layout for the base dimensions with respect to
which a relative property is calculated. The ipd of the containing
block is retrieved from it and is propagated to the method that
calculates the actual leader length:

LeafNodeLayoutManager.getNextBreakPoss:
  ipd = getAllocationIPD(context.getRefIPD());
AddLMVisitor.getLeaderAllocIPD:
  node.getLength(Constants.PR_LEADER_LENGTH | Constants.CP_MAXIMUM, ipd);
Leader.getLength:
  length = (int)(((PercentLength) maxlength).value() * dim);

where dim = ipd = context.getRefIPD().

I realized that this is wrong for exactly the above reasons. If the
percent expression is specified on an ancestral FO, the current
implementation fails to see this and always calculates it on the basis
of the ipd of the current containing block. See this example:

fo:flow flow-name=xsl-region-body
  fo:block leader-length=30% leader-pattern=rule
fo:leader/
fo:block margin-left=60pt margin-right=60pt
  fo:leader/
  fo:blockThis is a block with a leader and a block with left
  and right margins of 60pt. The latter block contains a leader and
  this text. The leader length is specified as 30% on the topmost
  block./fo:block
/fo:block
  /fo:block
/fo:flow

The 30% must be calculated w.r.t. the page width for both leaders, and
both leaders must be equally wide. This is not the current result.

When I tried to remedy this, I got confused by the sets of symbols on
PercentBase and on LengthBase. Why are there 2 sets of symbols?  They
are mapped onto each other in LengthBase.getBaseLength(), but not all
symbols are mapped, e.g. LengthBase.CONTAINING_BOX, which is used by
leader-length, has no corresponding action. Some further integration
of old and new code must be done here.

Question: What to do if I insert a fo:wrapper between fo:flow and
fo:block? That makes it the parent of fo:block, but it has no layout
manager corresponding to it. Override getLayoutDimension on it?

 But for now I think we should just use the FO tree and later change the 
 signature of getValue() to take some kind of context parameter when a 
 real need arise.

I agree.  I am now convinced that your solution is simple, practical
and robust. You demonstrated that it deals properly with FOs that
generate more than one area. You also demonstrated that the
LayoutContext idea is insufficient. Holding layout information in the
Layout Managers is more pure, but indeed not absolutely necessary.

Regards,
Simon Pepping

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Simon Pepping
On Wed, Feb 18, 2004 at 04:00:26PM -0800, Glen Mazza wrote:
 In general, yes, but not as 100%.  We had this debate
 for months, with Victor holding fast to your view on
 the issue.  We've done more spec research since then
 (I encourage you to read the parts of the spec I
 indicated in my posting) which support the view of
 Alt-Design (and probably still HEAD), that FOT  AT
 interact with each other and can't be separated, and
 for performance reasons, shouldn't be either.

I agree with you that the spec demands a close interaction of FOT 
AT. I interpret that mainly in terms of the process, which switches
between building the FO tree and building the area tree. It does not
necessarily mean that information should flow in both directions.

Regards,
Simon Pepping

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Test - please ignore

2004-02-20 Thread Peter B. West
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Peter B. West
Re-sending due to mailer problems.

Peter

 Original Message 
Subject: Re: [PATCH] Support for percentages and table-units
Date: Thu, 19 Feb 2004 12:48:59 +1000


Andreas L. Delmelle wrote:
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
In my view FOP consists of a number of subsystems that are ordered
from upstream to downstream. The FO tree is the most upstream system,
the area tree (or objects that are constructed by a renderer) is the
most downstream system.


Indeed, but...


Information should flow downstream, not
upstream.


(Hmm. Isn't there an Aussie in this house who disagrees? Callbacks, Peter?
;) Nah, bad example...)
Thanks Andreas.  Yes, I disagree, but then, so does the spec.  What
information *should* do is not terribly relevant.  We need to work out
and express what information *must* do to get this thing working.
...
Basic point: the preferred direction of the information flow depends (almost
entirely) upon the relationship between the up- and downstream events that
is being
Yep.  (Even without the end of the sentence.)

You are IMO very correct by stating that 'if the Layout info can be reused,
so can the AT and the renderer', however, if I interpret correctly, the
latter two are designed to dispose of their created objects ASAP.
The downstream objects hold a reference to the upstream ones, not the other
way around --unless you have a way out of there, as long as a certain
page-sequence is referenced, the entire Layout/AT/Renderer structure would
exist in memory, which can get .. quite large even for moderately sized
documents. Would it really be worth a shot to change the design there, and
flip a switch? Throw the FOTree away and just fill up the AT and re-use
that?
Or process the minimal relevant parts of the FO and Area trees in
parallel.  That is what I am working towards.  I believe that
page-at-a-time layout with just in time processing of the FOs is
possible.  Given that, both FOs and Areas can be kept alive while
required.  (I haven't given any thought to rendering.)  Note that
forward references are always going to be a problem, but that a
combination of weak/soft/phantom references and serialization should
keep memory requirements manageable.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

2004-02-20 Thread Peter B. West
Re-resending...

 Original Message 
Subject: Re: DO NOT REPLY [Bug 26778]  - [PATCH] Support for percentages
and table-units
Date: Fri, 20 Feb 2004 08:05:20 +1000
Simon Pepping wrote:
I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
	  v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)
Finn,

Can you describe your expression tree in more detail?

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Peter B. West
Re-resending...

 Original Message 
Subject: Re: [PATCH] Support for percentages and table-units
Date: Fri, 20 Feb 2004 19:07:06 +1000
Finn Bock wrote:
[me]

If an expression reference another expression in a parent fo, the 
parent fo expression must be evaluated against the LayoutContext that 
was in effect for the parent fo and *not* against the child fo 
LayoutContext.

fo:block id=a border-start-width=10%
   fo:block id=b border-start-width=inherit
   /fo:block
/fo:block
It must be the LayoutContex for 'a' that is used when we evaluate the 
10% even when we call:
propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.


[J.Pietschmann]

Well, I used to believe the 10% has been evaluated already, and the
inherited property can grab the absolute value immediately.


If it is evaluated already where would the evaluated value be stored? In 
the propertyList (aka the FO tree)? And then the value should be 
reverted to the expression when the base value changes due to breaks.

Storing the resolved value would IMO remove all the benefits from 
passing in a context parameter to getValue().

Perhaps it can be done that way too, but it is very different from my 
proposal.
In principle, no area-based percentage can benefit from a one-off
resolution until all of its children have been fully laid out.  The
children inherit the computed value, but that value may change during
the layout life of the parent in question.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Peter B. West
Re-resending...

 Original Message 
Subject: Re: [PATCH] Support for percentages and table-units
Date: Fri, 20 Feb 2004 21:20:52 +1000
Finn,

When I apply your most recent patch (10366) against a cvs updated HEAD
tree and attempt to compile, I get the following:
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: 

org.apache.fop.fo.properties.LinearCombinationLength is not abstract and
does not override abstract method getValue() in
org.apache.fop.datatypes.Length
[javac] public class LinearCombinationLength extends LengthProperty {
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:96: 

cannot resolve symbol
[javac] symbol  : method setComputedValue (int)
[javac] location: class
org.apache.fop.fo.properties.LinearCombinationLength
[javac] setComputedValue(result);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:64: 

org.apache.fop.fo.properties.MixedLength is not abstract and does not
override abstract method getValue() in org.apache.fop.datatypes.Length
[javac] public class MixedLength extends LengthProperty {
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:89: 

cannot resolve symbol
[javac] symbol  : method isComputed ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] if (!l.isComputed()) {
[javac]   ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:93: 

cannot resolve symbol
[javac] symbol  : method setComputedValue (int,boolean)
[javac] location: class org.apache.fop.fo.properties.MixedLength
[javac] setComputedValue(computedValue, bAllComputed);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:109: 

cannot resolve symbol
[javac] symbol  : method resolveTableUnit (double)
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] ((LengthProperty)
e.nextElement()).resolveTableUnit(dTableUnit);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:136: 

cannot resolve symbol
[javac] symbol  : method asNumeric ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] numeric = l.asNumeric();
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:139: 

cannot resolve symbol
[javac] symbol  : method asNumeric ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] NumericProperty sum =
numeric.add(l.asNumeric());
[javac]^
[javac] 8 errors
Is there a patch I have missed.  I tried applying the earlier patch
first, but then the second patch is reported as already/applied/reversed.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html