Chris, It seems to me the entire project is subject to change. In fact going from version 0.20 to 0.95 practically everything changed. Going from 0.95 to the Trunk, the EmbedFontInfo class changed. 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. 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. That is a hack if you're calling a program from the DOS prompt in embedded code. To me the public API is any public method in a public class.
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. -----Original Message----- From: Chris Bowditch [mailto:[email protected]] Sent: Monday, July 05, 2010 12:18 PM To: [email protected] Subject: Re: FOP trunk error message when run from ant Eric Douglas wrote: > I'm not suggesting that it wouldn't work, just that it sounds like > some ugly hack to combine the two methods, that the xconf file should > be required if you're calling FOP from a command prompt and if you're > using the classes with embedded code you could skip the xconf file and > use the proper code to import the font with the FontLoader. Hi Eric, I'm sorry but I don't agree that using the fop.xconf within an embedded Java application is a ugly hack as you suggest. This is the intended way of doing things. Some of the classes you have used in your mentioned approach of loading fonts do not form part of the public API and therefore are subject to change. Therefore the approach you suggested is a hack not the other way round. What is it that you don't like about using the fop.xconf file? You can still make sure fonts are used from your own distribution instead of the client machine. Just hide the fop.xconf file away if needed and configure the base path from source code. We store the fop.xconf file in a database which is accessed via a URL. We could easily stop users tampering with it if we saw fit. > > In my case there's an additional benefit to using the FontLoader, > because I'm using the classes in embedded dynamic code. I wrote a > program which puts all the data to be printed into an XML file. It > writes the data with made up tags to specify coordinates on a page to > print each piece of text with absolute locations. I tell it how many > characters I want to print across the page and it dynamically adjusts > the font size to fit. I'm using a fixed point font, so I get the font > size from the TTFLoader. It reads the font into a CustomFont which > implements FontDescriptor which extends FontMetrics which has a method > getWidth. Thanks, Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
