| | <<<Back 1 day (to 2018/07/16) | 20180717 |
| tor8 | fredross-perry: yeah, the end-size thing is what 'objcopy' and 'ld -r binary' does | 10:02.44 |
| | I tried to make the hexdump tool create something equivalent, but it seems that the android tools do something weird with the object file layout | 10:03.16 |
| paulgardiner | I've found another area of mupdf usage that I'm clear about. It's to do with continuing editing after saving changes so far. Are we handling this correctly in the apps? What if we access objects not previously accessed? Will they be read from the old version of the file? What version will a subsequent save be based on? | 11:04.46 |
| tor8 | paulgardiner: saving is a somewhat problematic issue, depending on the flags set when saving. | 11:07.08 |
| | objects can get renumbered, etc. | 11:07.16 |
| | I've found I often have to reload the document after saving. | 11:07.27 |
| | I think we should maybe take a lot of the save options out of the 'pdf_save_document' function and add them as generic transform functions instead (the garbage collection, deduping, compacting) | 11:08.22 |
| | or work on a temp copy of the document for saving, and not mutate the in-memory open document | 11:08.46 |
| paulgardiner | Yeah, reopening may be my best option for now. | 11:25.39 |
| | tor8: after an incremental update, I was wondering about just replacing the input stream | 11:26.36 |
| tor8 | all the open pages and annots and pdf_obj indirect references can be bust | 11:28.09 |
| | since objects are moved around, etc | 11:28.14 |
| | if you set certain pdf_write_options | 11:28.30 |
| paulgardiner | Oh okay. I was thinking that incremental saving was less invasive | 11:29.53 |
| tor8 | well, it all depends on what options you set. | 11:30.34 |
| | incremental saving blows up if you set the wrong options. | 11:30.41 |
| | it's all very fragile | 11:30.44 |
| | so I'd ideally like to revise it, and make the steps that change the document structure (such as compacting or garbage collecting, or picking a subset of pages, or sanitizing) a separate thing | 11:31.35 |
| | and saving would just be saving, as is, either fully or incrementally. all the other processing would be separate steps. | 11:32.18 |
| paulgardiner | That makes a lot of sense. | 11:32.29 |
| tor8 | and doing some of those steps, would flag it as 'can't save incrementally' | 11:32.56 |
| paulgardiner | pdfapp_save is confusing me now. It reopens after saving, but seemingly only if saving to a tmp file with the intention of overwriting the original. It looks like it doesn't reopen if you save to a new location. | 11:44.35 |
| tor8 | paulgardiner: could that be a workaround for windows not allowing you to open a file for writing if it's already open fro reading? | 11:45.32 |
| inflex | tor8, sorry for a possibly daft/silly question, I need to generate a footer/status bar in the pdfviewer, the default ui font size is set, but can I use a smaller size on demand or do I have to generate an extra font table / set ? | 11:50.06 |
| | ie, I'm thinking I'll need something like: g_font_sml = fz_new_font_from_memory(ctx, NULL, data, size *0.75, 0, 0); ? | 11:51.44 |
| paulgardiner | tor8: ah, it's because you cannot move the tmp file to the original location while either are open, so sort of yes. | 11:52.45 |
| | I'm wondering if I should change this to always reopen. | 11:53.06 |
| tor8 | inflex: the font rendering and caching can easily handle multiple fonts; I just saw no need for it so the ui_draw_string etc only have the one hardcoded font | 11:53.16 |
| | paulgardiner: you should reopen at a higher level, since you can have stale pdf_objs hanging around | 11:54.01 |
| paulgardiner | Higher than pdfapp_save? | 11:54.57 |
| inflex | tor8, thanks - all good. | 11:55.16 |
| paulgardiner | I would have hoped that would be harmless there given in some cases we do it already. | 11:55.23 |
| tor8 | inflex: you should be able to change g_font_size for one string and reset it afterwards and it *should* work properly | 11:56.06 |
| | but no promises :) | 11:56.09 |
| | paulgardiner: right, I was thinking you nee to do it in muso too | 11:56.57 |
| inflex | tor8, I'll be calling for a refund of my $0.00 investment if it doesn't ;) | 11:57.51 |
| paulgardiner | tor8: yes, was planning to change muso too, once I get multiple signatures working correctly in pdfapp | 11:57.52 |
| tor8 | paulgardiner: right, never mind then :) | 11:59.13 |
| inflex | tor8, side question - I've noticed you've used static declarations for most of the globals, is that out of habit/pedantic or a specific reason pertaining to the nature of the code? | 12:04.21 |
| | ( not questioning your choice, just curious as to the methodology ) | 12:04.41 |
| | btw, you're right, changing g_font_size works perfect. | 12:05.16 |
| tor8 | inflex: habit, don't want to accidentally pollute the namespace | 12:05.33 |
| inflex | That's fine - good to know. | 12:05.55 |
| | Just wanted to be sure I didn't clobber something with my hack & slashing. | 12:06.16 |
| tor8 | nah. it's just so I'm more aware of which globals are used outside the module, and also to avoid accidents with symbol clashes | 12:07.08 |
| inflex | Unfortunately, for as good as it was... seems there's a bit of a hiccup with the size changes. Getting some characters being too large among others. Hrm. | 12:13.09 |
| tor8 | inflex: oops. yeah, I think you need to add the 'size' to the struct key used in lookup_glyph | 12:14.48 |
| inflex | ok | 12:15.07 |
| | http://dxp.me/oddsizes.png <=- that's the effect it had (for reference) | 12:15.36 |
| tor8 | yeah, that's what I would expect | 12:15.53 |
| inflex | Though it happened only after the normal size was used (in the search window ) | 12:15.57 |
| | Good. | 12:16.00 |
| tor8 | I had removed the size from the cache lookup (this is code repurposed from elsewhere) | 12:16.19 |
| | since I only used one size | 12:16.25 |
| inflex | Will be something new for me to do. I appreciate that you've pointed me in the right direction. | 12:18.00 |
| tor8 | it should be a two line change | 12:18.20 |
| inflex | okay, have added float size; in to struct key | 12:18.57 |
| tor8 | a 'float size;' after fz_font *font; in the struct key, and then key.size = g_font_size in lookup_glyph | 12:18.59 |
| inflex | ok | 12:19.06 |
| | Fantastic, works. | 12:20.14 |
| | thanks for that second line, I would have taken half a day to deduce that. | 12:20.31 |
| paulgardiner | Is the cluster out of action? | 12:59.38 |
| kens | I probably killed it a little while back it should get better | 13:00.41 |
| | Looks like nodes are checking back in again now | 13:01.59 |
| paulgardiner | Oh okay. Thanks kens | 13:02.26 |
| kens | Hmm OTOH..... | 13:04.14 |
| | Maybe you should ask Robin_Watts to poke it | 13:05.32 |
| paulgardiner | Please would someone review the 6 commits on my master. The cluster is happy with them. The first two are Robin's and I've reviewed them, so only the last 4 need looking at really. | 13:34.52 |
| Robin_Watts | looking | 13:36.27 |
| | Does pdf_fiield_value really return something that should be fz_free'd ? | 13:37.39 |
| | I guess it does. | 13:39.13 |
| | paulgardiner: 3rd commit needs "not" added towards the end of the commit message. | 13:42.24 |
| paulgardiner | ah yes | 13:43.13 |
| Robin_Watts | paulgardiner: Otherwise lgtm. | 13:43.16 |
| paulgardiner | Great. Ta | 13:43.21 |
| tor8 | paulgardiner: the ps2-device.c change could be squashed out (it's introduced in "Add MementoOpenSSL" and removed in "Squash MSVC warnings" | 13:44.24 |
| | adding "random.c" is not mentioned in the message | 13:44.52 |
| paulgardiner | Okay. Will sort that out. | 13:46.29 |
| | There was a third commit, which I squashed onto one of those two, but looks like I picked the wrong one. | 13:47.26 |
| tor8 | paulgardiner: with git rebase -i, you can use the 'e' option to 'edit' a commit | 13:47.54 |
| | when in that state, you can amend the last commit, and even split off and create new commits | 13:48.13 |
| | and then a 'git rebase --continue' will put the rest back on top of what you committed/amended | 13:48.33 |
| | so in cases like this, I squash the problem ones into one, use git rebase to edit the squashed one | 13:49.07 |
| | pull out individual hunks and create new commits using git gui with the 'amend last commit' feature | 13:49.32 |
| | and then rebase --continue to get back to the tip | 13:49.51 |
| Robin_Watts | tor8: paulgardiner knows git - he's been using it longer than me :) | 13:50.40 |
| paulgardiner | I have to admit, I don't use the e option of rebase -i much | 13:51.23 |
| tor8 | fair enough, I just wanted to share a little trick that you may or may not have run across :) | 13:52.51 |
| | especially that you can create new commits while in the 'edit' part of an interactive rebase | 13:53.17 |
| paulgardiner | Yes, that's handy | 13:53.35 |
| Robin_Watts | indeed. | 13:53.42 |
| paulgardiner | I'm tempted to do this one with git gui and cherry picking though. | 13:54.13 |
| | .. ah I've just sussed what you were saying: you can use git gui in the middle of a rebase -i. I'd forgotten you could do that. | 14:04.07 |
| fredross-perry | tor8 - any reason not to do the same thing in noto.c for all platforms? Why is Win32 different? | 15:25.28 |
| tor8 | fredross-perry: so, we went to using objcopy so we didn't have to generate and compile huge C files | 15:29.10 |
| | but objcopy doesn't exist on win32, but there is a similar bin2coff tool | 15:29.20 |
| | which does the same thing, but emits a different type of object file | 15:29.35 |
| | for android, I haven't figured out how to make it use objcopy | 15:29.58 |
| | so it still uses a fallback hexdump C source | 15:30.12 |
| fredross-perry | But do they all wind up in-memory anyway? If so, why worry about the C files? | 15:30.18 |
| tor8 | the commit on tor/master makes that conform to what bin2coff generates (rather than objcopy) | 15:30.25 |
| | we worry about the C files because compilers run out of memory on them... | 15:30.40 |
| | especially newer versions of visual studio crash | 15:30.50 |
| fredross-perry | They are not really that large. I am confused about why VC has trouble. | 15:31.34 |
| tor8 | fredross-perry: we don't build the large ones for android. the CJK fonts are too big for VC. | 15:31.55 |
| | for android we can use the system fonts for CJK | 15:32.07 |
| | so only need to build a handful of smaller fonts | 15:32.15 |
| | for windows and linux, we can't rely on the CJK font being installed so there we need to build the big font blobs | 15:32.34 |
| fredross-perry | Ah. Well anyway, see if you can ive with the commit as I have it. Yours had build issues as I recall. | 15:32.53 |
| tor8 | fredross-perry: yeah, I fixed those by looking at yours. there should be an updated commit on tor/master. | 15:33.12 |
| fredross-perry | coolio | 15:33.20 |
| | thanks | 15:33.38 |
| | tor8 - sorry, still build issues. the filename that hexdump uses has the forge name in it (urw or sil). But your noto.c assumes it's not. that's why I did it the way I did. I still think relying on the compiler's placement/alignment of variables is not a good idea for any platform. | 15:59.36 |
| tor8 | fredross-perry: d'oh!@ | 19:31.17 |
| fredross-perry | lol | 19:44.07 |
| | tor8 - (for the logs) | 23:15.02 |
| | I can fix my not-UTF8 crash bug by changing | 23:15.03 |
| | const char *lname = pdf_dict_get_string(ctx, field, PDF_NAME(T), NULL); | 23:15.04 |
| | to | 23:15.06 |
| | const char *lname = pdf_dict_get_text_string(ctx, field, PDF_NAME(T)); | 23:15.08 |
| | in get_field_name() in pdf-form. | 23:15.09 |
| | There may be other places in the code where it's more correct to use pdf_dict_get_text_string, but I am not looking for them just now. | 23:15.10 |
| | There is probably an earlier place in the flow to deal with this, closer to when the file content is being parsed. | 23:15.10 |
| | this change is in my forms2 branch. | 23:27.26 |
| | Forward 1 day (to 2018/07/18)>>> | |
Log of #mupdf at irc.freenode.net.
