This commit is somewhat "high-risk". :-) I was very careful not to break
anything but you never know. At least, if it worked, one can now write
an FO file and produce PDF and TIFF/PNG from it without having to change
any font names if font auto-detection is enabled.
BTW, I was quite surprised to find that the subset handling of TrueType
was in fact not according to the specification. With this change,
Acrobat no longer reports "1Efb6aFuturaBT-Book (Embedded)" for a font,
but "FuturaBT-Book (Embedded Subset)". The old prefix was not correct.
It is now generated as (for example) "EAAAAA+FuturaBT-Book", i.e. with 6
uppercase characters and a "+" character to delimit the font name.
As noted in the commit message, the FontTriplet class should be
rethought. fontLookup() starts to get too many loops with some added
functionality. It's probably better to make a hierarchical structure
like a Map<String, FontVariant> where String is the font family and
FontVariant consist of the style and weight with a pointer to the actual
font. And then, of course, there is the whole "FontSource" idea....
On 08.11.2007 16:13:28 jeremias wrote:
> Author: jeremias
> Date: Thu Nov 8 07:13:24 2007
> New Revision: 593189
> URL: http://svn.apache.org/viewvc?rev=593189&view=rev
> Improved font auto-detection and handling of AWT-supplied fonts in order to
> achieve better results when using multiple output formats. Whenever possible,
> the font names appearing in the operating system can also be used in XSL-FO.
> Better distinction between Font Family Name ("Arial"), Full Font Name ("Arial
> Bold") and PostScript Name ("Arial-BoldMT"). This allows a better generation
> of FontTriplets. The same is done for AWT fonts where I have switch from
> font-family detection to enumerating all java.awt.Font instances so I can
> extract Family Name, Full Name and PostScript Name. FontInfoFinder and AWT's
> FontSetup are synchronized as well as possible at this time.
> Register "extra-bold" (weight 800) and "light" (weight 200) in triplets when
> Tweaked FontInfo.fontLookup() for better fallback behaviour. This approach is
> rapidly nearing its flexibility limits. We should rethink the FontTriplet
> Fixed font-autodetection so fonts with uppercase extensions are detected, too.
> Made the way TrueType fonts are embedded in PDF compliant to the
> specification so viewers correctly identify subset fonts. The name prefix in
> MultiByteFont was incorrect.
> Support the detection of the special Type 1 Symbol font. Symbol used to be
> detected with "ExpertSubsetEncoding" instead of "SymbolEncoding".
> Type1FontLoader tries to construct a "full name" from the PostScript name.
> This is a temporary hack until we have a PFB or PFA parser.