| | <<<Back 1 day (to 2016/12/08) | 20161209 |
| btwe_ | Hey all, quick question re mupdf: Howto reveal content of annotations? | 08:59.54 |
| Robin_Watts | You'll need to be clearer. | 09:02.47 |
| btwe | Robin_Watts: mupdf renders me a yellow post-it on pages which contains \ | 09:19.35 |
| | Robin_Watts: annotation, but I do not know how to I get the content of \ | 09:19.35 |
| | Robin_Watts: these - it is literally the text which I cannot see. | 09:19.35 |
| Robin_Watts | Right, so the yellow post it is the 'appearance stream', so that's what we render. | 09:27.21 |
| | Can you go to bugs.ghostscript.com and open a bug, and attach an example file? | 09:27.39 |
| | Then we can have a look and figure out what we need to do | 09:27.50 |
| btwe | Robin_Watts: How is it supposed to be? Do I have to press a key or click \ | 09:48.58 |
| | Robin_Watts: somewhere to get the annotation text? | 09:48.58 |
| kens | We need to see the file. | 09:50.25 |
| | Most likely the annotation does not have an appearance stream (or the appearance stream does not include the text), in which case it needs to be synthesised from the other contents | 09:51.03 |
| | But we need to see the file to find out , which is why RObin asked you to open a bug report | 09:51.28 |
| btwe | kens: ok, I'll continue there, thanks | 09:53.46 |
| Robin_Watts | tor8: Morning. | 12:01.42 |
| tor8 | Robin_Watts: morning. | 12:01.49 |
| Robin_Watts | Various commits on robin/master | 12:02.26 |
| | Ignore the last 2. | 12:02.34 |
| tor8 | the first 2 LGTM, I think I reviewed those already | 12:02.59 |
| | the "Fix API comment." LGTM as well | 12:03.45 |
| | pdfportfolio.o should be in alphabetic order in the Makefile | 12:04.01 |
| Robin_Watts | fixed. | 12:05.21 |
| tor8 | what do you think about mutool portfolio matching commands with 'ar'? | 12:06.40 |
| | t (list table of entries), x (extract), a (add) | 12:07.06 |
| | or is that going to be confusing, due to us not being able to create new blank pdf documents here? | 12:07.45 |
| Robin_Watts | I am not wedded to the current options. | 12:09.29 |
| | but trying to match ar seems bad. | 12:09.41 |
| | cos we do different things to ar. | 12:09.48 |
| | (in particular, when we embed, we have to give the filename to embed, plus what it should be embedded as) | 12:10.08 |
| tor8 | yeah. 't' for listing matches both ar and tar though. | 12:12.50 |
| | I think the question is, do we want to overwrite the input file when adding portfolios? | 12:13.37 |
| Robin_Watts | tor8: I do not. | 12:13.49 |
| | 't' rather than 'l' seems reasonable. | 12:14.03 |
| tor8 | can we create new empty portfolio wrapper pdf files? | 12:14.14 |
| | i.e. not have an input file to work from | 12:14.23 |
| Robin_Watts | if only cos l looks too much like 'i' or '1'. | 12:14.23 |
| | tor8: No. | 12:14.31 |
| | Not currently anyway. | 12:14.46 |
| | We can add portfolios to a PDF that doesn't have any, but we won't create a blank PDF for them. | 12:15.03 |
| tor8 | and can we embed multiple files in one go? | 12:15.05 |
| Robin_Watts | tor8: Not currently, but I can fix that I think. | 12:16.06 |
| tor8 | I think it should be easy to, if we have no infile, create a blank pdf to work from | 12:16.51 |
| | just call pdf_new_document and insert a blank page with some boilerplate text | 12:17.19 |
| | I'll patch that in if you want | 12:17.26 |
| Robin_Watts | oh, wait... | 12:17.27 |
| | I'd have to change the way 'e' works to enable us to do multiple files. | 12:18.01 |
| tor8 | Robin_Watts: also, not fond of the } for the switch and subcase being on the same level | 12:18.08 |
| | would prefer if you indented the case lines one level more | 12:18.20 |
| Robin_Watts | tor8: Hey, it's you're C-style, not mine! | 12:18.31 |
| | s/you're/your/ | 12:18.38 |
| tor8 | I indent the { when I have blocks after the case | 12:18.52 |
| Robin_Watts | tor8: I'd prefer case to always be indented. | 12:18.58 |
| | tor8: Why don't I let you hack on it for a bit? | 12:19.17 |
| | I'll bash on gs for a bit. | 12:19.53 |
| tor8 | sure. | 12:19.53 |
| | Robin_Watts: two commits on mujs tor/master for review | 12:22.21 |
| Robin_Watts | First one looks fine (indentation warning) | 12:45.49 |
| | second one... why the change to fs_defaultalloc ? | 12:45.58 |
| | seems harmless, but just wondered why you removed it. | 12:48.07 |
| | As much as I understand the rest of it, it looks fine. | 12:48.23 |
| tor8 | Robin_Watts: it's simpler and more obvious (and I finally got round to checking that all the existing realloc implementations to make sure they're sane) | 12:50.04 |
| | Robin_Watts: do you have any pdf portfolio test files? | 12:50.40 |
| Robin_Watts | tor8: Raed send some. | 12:51.33 |
| tor8 | Robin_Watts: found 'em | 12:52.16 |
| Robin_Watts | "PDF Portfolio", 22/11/2016 18:25 | 12:52.16 |
| tor8 | Robin_Watts: okay, so I've spotted a general problem with pdf saving | 13:02.50 |
| | if we save to the same name as an existing file, without the 'incremental' flag, we're going to bomb because we try to read from the same file we're writing to | 13:03.30 |
| Robin_Watts | tor8: Yeah, that's part of the design, though. | 13:05.52 |
| tor8 | really? throwing an exception when saving back a file non-incrementally is intended to crash and corrupt the file? | 13:06.29 |
| Robin_Watts | tor8: "Don't save back to the same file unless it's incremental, or you'll corrupt it", is the design. | 13:07.23 |
| tor8 | I think that's bad design | 13:07.44 |
| Robin_Watts | If you can see a way to spot that and protect against it, great. | 13:08.11 |
| tor8 | I'd open it with O_CREAT|O_EXCL, but with stdio it's not that easy | 13:10.14 |
| Robin_Watts | Do we pass in filenames? Or do we pass in an output stream? | 13:14.05 |
| tor8 | Robin_Watts: adding a remove() call in fz_new_output_with_filename (if not appending) solves the problem on linux | 13:14.26 |
| | on windows you can't remove files while they're open so there we will still have issues | 13:14.44 |
| Robin_Watts | tor8: yeah. | 13:15.19 |
| tor8 | uhm, do we always linearize when saving incrementally? | 13:15.49 |
| Robin_Watts | "Don't save back to the same file unless it's incremental, or you'll corrupt it" seems like the simplest statement. | 13:15.57 |
| tor8 | ah, nvm. uninitialized memory. | 13:16.04 |
| Robin_Watts | fz_throw(ctx, FZ_ERROR_GENERIC, "Can't do incremental writes with linearisation"); :) | 13:16.44 |
| tor8 | oh bollokcs. incremental save on a freshly created document doesn't write a full document. | 13:20.37 |
| | Forward 1 day (to 2016/12/10)>>> | |
Log of #ghostscript at irc.freenode.net.