Not really, the purpose of getting the internal_hex in most tests is to really know the internals of the pdf_text_t, so it should be retrieved as UTF-32HE, not as UTF-8.
On Tue, Dec 23, 2008 at 10:33 PM, <[email protected]> wrote: > > Hi Aleks. > > > I have finished task #79, the tests compile without errors. > > But, I have 40 failing test cases due to calling the text API with > the wrong > > UTF encoding type for each test data. > > > > Aleks could you help me with this ? I attach here the patch from my > branch so > > you can see what test cases are failing. > > > > Most of the changes you did are between the INTERACTIVE_DEBUG > preprocessor conditions, which mean that you want to know the exact data > stored in the pdf_text_t. Before the opaque pointer change, the > internals of the pdf_text_t where accessible directly, but now you need > to use the pdf_text_t API to access the internals. Now, UTF-8 is not the > encoding used internally by the pdf_text_t: use UTF-32HE instead (Host > encoded UTF-32, which means UTF-32LE in LE machines and UTF-32BE in BE > machines, without any extra option (no country/lang or 32-bit NUL suffix). > > Do you agree with Gerel's patch, then? Should we install it? > > > >
