Hi,
that´s my approach - could be written a little shorter.
byte b1 = input.readByte();
byte b2 = input.readByte();
byte b3 = input.readByte();
byte b4 = input.readByte();
int retval = 0;
if ((b1 & (1<<3)) == 0) {
retval = (0xFF & b1) << 16;
retval |= (0xFF & b2) << 8;
retval |= (0xFF & b4);
} else {
retval = (0xFF) << 24;
retval |= (0xFF & b1) << 16;
retval |= (0xFF & b2) << 8;
retval |= (0xFF & b4);
}
return Integer.valueOf((short) retval);
Maruan Sahyoun
Am 19.03.2010 um 12:23 schrieb Andreas Lehmkühler:
>
> ----- original Nachricht --------
>
> Betreff: Re: PDFBox 1.1.0 release plan (Was: Next release & merging of
> trunks)
> Gesendet: Fr, 19. Mrz 2010
> Von: Maruan Sahyoun<[email protected]>
>
>> Hi,
>>
>> I'm inline with your thoughts that the patch works but is not completely
>> inline with the spec. Would you mind showing your code so we can take a look
>> as I was about starting to come up with something too?
> No problem, but it has to wait until I'm back at home later in the evening.
>
> BR
> Andreas Lehmkühler
>> Kind regards
>>
>> Maruan Sahyoun
>>
>>
>> Am 19.03.2010 um 10:54 schrieb Andreas Lehmkühler:
>>
>>> Hi,
>>>
>>> Betreff: Re: PDFBox 1.1.0 release plan (Was: Next release & merging of
>> trunks)
>>> Gesendet: Do, 18. Mrz 2010
>>> Von: Villu Ruusmann<[email protected]>
>>>> Hello there,
>>>>
>>>>>
>>>>> The following two open issues are currently targeted for 1.1.0:
>>>>>
>>>>> [PDFBOX-624] Misplaced text
>>>>> [PDFBOX-663] Ensuring non-null FontDescriptor for external TrueType
>>>> fonts
>>>>>
>>>>> Both are unassigned. Can we postpone these to later releases?
>>>>>
>>>>
>>>> Both are "mine". They are solved (ie. the patchfiles are available)
>>>> and are waiting for approval by other project members.
>>>>
>>>> Andreas has looked at PDFBOX-624 lately. The patch looked somewhat
>>>> suspicious to him, because it employs simple Java casting instead of
>>>> more complex bit manipulation. Any more experts here?
>>> I puzzled about the specification:
>>>
>>> The chapter 3.2 "Charstring Number Encoding" contains the following
>> statement:
>>> "If the charstring byte contains the value 255, the next four bytes
>>> indicate a two's complement signed number. The first of these
>>> four bytes contains the highest order bits, the second byte
>>> contains the next higher order bits and the fourth byte contains
>>> the lowest order bits. This number is interpreted as a Fixed; that
>>> is, a signed number with 16 bits of fraction."
>>>
>>> AFAIU the spec, we have to use a combination of byte 1, 2 and 4. As it is
>>> a two's complement, we have to build the one complement. And after that
>>> we have to cut that result to a 16bit value. I've tried to implement some
>> code
>>> to follow that path, but it didn't work yet. Probably I'm just wrong with
>> my
>>> interpretation of the spec.
>>>
>>> Villus implementation only uses byte 1 and 2. Looking at the spec it
>> seems
>>> to be insufficient, but it works. So, at least it is a workaround.
>>>
>>> Finally I don't want to object to villus patch. I will keep that issue in
>> mind
>>> and try to figure out if something is left to do or not.
>>>
>>> BR
>>> Andreas Lehmkühler
>>
>>
>
> --- original Nachricht Ende ----
>
