----- 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 ----
