Hi Eric On 06.07.2010 14:35:11 Eric Douglas wrote: > Chris, > > It seems to me the entire project is subject to change.
Usually, people complain that too little is happening. But the only constant is change. ;-) > In fact going > from version 0.20 to 0.95 practically everything changed. It had to. Otherwise, we could not enjoy the additional functionality we have today. You can read up on why this had to happen in the archives. Furthermore, it's important to note that in the ten and a half years since the project's start, a lot of people have come and gone, everyone with different skill sets and coding styles. That tends to have an impact on the code overall. > Going from 0.95 to the Trunk, the EmbedFontInfo class changed. What are you referring to? I don't see any backwards-incompatible changes in EmbedFontInfo since 0.95. > Though > it seems you're suggesting no one should ever reference that class, the > jar requirements changed along with it. A newer version of > xmlgraphics-commons is required. You upgraded FOP, so it's not unreasonable that its dependencies can evolve as well. If you don't want new functionality, why upgrade? > Of course I don't reference every > public method so I don't know how much else changed. If you're > suggesting you should be able to use FOP without ever changing anything > and be able to use newer versions of the project, you probably should > never embed code. I assume by public API you mean features available > when calling the program from a DOS prompt. No, Chris is talking about the public API in org.apache.fop.apps which should not have had any backwards-incompatible change since the FOP redesign. http://xmlgraphics.apache.org/fop/0.95/embedding.html says exactly which parts are intended to be used for normal use inside a Java application. Plain Java doesn't give us the means to outline exactly which classes are supposed to be the public API and which classes are more or less internal classes. (Well, OSGi does, but that's a different story.) Given what you're describing, you're doing advanced stuff which 99% of FOP users will never need to use. There's a certain risk involved with using that. Not everything in FOP is designed so it can be used by everyone. For example, the PDF library has been developed as part of FOP and has evolved, not always in a good way. It would seem that the PDF library is a nice thing to use directly, but it may not be as comfortable as another PDF library that was designed to be used independently (like Apache PDFBox). > That is a hack if you're > calling a program from the DOS prompt in embedded code. Absolutely. > To me the > public API is any public method in a public class. I guess we disagree here. > For my purpose the xconf file sounds like a bad idea if A) it requires a > hard coded reference to a font which may be subject to change, or B) it > requires a path reference to the file which may change or may vary > depending which machine client or server is referencing it. It's just > easier to dynamically read in the name(s) of the fonts to use and embed > them with the EmbedFontInfo object. Also, I would avoid putting > configuration in external files any more than necessary. Plus as I > mentioned, the EmbedFontInfo object can dynamically read in font values > like the width of the characters, which you can't get using the xconf > file. Any configuration we do need stored in a file, I prefer to put in > our data file system, not text files. For you, it may be easier, but the font API is not properly documented so everyone can use it. For most people, a configuration file is much easier to use and requires much less Java code. The font package is also not really designed to be used from outside. And by the way, the font API is subject to change drastically as soon as someone has the time to do the redesign it's waiting for for years now. At the moment, the fonts are loaded for each document run because metrics and subset usage information is combined. That costs performance, but noone has had the time, yet, to tackle it. I think it will make sense to provide an easy API to set up custom fonts as part of the redesign. <snip/> Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
