xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Douglas" <edoug...@blockhouse.com>
Subject RE: FOP trunk error message when run from ant
Date Wed, 07 Jul 2010 12:41:23 GMT

-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch] 
Sent: Wednesday, July 07, 2010 5:17 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP trunk error message when run from ant

Hi Eric


> What are you referring to? I don't see any backwards-incompatible
changes in EmbedFontInfo since 0.95.

I switched the jar from 0.95 to the Trunk and got a compile error on the
use of this class.
0.95 constructor:
public EmbedFontInfo(String metricsFile, boolean kerning,
                    List fontTriplets, String embedFile)
Trunk constructor:
public EmbedFontInfo(String metricsFile, boolean kerning,
                    List/*<FontTriplet>*/ fontTriplets, String
embedFile, String subFontName)

Rather than overloading the constructor, the Trunk just added another
parameter, so any old calls to create the class now crash even though I
don't need subFontName because my font files only contain one font.  It
should be an optional parameter, passing in null for you if you exclude

> You upgraded FOP, so it's not unreasonable that its dependencies can
evolve as well. If you don't want new functionality, why upgrade?

I was just saying the Trunk didn't compile as is.  I believe when I ran
the subversion process to get the files, it got
xmlgraphics-commons-1.3.1.jar but had code which required the
xmlgraphics-commons-1.4svn.jar.  Now xmlgraphics has officially released
the version and it appears the Trunk includes -1.4.jar.  I haven't had
time to see what all the changes are, but I always welcome "new
functionality", assuming improvements not just change for the sake of

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

That is fine as long as those "public API" classes provide all the
functionality I need.  I personally however prefer to put all my program
code in the program.  If there's a class which is not intended to be
part of this "public API" but is declared as a public class with public
methods I can use to embed a custom font, I prefer to use that rather
than writing the information to a text file to pass in, even if it may
present an issue when trying to upgrade to a newer version.

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

I agree the font metrics appear to have some issues I'm still testing,
and a new API to make it easier to load custom fonts would be greatly
appreciated.  I have selected a fixed width font, and I'm still tweaking
it between my Java code and my XSL code to be able to dynamically size
text to fit a specified number of characters across a page, and to
dynamically place the XSL blocks with absolute positioning to start text
in the middle of the page and get it to line up with text running across
from a block started at the edge of the page.  I have it close but it
appears something is still off, and I'm checking on what FOP can do with
font sizing versus what Java classes do with it.

For instance, I found some Java code here
ospaced-in-java) which tests font character widths..
Also, I see that code is getting metrics from the font file and was
wondering if FOP should be doing that, if the metrics xml file should
really be required?

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

View raw message