Re: [PATCH] Support for percentages and table-units
[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
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
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
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
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
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
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'
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
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
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
-- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
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
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
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
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
