xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: FOP trunk error message when run from ant
Date Wed, 07 Jul 2010 09:16:49 GMT
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

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.


>  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.


Jeremias Maerki

To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message