| | <<<Back 1 day (to 2018/01/03) | 20180104 |
| deekej | hello chrisl, have you had any chance to look at the patches I've uploaded to BZ? :) | 11:41.31 |
| Robin_Watts | deekej: chrisl only got back from holiday today, and he's out for a few hours. Give him a mo :) | 12:25.13 |
| deekej | Robin_Watts: ah, I forgot he was on vacation... :-/ sorry :) | 12:46.09 |
| Robin_Watts | deekej: No worries :) | 12:46.32 |
| chrisl | deekej: I'll try to make a start on them tomorrow - I've got other stuff to catch up with today! | 15:22.27 |
| deekej | chrisl: no problem, I completely understand :) I'm also catching up after holidays... ;) | 15:23.22 |
| chrisl | deekej: TBH, there's not a massive amount to catch up with, but I also need to remember how to work, after two a half weeks of lazing around | 15:25.02 |
| albel727 | I'm curious, if there is anything special about gsapi_run_file(), that couldn't be reproduced by simply run_string_begin/continue/end()-ing file contents? Like speed of processing? Utilization of seekability? | 23:38.44 |
| | I also wonder if it's somehow possible to parse pdfs through run_string() interface, in a way that wouldn't involve having the pdfs as actual files. | 23:42.01 |
| | I assume not, b/c from irc logs seem to mention that pdfs require seeking. | 23:44.52 |
| | I guess it's unfortunate then, that ghostscript doesn't provide interface for seekable file emulation. something like gsapi_run_seekable_file(read_callback cb, void* user_data), where read_callback is something like int (*read_callback)(void* buffer, int offset, void* user_data) | 23:49.46 |
| | though it doesn't seem like gsapi_run_file() supports pdfs either, only postscript. probably running some ps code to prepare to interpret pdfs is necessary first. | 23:54.32 |
| | Forward 1 day (to 2018/01/05)>>> | |
Log of #ghostscript at irc.freenode.net.