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 12:59:22 GMT
On 07.07.2010 14:41:23 Eric Douglas wrote:
> -----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)

Ah, sorry, I saw that one but thought that came in before 0.95.
That change was on May 6 2008 and 0.95 was released Aug 05 2008.

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

That's the ideal case. Too bad, this didn't happen.

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

We tried to always keep xmlgraphics-commons-1.4svn.jar in sync with
Trunk. At any rate, we updated it a number of times. We usually find out
very quickly if FOP doesn't compile. Must be something else.

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

So we'll keep in mind when working on fonts in the future to make it
easier to add custom fonts and make that part of the public API that
people can use.

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

If you didn't use a monospace font, I'd say you're seeing kerning
effects, but that can't be the case. 

> For instance, I found some Java code here
> (http://stackoverflow.com/questions/922052/testing-whether-a-font-is-mon
> 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?

The metrics XML file is no longer required. It's just kept for
backwards-compatibility. I think there should be examples in the
archives on how to determine string widths using FOP's font classes.

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