You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Steve Ebersole <st...@hibernate.org> on 2009/04/06 04:56:20 UTC

Re: Font registration

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
> > steve@hibernate.org
> > 
> > Principal Software Engineer
> > JBoss, a division of Red Hat
> > http://jboss.com
> > http://redhat.com
> > steve.ebersole@jboss.com
> > steve.ebersole@redhat.com
> > 
> > 
> 
> 
> Jeremias Maerki
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Lol, ok that was it.  Somehow that bad entry got put into the cache and
was always used there-after.

Which brings up the question about guidelines for programatic use of 
FontCache.load().  Do I use it, and just tell my users to delete that
cache file if they encounter problems?  Do I add an option to clear the
font cache?  Do I just not use it?

Anyway, thanks for your help Andreas.

On Mon, 2009-06-15 at 23:27 +0200, Andreas Delmelle wrote:
> On 15 Jun 2009, at 21:44, Steve Ebersole wrote:
> 
> Hi Steve
> 
> > Now running with FOP trunk, but still have the same exact issue.  For
> > this TTC file, FontInfoFinder.find() is returning a single  
> > EmbedFontInfo
> > object which has no sub-font name.  It does however have 2
> > EmbedFontInfo.fontTriplets entries:
> > [0] = "AR PL UMing CN,normal,400"
> > [1] = "UMingCN,normal,400"
> >
> > This is exactly what the patched docx4j version was giving me for this
> > TTC.
> >
> > So is this the expected behavior?
> 
> No, I don't believe so, unless we're not seeing some relevant messages  
> about failures trying to load the other fonts in the collection. I  
> don't have a TTC at hand here to test with, otherwise I'd debug it to  
> see what's going on... Have you already tried this with other TTCs? Do  
> they exhibit the same behavior? If not, then it probably points to a  
> peculiarity in the file that we didn't account for.
> 
> 
> Regards
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Just to finish up on this, I need to do a release of my jDocBook plugin
for maven and I need to make use of this functionality.  So I need to
make use of FOP 0.95++.

First obvious question is when is 0.96 expected?

Second, I can do a "snapshot" build of FOP from the sources I have here.
For the lib/xmlgraphics-commons-1.4svn.jar, was there a particular tag
from which that was pulled and built?

On Mon, 2009-06-15 at 23:59 +0200, Andreas Delmelle wrote:
> On 15 Jun 2009, at 23:33, Steve Ebersole wrote:
> 
> > I am debugging through the code right now.  I am currently looking at
> > FontCache.  I was not expecting cache hits, I did not realize that the
> > cache was persistent.
> 
> Yes. I'm still not /completely/ up to speed as to what happens there,  
> but that I know for certain. Obviously, we want to avoid, as much as  
> possible, to open/read the font-file each and every time the font is  
> referenced. In fact, it goes so far that, if a font-file has failed to  
> load *and* the cache is not invalidated/deleted, the file will never  
> be checked again, except for the modification timestamp. FOP will only  
> retry parsing if the FontCache's serialVersionUID has been modified,  
> or the physical file appears more recent than the one that failed to  
> load.
> 
> <snip />
> > Which brings up the question about guidelines for programatic use of
> > FontCache.load().  Do I use it, and just tell my users to delete that
> > cache file if they encounter problems?  Do I add an option to clear  
> > the
> > font cache?  Do I just not use it?
> 
> That's entirely up to you. For regular embedded usage, if you want to  
> be absolutely sure that all the info is reconstituted from scratch,  
> the 'useCache' option on the FontManager allows you to do just that.  
> In your case, the fact that FontInfoFinder only does something with  
> the FontCache if it is non-null could be used to the same end.
> There is obviously a price to pay in terms of processing time  
> (increased/repeated disk I/O)
> I think the cache offers a significant benefit in a good deal of  
> common use-cases, so I'd personally only disable it after repeatedly  
> running into problems.
> 
> 
> Regards
> 
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 15 Jun 2009, at 23:33, Steve Ebersole wrote:

> I am debugging through the code right now.  I am currently looking at
> FontCache.  I was not expecting cache hits, I did not realize that the
> cache was persistent.

Yes. I'm still not /completely/ up to speed as to what happens there,  
but that I know for certain. Obviously, we want to avoid, as much as  
possible, to open/read the font-file each and every time the font is  
referenced. In fact, it goes so far that, if a font-file has failed to  
load *and* the cache is not invalidated/deleted, the file will never  
be checked again, except for the modification timestamp. FOP will only  
retry parsing if the FontCache's serialVersionUID has been modified,  
or the physical file appears more recent than the one that failed to  
load.

<snip />
> Which brings up the question about guidelines for programatic use of
> FontCache.load().  Do I use it, and just tell my users to delete that
> cache file if they encounter problems?  Do I add an option to clear  
> the
> font cache?  Do I just not use it?

That's entirely up to you. For regular embedded usage, if you want to  
be absolutely sure that all the info is reconstituted from scratch,  
the 'useCache' option on the FontManager allows you to do just that.  
In your case, the fact that FontInfoFinder only does something with  
the FontCache if it is non-null could be used to the same end.
There is obviously a price to pay in terms of processing time  
(increased/repeated disk I/O)
I think the cache offers a significant benefit in a good deal of  
common use-cases, so I'd personally only disable it after repeatedly  
running into problems.


Regards


Andreas


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
I am debugging through the code right now.  I am currently looking at
FontCache.  I was not expecting cache hits, I did not realize that the
cache was persistent.  

Anyway, I'll go as far as I can here.

On Mon, 2009-06-15 at 23:27 +0200, Andreas Delmelle wrote:
> On 15 Jun 2009, at 21:44, Steve Ebersole wrote:
> 
> Hi Steve
> 
> > Now running with FOP trunk, but still have the same exact issue.  For
> > this TTC file, FontInfoFinder.find() is returning a single  
> > EmbedFontInfo
> > object which has no sub-font name.  It does however have 2
> > EmbedFontInfo.fontTriplets entries:
> > [0] = "AR PL UMing CN,normal,400"
> > [1] = "UMingCN,normal,400"
> >
> > This is exactly what the patched docx4j version was giving me for this
> > TTC.
> >
> > So is this the expected behavior?
> 
> No, I don't believe so, unless we're not seeing some relevant messages  
> about failures trying to load the other fonts in the collection. I  
> don't have a TTC at hand here to test with, otherwise I'd debug it to  
> see what's going on... Have you already tried this with other TTCs? Do  
> they exhibit the same behavior? If not, then it probably points to a  
> peculiarity in the file that we didn't account for.
> 
> 
> Regards
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 15 Jun 2009, at 21:44, Steve Ebersole wrote:

Hi Steve

> Now running with FOP trunk, but still have the same exact issue.  For
> this TTC file, FontInfoFinder.find() is returning a single  
> EmbedFontInfo
> object which has no sub-font name.  It does however have 2
> EmbedFontInfo.fontTriplets entries:
> [0] = "AR PL UMing CN,normal,400"
> [1] = "UMingCN,normal,400"
>
> This is exactly what the patched docx4j version was giving me for this
> TTC.
>
> So is this the expected behavior?

No, I don't believe so, unless we're not seeing some relevant messages  
about failures trying to load the other fonts in the collection. I  
don't have a TTC at hand here to test with, otherwise I'd debug it to  
see what's going on... Have you already tried this with other TTCs? Do  
they exhibit the same behavior? If not, then it probably points to a  
peculiarity in the file that we didn't account for.


Regards

Andreas


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Now running with FOP trunk, but still have the same exact issue.  For
this TTC file, FontInfoFinder.find() is returning a single EmbedFontInfo
object which has no sub-font name.  It does however have 2
EmbedFontInfo.fontTriplets entries:
[0] = "AR PL UMing CN,normal,400"
[1] = "UMingCN,normal,400"

This is exactly what the patched docx4j version was giving me for this
TTC.

So is this the expected behavior?



On Mon, 2009-06-15 at 21:13 +0200, Andreas Delmelle wrote:
> On 15 Jun 2009, at 21:07, Steve Ebersole wrote:
> 
> > So I went ahead and built trunk via 'ant maven-artifacts' and  
> > installed
> > the resultant artifacts into my local repo.
> >
> > I then tried re-running my transformation, but am now getting
> > "NoClassDefFoundError:
> > org/apache/xmlgraphics/util/uri/CommonURIResolver"
> 
> No Maven experience here, but it seems you're missing the latest  
> version of the XMLGraphics Common JAR.
> 
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar?view=log
> 
> 
> Regards
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Thanks for the reply Andreas.  That's actually a problem with the pom
generated by FOP's ant build then.  It does name xmlgraphics-commons as
a dependency, but it lists 1.3.

I'll try to update that and try again...


On Mon, 2009-06-15 at 21:13 +0200, Andreas Delmelle wrote:
> On 15 Jun 2009, at 21:07, Steve Ebersole wrote:
> 
> > So I went ahead and built trunk via 'ant maven-artifacts' and  
> > installed
> > the resultant artifacts into my local repo.
> >
> > I then tried re-running my transformation, but am now getting
> > "NoClassDefFoundError:
> > org/apache/xmlgraphics/util/uri/CommonURIResolver"
> 
> No Maven experience here, but it seems you're missing the latest  
> version of the XMLGraphics Common JAR.
> 
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar?view=log
> 
> 
> Regards
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 15 Jun 2009, at 21:07, Steve Ebersole wrote:

> So I went ahead and built trunk via 'ant maven-artifacts' and  
> installed
> the resultant artifacts into my local repo.
>
> I then tried re-running my transformation, but am now getting
> "NoClassDefFoundError:
> org/apache/xmlgraphics/util/uri/CommonURIResolver"

No Maven experience here, but it seems you're missing the latest  
version of the XMLGraphics Common JAR.

http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar?view=log


Regards

Andreas


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
So I went ahead and built trunk via 'ant maven-artifacts' and installed
the resultant artifacts into my local repo.

I then tried re-running my transformation, but am now getting
"NoClassDefFoundError:
org/apache/xmlgraphics/util/uri/CommonURIResolver"


On Wed, 2009-06-10 at 13:22 -0500, Steve Ebersole wrote:
> On Wed, 2009-06-10 at 19:45 +0200, Andreas Delmelle wrote:
> > On 10 Jun 2009, at 19:07, Steve Ebersole wrote:
> > 
> > Hi Steve
> > 
> > > For example, on this TTC file TTFReader is showing 4 fonts/subfonts:
> > > This is a TrueType collection file with 4 fonts
> > > Containing the following fonts:
> > > AR PL UMing CN <-- selected
> > > AR PL UMing HK
> > > AR PL UMing TW
> > > AR PL UMing TW MBE
> > > Font Family: [AR PL UMing CN]
> > > Creating xml font file...
> > > Creating CID encoded metrics...
> > > Writing xml font file example-font-metrics.xml...
> > > This font contains no embedding license restrictions.
> > >
> > > The one marked "<-- selected" is the one that is coming back from my
> > > call to org.apache.fop.fonts.autodetect.FontInfoFinder#find.
> > 
> > I think that is because it is the only sub-font that is referenced in  
> > your config snippet earlier...
> Actually its the other way around.  I am constructing that config
> snippet based on what
> org.apache.fop.fonts.autodetect.FontInfoFinder#find is returning.
> 
> > Try leaving out the explicit font element in the configuration file  
> > altogether. I'm not a 100% certain, but I believe that is causing the  
> > confusion here. Explicit individual font elements in the configuration  
> > file take precedence over those generated by auto-detection.
> But from where will the auto-detection take place?  I am trying to avoid
> having to have users "setting up their system" by installing fonts.
> This code is used as part of localized project docbook builds.
> 
> > Either remove it, or add an additional three for the other sub-fonts.
> Ok, but again I am not sure how to do that based on the EmbedFontInfo
> info FontInfoFinder is returning to me in order to add the other 3.
> 
> > Indeed, and looking at the code, I cannot see why that would not be  
> > the case here...
> Could it be the patched version I am using?  As I mentioned, I am using
> a patched fop from docx4j versioned as 0.95.756434.  I think it was
> Jason as well who pointed me at that one because the current fop
> releases are not returning an array of EmbedFontInfo instances from
> FontInfoFinder.  Anyway, there was some signature difference.
> 
> > 
> > 
> > Andreas
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> > 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
On Wed, 2009-06-10 at 19:45 +0200, Andreas Delmelle wrote:
> On 10 Jun 2009, at 19:07, Steve Ebersole wrote:
> 
> Hi Steve
> 
> > For example, on this TTC file TTFReader is showing 4 fonts/subfonts:
> > This is a TrueType collection file with 4 fonts
> > Containing the following fonts:
> > AR PL UMing CN <-- selected
> > AR PL UMing HK
> > AR PL UMing TW
> > AR PL UMing TW MBE
> > Font Family: [AR PL UMing CN]
> > Creating xml font file...
> > Creating CID encoded metrics...
> > Writing xml font file example-font-metrics.xml...
> > This font contains no embedding license restrictions.
> >
> > The one marked "<-- selected" is the one that is coming back from my
> > call to org.apache.fop.fonts.autodetect.FontInfoFinder#find.
> 
> I think that is because it is the only sub-font that is referenced in  
> your config snippet earlier...
Actually its the other way around.  I am constructing that config
snippet based on what
org.apache.fop.fonts.autodetect.FontInfoFinder#find is returning.

> Try leaving out the explicit font element in the configuration file  
> altogether. I'm not a 100% certain, but I believe that is causing the  
> confusion here. Explicit individual font elements in the configuration  
> file take precedence over those generated by auto-detection.
But from where will the auto-detection take place?  I am trying to avoid
having to have users "setting up their system" by installing fonts.
This code is used as part of localized project docbook builds.

> Either remove it, or add an additional three for the other sub-fonts.
Ok, but again I am not sure how to do that based on the EmbedFontInfo
info FontInfoFinder is returning to me in order to add the other 3.

> Indeed, and looking at the code, I cannot see why that would not be  
> the case here...
Could it be the patched version I am using?  As I mentioned, I am using
a patched fop from docx4j versioned as 0.95.756434.  I think it was
Jason as well who pointed me at that one because the current fop
releases are not returning an array of EmbedFontInfo instances from
FontInfoFinder.  Anyway, there was some signature difference.

> 
> 
> Andreas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 10 Jun 2009, at 19:07, Steve Ebersole wrote:

Hi Steve

> For example, on this TTC file TTFReader is showing 4 fonts/subfonts:
> This is a TrueType collection file with 4 fonts
> Containing the following fonts:
> AR PL UMing CN <-- selected
> AR PL UMing HK
> AR PL UMing TW
> AR PL UMing TW MBE
> Font Family: [AR PL UMing CN]
> Creating xml font file...
> Creating CID encoded metrics...
> Writing xml font file example-font-metrics.xml...
> This font contains no embedding license restrictions.
>
> The one marked "<-- selected" is the one that is coming back from my
> call to org.apache.fop.fonts.autodetect.FontInfoFinder#find.

I think that is because it is the only sub-font that is referenced in  
your config snippet earlier...

Try leaving out the explicit font element in the configuration file  
altogether. I'm not a 100% certain, but I believe that is causing the  
confusion here. Explicit individual font elements in the configuration  
file take precedence over those generated by auto-detection.

Either remove it, or add an additional three for the other sub-fonts.

> The returned org.apache.fop.fonts.EmbedFontInfo object has no sub- 
> font name
> associated with it; the only place that "AR PL UMing CN" shows up is  
> if
> I grab the first font triplet from the EmbedFontInfo as outlined in  
> the
> code snippet from the previous email (its code Jason Harrop pointed  
> out
> to me).  That triplet has FontTriplet.getName() == "AR PL UMing CN".
> There is a second FontTriplet associated with that EmbedFontInfo, with
> getName() == "UMingCN" (not sure where that name comes from).

I think this is auto-generated (the PostScript name?)

> Again I just want to verify that this is the intent.  Can I code to  
> this
> behavior and have it continue to work?  Or would you consider this a
> bug?

I'm not sure. It does at least seem odd behavior.

> To me, I would think I should get back 4 EmbedFontInfo objects
> when I call org.apache.fop.fonts.autodetect.FontInfoFinder#find on  
> this
> ttc file: fontInfos[0].subFontName=="AR PL UMing CN",
> fontInfos[1].subFontName=="AR PL UMing HK", etc (maybe 8 total  
> depending
> on where that "UMingCN" comes from).

Indeed, and looking at the code, I cannot see why that would not be  
the case here...


Andreas

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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
TTFReader did show the sub-fonts.

The problem is that I am trying to do this programatically.  So I do not
really have this information ahead of time.  I was merely using
TTFReader in order to try to understand perhaps what the <font/> mapping
should look like exactly.  So at this point I am not sure exactly to
what format I need to alter the config.  For example, can I treat this
universally and say that all all <font/> definitions from all
EmbedFontInfo will have name/subFontName the same whether its a ttf file
or ttc file?  If not, how can I tell that an EmbedFontInfo represents a
TrueType Collection?  Is the only option to see whether the embed file
ends has a .ttc extebsion?


For example, on this TTC file TTFReader is showing 4 fonts/subfonts:
This is a TrueType collection file with 4 fonts
Containing the following fonts: 
AR PL UMing CN <-- selected
AR PL UMing HK
AR PL UMing TW
AR PL UMing TW MBE
Font Family: [AR PL UMing CN]
Creating xml font file...
Creating CID encoded metrics...
Writing xml font file example-font-metrics.xml...
This font contains no embedding license restrictions.

The one marked "<-- selected" is the one that is coming back from my
call to org.apache.fop.fonts.autodetect.FontInfoFinder#find.  The
returned org.apache.fop.fonts.EmbedFontInfo object has no sub-font name
associated with it; the only place that "AR PL UMing CN" shows up is if
I grab the first font triplet from the EmbedFontInfo as outlined in the
code snippet from the previous email (its code Jason Harrop pointed out
to me).  That triplet has FontTriplet.getName() == "AR PL UMing CN".
There is a second FontTriplet associated with that EmbedFontInfo, with
getName() == "UMingCN" (not sure where that name comes from).

Again I just want to verify that this is the intent.  Can I code to this
behavior and have it continue to work?  Or would you consider this a
bug?  To me, I would think I should get back 4 EmbedFontInfo objects
when I call org.apache.fop.fonts.autodetect.FontInfoFinder#find on this
ttc file: fontInfos[0].subFontName=="AR PL UMing CN",
fontInfos[1].subFontName=="AR PL UMing HK", etc (maybe 8 total depending
on where that "UMingCN" comes from).



On Wed, 2009-06-10 at 18:42 +0200, Andreas Delmelle wrote:
> On 10 Jun 2009, at 16:29, Steve Ebersole wrote:
> 
> > P.S.  I tried running org.apache.fop.fonts.apps.TTFReader to generate
> > the metrics file just to see what FOP itself would recognize here.   
> > But
> > unfortunately I got a resultant metrics file that no text editor on
> > earth seems to be able to open; well OK, no text editor on my  
> > system :)
> 
> Didn't the TTFReader show a list of the sub-fonts before exiting?
> 
> The only thing I can think of now, is that there's something special  
> about that .TTC file...
> 
> You did alter the config as suggested earlier, right? (add the sub- 
> font to the font-element)
> 
> 
> 
> Andreas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 10 Jun 2009, at 16:29, Steve Ebersole wrote:

> P.S.  I tried running org.apache.fop.fonts.apps.TTFReader to generate
> the metrics file just to see what FOP itself would recognize here.   
> But
> unfortunately I got a resultant metrics file that no text editor on
> earth seems to be able to open; well OK, no text editor on my  
> system :)

Didn't the TTFReader show a list of the sub-fonts before exiting?

The only thing I can think of now, is that there's something special  
about that .TTC file...

You did alter the config as suggested earlier, right? (add the sub- 
font to the font-element)



Andreas

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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
P.S.  I tried running org.apache.fop.fonts.apps.TTFReader to generate
the metrics file just to see what FOP itself would recognize here.  But
unfortunately I got a resultant metrics file that no text editor on
earth seems to be able to open; well OK, no text editor on my system :)


On Wed, 2009-06-10 at 09:26 -0500, Steve Ebersole wrote:
> So here is the code fragment I use to load the "font info":
> 
> FontCache fontCache = FontCache.load();
> if ( fontCache == null ) {
>     fontCache = new FontCache();
> }
> 
> FontInfoFinder fontInfoFinder = new FontInfoFinder();
> 
> // fontResolver below is a custom font resolver which 
> // just does some logging while delegating to the 
> // resolver returned from FontSetup.createMinimalFontResolver()
> 
> for ( File fontFile : fontDirectory.listFiles() ) {
>     EmbedFontInfo[] infos = fontInfoFinder.find( 
>             toURL( fontFile ), 
>             fontResolver, 
>             fontCache 
>     );
> 
>     if ( infos == null || infos.length == 0 ) {
>         // log error
>         continue;
>     }
> 
>     for ( EmbedFontInfo info : infos ) {
>         // log some info...
>         if ( info.getEmbedFile() != null ) {
>             infoList.add( info );
>         }
>     }
> }
> 
> However, the fontInfoFinder.find() call is returning just a single font
> info for the TTC file (just this particular TTC file maybe?).  And that
> single font info has no sub-font name associated with it.  It seems to
> recognize only one of the sub-fonts (not sure if it is just coincidence,
> but it appears to recognize the first sub-font).  Is this the intended
> behavior?
> 
> BTW, this is using a patched fop from docx4j versioned as 0.95.756434 if
> that makes any difference.
> 
> 
> On Wed, 2009-06-10 at 08:21 +0200, Andreas Delmelle wrote:
> > On 10 Jun 2009, at 06:18, Steve Ebersole wrote:
> > 
> > Hi Steve
> > 
> > > Anyone please?  Do we just need to say this is not going to work for  
> > > TTC
> > > files?  I am just setting this up incorrectly?
> > 
> > Sorry for the late reply.
> > 
> > See: http://xmlgraphics.apache.org/fop/trunk/fonts.html#truetype-collections-metrics
> > 
> > You have to register each sub-font in the TTC, by means of a "sub- 
> > font" attribute on the font element.
> > 
> > 
> > HTH!
> > 
> > Andreas
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> > 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
So here is the code fragment I use to load the "font info":

FontCache fontCache = FontCache.load();
if ( fontCache == null ) {
    fontCache = new FontCache();
}

FontInfoFinder fontInfoFinder = new FontInfoFinder();

// fontResolver below is a custom font resolver which 
// just does some logging while delegating to the 
// resolver returned from FontSetup.createMinimalFontResolver()

for ( File fontFile : fontDirectory.listFiles() ) {
    EmbedFontInfo[] infos = fontInfoFinder.find( 
            toURL( fontFile ), 
            fontResolver, 
            fontCache 
    );

    if ( infos == null || infos.length == 0 ) {
        // log error
        continue;
    }

    for ( EmbedFontInfo info : infos ) {
        // log some info...
        if ( info.getEmbedFile() != null ) {
            infoList.add( info );
        }
    }
}

However, the fontInfoFinder.find() call is returning just a single font
info for the TTC file (just this particular TTC file maybe?).  And that
single font info has no sub-font name associated with it.  It seems to
recognize only one of the sub-fonts (not sure if it is just coincidence,
but it appears to recognize the first sub-font).  Is this the intended
behavior?

BTW, this is using a patched fop from docx4j versioned as 0.95.756434 if
that makes any difference.


On Wed, 2009-06-10 at 08:21 +0200, Andreas Delmelle wrote:
> On 10 Jun 2009, at 06:18, Steve Ebersole wrote:
> 
> Hi Steve
> 
> > Anyone please?  Do we just need to say this is not going to work for  
> > TTC
> > files?  I am just setting this up incorrectly?
> 
> Sorry for the late reply.
> 
> See: http://xmlgraphics.apache.org/fop/trunk/fonts.html#truetype-collections-metrics
> 
> You have to register each sub-font in the TTC, by means of a "sub- 
> font" attribute on the font element.
> 
> 
> HTH!
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 10 Jun 2009, at 06:18, Steve Ebersole wrote:

Hi Steve

> Anyone please?  Do we just need to say this is not going to work for  
> TTC
> files?  I am just setting this up incorrectly?

Sorry for the late reply.

See: http://xmlgraphics.apache.org/fop/trunk/fonts.html#truetype-collections-metrics

You have to register each sub-font in the TTC, by means of a "sub- 
font" attribute on the font element.


HTH!

Andreas


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Anyone please?  Do we just need to say this is not going to work for TTC
files?  I am just setting this up incorrectly?


On Tue, 2009-06-09 at 10:28 -0500, Steve Ebersole wrote:
> Ooops, I had temporarily disabled the font registration code at one
> point to try to work around stuff and forgotten to re-enable it.  After
> re-enabling it, I am getting an exception about reading a TrueType font
> collection.  I have only one ttc file (uming.ttc), so i have to assume
> it is that one being processed.
> 
> The userconfig is generated by my code, and here is what gets passed in:
> <fop version="1.0">
>   <strict-configuration>true</strict-configuration>
>   <renderers>
>     <renderer mime="application/pdf">
>       <fonts>
>         ...
>         <font
> embed-url="file:/home/steve/projects/sandbox/jdocbook/target/docbook/staging/fonts/uming.ttc">
>           <font-triplet 
>               style="normal" 
>               name="AR PL UMing CN" 
>               weight="normal"/>
>           <font-triplet 
>               style="normal" 
>               name="AR PL UMing CN" 
>               weight="bold"/>
>           <font-triplet 
>               style="italic" 
>               name="AR PL UMing CN" 
>               weight="bold"/>
>            <font-triplet 
>               style="italic" 
>               name="AR PL UMing CN" 
>               weight="normal"/>
>         </font>
>       </fonts>
>     </renderer>
>   </renderers>
> </fop>
> 
> 
> I have attached the output log as well as the fragments of java code
> used to create this userconfig.
> 
> 
> Here is the snipped exception (present in the log too):
> 
> java.lang.IllegalArgumentException: For TrueType collection you must
> specify which font to select (-ttcname)
> 	at org.apache.fop.fonts.truetype.TTFFile.readFont(TTFFile.java:480)
> 	at
> org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:98)
> 	at
> org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:84)
> 	at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:190)
> 	at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:139)
> 	at org.apache.fop.fonts.LazyFont.load(LazyFont.java:134)
> 	at org.apache.fop.fonts.LazyFont.getAscender(LazyFont.java:241)
> 	at org.apache.fop.fonts.Font.getAscender(Font.java:106)
> 	at
> org.apache.fop.layoutmgr.BlockLayoutManager.initialize(BlockLayoutManager.java:89)
> 	at
> org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:119)
> 	at
> org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:75)
> 	at
> org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:144)
> 	at
> org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:553)
> 	at
> org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:136)
> 	at
> org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:303)
> 	at
> org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:265)
> 	at
> org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107)
> 	at
> org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238)
> 	at
> org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120)
> 	at org.apache.fop.fo.FOTreeBuilder
> $MainFOHandler.endElement(FOTreeBuilder.java:348)
> 	at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
> 	at
> com.icl.saxon.output.ContentHandlerProxy.endElement(ContentHandlerProxy.java:137)
> 	at com.icl.saxon.output.ProxyEmitter.endElement(ProxyEmitter.java:91)
> 	at
> com.icl.saxon.output.NamespaceEmitter.endElement(NamespaceEmitter.java:150)
> 	at
> com.icl.saxon.output.GeneralOutputter.writeEndTag(GeneralOutputter.java:681)
> 	at
> com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:293)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
> 	at
> com.icl.saxon.style.XSLCallTemplate.process(XSLCallTemplate.java:187)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLIf.process(XSLIf.java:78)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
> 	at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
> 	at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
> 	at
> com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at
> com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:289)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
> 	at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
> 	at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
> 	at com.icl.saxon.Controller.defaultAction(Controller.java:271)
> 	at com.icl.saxon.Controller.applyTemplates(Controller.java:236)
> 	at
> com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLIf.process(XSLIf.java:78)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
> 	at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
> 	at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
> 	at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
> 	at
> com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
> 	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
> 	at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
> 	at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
> 	at com.icl.saxon.Controller.run(Controller.java:178)
> 	at com.icl.saxon.Controller.transformDocument(Controller.java:1086)
> 	at com.icl.saxon.Controller.transform(Controller.java:953)
> 	at
> org.jboss.jdocbook.render.impl.BasicRenderer.performRendering(BasicRenderer.java:165)
> 	at
> org.jboss.jdocbook.render.impl.BasicRenderer.render(BasicRenderer.java:153)
> 	at
> org.jboss.jdocbook.render.impl.BasicRenderer.render(BasicRenderer.java:98)
> 	at
> org.jboss.maven.plugins.jdocbook.GenerationMojo.process(GenerationMojo.java:112)
> 	at
> org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.doExecute(AbstractDocBookMojo.java:379)
> 	at
> org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.execute(AbstractDocBookMojo.java:407)
> 	at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> ...
> 
> 
> I am really at a loss.
> 
> 
> On Mon, 2009-06-08 at 10:07 -0500, Steve Ebersole wrote:
> > Back at this yet again.
> > 
> > This time I added a feature to the maven plugin to actually dump the FO
> > file (I actually use the SAX approach for rendering, so iit was
> > previously not needed).  I am attaching it here.  As a total noob I have
> > no clue what to look for.  I do see the correct font-family selections
> > in the FO file.  I also added some output from my XSLT where I specify
> > the pickfont selections and verified that those are correct.
> > 
> > Yet I see lots of warning log messages which seem related to not being
> > able to locate the fonts.  Things like certain glyphs not being
> > available, etc.  I've attached the log output as well, but here is an
> > example:
> > 
> > WARNING: Font "Symbol,normal,700" not found. Substituting with
> > "Symbol,normal,400".
> > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
> > "ZapfDingbats,normal,400".
> > WARNING: Glyph "符" (0x7b26) not available in font "Helvetica-Bold".
> > 
> > 
> > 
> > 
> > 
> > On Tue, 2009-04-07 at 19:32 +0200, Andreas Delmelle wrote:
> > > On 07 Apr 2009, at 17:39, Steve Ebersole wrote:
> > > 
> > > Hi Steve
> > > 
> > > > 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):
> > > > <snip />
> > > >
> > > > 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.
> > > 
> > > Most likely an issue with the TTF file. FOP still chokes on some TTFs  
> > > (mostly on Linux and Mac OS, or OTF variants)
> > > Do you get any log output indicating such a problem?
> > > 
> > > Checking the code, FontInfoFinder.find() will return null if:
> > > * there is a FontCache and the file has failed to load on a previous  
> > > attempt. We only display the corresponding message if the log-level is  
> > > set to DEBUG.
> > > 
> > > * the file failed to load, but it is the first attempt. In FOP Trunk,  
> > > a message is then broadcast to the attached EventListener (if it has  
> > > been registered).
> > > 
> > > 
> > > HTH!
> > > 
> > > Andreas
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> > > 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Ooops, I had temporarily disabled the font registration code at one
point to try to work around stuff and forgotten to re-enable it.  After
re-enabling it, I am getting an exception about reading a TrueType font
collection.  I have only one ttc file (uming.ttc), so i have to assume
it is that one being processed.

The userconfig is generated by my code, and here is what gets passed in:
<fop version="1.0">
  <strict-configuration>true</strict-configuration>
  <renderers>
    <renderer mime="application/pdf">
      <fonts>
        ...
        <font
embed-url="file:/home/steve/projects/sandbox/jdocbook/target/docbook/staging/fonts/uming.ttc">
          <font-triplet 
              style="normal" 
              name="AR PL UMing CN" 
              weight="normal"/>
          <font-triplet 
              style="normal" 
              name="AR PL UMing CN" 
              weight="bold"/>
          <font-triplet 
              style="italic" 
              name="AR PL UMing CN" 
              weight="bold"/>
           <font-triplet 
              style="italic" 
              name="AR PL UMing CN" 
              weight="normal"/>
        </font>
      </fonts>
    </renderer>
  </renderers>
</fop>


I have attached the output log as well as the fragments of java code
used to create this userconfig.


Here is the snipped exception (present in the log too):

java.lang.IllegalArgumentException: For TrueType collection you must
specify which font to select (-ttcname)
	at org.apache.fop.fonts.truetype.TTFFile.readFont(TTFFile.java:480)
	at
org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:98)
	at
org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:84)
	at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:190)
	at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:139)
	at org.apache.fop.fonts.LazyFont.load(LazyFont.java:134)
	at org.apache.fop.fonts.LazyFont.getAscender(LazyFont.java:241)
	at org.apache.fop.fonts.Font.getAscender(Font.java:106)
	at
org.apache.fop.layoutmgr.BlockLayoutManager.initialize(BlockLayoutManager.java:89)
	at
org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:119)
	at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:75)
	at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:144)
	at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:553)
	at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:136)
	at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:303)
	at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:265)
	at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107)
	at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238)
	at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120)
	at org.apache.fop.fo.FOTreeBuilder
$MainFOHandler.endElement(FOTreeBuilder.java:348)
	at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
	at
com.icl.saxon.output.ContentHandlerProxy.endElement(ContentHandlerProxy.java:137)
	at com.icl.saxon.output.ProxyEmitter.endElement(ProxyEmitter.java:91)
	at
com.icl.saxon.output.NamespaceEmitter.endElement(NamespaceEmitter.java:150)
	at
com.icl.saxon.output.GeneralOutputter.writeEndTag(GeneralOutputter.java:681)
	at
com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:293)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
	at
com.icl.saxon.style.XSLCallTemplate.process(XSLCallTemplate.java:187)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLIf.process(XSLIf.java:78)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
	at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
	at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
	at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at
com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:289)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
	at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
	at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
	at com.icl.saxon.Controller.defaultAction(Controller.java:271)
	at com.icl.saxon.Controller.applyTemplates(Controller.java:236)
	at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLIf.process(XSLIf.java:78)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
	at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
	at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
	at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
	at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
	at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
	at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
	at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
	at com.icl.saxon.Controller.run(Controller.java:178)
	at com.icl.saxon.Controller.transformDocument(Controller.java:1086)
	at com.icl.saxon.Controller.transform(Controller.java:953)
	at
org.jboss.jdocbook.render.impl.BasicRenderer.performRendering(BasicRenderer.java:165)
	at
org.jboss.jdocbook.render.impl.BasicRenderer.render(BasicRenderer.java:153)
	at
org.jboss.jdocbook.render.impl.BasicRenderer.render(BasicRenderer.java:98)
	at
org.jboss.maven.plugins.jdocbook.GenerationMojo.process(GenerationMojo.java:112)
	at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.doExecute(AbstractDocBookMojo.java:379)
	at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.execute(AbstractDocBookMojo.java:407)
	at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
...


I am really at a loss.


On Mon, 2009-06-08 at 10:07 -0500, Steve Ebersole wrote:
> Back at this yet again.
> 
> This time I added a feature to the maven plugin to actually dump the FO
> file (I actually use the SAX approach for rendering, so iit was
> previously not needed).  I am attaching it here.  As a total noob I have
> no clue what to look for.  I do see the correct font-family selections
> in the FO file.  I also added some output from my XSLT where I specify
> the pickfont selections and verified that those are correct.
> 
> Yet I see lots of warning log messages which seem related to not being
> able to locate the fonts.  Things like certain glyphs not being
> available, etc.  I've attached the log output as well, but here is an
> example:
> 
> WARNING: Font "Symbol,normal,700" not found. Substituting with
> "Symbol,normal,400".
> WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
> "ZapfDingbats,normal,400".
> WARNING: Glyph "符" (0x7b26) not available in font "Helvetica-Bold".
> 
> 
> 
> 
> 
> On Tue, 2009-04-07 at 19:32 +0200, Andreas Delmelle wrote:
> > On 07 Apr 2009, at 17:39, Steve Ebersole wrote:
> > 
> > Hi Steve
> > 
> > > 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):
> > > <snip />
> > >
> > > 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.
> > 
> > Most likely an issue with the TTF file. FOP still chokes on some TTFs  
> > (mostly on Linux and Mac OS, or OTF variants)
> > Do you get any log output indicating such a problem?
> > 
> > Checking the code, FontInfoFinder.find() will return null if:
> > * there is a FontCache and the file has failed to load on a previous  
> > attempt. We only display the corresponding message if the log-level is  
> > set to DEBUG.
> > 
> > * the file failed to load, but it is the first attempt. In FOP Trunk,  
> > a message is then broadcast to the attached EventListener (if it has  
> > been registered).
> > 
> > 
> > HTH!
> > 
> > Andreas
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> > 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org

Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Back at this yet again.

This time I added a feature to the maven plugin to actually dump the FO
file (I actually use the SAX approach for rendering, so iit was
previously not needed).  I am attaching it here.  As a total noob I have
no clue what to look for.  I do see the correct font-family selections
in the FO file.  I also added some output from my XSLT where I specify
the pickfont selections and verified that those are correct.

Yet I see lots of warning log messages which seem related to not being
able to locate the fonts.  Things like certain glyphs not being
available, etc.  I've attached the log output as well, but here is an
example:

WARNING: Font "Symbol,normal,700" not found. Substituting with
"Symbol,normal,400".
WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
"ZapfDingbats,normal,400".
WARNING: Glyph "符" (0x7b26) not available in font "Helvetica-Bold".





On Tue, 2009-04-07 at 19:32 +0200, Andreas Delmelle wrote:
> On 07 Apr 2009, at 17:39, Steve Ebersole wrote:
> 
> Hi Steve
> 
> > 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):
> > <snip />
> >
> > 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.
> 
> Most likely an issue with the TTF file. FOP still chokes on some TTFs  
> (mostly on Linux and Mac OS, or OTF variants)
> Do you get any log output indicating such a problem?
> 
> Checking the code, FontInfoFinder.find() will return null if:
> * there is a FontCache and the file has failed to load on a previous  
> attempt. We only display the corresponding message if the log-level is  
> set to DEBUG.
> 
> * the file failed to load, but it is the first attempt. In FOP Trunk,  
> a message is then broadcast to the attached EventListener (if it has  
> been registered).
> 
> 
> HTH!
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org

Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 08 Apr 2009, at 15:21, Steve Ebersole wrote:

Hi Steve

> So there is obviously still something I am missing:
> 1) Told FOP about the fonts (via DefaultConfiguration ->
> FopFactory.userConfig)
> 2) Set the defined DocBook font family xslt params
> ('monospace.font.family', et al).
> 3) ???

Can you perform the XSLT transform and send us the resulting FO? Maybe  
something in there tells us why you're getting the missing glyphs.  
(unless of course, you already confirmed that it works from the  
command-line...)

Without looking at the FO result, I'm suspecting that, since you're  
now working with 0.95, there is still no automatic font-selection  
available. If the first font in the specified list of families does  
not contain the glyph, then FOP 0.95 will not yet look at the  
remaining specified fonts. FOP Trunk already contains basic support  
for font-selection-strategy (= will render a word in the font that can  
correctly display most or all of the glyphs, if such a font is  
specified and available).

Another option would be to render the same XML+XSLT with FOP Trunk. If  
that works, then the above is the most likely cause. If not, then we  
have to look elsewhere.



Regards

Andreas

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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Attempting to use the patched version published by Jason
http://dev.plutext.org/svn/docx4j/trunk/docx4j/m2/docx4j/fop-patched/0.95.756434/

However, now the error is just delayed.  Instead of happening when
executing FontInfoFinder.find, I instead get the same basic error later
when FOP tries to initialize the page layout[1].  Also, I found it
interesting that FontInfoFinder.find returns my a EmbedFontInfos array
with only one element when I know it has 4 font definitons (and logging
from TTFFile.checkTTC shows all 4).


[1]
java.lang.IllegalArgumentException: For TrueType collection you must
specify which font to select (-ttcname)
	at org.apache.fop.fonts.truetype.TTFFile.readFont(TTFFile.java:480)
	at
org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:98)
	at
org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:84)
	at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:190)
	at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:139)
	at org.apache.fop.fonts.LazyFont.load(LazyFont.java:134)
	at org.apache.fop.fonts.LazyFont.getAscender(LazyFont.java:241)
	at org.apache.fop.fonts.Font.getAscender(Font.java:106)
	at
org.apache.fop.layoutmgr.BlockLayoutManager.initialize(BlockLayoutManager.java:89)
	at
org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:119)
	at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:75)
	at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:144)
	at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:553)
	at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:136)
	at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:303)
	at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:265)
	at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107)
	at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238)
	at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120)
	at org.apache.fop.fo.FOTreeBuilder
$MainFOHandler.endElement(FOTreeBuilder.java:348)
	at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
	at
com.icl.saxon.output.ContentHandlerProxy.endElement(ContentHandlerProxy.java:137)



On Wed, 2009-04-08 at 19:24 +0200, Andreas Delmelle wrote:
> On 08 Apr 2009, at 19:00, Steve Ebersole wrote:
> 
> > <snip />
> >
> > Interestingly, the code Jason showed me has FontInfoFinder.find
> > returning an array of EmbedFontInfos, whereas the version of FOP I am
> > using 0.95 returns just a single EmbedFontInfo.  Perhaps this is a
> > change in trunk to handle just this font-collection issue?
> 
> Yep, a patch submitted by Jason himself, which was only committed to  
> Trunk at the time:
> http://svn.eu.apache.org/viewvc?view=rev&revision=644208
> 
> 
> Regards
> 
> Andreas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 08 Apr 2009, at 19:00, Steve Ebersole wrote:

> <snip />
>
> Interestingly, the code Jason showed me has FontInfoFinder.find
> returning an array of EmbedFontInfos, whereas the version of FOP I am
> using 0.95 returns just a single EmbedFontInfo.  Perhaps this is a
> change in trunk to handle just this font-collection issue?

Yep, a patch submitted by Jason himself, which was only committed to  
Trunk at the time:
http://svn.eu.apache.org/viewvc?view=rev&revision=644208


Regards

Andreas

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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
Found the problem here.  The font I choose to test with is part of
a .ttc collection.  FontInfoFinder is not liking that at all:


Attempting to resolve font :
file:/home/steve/projects/sandbox/jdocbook/target/docbook/staging/fonts/uming.ttc

INFO: This is a TrueType collection file with 4 fonts
INFO: Containing the following fonts: 
INFO: AR PL UMing CN
INFO: AR PL UMing HK
INFO: AR PL UMing TW
INFO: AR PL UMing TW MBE

Apr 8, 2009 11:23:18 AM org.apache.fop.fonts.autodetect.FontInfoFinder
find
SEVERE: Unable to load font file:
file:/home/steve/projects/sandbox/jdocbook/target/docbook/staging/fonts/uming.ttc. Reason: For TrueType collection you must specify which font to select (-ttcname)


Interestingly, the code Jason showed me has FontInfoFinder.find
returning an array of EmbedFontInfos, whereas the version of FOP I am
using 0.95 returns just a single EmbedFontInfo.  Perhaps this is a
change in trunk to handle just this font-collection issue?  If not, is
there something I am missing?

-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
The previous problem was definitely some issue with 0.94 which has since
been corrected.  I upgraded to 0.95 and fixed the issue FOP was
complaining about (after finally tracking it down) in the DocBook
sources and the EmbedFontInfo is now found correctly, which I use to
build the DefaultConfiguration as suggested by Jason (though I do it
slightly differently then he does).

I have also ensured that the following xslt params are properly set
(based on an xslt template selection given 'l10n.gentext.language =
zh-CN':
1) monospace.font.family = ZYSong18030,AR PL UMing CN,Liberation
Mono,monospace
2) body.font.family ZYSong18030,AR PL UMing CN,Liberation
Sans,sans-serif
3) title.font.family = ZYSong18030,AR PL UMing CN,Liberation
Sans,sans-serif
4) sans.font.family = ZYSong18030,AR PL UMing CN,Liberation
Sans,sans-serif

Yet FOP is still not rendering my pdf using those fonts.  My only means
of verifying this is opening the pdf (lots of '#' marks instead of
Chinese glyphs), opening it's properties and checking the embedded
fonts.

So there is obviously still something I am missing:
1) Told FOP about the fonts (via DefaultConfiguration ->
FopFactory.userConfig)
2) Set the defined DocBook font family xslt params
('monospace.font.family', et al).
3) ???


On Tue, 2009-04-07 at 19:32 +0200, Andreas Delmelle wrote:
> On 07 Apr 2009, at 17:39, Steve Ebersole wrote:
> 
> Hi Steve
> 
> > 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):
> > <snip />
> >
> > 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.
> 
> Most likely an issue with the TTF file. FOP still chokes on some TTFs  
> (mostly on Linux and Mac OS, or OTF variants)
> Do you get any log output indicating such a problem?
> 
> Checking the code, FontInfoFinder.find() will return null if:
> * there is a FontCache and the file has failed to load on a previous  
> attempt. We only display the corresponding message if the log-level is  
> set to DEBUG.
> 
> * the file failed to load, but it is the first attempt. In FOP Trunk,  
> a message is then broadcast to the attached EventListener (if it has  
> been registered).
> 
> 
> HTH!
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
On Tue, 2009-04-07 at 21:11 +0200, Andreas Delmelle wrote:
> On 07 Apr 2009, at 20:00, Steve Ebersole wrote:
> 
> > This is in fact on Linux (Fedora).  The odd thing though is that I  
> > have
> > seen these fonts works in FOP on Linux in the publican builds (which  
> > is
> > the documentation build system used by Fedora and RedHat).
> 
> Are those the exact same font-files?
Positive.  Publican only runs on Linux boxes and specifically loads the
fonts from /usr/share/fonts, which is exactly from where I grabbed mine.

> 
> > They rely on <auto-detect/>-ion though, so maybe it just handles the  
> > fonts
> > differently than this code.
> 
> IIJC, one big difference between the auto-detection routine and your  
> approach is that in the first case, a FontEventListener will  
> automatically be registered. If you're working with the trunk code,  
> then you will probably want to look at using  
> FontInfoFinder.setEventListener() to be notified about failed attempts  
> to load the font.
This may just be an issue with 0.94.  I pushed it back up to 0.95 and
the fonts at least are getting recognized (I am getting EmbedFontInfo).
But upgrading to 0.95 is also, unfortunately giving me errors on the
docbook source or in the xslt :(

Guess I'll spend a little time and try to track that down

> 
> Roughly, something like:
> 
>      fontInfoFinder.setEventListener(
>          new org.apache.fop.fonts.FontEventAdapter(
>                 foUserAgent.getEventBroadcaster());
> 
> 
> 
> 
> If none is registered, it seems like find() assumes that you're not  
> interested in the event, and silently returns null, without giving any  
> indication as to what is going on (why the font fails to load).
> 
> > As another option, I read in the docs[1] that jars can be created  
> > with a
> > particular manifest entry and that FOP would automatically find them  
> > as
> > part of <auto-detect/>.  Curious which ClassLoader it uses for this?
> 
> I'm not 100% sure. That would most likely be the one that is used to  
> load the FopFactory, to which the font resources are attached (like  
> most resources that can be shared between runs).
> 
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 07 Apr 2009, at 20:00, Steve Ebersole wrote:

> This is in fact on Linux (Fedora).  The odd thing though is that I  
> have
> seen these fonts works in FOP on Linux in the publican builds (which  
> is
> the documentation build system used by Fedora and RedHat).

Are those the exact same font-files?

> They rely on <auto-detect/>-ion though, so maybe it just handles the  
> fonts
> differently than this code.

IIJC, one big difference between the auto-detection routine and your  
approach is that in the first case, a FontEventListener will  
automatically be registered. If you're working with the trunk code,  
then you will probably want to look at using  
FontInfoFinder.setEventListener() to be notified about failed attempts  
to load the font.

Roughly, something like:

     fontInfoFinder.setEventListener(
         new org.apache.fop.fonts.FontEventAdapter(
                foUserAgent.getEventBroadcaster());




If none is registered, it seems like find() assumes that you're not  
interested in the event, and silently returns null, without giving any  
indication as to what is going on (why the font fails to load).

> As another option, I read in the docs[1] that jars can be created  
> with a
> particular manifest entry and that FOP would automatically find them  
> as
> part of <auto-detect/>.  Curious which ClassLoader it uses for this?

I'm not 100% sure. That would most likely be the one that is used to  
load the FopFactory, to which the font resources are attached (like  
most resources that can be shared between runs).


Andreas


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
This is in fact on Linux (Fedora).  The odd thing though is that I have
seen these fonts works in FOP on Linux in the publican builds (which is
the documentation build system used by Fedora and RedHat).  They rely on
<auto-detect/>-ion though, so maybe it just handles the fonts
differently than this code.

As another option, I read in the docs[1] that jars can be created with a
particular manifest entry and that FOP would automatically find them as
part of <auto-detect/>.  Curious which ClassLoader it uses for this?

[1] http://xmlgraphics.apache.org/fop/trunk/fonts.html#autodetect

On Tue, 2009-04-07 at 19:32 +0200, Andreas Delmelle wrote:
> On 07 Apr 2009, at 17:39, Steve Ebersole wrote:
> 
> Hi Steve
> 
> > 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):
> > <snip />
> >
> > 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.
> 
> Most likely an issue with the TTF file. FOP still chokes on some TTFs  
> (mostly on Linux and Mac OS, or OTF variants)
> Do you get any log output indicating such a problem?
> 
> Checking the code, FontInfoFinder.find() will return null if:
> * there is a FontCache and the file has failed to load on a previous  
> attempt. We only display the corresponding message if the log-level is  
> set to DEBUG.
> 
> * the file failed to load, but it is the first attempt. In FOP Trunk,  
> a message is then broadcast to the attached EventListener (if it has  
> been registered).
> 
> 
> HTH!
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Andreas Delmelle <an...@telenet.be>.
On 07 Apr 2009, at 17:39, Steve Ebersole wrote:

Hi Steve

> 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):
> <snip />
>
> 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.

Most likely an issue with the TTF file. FOP still chokes on some TTFs  
(mostly on Linux and Mac OS, or OTF variants)
Do you get any log output indicating such a problem?

Checking the code, FontInfoFinder.find() will return null if:
* there is a FontCache and the file has failed to load on a previous  
attempt. We only display the corresponding message if the log-level is  
set to DEBUG.

* the file failed to load, but it is the first attempt. In FOP Trunk,  
a message is then broadcast to the attached EventListener (if it has  
been registered).


HTH!

Andreas


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


Re: Font registration

Posted by Steve Ebersole <st...@hibernate.org>.
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 <st...@hibernate.org> 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
> >> > steve@hibernate.org
> >> >
> >> > Principal Software Engineer
> >> > JBoss, a division of Red Hat
> >> > http://jboss.com
> >> > http://redhat.com
> >> > steve.ebersole@jboss.com
> >> > steve.ebersole@redhat.com
> >> >
> >> >
> >>
> >>
> >> Jeremias Maerki
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >>
> > --
> > Steve Ebersole <st...@hibernate.org>
> > Hibernate.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org


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


Re: Font registration

Posted by Jason Harrop <jh...@gmail.com>.
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 <st...@hibernate.org> 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
>> > steve@hibernate.org
>> >
>> > Principal Software Engineer
>> > JBoss, a division of Red Hat
>> > http://jboss.com
>> > http://redhat.com
>> > steve.ebersole@jboss.com
>> > steve.ebersole@redhat.com
>> >
>> >
>>
>>
>> Jeremias Maerki
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
> --
> Steve Ebersole <st...@hibernate.org>
> Hibernate.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>

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