Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
Hi, Manuel Mall a écrit : On Wednesday 18 July 2007 02:58, Andreas L Delmelle wrote: snip/ Interestingly Java 1.5 has added the Integer.valueOf(int) method with the following comment: Flyweight pattern. That's what I was looking for before replying to Andreas' commit, and I was surprised to not find it in the 1.4 standard library. A good thing it finally got added. Returns a Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values. Obviously we can't use it because of backwards compatibility with 1.4 but it seems to address, to some extent, the performance issue you tried to solve. Indeed. And with the auto-boxing of primitive types we wouldn't even see those ugly new Integer(...) anymore. And guess what? The compiler makes use of Integer.valueOf() for auto-boxing. Shall we launch a poll on fop-user about abandoning support for 1.4 and require 1.5 as a minimum? :-] Vincent PS: BTW, thanks for your understanding, Andreas!
Re: Remove Useless Comments
Hi Andreas, Andreas L Delmelle a écrit : On Jul 14, 2007, at 15:59, Vincent Hennebert wrote: Vincent Andreas L Delmelle a écrit : Tested locally, and is OK here. If you'd like, I can run a sanity diff later tonight, and commit the changes sometime tomorrow. Thanks, Andreas. We should perhaps just wait a couple of days, just to be sure everybody's ok with that? Concerning these javadoc changes I'm going to commit tomorrow (Wednesday) evening: Do I apply the changes to the release branch, to the trunk or both? Only the trunk. They are not functional changes so don't need to figure in the 0.94 release. Only (urgent) bug corrections should be merged in the branch now. BTW, the proper use of inheritDoc seems to be like the following: /** [EMAIL PROTECTED] */ public void someMethod() and not /** @inheritDoc SuperClass#someMethod() */ public void someMethod() Javadoc doesn't seem to be troubled by the latter and gives the same result, but Eclipse only displays SuperClass#someMethod() in the tooltip in this case. Not really an improvement :-( Can you check this? Thanks, Vincent
DO NOT REPLY [Bug 37157] - Port fox:destination to FOP Trunk
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=37157. 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=37157 --- Additional Comments From [EMAIL PROTECTED] 2007-07-18 02:58 --- Nope, the documentation has not been updated, yet. :-( -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: FontSources
On 17.07.2007 11:36:42 Vincent Hennebert wrote: Hi Adrian, I'm not really a specialist of the font handling stuff in FOP, but having worked a bit in this area I can drop a few ideas (and ask a few naive questions), in the hope they will be useful. In the process of looking at this bug (http://issues.apache.org/bugzilla/show_bug.cgi?id=42861) I came to the conclusion that I´m not really happy with the current font handling implementation. There is quite a bit of duplicated effort between the renderers with regards to font configuration. Can you give some examples? Not that I don't believe you, just to have some concrete things to discuss about. For example, IIRC, in PDFFactory there is some code to read the font stream for embedding it. I guess there is about the same code in the PS renderer for embedding TrueType fonts. That job should really be deferred to the font library which would directly provide the stream to those renderers that need it. Is that what you're thinking of? I would very much like to see a shared ¨FontSource¨ implementation (e.g. both the Postscript and PDF renderers could make use of a shared Base14FontSource and CustomFontSource) instead of having their own separate configurations. Any new implementation would of course What would a FontSource exactly correspond to? What would be the different kinds of FontSources? Links to my posts on this matter back in 2003: http://wiki.apache.org/xmlgraphics-fop/FOPFontSubsystemDesign http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200311.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200311.mbox/[EMAIL PROTECTED] (the third link contains a list of those FontSources but it's incomplete now that we have AFP, too.) Would a Base14FontSource really make sense? I mean, base14 fonts are PDF- (and, to a certain extent, PS-) specific. Does a PDF renderer really need to know that it's manipulating a base14 font? Isn't it just enough to know whether the font should be embedded or not? No, in the case of PDF, for example, there's a difference in handling between the base 14 fonts and a normal Type 1 font (see PDFFactory.makeFont()). Base 14 fonts don't have a font descriptor. In PostScript, it's the same although you don't have to define the base 14 font at all, just use it. Jeremias has been having some ideas regarding font handling for some time. You can probably find some of them by looking at the archives [1]. I hope he'll have time to speak up but, if I remember well, he wants to group fonts by kinds: Type1 fonts, TrueType fonts, AFP fonts, AWT fonts, SVG fonts, etc. Each kind would be usable by one or more renderers; for example the PDF renderer could use Type1, TrueType and AWT fonts (although it would not be possible to embed the latter). I think this all makes sense. Ideally we would define a common API that would be used by the renderers and hide as much as possible of the actual font manipulation. The renderers would keep only their format's specific code (e.g., creating a PDF font object). Yep, that's basically the idea. The layout engine still just needs a general interface where it can access the font metrics and the available glyphs of a font. Only the renderer has to work with the format-specific details. Of course, the renderer more or less defines which font sources can be used for a rendering run, although that statement is a little difficult to maintain if you render to the intermediate format or if you want to render a document to two different formats simultaneously (ex. PDF for archiving and PS for print). Breaking this down, the layout engine needs a set of font sources it can work with. (initially at least) remain backwards compatible with existing FOP font configurations. I believe these ideas were spoken about a while ago and I do not think it would be too much work and it should simplify font configuration somewhat and should be more efficient in embedded implementations that make use of more than one renderer. Its probably a bit late in the day to make the 0.94 release, but in the longer term does anybody have any initial thoughts on this proposal? I hope those few ideas will give you some things to think about. Anyway, I think there's still quite a bit of work to do in this area, even if the auto-detection stuff was a big step forward. Thanks for looking into this, Vincent [1] See, among others, the first thread about FOrayFont (hem, and please don't pay attention to the flame war!) http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200506.mbox/[EMAIL PROTECTED] Jeremias Maerki
Re: Plan for the 0.94 release
On 13.07.2007 17:08:22 Vincent Hennebert wrote: Jeremias Maerki a écrit : On 13.07.2007 15:45:01 Vincent Hennebert wrote: snip/ Speaking of branches, I noticed that there are many (very) old branches on Subversion. What about removing them? -1. If you want to clean up, please create a subdirectory old-tags (or similar) and move the old tags there. If you just delete them, it is too difficult to access them anymore (provided you still know at which point in time they existed). Well I was talking of branches and not tags. I can understand that this may be a pain to retrieve old tags, but old branches really seem to not be useful anymore. Moreover most of them can be retrieved from their corresponding tags. I'm sorry, you're right. I read too quickly. Anyway, I have the same opinion for branches. Moving them to an old-branches directory is about as difficult as deleting them. Jeremias Maerki
Re: IntMap.java
Vincent Hennebert wrote: Shall we launch a poll on fop-user about abandoning support for 1.4 and require 1.5 as a minimum? :-] A poll: maybe. Abandoning 1.3: Not yet. If the usage of those hash maps is only in a few places, we could provide JDK dependent code and tell people that FOP runs faster on JDK 1.5. J.Pietschmann
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
Vincent Hennebert wrote: Hi, Manuel Mall a écrit : On Wednesday 18 July 2007 02:58, Andreas L Delmelle wrote: snip/ Interestingly Java 1.5 has added the Integer.valueOf(int) method with the following comment: Flyweight pattern. That's what I was looking for before replying to Andreas' commit, and I was surprised to not find it in the 1.4 standard library. A good thing it finally got added. Not a pattern. It's an object cache. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
On Jul 18, 2007, at 14:28, Peter B. West wrote: Hi Peter alt-design always cached _all_ the Integer instances it needed. Another startling new idea. FWIW, I did not presume my idea to be startling or new. Just was a bit bugged by the number of places in the current trunk where Integers are used, solely for the purpose of being able to store ints in a Map... Personally, I would not even cache Integer instances, but deal only with the primitives unless there was a really /compelling/ reason not to do so, not merely because 'It's cool to use Objects'. Following that latter motto, I'd as soon compile a new object type that is dedicated to storing primitive int-to-int mappings and avoid the construction of Integers altogether. Oh well, in the end more a question of personal taste, I guess. Cheers Andreas
Re: FOP 0.94 : font auto detection test
To your question: Where are the xml metrics files ? They are not needed anymore. Today, we have a resonable well working font loading mechanism which makes metric files unnecessary since manual tweaking of the values is not needed anymore. Well, that's the theory. Auto-configuration still is a step backwards for a few minor points: - TrueType collections are not supported with auto-config, yet. - Some special fonts like Symbol may not be handled correctly. But then, it's still possible to configure the fonts explicitely with font metric files. On 18.07.2007 01:20:45 HLeonardi wrote: Hugues Leonardi wrote: Hello all, As said in this thread : http://www.nabble.com/Quick-survey%3A-upcoming-release-of-FOP-0.94-tf4085495.html, I have quickly tested auto detection font feature and my results are at this page : http://leohome.free.fr/FOP/tests/fop094.xml.pdf Best regards Hugues Leonardi -- View this message in context: http://www.nabble.com/FOP-0.94-%3A-font-auto-detection-test-tf4100093.html#a11659676 Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
Re: IntMap.java
J.Pietschmann wrote: Vincent Hennebert wrote: Shall we launch a poll on fop-user about abandoning support for 1.4 and require 1.5 as a minimum? :-] A poll: maybe. Abandoning 1.3: Not yet. If the usage of those hash maps is only in a few places, we could provide JDK dependent code and tell people that FOP runs faster on JDK 1.5. J.Pietschmann FOP should run markedly faster on 1.6 without any changes. Just about everything else does. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: svn commit: r554092 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt: TXTFOEventHandlerMaker.java TXTHandler.java
Unused, yes, because I seem to have screwed up. The TXTHandler was added as part of Sergey Simonchik's patch #37253, applied with revision: http://svn.apache.org/viewvc?view=revrevision=332141 Then, during refactoring for dynamic Renderer and FOEventHandler configuration, the TXTHandler got lost: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/RendererFactory.java?r1=332141r2=332549diff_format=h The TXTRenderer does work without the TXTHandler. I never really understood what exactly the TXTHandler tweaks to make the text output better. At least, we have now reconnected the pieces in the mail-archive if this needs to be restored at some point. I wonder how many people actually use the text renderer. Apparently quite a few since we get question about it every now and then. If I had time, I'd do a comparison of the output with and without the TXTHandler. But in a few months things will look different... On 07.07.2007 01:53:21 Andreas L Delmelle wrote: On Jul 7, 2007, at 01:49, [EMAIL PROTECTED] wrote: Hi all Author: adelmelle Date: Fri Jul 6 16:49:30 2007 New Revision: 554092 URL: http://svn.apache.org/viewvc?view=revrev=554092 Log: Removal of unused classes ? Removed: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/ TXTFOEventHandlerMaker.java xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/ TXTHandler.java Hope nobody minds. As Richard Wheeldon rightly points out in Bugzilla 41044, those classes aren't used anyway. Probably part of the old implementation? Cheers Andreas Jeremias Maerki
Re: svn commit: r557035 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/ util/
On 17.07.2007 21:29:43 adelmelle wrote:
Author: adelmelle
Date: Tue Jul 17 12:29:40 2007
New Revision: 557035
URL: http://svn.apache.org/viewvc?view=revrev=557035
Log:
Undo changes of r556112
snip/
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java?view=diffrev=557035r1=557034r2=557035
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
Tue Jul 17 12:29:40 2007
@@ -38,7 +38,7 @@
public class DataURIResolver implements URIResolver {
/**
- * @see javax.xml.transform.URIResolver#resolve(java.lang.String,
java.lang.String)
+ * @inheritDoc javax.xml.transform.URIResolver#resolve(java.lang.String,
java.lang.String)
*/
public Source resolve(String href, String base) throws
TransformerException {
if (href.startsWith(data:)) {
@@ -52,7 +52,7 @@
* Parses inline data URIs as generated by MS Word's XML export and FO
* stylesheet.
*
- * @see a href=http://www.ietf.org/rfc/rfc2397;RFC 2397/a
+ * @inheritDoc a href=http://www.ietf.org/rfc/rfc2397;RFC 2397/a
^
Careful
*/
private Source parseDataURI(String href) {
int commaPos = href.indexOf(',');
snip/
Jeremias Maerki
Re: IntMap.java
J.Pietschmann wrote: Vincent Hennebert wrote: Shall we launch a poll on fop-user about abandoning support for 1.4 and require 1.5 as a minimum? :-] A poll: maybe. Abandoning 1.3: Not yet. Did you mean 1.4 here? I thought we had all agreed to drop support for 1.3 now? I have long argued that we maintain support for it due to the length of time it takes for more recent JDKs to become available for ancient o/s which large organisations tend to use to run their batch processes on. AFICT, 98% of all o/s can now support 1.4, but not yet 1.5 so we shouldn't drop support for 1.4 for a while yet but I think its safe to drop 1.3 support. snip/ Chris
Re: svn commit: r557035 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/ util/
On Jul 18, 2007, at 16:07, Jeremias Maerki wrote: - * @see a href=http://www.ietf.org/rfc/rfc2397;RFC 2397/a + * @inheritDoc a href=http://www.ietf.org/rfc/rfc2397;RFC 2397/a ^ Careful Sorry, but no need to worry. If the correct [EMAIL PROTECTED] syntax is used, as Vincent pointed out, mistakes such as these are caught when building the javadocs. See: http://svn.apache.org/viewvc?view=revrev=557272 for the correct and intended results. Cheers Andreas
Re: Lines breaking on '/' and '-'
On Wednesday 18 July 2007 23:15, Manuel Mall wrote: On Wednesday 18 July 2007 19:01, Andreas L Delmelle wrote: On Jul 18, 2007, at 10:15, Vincent Hennebert wrote: J.Pietschmann a écrit : Brad Smith wrote: snip/ Turned out adding basic support for keep-together.within-line=always was fairly simple. So I will commit a patch shortly. Moving this thread to fop-dev. This proposed patch seems to cause a side-effect I would like a clarification on. The following fo snippet fo:block keep-together=alwayssome long text/fo:block used to have the effect of keeping some long text on a single page. After my patch it would also keep some long text on a single line! keep-together is an inherited property and it seems keep-together=always is just a shorthand for keep-together.within-page=always keep-together.within-line=always keep-together.within-column=always This could mean existing fos which render fine now will render diffrently after support for keep-together.within-line=always has been added. I guess that is acceptable but rather wanted to check before. Manuel snip/ Cheers Andreas
Re: Lines breaking on '/' and '-'
On Jul 18, 2007, at 17:44, Manuel Mall wrote: Hi Manuel snip / This proposed patch seems to cause a side-effect I would like a clarification on. The following fo snippet fo:block keep-together=alwayssome long text/fo:block used to have the effect of keeping some long text on a single page. After my patch it would also keep some long text on a single line! keep-together is an inherited property and it seems keep-together=always is just a shorthand for keep-together.within-page=always keep-together.within-line=always keep-together.within-column=always That is how I would interpret it. If there is no constraint to keep the content together on a line, then the author needs to explicitly specify only the applicable components. If you alter the original snippet to: fo:block keep-together.within-page=alwayssome long text/fo:block Then the other two components would default to auto. The only minor inconvenience being that to prohibit page- and column-breaks but not line-breaks, the user has to specify two components separately to have the third revert to the initial value. This could mean existing fos which render fine now will render diffrently after support for keep-together.within-line=always has been added. I guess that is acceptable but rather wanted to check before. The effects could (and should IMO) indeed be different in the case you describe. Cheers Andreas
Re: Lines breaking on '/' and '-'
On 18.07.2007 18:00:57 Andreas L Delmelle wrote: On Jul 18, 2007, at 17:44, Manuel Mall wrote: Hi Manuel snip / This proposed patch seems to cause a side-effect I would like a clarification on. The following fo snippet fo:block keep-together=alwayssome long text/fo:block used to have the effect of keeping some long text on a single page. After my patch it would also keep some long text on a single line! keep-together is an inherited property and it seems keep-together=always is just a shorthand for keep-together.within-page=always keep-together.within-line=always keep-together.within-column=always That is how I would interpret it. Me, too. Actually, this is found literally in XSL 1.1, ch. 5.11. snip/ Cool stuff, Manuel, especially if you get this running with so little effort! We just have to do something about those integer values one day... Jeremias Maerki
Re: svn commit: r557337 [1/8] - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: apps/ area/ area/inline/ cli/ datatypes/ fo/ fo/expr/ fo/extensions/ fo/extensions/destination/ fo/extensions/svg/ fo
Thank you, Andreas!!! On 18.07.2007 19:51:04 Andreas L Delmelle wrote: On Jul 18, 2007, at 19:38, [EMAIL PROTECTED] wrote: Hi all Author: adelmelle Date: Wed Jul 18 10:37:14 2007 New Revision: 557337 URL: http://svn.apache.org/viewvc?view=revrev=557337 Log: * Javadoc update: use [EMAIL PROTECTED] instead of @see where applicable, removal of some @author tags So, this is it. Phew! *wipes sweat of forehead* I ended up going over the unified diff four times, and corrected some things manually. In the process, some oddities that caught my eye in the javadocs were corrected as well. On the other hand, I do not completely rule out that new oddities have been introduced (the diff being +16000 lines), so keep your eyes open for those... Hope it serves us well in the long run. Cheers Andreas Jeremias Maerki
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 18, 2007, at 20:06, [EMAIL PROTECTED] wrote: Hi Manuel others Author: manuel Date: Wed Jul 18 11:06:09 2007 New Revision: 557347 URL: http://svn.apache.org/viewvc?view=revrev=557347 Log: Added support for keep-togther.within-line=always Cool to see this implemented so quickly! On the other hand, I do have a few (non-blocking) comments. There is no real support for inline-level elements yet, as your adaptation of the testcase demonstrates: in one case the fo:inline is removed, in the other it is substituted with an fo:wrapper. IMO, in the near future, keeps on other inline-level FOs should be reactivated as well. I was thinking of reactivating the related properties on fo.flow.InlineLevel... I had also been thinking in the direction of letting the TextLM deal with this, but further considerations made me think this was suboptimal. Although this approach works perfectly for a value of always, it could(?) become rather messy when looking at integer-keeps. My last ideas on the subject went in the direction of letting the inline-level LM accumulate the regular sequence, and, for a value of always, wrap it in a single box. If the keep-constraint is not absolute, the TextLM's parent could still do something similar for the individual elements, or something like: surround the entire sequence by two penalties, and insert penalties in the sequence but with significantly higher/lower values. WDYT? Cheers Andreas
The effect of the property cache (or: playing around with a new toy)
I read this week about SAP publishing a free Memory Analyzer. I first tried it on a OutOfMemory heap dump of an commercial formatter which we use in that project that consumed so much of my time lately. It was an immediate eye opener. So I wanted to play with this really great tool a little more and ran a big document which I knew would cause an OutOfMemoryError at 64MB heap size. Here's what came out: Class Name |Objects |Shallow Heap |Retained Heap |Perm - org.apache.fop.fo.properties.CondLengthProperty| 315'760|7'578'240| 7'578'240| java.util.WeakHashMap$Entry| 121'873|4'874'920| 8'861'568| org.apache.fop.fo.flow.Block | 26'391|4'855'944|54'554'584| org.apache.fop.fo.properties.SpaceProperty | 87'592|4'204'416| 7'160'880| org.apache.fop.fo.properties.CommonBorderPaddingBackground | 78'940|3'789'120|16'419'968| org.apache.fop.fo.properties.KeepProperty | 110'661|3'541'152| 3'541'152| org.apache.fop.fo.FOText | 30'461|2'924'256|52'488'224| org.apache.fop.fo.properties.CommonFont| 56'859|2'729'232| 3'638'976| org.xml.sax.helpers.LocatorImpl| 109'431|2'626'344| 2'626'344| org.apache.fop.fo.flow.TableCell | 23'154|2'593'248|54'296'024| org.apache.fop.fo.properties.CondLengthProperty[] | 78'940|2'526'080|10'102'592| org.apache.fop.fo.properties.CommonBorderPaddingBackground$BorderInfo[]| 78'940|2'526'080| 2'526'080| org.apache.fop.fo.properties.NumberProperty| 98'304|2'359'296| 3'932'184| org.apache.fop.fo.properties.CommonHyphenation | 56'852|2'274'080| 2'274'080| char[] | 63'420|1'931'488| 1'931'488| org.apache.fop.fo.properties.LengthRangeProperty | 37'843|1'513'720| 1'513'736| org.apache.fop.fo.flow.TableColumn | 14'687|1'409'952| 4'829'912| org.apache.fop.fo.properties.CommonMarginBlock | 30'592|1'223'680| 4'160'448| org.apache.fop.fo.FONode[] | 44'346|1'064'304|55'383'904| org.apache.fop.fo.properties.PercentLength | 26'402|1'056'080| 1'689'728| java.lang.Double | 57'931| 926'896| 926'968| java.lang.String[] | 57'188| 920'096| 943'640| org.apache.fop.fo.properties.CommonRelativePosition| 26'391| 844'512| 844'512| java.lang.String | 33'367| 800'808| 1'794'048| java.lang.Integer | 45'526| 728'416| 729'032| 2'221 more... | | | | Total of 2'246 entries |1'818'755| 67'134'104| | - Immediately shows that Andreas' recent change (rev 554091) for switching off the SAX Locators can save a lot of memory. I remembered Andreas working on a property cache a couple of weeks ago. Seems to work fine on EnumProperty: Look for class: .*EnumProperty.* Class Name |Objects |Shallow Heap |Retained Heap |Perm org.apache.fop.fo.properties.EnumProperty$Maker| 94|4'512| | org.apache.fop.fo.properties.EnumProperty | 182|4'368| | Total of 2 entries | 276|8'880| | Then I noticed that NumberProperty (which uses the property cache) has 98304 instances which couldn't be right. The problem: just using that WeakHashMap isn't enough without the key objects implementing hashCode() and equals()
Re: The effect of the property cache (or: playing around with a new toy)
On Jul 18, 2007, at 22:17, Jeremias Maerki wrote:
So I wanted to play with this really great tool a little more and
ran a
big document which I knew would cause an OutOfMemoryError at 64MB heap
size. Here's what came out:
snip /
Interesting figures!
Did you have any chance to run a comparative test with say, FOP 0.93?
Strange results for TableColumn, though, or are those 14000 instances
normal given the input (lots of smaller nested tables)?
snip /
Immediately shows that Andreas' recent change (rev 554091) for
switching
off the SAX Locators can save a lot of memory.
Well, that was also part of Richard Wheeldon's patch (Bugzilla 41044)
containing the basic idea for the property cache. The patch itself
ultimately got committed in a few parts, and very much trimmed down,
but Richard deserves most of the credit. I only applied a razor to
his patch. :-)
I remembered Andreas working on a property cache a couple of weeks
ago.
Seems to work fine on EnumProperty:
This should be already the case in 0.93. I seem to remember Simon
having applied Richard's initial patch shortly before the 0.93 release.
Look for class: .*EnumProperty.*
Class Name |Objects |Shallow
Heap |Retained Heap |Perm
--
--
org.apache.fop.fo.properties.EnumProperty$Maker| 94|
4'512| |
org.apache.fop.fo.properties.EnumProperty | 182|
4'368| |
Total of 2 entries | 276|
8'880| |
--
--
Then I noticed that NumberProperty (which uses the property cache)
has 98304 instances which couldn't be right. The problem: just using
that WeakHashMap isn't enough without the key objects implementing
hashCode() and equals() (see JDK javadocs).
Ouch! A painful oversight on my part. Good thing you checked. :)
As to the implementations, I'm wondering, since NumberProperty is
actually only a proxy for an underlying java.lang.Number, whether it
wouldn't be more convenient to simply reuse those:
hashCode() {
return number.hashCode();
}
equals(Object o) {
if (o instanceof NumberProperty
o != null) {
return this.number.equals(
((NumberProperty) o).number);
} else {
return false;
}
All we really need to uniquely identify a NumberProperty is the
number-member, I think...
Cheers
Andreas
Re: The effect of the property cache (or: playing around with a new toy)
Some additional thoughts before going to bed: - I think the static synchronized WeakHashMap should be avoided. There's a lot of synchronization that is performed. I suspect this will have a bad effect on performance. It may make more sense to have a FlyWeightFactory (per object) per rendering run. Somebody (don't remember who, sorry) wrote that FOP cannot bring the CPU to 100%, probably due to synchronization issues. Could be worth investigating since this would mean we give away CPU cicles here. - It's probably not the most effective way to use the Property itself as the key into the Map, i.e. creating throw-away instances excessively. Working with specialized FlyWeightFactories could be more efficient. See http://en.wikipedia.org/wiki/Flyweight_pattern - One of the easiest candidates for another flyweight is probably CommonHyphenation (56K instances, 2.3MB in my example). The few member variables could probably just be concatenated to a String (to be used as the key). - It could be worth looking into the difference between HashMap and TreeMap. Maybe one is more suitable than the other. I haven't looked at the difference, yet. Jeremias Maerki
Re: The effect of the property cache (or: playing around with a new toy)
On 18.07.2007 23:05:57 Andreas L Delmelle wrote:
On Jul 18, 2007, at 22:17, Jeremias Maerki wrote:
So I wanted to play with this really great tool a little more and
ran a
big document which I knew would cause an OutOfMemoryError at 64MB heap
size. Here's what came out:
snip /
Interesting figures!
Did you have any chance to run a comparative test with say, FOP 0.93?
No, that need to wait until after my holidays.
One thing, I'm planning is to create a tool that downloads older FOP
revisions in a one-month rhythm to see how performance evolved over time.
I want to do this because I suspect we noticably lost performance
somewhere during the last 2 years. That could also involve taking memory
snapshots for each version to find out about memory development.
Strange results for TableColumn, though, or are those 14000 instances
normal given the input (lots of smaller nested tables)?
No, just lots of small tables (an example from Luis Ferro in 2006).
snip /
Immediately shows that Andreas' recent change (rev 554091) for
switching
off the SAX Locators can save a lot of memory.
Well, that was also part of Richard Wheeldon's patch (Bugzilla 41044)
containing the basic idea for the property cache. The patch itself
ultimately got committed in a few parts, and very much trimmed down,
but Richard deserves most of the credit. I only applied a razor to
his patch. :-)
Oops. Thanks, Richard!!!
I remembered Andreas working on a property cache a couple of weeks
ago.
Seems to work fine on EnumProperty:
This should be already the case in 0.93. I seem to remember Simon
having applied Richard's initial patch shortly before the 0.93 release.
Look for class: .*EnumProperty.*
Class Name |Objects |Shallow
Heap |Retained Heap |Perm
--
--
org.apache.fop.fo.properties.EnumProperty$Maker| 94|
4'512| |
org.apache.fop.fo.properties.EnumProperty | 182|
4'368| |
Total of 2 entries | 276|
8'880| |
--
--
Then I noticed that NumberProperty (which uses the property cache)
has 98304 instances which couldn't be right. The problem: just using
that WeakHashMap isn't enough without the key objects implementing
hashCode() and equals() (see JDK javadocs).
Ouch! A painful oversight on my part. Good thing you checked. :)
As to the implementations, I'm wondering, since NumberProperty is
actually only a proxy for an underlying java.lang.Number, whether it
wouldn't be more convenient to simply reuse those:
hashCode() {
return number.hashCode();
}
equals(Object o) {
if (o instanceof NumberProperty
o != null) {
return this.number.equals(
((NumberProperty) o).number);
} else {
return false;
}
All we really need to uniquely identify a NumberProperty is the
number-member, I think...
I dont' think that works, since Number doesn't implement hashCode(), for
example.
BTW, I don't know if we should do anything about the specVal member
variable in Property. I think it's mostly set to null.
Jeremias Maerki
Re: FOP 0.94 : font auto detection test
Hugues Leonardi wrote: Auto-configuration still is a step backwards for a few minor points: - TrueType collections are not supported with auto-config, yet. - Some special fonts like Symbol may not be handled correctly. Hi Jeremias, I didn't know this. I haven't read the whole of fop documentation, but if theses informations are not present, it could be interesting to add them. Best regards Hugues Leonardi -- View this message in context: http://www.nabble.com/FOP-0.94-%3A-font-auto-detection-test-tf4100093.html#a11678794 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: The effect of the property cache (or: playing around with a new toy)
On Jul 18, 2007, at 23:18, Jeremias Maerki wrote: Some additional thoughts before going to bed: - I think the static synchronized WeakHashMap should be avoided. There's a lot of synchronization that is performed. I suspect this will have a bad effect on performance. I have always assumed it would have some effect that could be interpreted as bad. Richard's initial version of the PropertyCache synchronized the fetch () method, and if I remember and interpret correctly, this caused a noticeable slowdown in performing the jUnit tests. Once I decided to use Collections.synchronizedMap(), the speed went back to normal. It may make more sense to have a FlyWeightFactory (per object) per rendering run. Somebody (don't remember who, sorry) wrote that FOP cannot bring the CPU to 100%, probably due to synchronization issues. Could be worth investigating since this would mean we give away CPU cicles here. Could indeed be interesting to know if it's really the synchronization or other aspects of FOP's architecture that would be the cause of that. Using statics and the above utility method of course makes performance greatly dependent on the cleverness of the JVM implementation. Other than that, /if/ any synchronization should be performed, then it would seem better to do so on the lower level: with the original patch, multiple calls to the fetch() method would be prevented from being executed concurrently, even if none of them altered the underlying Map. - It's probably not the most effective way to use the Property itself as the key into the Map, i.e. creating throw-away instances excessively. Working with specialized FlyWeightFactories could be more efficient. See http://en.wikipedia.org/wiki/Flyweight_pattern Also my initial thought: if the Property is simply a wrapper around an int or a String, then I'd assume that it would be better to check for an existing instance corresponding to that base value. Then again, I do seem to remember Richard pointing out that creating a lot of temporary instances is quasi irrelevant in a language like Java, especially the later JVM versions. IIRC, it has to do with the fact that the throw-away instances never have to leave the stack -- which by itself already saves the time it takes to reserve addresses in the heap and transfer the instances to them. This factor does become important once you have a situation where a pass through the constructor triggers a method call for each of a handful of members, like in the case of the Common-bundles. In case of the immediate Property subclasses, however, the constructors themselves are actually very light, so it should not be much of a problem. The bulk of the 'construction' work is carried by the Makers and the PropertyParser. - One of the easiest candidates for another flyweight is probably CommonHyphenation (56K instances, 2.3MB in my example). The few member variables could probably just be concatenated to a String (to be used as the key). Interesting idea, will look into that asap. - It could be worth looking into the difference between HashMap and TreeMap. Maybe one is more suitable than the other. I haven't looked at the difference, yet. No idea here either. Come to think of it, I've never really looked at TreeMap before at all. I'd have to check for specific use-cases first to see what the specific use could be here. There's no WeakTreeMap yet, though... 8-) Cheers Andreas
Re: The effect of the property cache (or: playing around with a new toy)
On Jul 18, 2007, at 23:31, Jeremias Maerki wrote: snip / [Me:] All we really need to uniquely identify a NumberProperty is the number-member, I think... I dont' think that works, since Number doesn't implement hashCode (), for example. Right, but its concrete subclasses in the java.lang package do. Since the Number class itself is abstract, number will in fact have a runtime type of Integer or Double, so we would rely on the subclass implementation here... Hmm, made me wonder: Number oneInt = new Integer(1); Number oneDouble = new Double(1.0); boolean check = (oneInt.hashCode() != oneDouble.hashCode()); = (check == true) Can this be relied upon? BTW, I don't know if we should do anything about the specVal member variable in Property. I think it's mostly set to null. Looking a bit closer, I think that member could even be dropped entirely. The only place where this value is accessed by means of getSpecifiedValue() is in LineHeightPropertyMaker. I'd be surprised if that cannot be avoided. Cheers Andreas
Re: The effect of the property cache (or: playing around with a new toy)
On Jul 19, 2007, at 01:10, Andreas L Delmelle wrote: snip / Hmm, made me wonder: Number oneInt = new Integer(1); Number oneDouble = new Double(1.0); boolean check = (oneInt.hashCode() != oneDouble.hashCode()); = (check == true) Can this be relied upon? BTW: the following is perfectly legitimate Object o = new Object(); Just wondering if anyone can think of a use-case... Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Thursday 19 July 2007 02:31, Andreas L Delmelle wrote: On Jul 18, 2007, at 20:06, [EMAIL PROTECTED] wrote: Hi Manuel others Author: manuel Date: Wed Jul 18 11:06:09 2007 New Revision: 557347 URL: http://svn.apache.org/viewvc?view=revrev=557347 Log: Added support for keep-togther.within-line=always Cool to see this implemented so quickly! On the other hand, I do have a few (non-blocking) comments. There is no real support for inline-level elements yet, as your adaptation of the testcase demonstrates: in one case the fo:inline is removed, in the other it is substituted with an fo:wrapper. IMO, in the near future, keeps on other inline-level FOs should be reactivated as well. I was thinking of reactivating the related properties on fo.flow.InlineLevel... I don't quite understand what you are trying to say here. The test case in question checks the use of keep-together.within-line=always in the context of fo:block, fo:inline and fo:marker. Have I missed an important use case? I had also been thinking in the direction of letting the TextLM deal with this, but further considerations made me think this was suboptimal. Although this approach works perfectly for a value of always, it could(?) become rather messy when looking at integer-keeps. My last ideas on the subject went in the direction of letting the inline-level LM accumulate the regular sequence, and, for a value of always, wrap it in a single box. If the keep-constraint is not absolute, the TextLM's parent could still do something similar for the individual elements, or something like: surround the entire sequence by two penalties, and insert penalties in the sequence but with significantly higher/lower values. Regarding integer keeps I have no real idea how to do it. Can we express integer keep conditions correctly using our Knuth sequences for example by adjusting the penalty values as you suggest? If the answer is yes implementation is easy and can stay within TextLM. If the answer is no then we have a real problem IMO as the algorithm then has to work on top of Knuth. I believe the same issue exists for the .within-page case which is probably even more important. WDYT? Cheers Andreas Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 19, 2007, at 01:31, Manuel Mall wrote: snip / I don't quite understand what you are trying to say here. The test case in question checks the use of keep-together.within-line=always in the context of fo:block, fo:inline and fo:marker. Nope. For the sake of completeness, this is the one and only page- sequence, including diffs: fo:page-sequence master-reference=simple -fo:flow flow-name=xsl-region-body hyphenate=true +fo:flow flow-name=xsl-region-body fo:block-container width=100pt background-color=yellow -fo:blockThis is fo:inline keep-together.within- line=alwaysBLah-blah-blah-blah!/fo:inline/fo:block -fo:blockThis is fo:inline keep-together.within- line=alwaysBlah-blah-blah-blah!/fo:inline/fo:block -fo:blockThis is fo:inlineBlah blah blah blah!/ fo:inline/fo:block +fo:block keep-together.within-line=alwaysThis is Blah blah blah blah!/fo:block fo:blockThis is fo:inline keep-together.within- line=alwaysBlah blah blah blah!/fo:inline/fo:block +fo:blockThis is fo:wrapper keep-together.within- line=alwaysBlah blah blah blah!/fo:wrapper/fo:block /fo:block-container /fo:flow /fo:page-sequence Have I missed an important use case? Question seems to be whether you forgot an important /test/ case in the commit... ;-) Looking closer, specified properties on an fo:inline are still ignored after applying your patch (which I took to be the reason for your removing the fo:inlines or replacing them with fo:wrappers?) snip / Regarding integer keeps I have no real idea how to do it. Can we express integer keep conditions correctly using our Knuth sequences for example by adjusting the penalty values as you suggest? I think so. Consider: fo:block Some text with auto keep-constraint fo:inline keep-together.within-line=100 Some text with a keep.within-line constraint of 100 fo:inline keep-together.within-line=500 keep.within-line=500 /fo:inline Some more text in the first nested inline /fo:inline More text after the first nested inline. /fo:block In the code we get something like: BlockLM.getNextKnuthElements() - LineLM.collectInlineKnuthElements() - TextLM.getNextKnuthElements() - InlineLM.getNextKnuthElements() - TextLM.getNextKnuthElements() [a] - InlineLM.getNextKnuthElements() [b] - TextLM.getNextKnuthElements() [c] - TextLM.getNextKnuthElements() ... If, at point [a], the first nested inline would prefix the returned sequence with a penalty of 50, and pass a value of 100 down to its descendant TextLM to use for penalties to insert between its elements. Then, before processing the second inline at [b], insert a penalty of 100, while the second nested InlineLM surrounds its sequence by two penalties of 250 and passes a value of 500 down its TextLM [c]. This should steer the line-breaking algorithm in the right direction to satisfy all keep constraints, IIC. The only big difference compared to an auto keep-constraint, if I judge correctly, would then be that we would somehow have to use penalties to represent all legal break-opportunities. Instead of glues being considered as feasible breakpoints, they would always be preceded by a zero-width penalty having a value corresponding to the keep-constraint governing the base FO. Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Thursday 19 July 2007 08:39, Andreas L Delmelle wrote: On Jul 19, 2007, at 01:31, Manuel Mall wrote: snip / I don't quite understand what you are trying to say here. The test case in question checks the use of keep-together.within-line=always in the context of fo:block, fo:inline and fo:marker. Nope. For the sake of completeness, this is the one and only page- sequence, including diffs: fo:page-sequence master-reference=simple -fo:flow flow-name=xsl-region-body hyphenate=true +fo:flow flow-name=xsl-region-body fo:block-container width=100pt background-color=yellow -fo:blockThis is fo:inline keep-together.within- line=alwaysBLah-blah-blah-blah!/fo:inline/fo:block -fo:blockThis is fo:inline keep-together.within- line=alwaysBlah-blah-blah-blah!/fo:inline/fo:block -fo:blockThis is fo:inlineBlah blah blah blah!/ fo:inline/fo:block +fo:block keep-together.within-line=alwaysThis is Blah blah blah blah!/fo:block fo:blockThis is fo:inline keep-together.within- line=alwaysBlah blah blah blah!/fo:inline/fo:block +fo:blockThis is fo:wrapper keep-together.within- line=alwaysBlah blah blah blah!/fo:wrapper/fo:block /fo:block-container /fo:flow /fo:page-sequence Have I missed an important use case? Question seems to be whether you forgot an important /test/ case in the commit... ;-) Looking closer, specified properties on an fo:inline are still ignored after applying your patch (which I took to be the reason for your removing the fo:inlines or replacing them with fo:wrappers?) Sorry Andreas but I still don't get it. We have this test case fo:blockThis is fo:inline keep-together.within- line=alwaysBlah blah blah blah!/fo:inline/fo:block which (attempts) to test that keep-together.within-line=always specified on an fo:inline does work correctly. So this property is not ignored as far as I can tell. What am I missing? snip / Regarding integer keeps I have no real idea how to do it. Can we express integer keep conditions correctly using our Knuth sequences for example by adjusting the penalty values as you suggest? I think so. Consider: fo:block Some text with auto keep-constraint fo:inline keep-together.within-line=100 Some text with a keep.within-line constraint of 100 fo:inline keep-together.within-line=500 keep.within-line=500 /fo:inline Some more text in the first nested inline /fo:inline More text after the first nested inline. /fo:block In the code we get something like: BlockLM.getNextKnuthElements() - LineLM.collectInlineKnuthElements() - TextLM.getNextKnuthElements() - InlineLM.getNextKnuthElements() - TextLM.getNextKnuthElements() [a] - InlineLM.getNextKnuthElements() [b] - TextLM.getNextKnuthElements() [c] - TextLM.getNextKnuthElements() ... If, at point [a], the first nested inline would prefix the returned sequence with a penalty of 50, and pass a value of 100 down to its descendant TextLM to use for penalties to insert between its elements. Then, before processing the second inline at [b], insert a penalty of 100, while the second nested InlineLM surrounds its sequence by two penalties of 250 and passes a value of 500 down its TextLM [c]. This should steer the line-breaking algorithm in the right direction to satisfy all keep constraints, IIC. The only big difference compared to an auto keep-constraint, if I judge correctly, would then be that we would somehow have to use penalties to represent all legal break-opportunities. Instead of glues being considered as feasible breakpoints, they would always be preceded by a zero-width penalty having a value corresponding to the keep-constraint governing the base FO. This is worth a shot. I tried before using different penalty values to achieve specific effects and it failed miserably. But may be I did something wrong. For example in one test I significantly increased the penalty associated with a hyphen to see if I can get it to 'hyphenate less' and it seemed to have zero effect. Any way trying to do something like that would exceed significantly my admittedly very limited time available to spend on fop. Cheers Andreas Cheers Manuel
