| | <<<Back 1 day (to 2016/11/24) | 20161125 |
| RancheySis | -__- I want to add digital signature to a pdf via function "pdf_sign_signature" and "pdf_create_widget", but I don | 01:44.19 |
| | I don't know what the param "field"means in"pdf_widget *pdf_create_widget(fz_context *ctx, pdf_document *doc, pdf_page *page, int type, char *fieldname)", could any body help me ... | 01:44.57 |
| sebras | Robin_Watts: the random pdf_mark_obj() looks like they shouldn't be part of the portfolio commit..? | 09:18.07 |
| | They do look important though. | 09:18.19 |
| | Robin_Watts: also showobject seems not to be called..? | 09:55.34 |
| Robin_Watts | sebras: Yeah, I need to split them out. | 11:50.29 |
| | showobject (and many other fns) are hangovers from pdfextract.c which is the file I copied :) | 11:54.58 |
| | tor8, sebras: pdf_array_put(ctx, empty_array, 0, val); throws. | 12:24.59 |
| | Is it not reasonable to expect an array put at the end to extend the array? | 12:25.21 |
| tor8 | Robin_Watts: yes. pdf_array_push extends an array at the end. | 12:25.35 |
| Robin_Watts | tor8: But array put does not. | 12:25.59 |
| tor8 | Robin_Watts: I've considered it, I do automatic extension of pdf arrays when putting values one past the end in the JS bindings | 12:26.02 |
| Robin_Watts | tor8: Then it seems to me it would be nicer to make that change in the C level too. | 12:26.31 |
| | Will do so. | 12:26.33 |
| tor8 | I think it may lead to hard to spot bugs when doing automagic things like that though, which is why I haven't made the change to C. | 12:26.57 |
| | and if you do pdf_aray_put(ctx, empty_array, 59005, val) will we create a very long array with nulls? | 12:27.47 |
| Robin_Watts | No, I'm thinking just putting at the end should be defined. | 12:28.09 |
| tor8 | okay. | 12:28.22 |
| Robin_Watts | (though the former behaviour wouldn't be awful) | 12:28.28 |
| | tor8, sebras: Updated pdf portfolio stuff on robin/master. | 14:32.36 |
| | I have successfully listed, extracted and embedded stuff. | 14:32.58 |
| tor8 | "recursive CMAP" should be capitalized CMap | 14:34.32 |
| Robin_Watts | fixed. | 14:38.25 |
| | Hmm. The code fails to add a portfolio entry to a file with no such entries. | 14:38.38 |
| tor8 | Robin_Watts: a commit on tor/master that you can merge into the pdf_array_put commit | 14:39.24 |
| Robin_Watts | Updated code. Now to figure out what I'm doing wrong with a portfolioless file. | 14:47.21 |
| tor8 | Robin_Watts: libmupdf.vcproj adds a text-shaper.h entry | 14:51.42 |
| Robin_Watts | tor8: Bah. Thanks. | 14:52.20 |
| tor8 | the ; at the end of the for is bound to give some compiler warnings down the line | 14:52.33 |
| | in pdf_count_portfolio_schema | 14:52.40 |
| Robin_Watts | It is? | 14:53.24 |
| | I'm adding stuff to a dictionary, but that object isn't been written out in the updated file. | 14:54.07 |
| | I guess that means the 'dirty' flag isn't being set. | 14:54.23 |
| tor8 | are you doing an incremental save? | 14:55.02 |
| Robin_Watts | I am. | 14:55.36 |
| | I probably don't want to be, but I'd have hoped that this would work OK if I did. | 14:56.02 |
| tor8 | should add a -O pdf write options argument, and use pdf_parse_write_options to pass along | 14:56.54 |
| | I think that lets you toggle incremental on or off | 14:57.11 |
| Robin_Watts | tor8: Should all our pdf obj manipulation functions set the dirty flag? | 14:57.33 |
| tor8 | it looks like you're just passing NULL as the options to pdf_save_document; and the defaults don't do incremental saves | 14:58.18 |
| Robin_Watts | D'Oh. I'm being confused by the embedded file being a PDF :) | 14:59.33 |
| sebras | tor8: once upon a time we discussed portfolio pdfs. I think we mentioned being able to extract the embedded file into a memory buffer, forking and loading the new document from that buffer..? | 15:01.18 |
| Robin_Watts | sebras: The API allows us to extract into an fz_buffer. | 15:02.13 |
| | what we then do with that, is up to us :) | 15:02.20 |
| sebras | Robin_Watts: yeah, I know. I'm just trying to revive the discussion we had at the time. | 15:03.58 |
| tor8 | Robin_Watts: architectural question ... do we really need the pdf_portfolio c structs in the xref? would it be possible to read/write the portfolio stuff on the fly from the pdf objects? | 15:11.03 |
| | without chainging the api you have exposed | 15:11.10 |
| Robin_Watts | tor8: The Schema entries are supposed to be sorted in a particular order. | 15:12.03 |
| | accordingly as I read them, I pull them into an ordered linked list. | 15:12.17 |
| | I would rather not have to do that reordering every time we access something in the collection data. | 15:12.47 |
| | hence there needs to be some persistent state. | 15:12.57 |
| | the document seems the most reasonable place to have that. | 15:13.10 |
| | We only load the portfolio data if requested. | 15:13.42 |
| | I could virtualise the 'drop' function so that we don't pull the portfolio code in if not required. | 15:14.10 |
| | i.e. the sole cost in no portfolio using builds would then be a NULL pointer and a NULL function pointer. | 15:14.47 |
| | s/no/non/ | 15:14.55 |
| | theoretically, I think there is supposed to be sorting involved for the portfolio entries themselves, but life is too short. | 15:16.04 |
| | This'll do for a first cut at least. | 15:16.15 |
| | Ok, fixed version up. | 15:27.44 |
| sebras | Robin_Watts: I get undefined reference to `pdfportfolio_main' when building from scratch. | 15:31.40 |
| | Robin_Watts: I think you need ot update the Makefile too. | 15:32.12 |
| Robin_Watts | sebras: Thanks. | 15:33.34 |
| | Try that? | 15:34.18 |
| tor8 | Robin_Watts: okay. I just want to avoid having duplicated stuff as much as possible. | 15:36.12 |
| | it would be neat if someone edits the pdf portfolio objects using the low level functions and that automatically showing up in the high level functions without needing to invalidate some cache or force a reload | 15:36.44 |
| sebras | Robin_Watts: in pdf_add_portfolio_scheme() you have a trailing ; on the first for(). | 15:36.54 |
| | but the if is indented. | 15:36.59 |
| | I assume the ; is incorrect. | 15:37.08 |
| Robin_Watts | sebras: Nice spot, thanks. | 15:38.09 |
| sebras | Robin_Watts: thank gcc. | 15:38.17 |
| Robin_Watts | gcc: Nice spot. | 15:38.32 |
| | Fixed version online. | 15:38.39 |
| sebras | malc_: tgmt. | 15:40.36 |
| | malc_: tgmta. | 15:40.40 |
| malc_ | sebras: pardon ;) | 15:41.08 |
| sebras | malc_: Two Great Minds Think Alike. | 15:41.51 |
| malc_ | ah :) | 15:42.05 |
| | sebras: any progress on "get image dimensions without decoding" front? | 15:43.46 |
| sebras | Robin_Watts: how are the sort field supposed to be used? seems to be relevant for the reordering of the entries by sorting by name/date/whatever. | 15:44.13 |
| | Robin_Watts: but that field seems to be internal to pdf-portfolio.c | 15:44.29 |
| | Robin_Watts: so you are planning for a pdf_portfolio_sort()? | 15:44.40 |
| | malc_: no, none at all. | 15:44.53 |
| Robin_Watts | sebras: pdf_portfolio is a list of schema entries. | 15:45.11 |
| | Each schema entry has a integer value in it used to order the entries. | 15:45.29 |
| | So when I read the entries in, I insertion sort them into an ordered list. | 15:45.46 |
| malc_ | sebras: :( | 15:46.08 |
| Robin_Watts | If the user then adds a new schema entry, I insert it in the given position within my list, and then renumber all the schema entries (and sort values). | 15:46.58 |
| sebras | malc_: I did tell you that it is unlikely I'll make any progress on that until mid december. I was trying to be honest about it. | 15:47.00 |
| | malc_: to make sure that you don't get your hopes up that I'll make this top prio unnecessarily. | 15:47.32 |
| malc_ | sebras: i have extremely poor memory, and was all excited by some of the progress i've made on other fronts | 15:47.47 |
| | sebras: sure | 15:48.03 |
| sebras | Robin_Watts: Oh, we never read the Sort key from the Collection dictionary, I see. | 15:48.35 |
| Robin_Watts | Possibly I could get rid of the 'sort' value in pdf_portfolio, as it's only ever set... | 15:48.36 |
| | sebras: The Sort key from the collection dictionary is for sorting portfolio entries, not portfolio scheme entries. | 15:49.03 |
| sebras | Robin_Watts: you do read it at the end of load_portfolio though. | 15:49.05 |
| Robin_Watts | sebras: Ah, right, so I do. That's the insertion sort. | 15:49.35 |
| | so the code is perfect! :) | 15:49.43 |
| sebras | Robin_Watts: and given that you need to retain the number for a later insertion. | 15:50.07 |
| | insert? | 15:50.11 |
| | hm. | 15:50.13 |
| Robin_Watts | insertion. | 15:51.10 |
| sebras | Robin_Watts: you'll have to walk me through the difference between portfolio entries and portfolio scheme entries. | 15:52.18 |
| Robin_Watts | sebras: schema, not scheme. | 15:52.40 |
| | Think of this stuff as being a table. | 15:52.56 |
| | The Schema = the labels for the top of the columns in the table. | 15:53.07 |
| | "Description" "Size" "Date" etc. | 15:53.18 |
| | The rows in the columns are portfolio entries. | 15:53.33 |
| | So, I have an example file that has some emails in. | 15:53.45 |
| sebras | from raed? I have that here. | 15:53.56 |
| Robin_Watts | The columns are things like "From" "To" "Cc" etc. | 15:54.00 |
| | The rows are then values for those (plus the actual email) | 15:54.30 |
| | The sort values in the Schema entries says what order the put "From" "To" "Cc" etc in. | 15:55.13 |
| sebras | Robin_Watts: ok, so ->sort is for sorting the columns while /Sort is for forting the rows? | 15:55.16 |
| Robin_Watts | The sort values in the portfolio entries are ... exactly. | 15:55.25 |
| sebras | Robin_Watts: ok, I see. | 15:55.37 |
| Robin_Watts | Currently, I'm ignoring the /Sort values. | 15:55.41 |
| | If it ever becomes an issue, we can revisit. | 15:55.52 |
| sebras | Robin_Watts: yes, and despite that it makes sense to sort the collection fields, I get that now. | 15:56.10 |
| | Robin_Watts: I interpreted the ->sort as being sorting for the rows and so was puzzled that the l subcommand didn't allow for the user to specify an alternative sorting order. | 15:56.56 |
| | Robin_Watts: how is the schematype used in pdfportfolio.c? | 16:01.30 |
| | Robin_Watts: seems to be unused, did you have a plan to use it? | 16:01.54 |
| Robin_Watts | pdf_portfolio_schema_type ? | 16:02.24 |
| | That's definitely used. | 16:02.46 |
| sebras | pdfportfolio_main() line 127 | 16:02.51 |
| Robin_Watts | oh, I forgot to print it out :) | 16:03.28 |
| sebras | the char *type | 16:03.28 |
| | Robin_Watts: you might want to print editable/visible as well? | 16:04.23 |
| | I guess this is all mostly for debugpurposeses. a viewer handling portfolios properly needs to use this API and do something more intelligently. | 16:05.30 |
| Robin_Watts | sebras: yes. | 16:05.49 |
| sebras | Robin_Watts: which is when /Sort and /View come into play. | 16:06.29 |
| Robin_Watts | sebras: Not necessarily. | 16:06.41 |
| | It's perfectly possible to produce a 'reasonable' UI with what we have here. | 16:06.58 |
| sebras | Robin_Watts: absolutely. | 16:07.07 |
| Robin_Watts | If people ever seriously complain about wanting to get the entries out in sorted order, then we can do that too under this same API. | 16:07.41 |
| | (I believe) | 16:07.44 |
| | it just requires us to sort the entries before returning them, rather than returning them in nametree order as we do now. | 16:08.10 |
| sebras | Robin_Watts: indeed. | 16:09.01 |
| | Robin_Watts: but the /View key would need to be exposed home how | 16:09.17 |
| | but not at this time, on. | 16:09.26 |
| | no | 16:09.28 |
| | Robin_Watts: I tested this with pdfimpl81.pdf as released by adobe and it appears to work well. | 16:09.55 |
| Robin_Watts | tor8: Are you going to do a 1.10.1 ? | 16:13.28 |
| | We really need to get that done before the meeting, or Miles will be mad. | 16:13.39 |
| Robin_Watts | updates the comments in document.h for this commit. | 16:14.21 |
| tor8 | Robin_Watts: yeah. so, just pull the alphabetic fix to a branch and rebuild? | 16:18.29 |
| Robin_Watts | tor8: I think so. Nothing else we have comes anywhere close to being as important as that. | 16:18.48 |
| tor8 | 1.10a to match the naming we did for 1.9 | 16:18.55 |
| Robin_Watts | tor8: )K. | 16:19.08 |
| | OK. | 16:19.10 |
| sebras | Robin_Watts: if I embed a file into an existing pdf and provide a non-ascii name argument to mutool portfolio it is incorrectly encoded in /F, /UF and /Desc. not sure we care, but we ought to omit it knowingly. | 16:20.44 |
| | Robin_Watts: tor8 you guys discussed an ascii-fix the other day. should it go in too? | 16:21.08 |
| | is that a2afcdf0f2b6cb0a342c38933d347169c0c7b6e4? | 16:21.25 |
| tor8 | Robin_Watts: tor/1.10-release branch | 16:21.38 |
| Robin_Watts | sebras: That's the "alphabetic fix" that tor was referring to above I think. | 16:22.11 |
| sebras | Robin_Watts: I thought tor8 was referring to 91344b2..? | 16:22.56 |
| Robin_Watts | sebras: That is a fix for CMaps that weren't in 1.10 | 16:23.55 |
| sebras | right, in that case, remind me: what is alphabatic about that fix? | 16:24.16 |
| Robin_Watts | 'ascii' rather than 'alphabetic' I believe. | 16:24.37 |
| sebras | then it makes more sense. | 16:24.59 |
| Robin_Watts | Certainly the release branch lgtm. | 16:25.01 |
| sebras | Robin_Watts: not to me, tor needs to update the platform/ios/Info.plist and platform/android/viewer/res/values/strings.xml too | 16:26.15 |
| Robin_Watts | sebras: oh, you are right. | 16:26.57 |
| | sebras: Yeah, I was hoping I could get away with null terminated strings of bytes for now. | 16:27.21 |
| sebras | Robin_Watts: maybe we could error out on non-ascii-strings? | 16:27.40 |
| | Robin_Watts: that way we don't create bogus pdfs at least. | 16:27.57 |
| Robin_Watts | As long as you only pass pdfdocenc strings we should be OK, right? | 16:27.58 |
| | unicode strings would be a problem. | 16:28.18 |
| | You want to throw on bytes >= x80 ? | 16:28.32 |
| | You want to throw on bytes >= 0x80 ? | 16:28.36 |
| sebras | Robin_Watts: actually PDFDocEncoding is the only encoding that would work for all of /F, /UF and /Desc | 16:31.44 |
| Robin_Watts | sebras: I don't care so much about pdfportfolio not being perfect, as long as the API is capable of being driven correctly. | 16:37.19 |
| | The API is not right in that F and UF are being set to be the same. | 16:37.49 |
| sebras | Robin_Watts: agreed. | 16:48.45 |
| | Robin_Watts: I think what you have now is likely enough to supply a testbuild and see if it fulfills the requirements. | 16:49.41 |
| Robin_Watts | sebras: I have a fix. I'll put it online in a mo. | 16:50.00 |
| | sebras: So you must be nearly finished at school now? | 16:50.17 |
| | or finished maybe? | 16:50.23 |
| sebras | Robin_Watts: finished yesterday. | 16:53.34 |
| | Robin_Watts: I'll be on a plane the day after tomorrow. | 16:53.43 |
| Robin_Watts | sunday, right. | 16:54.07 |
| sebras | Robin_Watts: btw, pdf_name_tree_insert() wants pdf_dict_put_DROP() if !data.found | 16:54.07 |
| Robin_Watts | So are you all packed? | 16:54.18 |
| sebras | Robin_Watts: not even started. :( | 16:54.26 |
| Robin_Watts | How was your final result? | 16:54.56 |
| sebras | Robin_Watts: I have received chapter testresults ever week in the range 80-90 but the very last one was 77, these together with the teach evaluation of two presentations make up the final grade. but then there is a semester exam which is used to determine if I can progress to the next level, which I failed by 4.5p out of a hundred (55.5 vs 60p to pass). | 16:56.46 |
| Robin_Watts | ouch. | 16:57.20 |
| sebras | Robin_Watts: however I will have to do an interview in feb/mar to reassess my level so that exam result doesn't matter as much. | 16:57.21 |
| Robin_Watts | sebras: in person interview, or skype interview ? | 16:57.36 |
| sebras | in person interview. | 16:57.42 |
| Robin_Watts | So you'll have to fly back for that? | 16:57.49 |
| sebras | Robin_Watts: yeah, but they do it about a week before the semester starts. | 16:58.11 |
| Robin_Watts | so you plan to go back, do the interview, then stay on for another semester ? | 16:58.47 |
| sebras | Robin_Watts: should pdf_name_tree_insert() take ownership of key? | 16:58.50 |
| | Robin_Watts: I do. quite possibly two. | 16:59.07 |
| | Robin_Watts: I'm seeing memory leaks. | 16:59.52 |
| | Robin_Watts: also fz_buffer in pdfportfolio.c is leaked after fz_read_file(). pdf_add_portfolio_entry() does not (and should not) take ownership of buf, so it must be dropped. | 17:01.17 |
| Robin_Watts | Yeah, that one is a no brainer. | 17:01.58 |
| | pdf_name_tree_insert is currently a static function, but I think it could become a general utility function eventually. | 17:02.30 |
| | well, pdf_name_tree_map, at least. | 17:03.00 |
| sebras | Robin_Watts: actually pdf_name_tree_insert() ought to decide whether to take ownership of _both_ key and val or whether pdf_add_portfolio_entry() should free them in a fz_always(). | 17:05.52 |
| Robin_Watts | in the always. | 17:06.10 |
| | Just preparing a fixed version now. | 17:06.15 |
| sebras | I should be packing and sleeping so this will be the last thing I do today. | 17:06.44 |
| Robin_Watts | Latest version pushed. | 17:07.22 |
| | I still have some comments to fix, but I think I've addressed your remarks. | 17:07.37 |
| | I will check for leaks in a mo. | 17:07.43 |
| sebras | Robin_Watts: you can remove the dorgb global from tools/pdfportfolio.c, as well int list from pdfportfolio_main() and the fprintf() for the 'x' flag is missing an argument | 17:09.47 |
| | noticed the gcc warning just now, sorry I didn't see it earlier. | 17:10.04 |
| | also I'm seeing one more memory leak in valgrind when I'm listing the entries in pdfimpl81.pdf | 17:12.21 |
| | (on casper unless you have it already) | 17:12.46 |
| Robin_Watts | All of those except the memory leak fixed. | 17:13.23 |
| sebras | the memory leak is in load_portfolio() when calling pdf_dict_get(), which is puzzling me. | 17:13.49 |
| | seems to me like those ought to be inserted into the xref and then freed on exit? | 17:14.24 |
| Robin_Watts | sebras: Have you seen http://www.drmemory.org/ ? | 17:16.28 |
| | Not tried it yet, but sounds interesting. | 17:16.37 |
| sebras | Robin_Watts: interesting! | 17:17.14 |
| Robin_Watts | I see leaks too. | 17:18.08 |
| sebras | Robin_Watts: you do call pdf_drop_document() though so pdf_drop_portfolio() ought to be called... | 17:21.27 |
| Robin_Watts | The strings I see leaked are "Name" "Description" "Index" | 17:22.55 |
| sebras | Robin_Watts: how do you determine that? | 17:23.18 |
| Robin_Watts | I run a memento build, breakset Memento_breakpoint, and that gets called at the end of the program. | 17:23.56 |
| | I then look at the addresses given in the debugger. | 17:24.12 |
| sebras | I need to try that. | 17:24.40 |
| Robin_Watts | or in gdb: call pdf_print_obj(ctx, fz_stderr(ctx), (pdf_obj *)address, 1); | 17:24.48 |
| | The strings I get leaked are the Schema names. | 17:25.14 |
| sebras | Robin_Watts: right. | 17:25.22 |
| | Robin_Watts: because you do pdf_keep_obj() in load | 17:26.05 |
| | portfolio() | 17:26.09 |
| Robin_Watts | and I forgot to drop them. | 17:26.16 |
| sebras | but no corresponding drop in pdf_drop_portfolio(). yes. | 17:26.22 |
| Robin_Watts | Fixed version online. | 17:26.50 |
| | and listing, embedding and extracting all run with no leaks now (in my very quick test) | 17:29.41 |
| | Go pack/sleep. | 17:29.50 |
| sebras | Robin_Watts: this is what I tested too. | 17:29.53 |
| Robin_Watts | Thanks for your help. | 17:30.07 |
| sebras | Robin_Watts: throwing in pdfportfolio_main | 17:30.51 |
| | () doesn't help without a try doing the cleanup. | 17:31.03 |
| | (e.g. if portfolio.pdf doesn't exist) | 17:31.14 |
| | actually the same goes if we end up in usage(). | 17:32.04 |
| Robin_Watts | If we die with usage I don't bother to cleanup. | 17:33.31 |
| | But the new version has a try/catch in there. | 17:33.44 |
| sebras | that's ok with me, I just want to mention it. | 17:33.44 |
| | Robin_Watts: hew new version does have a try/catch. | 17:35.03 |
| | Robin_Watts: should pdf_rename_portfolio_schema() keep s when assigning entry.name? | 17:38.45 |
| | Robin_Watts: if not I'm thinking that pdf_dict_put_drop() will free it. | 17:39.13 |
| Robin_Watts | Yes, and we should also drop the old version there. | 17:39.35 |
| | Fixed version online. | 17:40.22 |
| | I'm very grateful for you looking at this stuff, but if you need to pack/sleep it can wait now. | 17:40.52 |
| sebras | Robin_Watts: also there is no way to run reorder/rename/delete on the entries. not sure we care. | 17:41.01 |
| | Robin_Watts: yeah, I know. I'll look at the comments and then leave. | 17:41.17 |
| Robin_Watts | sebras: Renaming involves moving them in the nametree. | 17:41.21 |
| sebras | Robin_Watts: I know, and I cannot fault the code, but maybe valgrind can. | 17:41.38 |
| Robin_Watts | I probably ought to have a delete though. | 17:41.40 |
| | but that can wait for now. | 17:41.54 |
| | This should be enough to satisfy the customers requirements. | 17:42.20 |
| sebras | Robin_Watts: yes, and the comments look reasonable. | 17:44.05 |
| | I'm done for tonight. :) | 17:44.09 |
| | well, until the meeting. | 17:44.22 |
| Robin_Watts | sebras: See you there! | 17:44.31 |
| sebras | Robin_Watts: hopefully in a semi-awake state. | 17:44.49 |
| Robin_Watts | You arrive on tuesday, right? | 17:44.49 |
| | Who are you flying with ? | 17:44.55 |
| sebras | Robin_Watts: I honestly have no idea right now. :) tor8 | 17:45.01 |
| sebras | sleeps. | 17:45.21 |
| Robin_Watts | If it's a BA flight, then you might be on a plane with quite a lot of us :) | 17:45.22 |
| | Night. | 17:45.24 |
| aeht | Hi | 21:39.45 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 21:39.45 |
| aeht | Im having issue compiling the MuPDF source code for Android NDK. it seems that 32bit ABI will work without issues but if any 64 bit is added it will throw file not found error with incbin command for font files starting with CharisSIL-B.cff | 21:40.18 |
| | is there any specific reason as to why 64 bit is throwing this issue? such as x86_64, arm64-v8a, mips64 | 21:41.27 |
| | nvm, i figured out by using 4.9 toolchain via NDK_TOOLCHAIN_VERSION=4.9 it fixes the issue | 22:24.16 |
| | Forward 1 day (to 2016/11/26)>>> | |
Log of #ghostscript at irc.freenode.net.