| | <<<Back 1 day (to 2018/07/17) | 20180718 |
| tor8 | fredross-perry (for the logs): Your fix is good (but incomplete, there are as you said a few other spots that should also change) | 14:08.28 |
| | This is the place where it should be dealt with--pdf_dict_get_text_string is the correct function to use when accessing a pdf_obj that should be a human readable string | 14:08.58 |
| | pdf_dict_get_string is only suitable when using the string as raw binary data | 14:09.19 |
| | in the pdf reference, in the tables listing the dictionary entries, if the "TYPE" column says "text string" then the value should be read with get_text_string | 14:10.16 |
| | for example table 8.69 "Entries common to all field dictionaries" lists the "T" entry as type "text string" | 14:12.25 |
| | I've pushed some revised commits to tor/master -- hopefully that should finally solve the objcopy/hexdump build issues | 14:12.57 |
| | Now the build system needs to define HAVE_OBJCOPY if building with objcopy; otherwise it'll use the bin2coff/hexdump layout. | 14:13.33 |
| fredross-perry | tor8 - I've rebased with your latest and all is well. It looks like HAVE_OBJCOPY does not apply to ndk-build, yes? So for Android, nothing to change regarding the build system that I see. | 17:47.30 |
| tor8 | fredross-perry: corect. | 18:47.20 |
| | correct. | 18:47.23 |
| fredross-perry | oj | 18:47.33 |
| | Forward 1 day (to 2018/07/19)>>> | |
Log of #mupdf at irc.freenode.net.