I tried a mixture of the two. I have a problem though.
FontInfoFinder.find is returning me null. Basically I have a directory
of fonts (.ttf and .ttc). I was trying the following code fragment
(which is where FontInfoFinder.find is returning null):
private List<EmbedFontInfo> locateEmbedFontInfos() {
List<EmbedFontInfo> infos = new
ArrayList<EmbedFontInfo>();
if ( environment.getFontDirectories() != null ) {
FontCache fontCache = FontCache.load();
if ( fontCache == null ) {
fontCache = new FontCache();
}
FontResolver fontResolver =
FontSetup.createMinimalFontResolver();
FontInfoFinder fontInfoFinder = new
FontInfoFinder();
for ( File fontDirectory :
environment.getFontDirectories() ) {
for ( File fontFile :
fontDirectory.listFiles() ) {
EmbedFontInfo info =
fontInfoFinder.find( fontFile, fontResolver, fontCache );
infos.add( info );
}
}
}
return infos;
}
So basically, for each direcrtory containing fonts
(environment.getFontDirectories()), I iterate the files
(fontDirectory.listFiles()). So fontFile is the .ttf files. I have
verified this in debugger. Yet when fontInfoFinder.find is called on
that .ttf file, it returns null.
On Mon, 2009-04-06 at 14:00 +1000, Jason Harrop wrote:
> For what its worth, here is how I do (1) and (2):
>
> (1)
> http://dev.plutext.org/trac/docx4j/browser/trunk/docx4j/src/main/java/org/docx4j/fonts/PhysicalFonts.java
>
> (2)
> http://dev.plutext.org/trac/docx4j/browser/trunk/docx4j/src/main/java/org/docx4j/convert/out/pdf/viaXSLFO/Conversion.java
>
> Feel free to copy ...
>
> cheers .. Jason
>
>
>
> On Mon, Apr 6, 2009 at 12:56 PM, Steve Ebersole <[email protected]> wrote:
> > This week I am back at this task. I have (I think/hope) the code
> > written for #2, but quick question...
> >
> > For me the easiest will be the <directory/> option (I think). But what
> > is expected in the directory? The .ttf files? Or the font metric
> > files?
> >
> >
> >
> > On Thu, 2009-03-12 at 11:44 +0100, Jeremias Maerki wrote:
> >> It's a known issue that programmatic font configuration is not ideal at
> >> the moment. I see two possible routes short of doing the full
> >> refactoring of the font subsystem that would be the ideal solution but
> >> take a lot of effort:
> >>
> >> 1. Take a look at PrintRendererConfigurator to see how you could emulate
> >> the auto-detection from outside FOP:
> >> http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/PrintRendererConfigurator.java?view=markup
> >>
> >> 2. Create the XML configuration in code by constructing
> >> DefaultConfiguration (from Avalon Framework) elements. This works much
> >> like a DOM. You can then pass the Configuration object to the FopFactory.
> >>
> >> HTH
> >>
> >> On 11.03.2009 22:02:21 Steve Ebersole wrote:
> >> > I develop a maven plugin which does docbook processing. It's a little
> >> > different in that it utilizes maven's artifact/dependency capabilities
> >> > to pull the individual pieces (xslt, images, css, etc) together
> >> > dynamically.
> >> >
> >> > I'd love for the same to happen with fonts with the fop/dpf processing.
> >> > looking over http://xmlgraphics.apache.org/fop/trunk/fonts.html and
> >> > http://xmlgraphics.apache.org/fop/trunk/fonts.html#autodetect but am not
> >> > really seeing the way to do this. The main issue is that this most all
> >> > be accomplished programatically in my plugin code.
> >> >
> >> > Of course part of the problem is that I really have no background in fop
> >> > nor docbook :)
> >> >
> >> > Anyway, does anyone have thoughts on how this might be cool to
> >> > accomplish?
> >> >
> >> > -
> >> >
> >> > Steve Ebersole
> >> > Project Lead
> >> > http://hibernate.org
> >> > [email protected]
> >> >
> >> > Principal Software Engineer
> >> > JBoss, a division of Red Hat
> >> > http://jboss.com
> >> > http://redhat.com
> >> > [email protected]
> >> > [email protected]
> >> >
> >> >
> >>
> >>
> >> Jeremias Maerki
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> > --
> > Steve Ebersole <[email protected]>
> > Hibernate.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
--
Steve Ebersole <[email protected]>
Hibernate.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
