Well, as far as I know relying on dfCharset is not safe. The barcode
font that caused the problem didn't use Expert(Subset) encoding. It had
a custom encoding ("FontSpecific").Do you have a pointer to a specification that shows that dfCharset=2 means ExpertSubset encoding? AFAICS, the only realiable method to detect the encoding of a font is inspecting the AFM or the PFB file which we don't support, yet. The AFM often contains the name of the encoding. In the case of "FontSpecific" encodings, the PFA or PFB file has to be parsed to extract the custom encoding. Jeremias Maerki On 16.11.2007 18:45:34 Adrian Cumiskey wrote: > Hi Jeremias, > > As far as I know any parsed PFM file (Type 1 font) with a dfCharset=2 is > using ExpertSubset encoding > and similarly dfCharset=1 is Expert encoding). > > The problem before was that FOP was only able to detect Expert and > ExpertSubset encoding types but > was not able to provide the glyph mappings. I have now spent some time > providing support for these > and from the testing I have done it seems to work fine, so unless there are > any objections I will > add the detection back in and commit my changes after the weekend. > > Adrian. > > [EMAIL PROTECTED] wrote: > > Author: jeremias > > Date: Thu Nov 15 05:28:58 2007 > > New Revision: 595297 > > > > URL: http://svn.apache.org/viewvc?rev=595297&view=rev > > Log: > > Bugzilla #43143: > > Had to remove the Expert(Subset) Encoding detection as this caused problems > > with a barcode font that used dfCharset=2 but was not using ExpertSubset > > encoding. To detect Expert(Subset)Encoding, the AFM needs to be parsed. And > > since we don't support that encoding, yet, the fallback to WinAnsiEncoding > > should work well enough. > > > > Modified: > > xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java <snip/>
