Hi, The change is not about trying also the opposite byte order, it is about trying the single byte encoding (first call to GetUnicodeValue) and if it fails, then trying 2-bytes encoding (2nd call to GetUnicodeValue).
This is ok with CMaps because the regions are not allowed to overlap when taken byte per byte (see the doc 5014.CIDFont_Spec.pdf from Adobe, p 49-50) But, I don’t think that this is a valid assumption for other encodings. Best regards, Etienne > On 15 Feb 2017, at 13:03, zyx <z...@litepdf.cz> wrote: > > On Wed, 2017-02-15 at 11:49 +0100, Etienne Robin wrote: >> Here are the revised patches (stiil w.r.t. 0.9.4) > > Hi, > maybe I miss something here, but your changes look pretty close to the > implementation of PdfEncoding::ConvertToUnicode(), thus why to > duplicate the code, instead of fixing the base class of it? > > Also, if I read it correctly, then the main change is to try also the > opposite byte order, if the expected byte order fails. It doesn't sound > like a good idea, the PDF definition is pretty well described, thus > maybe you are just hiding some bigger issue in the code? > > Just a quick opinion on the proposed change, I can be completely wrong. > Bye, > zyx > > -- > http://www.litePDF.cz i...@litepdf.cz > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
