Log of #mupdf at irc.freenode.net.

 <<<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 output13:00.53 
  it only invokes printf for multiple file output13:01.02 
  SVG is *always* multiple file output13:01.11 
  whether the %d is present or not13:01.20 
  the code should just be rejigged to use the fz_format_output_path thingy13: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 tools14:12.15 
  a GUI tool should just populate the options struct directly14:12.31 
  like in mupdf-gl14:12.38 
Robin_Watts ator, sebras: ping18: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)>>> 
ghostscript.com #ghostscript