Re: FontSources
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? 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? 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). (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]
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
On Jul 16, 2007, at 22:25, J.Pietschmann wrote: Vincent Hennebert wrote: Addition of a general-purpose int-to-int map ... ... This change makes me a bit uneasy. No doubt that this class is clever and efficient and working, but that's something more to maintain. Jakarta Commons Collections has all kind of clever implementation. Don't they have already something similar, and if not, would it make sense to donate this implementation to Collections? Not sure if it would fit in there. It seems more meant for classes extending the Java Collections Framework. I precisely abandoned any attempt to make it fit into the JCF. Started out by implementing java.util.Map, but soon experienced that as adding additional annoyances than relieving any. As to the efficiency: I did some measurements of the difference in processing speed (for 64K elements), and the factor lies somewhere between 5 and 20 (times faster). A difference that is not caused by the HashMap lookups, but almost solely due to the necessary Integer constructions and casts... So, the motives were more aesthetic, I guess. More caused by my aversion for the dumb Integer immutables... I have nothing against HashMaps, but I just do not care much for lines of code like this: int someInt = ((Integer) someMap.get(new Integer (anotherInt))).intValue(); Granted, CPUs have become so fast and JVMs have been optimized in such a way that one does not even notice the difference unless when executing this ugly line of code 10 million times in a row, but still... Cheers Andreas
Re: Remove Useless Comments
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? Cheers Andreas
Re: svn commit: r557035 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/ util/
On Jul 17, 2007, at 21:29, [EMAIL PROTECTED] 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 Oops! Some javadoc changes already committed as well... Well, if no one objects before tomorrow evening, the rest will follow then. Cheers Andreas
FOP 0.94 : font auto detection test
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.
Re: FOP 0.94 : font auto detection test
On Jul 18, 2007, at 01:20, HLeonardi wrote: Hi Hugues others I have quickly tested auto detection font feature and my results are at this page : http://leohome.free.fr/FOP/tests/fop094.xml.pdf FWIW, I have taken a closer look at the related test-output myself here, and I also get a number of errors, mostly the same as in Hugues' case. At first glance, I would not take these to be errors in the font- detection routine per se, but they seem to point to limitations in the types of font-files FOP can currently handle, or errors in the suppositions the current code makes about the location of ascender/ descender pairs or Unicode CMAPs in the font-files? Cheers Andreas
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
On Wednesday 18 July 2007 02:58, Andreas L Delmelle wrote: On Jul 16, 2007, at 22:25, J.Pietschmann wrote: Vincent Hennebert wrote: Addition of a general-purpose int-to-int map ... ... As to the efficiency: I did some measurements of the difference in processing speed (for 64K elements), and the factor lies somewhere between 5 and 20 (times faster). A difference that is not caused by the HashMap lookups, but almost solely due to the necessary Integer constructions and casts... So, the motives were more aesthetic, I guess. More caused by my aversion for the dumb Integer immutables... I have nothing against HashMaps, but I just do not care much for lines of code like this: int someInt = ((Integer) someMap.get(new Integer (anotherInt))).intValue(); Granted, CPUs have become so fast and JVMs have been optimized in such a way that one does not even notice the difference unless when executing this ugly line of code 10 million times in a row, but still... Interestingly Java 1.5 has added the Integer.valueOf(int) method with the following comment: 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. Cheers Andreas Cheers Manuel
