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: [email protected]
For additional commands, e-mail: [email protected]
