Fontbox Type1 support inconsistencies

[Robert Meyer <tr...@googlemail.com>]

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.

Thanks,

Robert Meyer

Re: Fontbox Type1 support inconsistencies

[Timo Boehme <ti...@ontochem.com>]

Hi,

I do have an own written CFF parser with conversion support to Type1. 
Maybe next week I can find some time to provide it in an Jira issue.

Best,
Timo


Am 26.09.2013 12:27, schrieb Andreas Lehmkühler:
> Hi,
>
> sorry for answering that late ....
>
>>   Robert Meyer <tr...@googlemail.com> 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
>


-- 

  Timo Boehme
  OntoChem GmbH
  H.-Damerow-Str. 4
  06120 Halle/Saale
  T: +49 345 4780474
  F: +49 345 4780471
  timo.boehme@ontochem.com

_____________________________________________________________________

  OntoChem GmbH
  Geschäftsführer: Dr. Lutz Weber
  Sitz: Halle / Saale
  Registergericht: Stendal
  Registernummer: HRB 215461
_____________________________________________________________________

Re: Fontbox Type1 support inconsistencies

[Andreas Lehmkühler <an...@lehmi.de>]

Hi,

sorry for answering that late ....

> Robert Meyer <tr...@googlemail.com> 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