Re: Properties question ( again? )
Andreas L. Delmelle wrote: fop.fo.flow.Table line 157:CommonBackground bProps = propMgr.getBackgroundProps(); line 193:this.BackgroundColor = this.propertyList.get(PR_BACKGROUND_COLOR).getColorType(); I thought porpertyList had been retired in HEAD? How should I see this? Is one of the two superfluous? Do they complement each other? Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor I'd think so. J.Pietschmann
RE: Properties question ( again? )
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] I thought porpertyList had been retired in HEAD? That's what I initially thought, but got a bit confused... Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor I'd think so. Ok. Probably means reviewing a few patches submitted recently. Thanks for the quick response. Cheers, Andreas
Re: Properties question ( again? )
[J.Pietschmann] I thought porpertyList had been retired in HEAD? PropertyListBuilder was recently removed from HEAD. [Andreas L. Delmelle] How should I see this? Is one of the two superfluous? Do they complement each other? Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor That is also my feeling. regards, finn
RE: Properties question ( again? )
Please fix it whenever you get write access. Glen --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor I'd think so. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Properties Implementation and Canonical Mappings
On Mon, 2003-12-01 at 02:45, Glen Mazza wrote: --- John Austin [EMAIL PROTECTED] wrote: The property strings are given to the Property object constructor by some path beginning with a SAX parser. It is reasonable to assume that the SAX parser loses refs to most of these strings and that the Property implementation retains the only references to these String objects. How big are String Objects ? At least 16 bytes plus storage for characters. What does this save us ? Probably only about 1,600,000 bytes for this file. CPU cost of creating strings is probably similar to cost of checking string table for a copy. Just to clarify, the (additional?) CPU cost you mentioning above is *not* occurring for the present process, correct? I think you're referring to the cost that would be added as a result of the changes you're recommending (because there now will be a string table search to avoid duplication). Going back to the beginning of my involvement, I found this issue because Property searches are the high-runner for CPU in FOP. I don't want to split hairs in isolation over which search/constructor sequence is faster. I want to remove the conditions that cause the current pathology. Hash table lookups are FAST. When we invest in object creation we recover many times over in the end. Also, the string table you mention--I think you're speaking generically, but is there a specific, already available construct in Java that we can use for this purpose in FOP? I'd like to find out what you have in mind for a specific implementation. HashMap works fine the way Peter has it set up in alt-design. I use the same construct in the Perl code I use to analyze the large sample FO files. -- John Austin [EMAIL PROTECTED]
Re: Properties Implementation and Canonical Mappings
Input: The XSL-FO file produced from: DocBook: The Definitive Guide Document size: 648 Pages // for the O'Reilly edition FO file size: 21,659,370 bytes Properties: 526,648 Tags: 285,223 Height of tree: 17 // max height of the parse tree Unique prop names: 117 // bounded by the spec Unique prop values: 13,520 // bounded by the real world Using these numbers, we can explore the sort of benefits to expect from revised Property implementation. With over a million strings, the FOTree for this document would use forty or fifty Mb in addition to data structures. This document can be used as an example even though it probably can't be formatted (yet) by FOP. It has a lot of tables. It could be a goal of the FOP project to generate this well-known document. I was thinking of using the XSL-FO spec from the W3C web site but couldn't find the stylesheet to make the FO file. If anyone knows where to find them, please let me know. Statistics from this file: Number of Elements by tree level: level=1 count=1 level=2 count=473 level=3 count=5242 level=4 count=5480 level=5 count=7129 level=6 count=26231 level=7 count=22475 level=8 count=36447 level=9 count=62288 level=10 count=38536 level=11 count=30486 level=12 count=23641 level=13 count=23190 level=14 count=2023 level=15 count=771 level=16 count=701 level=17 count=109 Element frequencies: a 24 I wonder where this came from fo:basic-link 5225 fo:block 112142 fo:conditional-page-master-reference 48 fo:external-graphic 1097 fo:flow 472 fo:footnote 22 fo:footnote-body 22 fo:inline 62792 fo:layout-master-set 1 fo:leader 1764 fo:list-block 279 fo:list-item 1004 fo:list-item-body 1004 fo:list-item-label 1004 fo:marker 5335 fo:page-number 1872 fo:page-number-citation 3224 fo:page-sequence 472 fo:page-sequence-master 12 fo:region-after 38 fo:region-before 38 fo:region-body 38 fo:repeatable-page-master-alternatives 12 fo:root 1 fo:simple-page-master 38 fo:static-content 4720 fo:table 6497 fo:table-body 6497 fo:table-cell 33174 fo:table-column 19225 fo:table-footer 1 fo:table-header 29 fo:table-row 15301 fo:wrapper 1799 Properties: 526648 Tags: 285223 num_keys: 117 num_vals: 13520 -- John Austin [EMAIL PROTECTED]
Re: Properties Implementation and Canonical Mappings
--- John Austin [EMAIL PROTECTED] wrote: The property strings are given to the Property object constructor by some path beginning with a SAX parser. It is reasonable to assume that the SAX parser loses refs to most of these strings and that the Property implementation retains the only references to these String objects. How big are String Objects ? At least 16 bytes plus storage for characters. What does this save us ? Probably only about 1,600,000 bytes for this file. CPU cost of creating strings is probably similar to cost of checking string table for a copy. Just to clarify, the (additional?) CPU cost you mentioning above is *not* occurring for the present process, correct? I think you're referring to the cost that would be added as a result of the changes you're recommending (because there now will be a string table search to avoid duplication). Also, the string table you mention--I think you're speaking generically, but is there a specific, already available construct in Java that we can use for this purpose in FOP? I'd like to find out what you have in mind for a specific implementation. Thanks, Glen __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: Properties Implementation and Canonical Mappings
John Austin wrote: In the interest of contributing (instead of just trashing) to the proposed implementation, I wrote a simple Perl script to get some counts out of a real-world XSL-FO file. Input: The XSL-FO file produced from a DocBook file I have left from a dormant project. The perl program counts the number of properties in the source file. PDF size: 130 Pages // some users have a lot more FO file size: 1.2M bytes Properties: 22,815 Unique prop names: 89 // bounded by the spec Unique prop values: 2,227 // bounded by the real world Note that storing the property name and value refs supplied to the Property constructor will use 45,620 strings. If the Property implementation employs canonical mapping to ensure that only one copy of each unique string is stored, then just over 2,300 strings are required. The property strings are given to the Property object constructor by some path beginning with a SAX parser. It is reasonable to assume that the SAX parser loses refs to most of these strings and that the Property implementation retains the only references to these String objects. How big are String Objects ? At least 16 bytes plus storage for characters. What does this save us ? Probably only about 1,600,000 bytes for this file. CPU cost of creating strings is probably similar to cost of checking string table for a copy. What does it buy for us ? Bounds a source of current Order(n) memory growth. It gets us in the habit of using another good technique. I am all ready thinking along the lines of: The property lists for these FO's are usually generated by programs and will be the repeated many times. Perhaps we could use larger, faster working Property Lists consolidated with Canonical Mappings to save both time and space. I am thinking again along the lines of handling properties more like C++ virtual function table (vTable). This object is larger than Peter's ordered Property array, but would be faster. That's a reason C++ has fast virtual function dispatching.
Re: Properties Implementation and Canonical Mappings
Darn, racall the last post. John Austin wrote: Note that storing the property name and value refs supplied to the Property constructor will use 45,620 strings. If the Property implementation employs canonical mapping to ensure that only one copy of each unique string is stored, then just over 2,300 strings are required. Have a look at String.intern() J.Pietschmann
Re: Properties Implementation and Canonical Mappings
On Sat, 2003-11-29 at 16:35, J.Pietschmann wrote: Darn, racall the last post. John Austin wrote: Note that storing the property name and value refs supplied to the Property constructor will use 45,620 strings. If the Property implementation employs canonical mapping to ensure that only one copy of each unique string is stored, then just over 2,300 strings are required. Have a look at String.intern() Bruce Eckel said not to trust it for some reason. I have 2nd Ed of Thinking in Java and the online one is 3rd Ed so I haven't found chapter and verse for this yet. The only 'bad thing' said about it that I could find quickly was: http://mindprod.com/jgloss/gotchas.html The other good thing we can do is compare these string refs for equality. J.Pietschmann -- John Austin [EMAIL PROTECTED]
Re: Properties of PDF Documents
Ing. Atilio Ranzuglia Buteler wrote: i'm looking for information about the following: - is the any way in securing a pdf document. to prohibit that a user selects and copies the text? - can the printer be selected from the pdf document? I doubt this has something to do with fop, look for info about pdf format at planetpdf.com, for example. -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties of PDF Documents
the thing is that i'm producing the pdf document with fop, otherwise i'll be looking for information about the pdf specification --- Oleg Tkachenko [EMAIL PROTECTED] wrote: Ing. Atilio Ranzuglia Buteler wrote: i'm looking for information about the following: - is the any way in securing a pdf document. to prohibit that a user selects and copies the text? - can the printer be selected from the pdf document? I doubt this has something to do with fop, look for info about pdf format at planetpdf.com, for example. -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties of PDF Documents
Ing. Atilio Ranzuglia Buteler wrote: the thing is that i'm producing the pdf document with fop, otherwise i'll be looking for information about the pdf specification fop cannot accomplish what you want, but you can postprocess generated pdf by some pdf-oriented library (iText is the most mentioned), see PDF encryption example by J.Pietschmann at http://marc.theaimsgroup.com/?l=fop-devm=102002975028427w=2. -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
Not really. As a fairly interested party, I must admit that mentions of throwing it out and starting over don't leave me totally indifferent, but I've got little enough time as it is for FOP these days, and I'm trying not to let myself be distracted. In any case, we all know that it's never right the first time around. Regards, Karen Peter B. West wrote: Hello devs. Does the near-silence on this one signify consent? Peter Keiron Liddle wrote: Hi Peter and others, What is the status of property handling? Are we going to go with Peter's suggestion and commit the java source to cvs and work on handling properties fully from there? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
Karen, I was your opinion that I was most concerned about on this one. I, for one, am quite happy to hold off to give you more time to make an argument. Part of my point was that it *was* in pretty good shape the first time around. Peter Karen Lease wrote: Not really. As a fairly interested party, I must admit that mentions of throwing it out and starting over don't leave me totally indifferent, but I've got little enough time as it is for FOP these days, and I'm trying not to let myself be distracted. In any case, we all know that it's never right the first time around. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
Hello devs. Does the near-silence on this one signify consent? Peter Keiron Liddle wrote: Hi Peter and others, What is the status of property handling? Are we going to go with Peter's suggestion and commit the java source to cvs and work on handling properties fully from there? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
On Wednesday 01 May 2002 18:19, Peter B. West wrote: Does the near-silence on this one signify consent? I don't know enough about this to give meaningful advice, so in my case yes, silence means consent. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
Bertrand Delacretaz wrote: On Wednesday 01 May 2002 18:19, Peter B. West wrote: Does the near-silence on this one signify consent? I don't know enough about this to give meaningful advice, so in my case yes, silence means consent. Yes, it ought to be a reasonable idea. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
What is the status of property handling? Are we going to go with Peter's suggestion and commit the java source to cvs and work on handling properties fully from there? +1. As this is a section largely separate from the layout then it is a good area to work on independantly. After all, there are lots of properties that need handling ranging from easy to very hard. My hope is that this part will become more simple to understand and to handle. Until recently, I've mostly been able to stick to the rendering part of FOP. But I see myself going into the other parts more and more (I'm still trying to understand overflow/clipping). You might also remember the recent posts about padding and border. I went lost trying to understand why this really happens (actually, I haven't invested that much time in that). Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties documentation
On 2002.01.02 15:10 Peter B. West wrote: Keiron, Thanks for clueing me up on the documentation. I strongly accept you recommendation, and I will gladly use it in future. Btw, the heading graphics from the the design documents seem to have been screwed up. Have you noticed this? Yes, I noticed. I figured that that it would be easier to way for the new website design than to delve into the outdated stylebook. The new design will look quite different without all the images etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties documentation
Hi Peter, Thanks for the work. Maybe this can go with the rest of the design. I would strongly suggest that you do not write the html. The apache web site is done from xml and all the images, layout etc. is done from a stylesheet. These will also be updated by others. If you look at docs/xml-docs/fop/*.xml this is the xml format. It is converted by stylebook (will become cocoon soon) into the html. On 2001.12.29 02:57 Peter B. West wrote: Dear list, After sepnding some days wrestling with various graphics tools in linux in an attempt to make html that looked like the standard apache documentation, I finally surrendered and made do with CSS to create a facsimile that should be sufficient for this list. It works with a recent Mozilla build, and should probably work with IE5.something. I have made some notes and some semi-UML diagrams to illustrate the approach I have been taking to the implementation of properties. These can be found at http://home.iprimus.com.au/pbwest/xml-fop/docs/html-docs/design/properties-new.html. lease let me know if there is some easy way to get full conformance with the Apache XML norm, or if there are severe problems viewing these pages with modern browsers. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties documentation
Bernard, Thanks for that. I have just had a long day trying to make the html at least readable under Navigator 4.75. Isn't html wonderful? I have also tried the current Opera 5.0 release on linux, with reasonable results. The problem with using CSS is that the actual font sizes on a particular browser are still unpredictable. Peter Bertrand Delacretaz wrote: On Saturday 29 December 2001 02:57, Peter B. West wrote: . . .let me know if there is some easy way to get full conformance with the Apache XML norm, or if there are severe problems viewing these pages with modern browsers. Hi Peter, FYI, with Konqueror (modern yes, 100% finished maybe not), the PNG images (like in PropertyConsts.html) aren't displayed, but right-clicking them allow them to be opened in the image viewer. Maybe a mime-type problem? The pages look fine with IE5. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties documentation
On Saturday 29 December 2001 02:57, Peter B. West wrote: . . .let me know if there is some easy way to get full conformance with the Apache XML norm, or if there are severe problems viewing these pages with modern browsers. Hi Peter, FYI, with Konqueror (modern yes, 100% finished maybe not), the PNG images (like in PropertyConsts.html) aren't displayed, but right-clicking them allow them to be opened in the image viewer. Maybe a mime-type problem? The pages look fine with IE5. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties, elements
On Thu, 12 Jul 2001 22:50:44 Karen Lease wrote: A few quick thoughts... That was probably just my XML super-ego thinking that case-by-case checks were a _bad_ thing... But on the other hand, as Arved points out, the complexity of the model would make it rather problematic. It's certainly more important to focus on detecting cases which FOP (or FO) can't or isn't supposed to handle and giving some kind of comprehensible message to the user, rather than getting hung up on formal correctness. I was thinking along the lines of some simple hashmaps (tables) containing which elements are allowed as a child for the current element and which are not allowed as a descendant, which is passed down to the children. This includes sets such as block and inline. The attribute constraint example is more difficult and will we run into a problem handling the situation anyway. So the error handling could be left until the problem is encountered. We also need to think about what to do when we encounter this kind of case. Obviously we want to inform the user. We could either stop on an exception or just ignore the offending FO and keep going. Usually a spec has a section on how the processor should handle errors but I couldn't find it in the XSL spec. Anyway, I think I will create a document with all the constraint info for all the elements. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties, elements
At 11:21 AM 7/13/01 +0200, Keiron Liddle wrote: On Thu, 12 Jul 2001 22:50:44 Karen Lease wrote: We also need to think about what to do when we encounter this kind of case. Obviously we want to inform the user. We could either stop on an exception or just ignore the offending FO and keep going. Usually a spec has a section on how the processor should handle errors but I couldn't find it in the XSL spec. You're right, doesn't seem to be anything said about content-model errors. I like the idea of trying to help out the user; I would say that we ignore the offending FO (and all descendants), with a warning (line, column, name, and short explanation if possible), and continue if possible. For example, let's say that someone's XSL has produced FO with a page-sequence containing not only an fo:flow and a couple of fo:static-contents, but a top-level fo:block by mistake. I can see errors happen fairly often as people work up stylesheets. The user-friendly thing to do would be to emit a warning about the fo:block, and continue checking the tree. Maybe we'd catch several independent errors that way, and help the user speed up the debugging/correction process. One thing to consider is stopping the process after refinement, but before layout, if there are any content-model errors. Or maybe all of this can be subject to user control? Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties, elements
A few quick thoughts... That was probably just my XML super-ego thinking that case-by-case checks were a _bad_ thing... But on the other hand, as Arved points out, the complexity of the model would make it rather problematic. It's certainly more important to focus on detecting cases which FOP (or FO) can't or isn't supposed to handle and giving some kind of comprehensible message to the user, rather than getting hung up on formal correctness. We can do some global checking in the end method if that's necessary. That lets us look at all the descendants of an FO. The other way to look at constraints like the footnote one (or more generally, no floats beneath other floats - Dieu merci!) is from the ancestor point of view. When an FO is created, it knows what its parent will be even though it isn't yet on that parent's child list. So a footnote or float FO can check to see if has a footnote or float ancestor. We also need to think about what to do when we encounter this kind of case. Obviously we want to inform the user. We could either stop on an exception or just ignore the offending FO and keep going. Considering the property validity checks, I haven't touched that stuff in ages. In general there are warning messages for values that aren't convertible into one of the expected types. Most properties are just assumed to be valid for all elements unless they are explicitly associated with a particular element or elements. There are still lots of values which aren't handled, including the famous inherit keyword for all properties. In short, there is still plenty of work in there for some enterprising person(s). Regards, Karen Arved Sandstrom wrote: At 10:25 PM 7/11/01 +0200, Karen Lease wrote: Keiron Liddle wrote: Then after that I will see about handling the element child constraints (I haven't worked out how this should be done yet, any ideas) and doing a similar thing (to be impl.) with the rest of the elements that we don't have yet. For things like tables, I had been thinking of handling child type checking in the addChild method. That way we can give messages early in the game and also do special things like handling different children in special ways. An example is when table-cell FO are directly under a table-body (or header or footer) rather than in a table-row. In that case, I think it would be better to create a fake row to hold them. That kind of work is logically done during FO tree building. However that's rather a piecemeal approach. Perhaps it would be good to describe (schema? DTD?) the possible child types and have the base class implementation do that kind of checking. Just my .02 euros! I wonder if we should bother with formal parse-time validation at all (i.e. the schema/DTD idea). We already know that inheritable properties complicate the attribute issue, and then we also know that there are enough formatting objects with special content constraints that why even bother? I suggest letting the existing (and improved as required) properties refinement mechanism worry about checking property validity (Karen, maybe you can give us a state of the union as to where we stand on this?), and as Karen also mentioned, let's build in our own checking mechanism. My contribution to Karen's comments is merely to argue for not even bothering with schemas or DTDs at all. Perhaps we should winnow out all the rules from the spec into one document, and that should give us a 10,000 ft view of what we are faced with. That might lead us to an efficient approach, or suggest certain base-class checking shortcuts rather than sub-class checking. For example, among the variety of things we have are: 1) fo:wrapper - (#PCDATA|%inline;|%block;)* An fo:wrapper is only permitted to have children that would be permitted to be children of the parent of the fo:wrapper, with two exceptions: * An fo:wrapper may always have a sequence of zero or more fo:markers as its initial children. * An fo:wrapper that is a child of an fo:multi-properties is only permitted to have children that would be permitted in place of the fo:multi-properties. This restriction applies recursively. 2) fo:footnote Contents: (inline,footnote-body) An fo:footnote is not permitted to have an fo:float, fo:footnote, or fo:marker as a descendant. Additionally, an fo:footnote is not permitted to have as a descendant an fo:block-container that generates an absolutely positioned area. 3) fo:table-header Contents: (table-row+|table-cell+) The fo:table-header has fo:table-row (one or more) as its children, or alternatively fo:table-cell (one or more). In the latter case cells are grouped into rows using the starts-row and ends-row properties. In addition this formatting object may have a sequence of zero or more fo:markers as its initial children. I do not get the feeling that we have a comprehensive or consistent system for enforcing these content rules. Note
Re: properties, elements
Keiron Liddle wrote: Then after that I will see about handling the element child constraints (I haven't worked out how this should be done yet, any ideas) and doing a similar thing (to be impl.) with the rest of the elements that we don't have yet. For things like tables, I had been thinking of handling child type checking in the addChild method. That way we can give messages early in the game and also do special things like handling different children in special ways. An example is when table-cell FO are directly under a table-body (or header or footer) rather than in a table-row. In that case, I think it would be better to create a fake row to hold them. That kind of work is logically done during FO tree building. However that's rather a piecemeal approach. Perhaps it would be good to describe (schema? DTD?) the possible child types and have the base class implementation do that kind of checking. Just my .02 euros! Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]