| | <<<Back 1 day (to 2019/06/12) | Fwd 1 day (to 2019/06/14)>>> | 20190613 |
| sebras | ator: re: 701185 I only tested %n and ended up in fz_new_output_with_path() which did no formatting. | 12:54.53 |
| | ator: so it is only SVG and other formats that have a new output file per page that has this issue? | 12:56.32 |
| ator | sebras: the mudraw code checks for %d before deciding whether to do single or multiple file output | 13:00.53 |
| | it only invokes printf for multiple file output | 13:01.02 |
| | SVG is *always* multiple file output | 13:01.11 |
| | whether the %d is present or not | 13:01.20 |
| | the code should just be rejigged to use the fz_format_output_path thingy | 13:01.28 |
| sebras | ator: I'll look into it. | 13:02.50 |
| | ator: do we advice for or against populating a pdf_write_options manually? | 13:11.00 |
| | consider that the options string prevents the owner/user passwords from containing certain characters. | 13:11.21 |
| ator | sebras: define "manually" | 13:14.34 |
| sebras | ator: consider if I want the userpassword "hello,world" | 13:25.40 |
| | ator: that would be hard to do by calling pdf_parse_write_options(). | 13:26.03 |
| | ator: hard to accomplish. | 13:26.15 |
| | I don't think there would be issues with any other character. | 13:28.11 |
| | ator: in those cases perhaps it is best to allocate pdf_write_options and populate all its fields by simple assignment, instead of calling pdf_parse_write_options()? | 13:32.18 |
| ator | sebras: yes. parse_write_options is more for command line tools | 14:12.15 |
| | a GUI tool should just populate the options struct directly | 14:12.31 |
| | like in mupdf-gl | 14:12.38 |
| Robin_Watts | ator, sebras: ping | 18:09.38 |
| | actually let's do this on #artifex. | 18:09.58 |
| | <<<Back 1 day (to 2019/06/12) | Forward 1 day (to 2019/06/14)>>> | |
Log of #mupdf at irc.freenode.net.