Hi, sorry for answering that late ....
> Robert Meyer <[email protected]> hat am 30. August 2013 um 12:57 >geschrieben: > > > Currently I am working on subsetting Type 1 fonts but need a way to verify > that what I have done is correct. In fontbox there is a class called > Type1CharStringParser which appears to do what I want. However, there seems > to be inconsistencies with the code and what it is saying in the > specification? For example, the parse method is expecting an IndexData > object like like that found in CFF, but the data doesn't come in that > format. I have already parsed the binary data myself and decrypted it so I > guess I could create one, but this leads me on to the second point. The > parse() method uses a bias to calculate the subroutine number, but I can > see no mention of this in the specification. The only thing I did find was > from the Type 2 specification which states: > > "The above calculation obviates the need for an explicit bias to be stored > in the font which is currently the case for Type 1 fonts." > > So, if the bias is stored in the font somewhere, why is fontbox using fixed > values for which they are only used in Type 2 and CFF fonts. > > I am not saying this code is worng, but has anyone tested this with a true > Type 1 font and it actually worked? Also, the Type 1 and CFF parsing seems > to be inexorably linked, so is this Type 1 parser doing something different > than I am expecting? > > Any help would be appreciated. The whole stuff was added to parse embedded CFF fonts and to convert them to type1 fonts, so that those can be rendered using the buildin font support of the JVM. I tried to understand the code some time ago. It is very complicated and as far as I remember some things are somehow mixed up, e.g. the handling of type1 and type2 commands. I pretty sure that we have to rewrite/overhaul the code but I didn't find the time. I'm working on an improved font rendering support and maybe this will be the right moment to fix/improve the parser as well. And yes, any help is appreciated :-) > Thanks, > > Robert Meyer Sorry, that wasn't that much of help BR Andreas Lehmkühler
