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
