| | <<<Back 1 day (to 2016/11/10) | 20161111 |
| ray_laptop | fredross-perry: Optional Content Groups (OCG) has been around a LONG time since 1.5 | 05:12.23 |
| | Section 4.10 of the PDF 1.7 spec. Ghostscript has had (some) support for it since 2009 | 05:14.54 |
| Robin_Watts | tor8: ping? | 11:25.28 |
| tor8 | Robin_Watts: morning | 11:29.27 |
| Robin_Watts | morning. | 11:31.35 |
| | So various commits on robin/master. | 11:31.40 |
| | The one remaining thing on the list is the ability to extract a PDF file with specific layers in it. | 11:32.15 |
| tor8 | the -l option commit LGTM | 11:32.21 |
| Robin_Watts | Which I'm thinking we can do using a modified muclean if I tweak the sanitise stuff. | 11:32.43 |
| tor8 | Robin_Watts: you mean to flatten the layers into the content stream and drop all the OCG and OCGD stuff? | 11:33.29 |
| | should be simple enough if we add a flag to pdf-op-buffer to drop BMC/BDC/EMC operators | 11:35.23 |
| | the 'hidden' stuff in pdf-interpret already drops the stuff inside the hidden OCG's BDC/EMC brackets | 11:36.22 |
| | though looking at the pdf_process_BDC code, maybe the pdf_is_hidden_ocg should move up to before we call the op_BDC | 11:36.47 |
| | so we drop the whole thing | 11:36.50 |
| Robin_Watts | tor8: No, I was thinking of a mechanism for saying "take this PDF file, and give me another one that just contains the selected layers". | 11:36.54 |
| | BUT... actually it might be better to just leave the layer information in there and change the defaults. | 11:37.17 |
| | So maybe what's needed is a mechanism to say "Update the configuration in the file to match the current config" | 11:37.53 |
| tor8 | "OCCD groups" in the commit message | 11:38.26 |
| Robin_Watts | OCCD is correct. | 11:39.19 |
| | OCCDs ? | 11:39.29 |
| | Optional Content Configuration Dictionaries | 11:39.48 |
| tor8 | oh! you're right. | 11:40.32 |
| | I thought I saw OCGD somewhere in the spec | 11:40.40 |
| | but now I can't find either abbreviation :) | 11:40.48 |
| | OCCDs or spelled out so you can search for it, they're not OCCD groups anyway | 11:41.45 |
| | or "/OCProperties/Configs" to say where in the PDF file they're from | 11:42.27 |
| | PDF_LABEL_TEXT maybe PDF_OCG_UI_LABEL and PDF_OCG_UI_CHECKBOX etc to keep the enum namespace clear? | 11:43.14 |
| | or PDF_LAYER_UI_LABEL, etc | 11:43.40 |
| | Robin_Watts: how do you feel about putting all the OCG and layer stuff in a separate file pdf-ocg.c? | 11:44.52 |
| Robin_Watts | I started out with them in pdf-layer.c | 11:45.35 |
| | but they got pulled back into pdf-xref.c because I didn't want to have the structure definitions in the public API. | 11:45.58 |
| tor8 | pdf-xref.c is already bulging at the seams of being too large | 11:46.10 |
| Robin_Watts | I could do it if we had a pdf-xref-internal.h or something | 11:46.18 |
| tor8 | pdf-layer-imp.h? | 11:46.21 |
| Robin_Watts | yeah. | 11:46.26 |
| tor8 | I think that'd be preferable | 11:46.33 |
| Robin_Watts | Ok. | 11:46.38 |
| tor8 | although we do have a lot of semi-private stuff in the public headers | 11:46.51 |
| | the only 'private' headers we have in source/pdf at the moment are all just autogenerated data tables | 11:48.31 |
| Robin_Watts | tor8: I think moving as much stuff out of the public headers as possible would be good. | 11:48.52 |
| tor8 | so doing adding -imp.h now does mean we'll need to start looking in two places | 11:49.01 |
| | but we've got to start somewhere | 11:49.09 |
| Robin_Watts | tor8: I always find header definitions by either search or by right-click "go to declaration" | 11:49.36 |
| | so another place won't bother me. | 11:49.45 |
| tor8 | and I use ctags and vim ^] so won't really bother me either | 11:53.28 |
| | nor do large files that much anymore | 11:53.33 |
| | but for someone new to the project, knowing where to add stuff is more difficult | 11:53.48 |
| Robin_Watts | tor8: I don't think it's a hard choice to recognise the difference between public and private APIs. Certainly it's a worthwhile choice to have to make. | 11:59.52 |
| | tor8: Yeah. I am tempted to fix the enum names, get this commit in as is, and then do a 'public->private' pass where I separate stuff. | 12:08.58 |
| | Updated commits online. | 12:11.18 |
| | Ok, so I did the split - turned out easier than I thought. Updated commits online. Clustering now. | 12:45.46 |
| | tor8: And 1 more commit on robin/master | 16:18.04 |
| tor8 | Robin_Watts: oh, nice. fz_buffer_as_string (though maybe I'd have called it fz_string_from_buffer?) | 16:21.45 |
| Robin_Watts | tor8: If the latter is more in keeping I can change it. | 16:22.02 |
| tor8 | I like the name you picked too | 16:22.38 |
| | but I think the latter is more in keeping | 16:22.53 |
| Robin_Watts | I think you're right. Will fix. | 16:23.04 |
| tor8 | glfwSetClipboardString could use fz_string_from_buffer as well, it also doen the write_buffer_byte 0 thing | 16:23.26 |
| Robin_Watts | tor8: is that function name right? | 16:24.26 |
| tor8 | Robin_Watts: which one? | 16:24.49 |
| Robin_Watts | Ah. You mean do_copy_region | 16:24.57 |
| tor8 | yeah | 16:25.14 |
| | the fz_parse_xml in epub-doc could also use string_from_buffer | 16:25.38 |
| | epub_parse_ncx, epub_parse_header, and fz_parse_html | 16:26.10 |
| Robin_Watts | fz_parse_xml takes a length. | 16:26.17 |
| tor8 | ah, yes | 16:26.36 |
| | that's in case it runs into UTF-16 | 16:26.42 |
| Robin_Watts | I'd have to write an fz_utf8_from_buffer or something to cope with that. | 16:27.32 |
| tor8 | that might not be so bad, actually | 16:27.47 |
| cheng | hello,thanks for your mupdf,and the 1.10rc support epub's link | 16:28.01 |
| tor8 | *but* it does mean messing with ownership | 16:28.02 |
| cheng | but some link can not indifty | 16:28.16 |
| tor8 | so leave it out of this commit | 16:28.17 |
| cheng | <a href="The_Martian__A_Novel_split_022.html#filepos68689"><span class="calibre8">Chapter 4</span></a></p> | 16:28.54 |
| Robin_Watts | cheng: We'd need a copy of a file that shows the problem. | 16:29.58 |
| cheng | ok,i will share a onedrive link,is that ok? | 16:30.55 |
| Robin_Watts | cheng: Can you open a bug on bugs.ghostscript.com? | 16:31.33 |
| | Attach the file there. Describe exactly what the problem is. | 16:31.52 |
| cheng | ok.thanks for your reply.i will post the bug now | 16:32.15 |
| Robin_Watts | The clearer the explanation, the easier we can reproduce it, and the more likely it is to get fixed. | 16:32.26 |
| | Thanks. | 16:32.28 |
| cheng | hi,the bug url is http://bugs.ghostscript.com/show_bug.cgi?id=697335 | 16:40.18 |
| Robin_Watts | Thanks. | 16:40.38 |
| cheng | Also,will mupdf will support the table in epub file | 16:41.15 |
| | Some books contians a lot of tables | 16:41.42 |
| | and i found the bug like http://bugs.ghostscript.com/show_bug.cgi?id=696319 | 16:44.21 |
| Robin_Watts | yeah, tables are on the list to look at in future. | 16:57.46 |
| | tor8: Updated commit, plus 1 more commit. | 19:14.28 |
| ubl0 | Hello! I'm wondering which capabilities have embeded js code. I'm a bit worried about security | 21:49.08 |
| | I'm just reading the mujs source and pdf-form.c, but is the first time I mess with mupdf source | 21:51.00 |
| w1nky | hey guys, are some mupdf dev's on? | 23:30.34 |
| Robin_Watts | yes. | 23:53.38 |
| w1nky | i made a cheatsheet for 1.9a and want to share it | 23:54.20 |
| | http://f.qigh.de/f.php?h=1fPIjTuP&d=1 | 23:54.34 |
| | i'm open for your feedback | 23:54.54 |
| Robin_Watts | Cool. That's for the linux/windows non-gl desktop viewer | 23:56.21 |
| w1nky | yup | 23:56.33 |
| Robin_Watts | The release candidate for 1.10 is up online. | 23:59.53 |
| | Forward 1 day (to 2016/11/12)>>> | |
Log of #ghostscript at irc.freenode.net.