Log of #mupdf at irc.freenode.net.

Search:
 <<<Back 1 day (to 2021/07/20)Fwd 1 day (to 2021/07/22)>>>20210721 
artifexirc-bot <sebras> @Robin_Watts I'm not quite sure about it but I'm suspicious towards doc->resources.fonts. I can see that when we're updating the appearances for the unsigned signatures we're adding a Helvetica entry to the font resources while the local_xref_nesting > 0 (since the unsigned signature appearances are locally synthesised).02:13.38 
  <sebras> when we are altering the text field using pdf_set_field_value() we end up calling pdf_dict_get_put() to change some key/value pair and thus end up in prepare_object_for_alteration(), which in turn calls pdf_purge_local_font_resources() and we wipe out the font we just added when adding the signature appearance.02:16.41 
  <sebras> it does look like we're adding similar (possibly identical) entries to doc->resources.fonts when we're locally synthesising the signature appearances anew.02:17.31 
  <kevin_hicks> Any thoughts on when a new version of mupdf will be tagged and posted on website?02:29.13 
  <sebras> @kevin_hicks I don't want to promise a date, but we're closing in on a 1.19.0 release in the near future.02:30.10 
  <sebras> @kevin_hicks how so? maybe you are a package maintainer and then the reason for the question is obvious, but I don't recognize you as such (yet!) πŸ™‚02:31.02 
  <kevin_hicks> No worries, I was just troubleshooting an issue internally and always like to check on my project dependencies.02:31.32 
  <sebras> @kevin_hicks it might be useful to compile and test our git master anyhow, so you can be confident that the problem is resolved in 1.19.002:32.32 
  <sebras> if not, and it is a serious bug, and a simple fix, then we might want to include that in 1.19.0.02:32.59 
  <kevin_hicks> @sebras good call. Let me dig into the issue more in the AM and and verify it is related to my use of mupdf. I can also scan the change-log for related commits if I think it is mupdf. Thanks for the response!02:35.31 
  <sebras> @kevin_hicks no problem. if you end up with issues most of us devs are here during european business hours. I really shouldn't be here now, so you're lucky to catch me. πŸ™‚02:37.41 
  <sebras> @kevin_hicks btw, how are you guys using mupdf? sounds like it is a bigger project where mupdf is only one part?02:38.20 
  <kevin_hicks> @sebras 10 4. I really not be here either. Just got back from vacation. Been at work since 8 am. It is not 9:38. Time to head to the house. haha.02:39.06 
  <kevin_hicks> @sebras 10 4. I really should not be here either. Just got back from vacation. Been at work since 8 am. It is now 9:38 pm. Time to head to the house. haha.02:39.52 
  <kevin_hicks> @sebras it is part of a large internal app written in VB6. I can share more details later. Honestly I need to review my own code to see how I used it. It's been a while since I made any updates.02:44.15 
  <sebras> VB6! that's not something we hear about very often. πŸ™‚02:45.37 
  <kevin_hicks> Haha, I was waiting for you to catch that.02:46.49 
  <sebras> I ought to head to sleep in a bit, let me know if your issue is resolved, or feel free to register a bug at bugs.ghostscript.com02:47.42 
  <kevin_hicks> 10 4, I will circle back tomorrow.02:48.20 
  <clam_> The Ace of base discussion reminded me that we had Γ  la russe version - https://www.youtube.com/watch?v=90ArrDU0p0M03:14.06 
  <Lucas-C> Hi!07:24.43 
  <Lucas-C> Thank you for the "Fix graphical glitches seen with undying-dusk.pdf" patch & other related commits πŸ™‚07:24.44 
  <Lucas-C> I'll see if I can have those fixes integrated in Sumatra PDF...07:24.46 
  <malc> Lucas-C: hi. tested the game with llpp, it works but initial loding time is out-of this world (~10seconds on my beefy machine), i need to calculate the dimensions off all pages on lead (so that continuous scroll mode works).. wonder how it works with sumatra... and anythying xpdf/poppler derived07:28.14 
  <Lucas-C> Thanks for testing @malc!07:29.46 
  <Lucas-C> It works really well with Sumatra : just a few seconds of initial loading, and then progressive loading works well07:29.47 
  <malc> Lucas-C: please quantify "few" knowing on what machine the measurements were obtained would also be illuminating07:31.17 
  <Lucas-C> ~3s with the latest release of Sumatra PDF on Windows 10 with 16GB of RAM (yes, that might help)07:34.54 
  <Lucas-C> Actually Sumatra PDF just updated their dependency to MuPDF!08:07.46 
  <Lucas-C> https://github.com/sumatrapdfreader/sumatrapdf/commit/f3d98f69a4d2a3c490a1e819b8570a1af37b04a208:07.46 
  <malc> Lucas-C: amount of RAM should be irrelevant here, i'm interested how beefy the CPU is.. here it takes ~10seconds (intel nuc8i3beh)08:16.09 
  <Lucas-C> Intel Core i7-8550U CPU @ 1.80GHz08:21.28 
  <malc> Lucas-C: i3-8109U CPU @ 3.00GHz here08:22.23 
  <Robin_Watts> In the course of fixing that, I had to look at how some of the PDF graphics are structured.09:29.00 
  <Robin_Watts> You do each text char, AFAICT, with large images and a corresponding smask.09:29.46 
  <Robin_Watts> 516x8 in the case I looked at.09:29.56 
  <Robin_Watts> Is there a reason why you didn't just use an imagemask? It'd be much smaller in the file and easier to draw.09:30.22 
  <Robin_Watts> Wow. I have no memory of pdf_purge_local_font_resources at all.10:28.17 
  <Robin_Watts> Ah, @ator added it.10:29.12 
  <Robin_Watts> @sebras So, we create a local_xref in order to synthesise the appearance for an unsigned sig.10:32.38 
  <Robin_Watts> As part of that we create a font resource for Helvetica.10:32.51 
  <Robin_Watts> Later, we come to set the text for an annotation. That throws away the local_xref (and hence the appearance stream for the sig). We throw away all the stored pdf_font resources, so there are no nastily cached ones there. We then set the text, and create a non-local xref version of helvetica.10:34.32 
  <Robin_Watts> What does that leave relying on the now defunct local xref version?10:34.46 
  <malc> Robin_Watts: any time frame for segfault fix?11:09.24 
  <Robin_Watts> malc: We can maybe push that one if @sebras will lgtm it.11:11.25 
  <sebras> @Robin_Watts I'm not sure that I was right about that cache being implicated. but at least I can see that the two helvetica fonts are both being cached there. I haven't checked their life times (maybe one lives on outside the cache because it's referenced).11:11.46 
  <Robin_Watts> But by what is it referenced, dear lisa, dear lisa?11:12.09 
  <sebras> @Robin_Watts none of these appear to be related to a SEGV?11:12.46 
  <sebras> | * cd1a4aa4e ce6c87161 (robin/master) First cut at JPEGXL support.11:12.47 
  <sebras> | * ce6c87161 3df056e58 Update LCMS2 to support premultiplied data, and use that.11:12.48 
  <Robin_Watts> First one on bug-70404511:13.05 
  <malc> Robin_Watts: i offended sebras somehow, so doubt he will lgtm anything where i am implicated :(11:13.07 
  <sebras> I don't know. maybe the annotation appearance still lives on or something.11:13.18 
  <Robin_Watts> It *shouldn't* live on cos it should only be in the local_xref11:13.44 
  <sebras> I know. I'm trying to debug this from two directions. both from when the fz_warn()ings are printed to see where they are called and what is happening there, _and_ what is happening way prior when the signature appearances are being synthesised. since they appear to be related somehow.11:15.15 
  <Robin_Watts> @sebras This one: https://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=3ba8a4cd71e9ca527c5cb67bd23b95f04c6a258411:16.18 
  <sebras> LGTM "Check entry is not NULL before dereferencing it."11:17.16 
  <sebras> yes, I was just checking whether it coincided with Coverity CID 236801 and it does.11:17.37 
  <Robin_Watts> Ta.11:17.49 
  <sebras> np11:17.51 
  <Robin_Watts> malc: There you go.11:18.15 
  <malc> Robin_Watts: what can i say... the english subjugated the swedes, ta11:18.57 
  <sebras> @Robin_Watts this is where I see the warning https://pastebin.com/raw/Aw6aaXK811:20.21 
  <sebras> the warning being: "warning: FT_Load_Glyph(NimbusSans-Regular,26725,FT_LOAD_NO_HINTING): invalid argument"11:20.39 
  <Robin_Watts> yeah, I get the same thing here. Just trying to add some debugging.11:20.55 
  <sebras> @Robin_Watts gid == 2672511:21.05 
  <sebras> and 26725 == 0x6865 == "he"11:21.36 
  <sebras> which are the two first bytes in the string "hello"11:21.47 
  <sebras> this gid is constructed when pdf_decode_cmap() gets called in show_string() called by pdf_show_string() called by pdf_run_Tj().11:22.46 
  <sebras> I'm thinking that the cmap Identity-H is probably not correct in this case.11:23.10 
  <sebras> it seems to me that the cmap tells us that 0x6865 is a valid cid, but then that glyph doesn't exist in the font.11:24.05 
  <sebras> the reason I think Identity-H is wrong is because when we created the text field annotation value we registered this in the document fonts resource cache: 11:34.34 
  <sebras> <<11:34.35 
  <sebras> /Type /Font11:34.36 
  <sebras> /Subtype /Type111:34.37 
  <sebras> /BaseFont /Helvetica11:34.39 
  <sebras> /Encoding /WinAnsiEncoding11:34.40 
  <sebras> >>11:34.41 
  <sebras> which implies that the string is WinAnsiEncoding.11:34.44 
  <sebras> and that matches the string.11:34.53 
  <paulgardiner> I was just seeing if I can trigger some of the AppKit problems in mupdf-gl, and one of the test files causes an access violation on opening.11:35.48 
  <Robin_Watts> @paulgardiner I just pushed a fix for that.11:36.36 
  <paulgardiner> Oh right. I'll grab it11:36.49 
  <Robin_Watts> @paulgardiner At this point, we can reproduce a nasty problem that we need to solve.11:37.07 
  <Robin_Watts> If we solve it, it's possible all the other stuff will fall out.11:37.14 
  <paulgardiner> That's good. I'll wait on that11:37.29 
  <Robin_Watts> It seems to me that to have 3 of us all working on the same issue is probably not ideal πŸ™‚11:37.39 
  <sebras> @Robin_Watts I guess I volunteered for the night shift? πŸ˜‰11:43.46 
  <Robin_Watts> OK, so the 'date' field into which we have been typing "hello" is the first widget on the page.12:02.31 
  <Robin_Watts> My debugging shows that we do pdf_update_page (just after having set the value), and that does the Update Appearance dance.12:03.18 
  <Robin_Watts> We do that as non-local synthesis (as you'd hope), which pops and discards the local xref.12:03.43 
  <Robin_Watts> Then we roll through the rest of the widgets, and do local synthesis for subsequent ones.12:04.22 
  <Robin_Watts> then we finish pdf_update_page.12:04.51 
  <Robin_Watts> So next, we run the annots to actually display them.12:05.08 
  <Robin_Watts> And on the very first annot (i.e. the hello one), we push the local_xref, and that's when we get the warnings.12:05.38 
  <Robin_Watts> So, on the face of it, it looks like we have an appearance generated into the real document, that is upset by the presence of appearances added in the local_xref.12:06.49 
  <Robin_Watts> So, on the face of it, it looks like we have an appearance generated into the real document, that is upset by the presence of appearances added subsequently in the local_xref.12:07.09 
  <sebras> yes, that seems plausible12:15.39 
  <sebras> @Robin_Watts I might be on to something.15:07.36 
  <sebras> @Robin_Watts I'm seeting that we call pdf_store_item(key == 395 0 R == << /Type /Font /Subtype /Type0 /BaseFont /Helvetica /Encoding /Identity-H /ToUnicode 396 0 R /DescendantFonts [ 400 0 R ]>>, val->font == NimbusSans-Regular and val->cmap == Identity-H ) and later look it up correctly with pdf_find_item(key == 395 0 R == << /Type /Font /Subtype /Type0 /BaseFont /Helvetica /Encoding /Identity-H /ToUnicode 396 0 R 15:10.21 
  <Robin_Watts> ok...15:11.11 
  <sebras> after pdf_set_field_value() has been called we're calling pdf_find_item again: pdf_find_item(key == 395 0 R == << /Type /Font /Subtype /Type1 /BaseFont /Helvetica /Encoding /WinAnsiEncoding >>) but we get the old entry: returnvalue->font == NimbusSans-Regular and returnvalue->cmap == Identity-H15:13.30 
  <sebras> so we have a different key with the same object number, hence we end up at the same entry in the pdf store15:14.00 
  <sebras> pdf_make_hash_key() is based only on the object number.15:14.30 
  <sebras> and there is no calling of pdf_remove_item(), I've checked that.15:14.43 
  <Robin_Watts> this is what pdf_purge_store_of_font_crap (or whatever it is called) is supposed to stop.15:15.02 
  <sebras> and no intervening calls to pdf_store_item() either.15:15.03 
  <sebras> pdf_purge_local_font_resources() works on doc->resources.fonts but pdf_remove_item() works on pdf_obj_store_type which is a different cache.15:16.34 
  <sebras> perhaps pdf_purge_local_font_resources() ought to call pdf_remove_item() for relevant items too?15:16.52 
  <sebras> pdf_find_item() doesn't appear to be keyed on local_xref and local_xref_nesting. that seems suspicious to me.15:17.18 
  <Robin_Watts> pdf_find_item is indeed not keyed on local_xref and local_xref_nesting.15:17.52 
  <sebras> perhaps the keying there is not the issue though. I'm not sure. I can't quite grasp the issue just yet.15:17.58 
  <Robin_Watts> The idea is that when we purge local_xref, we purge the store.15:18.24 
  <sebras> what call purges the local xref?15:18.49 
  <Robin_Watts> pdf_purge_local_font_resources.15:19.04 
  <sebras> right, and that happens as a side effect of calling pdf_dict_put().15:19.26 
  <Robin_Watts> oh, wait, no, that's not what that function does.15:19.48 
  <sebras> pdf_drop_local_xref() perhaps?15:20.07 
  <Robin_Watts> Gah. I convinced myself this morning that we needed something that purged the font stuff from the store when we dumped the local_xrefs.15:21.07 
  <Robin_Watts> Then I (incorrectly) convinced myself that tor had already coded that.15:21.26 
  <sebras> right.15:21.33 
  <sebras> yes, this is likely the core issue.15:21.42 
  <sebras> and we happen to have the same object 395 0 R referring to the font of the unsigned signature appearance text before I edit the text field as well as the text fields own font immediately after I have edited it, then referring to a different object, but we return the same font from the store.15:23.00 
  <Robin_Watts> Lets try an fz_empty_store();15:23.17 
  <sebras> I put one next to pdf_purge_local_font_resources() and then it works fine.15:24.24 
  <Robin_Watts> That solved it.15:24.26 
  <sebras> agreed.15:24.37 
  <Robin_Watts> OK, so we have a workaround, maybe.15:24.41 
  <Robin_Watts> So, let me try and find a nicer solution than dumping everything.15:24.57 
  <sebras> is it the case that we shouldn't be sticking objects from the local_xref into the store?15:25.07 
  <Robin_Watts> If we don't do that, then we'll never cache fonts/images/etc from local synthesis.15:25.39 
  <sebras> or rather, when they are keys we shoudl ignore the store.15:25.41 
  <sebras> ok. is that a problem?15:25.52 
  <Robin_Watts> I think so.15:26.12 
  <sebras> ok. is that a big problem?15:26.13 
  <sebras> ok.15:26.16 
  <Robin_Watts> I can probably do something whereby I filter the store, and evict all local xref keyed objects.15:26.42 
  <sebras> that sounds doable.15:29.02 
  <sebras> agh. using pdf_is_local_object() to do the filtering was difficult since the local xref has already been popped!15:39.28 
  <sebras> I hackily added doc->local_xref_nesting++ and -- around the call and that helped of course, but that's not how to do it.15:40.00 
  <Robin_Watts> pdf_is_local_object is only called from one place.15:42.54 
  <Robin_Watts> and that's always got a local_xref in place if there is one.15:43.11 
  <Robin_Watts> so we could just remove the check from that function.15:43.21 
  <sebras> right.15:43.33 
  <sebras> @Robin_Watts http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=f4b8491239f79d36224431394ba34cb46788313315:45.36 
  <Robin_Watts> not quite.15:45.56 
  <sebras> ok, then I want to see your proposal to fix it.15:46.29 
  <sebras> (mine appears to work, but I don't fully understand what I'm doing, so I might be removing too much or in the wrong way somehow)15:47.36 
  <Robin_Watts> Just writing a commit message.15:47.41 
  <Robin_Watts> Yours is very close. We need to check doc too, I believe.15:47.55 
  <sebras> ah, yes, of course.15:48.36 
  <sebras> like the other filter function just above. makes sense.15:48.44 
  <Robin_Watts> actually, rather than changing pdf_is_local_object, why don't we just do the purge 3 lines earlier?15:49.00 
  <sebras> not sure I follow.15:49.38 
  <sebras> you mean before if(doc->local_xref_nesting > 0) in prepare_object_for_alteration()?15:49.51 
  <Robin_Watts> https://git.ghostscript.com/?p=user/robin/mupdf.git;a=shortlog;h=refs/heads/bug-70404515:50.46 
  <sebras> you pushed master, not that branch. no changes.15:52.30 
  <Robin_Watts> oops. pushed the wrong thing. Look again.15:52.33 
  <Robin_Watts> sorry15:52.42 
  <Robin_Watts> bugger. still not right.15:53.27 
  <sebras> ah, yes I was contemplating why we were doing this prepare_object_for_alteration() instead of pdf_annot_pop_and_discard_local_xref().15:53.36 
  <Robin_Watts> OK, fixed version pushed.15:55.39 
  <sebras> @Robin_Watts "Extend PDF_DEBUG_APPERANCE_SYNTHESIS printouts." calls fz_empty_store() and it shoudln't15:55.44 
  <Robin_Watts> I just fixed that, and I removed the stray lcms2 change.15:56.00 
  <sebras> since pdf_debug_doc_changes() will not be called anywhere I'll just trust that commit if it compiles. πŸ™‚15:56.37 
  <sebras> /* #define PDF_DEBUG_APPEARANCE_SYNTHESIS */ -----> #undef PDF_DEBUG_APPEARANCE_SYNTHESIS ???? like we have done for DEBUG_SCAN_CONVERTER and DEBUG_PROGESSIVE_ADVANCE15:57.31 
  <sebras> if you change that break to goto, then you can remove the preceeding calls to pdf_clean_obj() as well (since it will be called at the end of the block).15:58.43 
  <Robin_Watts> If you want. Using #undef means people can't "-DPDF_DEBUG_APPEARANCE_SYNTHESIS"15:58.45 
  <Robin_Watts> ah, nice.15:59.00 
  <sebras> that's true for all the debug flags. I change the code myself, so not very bothered by -D not working. are you?15:59.51 
  <Robin_Watts> I could avoid the goto by using a do { ... } while (0); and breaking out of it. What do you think is neater?16:00.19 
  <Robin_Watts> or by just making it if () else if ... else ...16:00.58 
  <Robin_Watts> That's neater.16:01.00 
  <sebras> the latter.16:01.03 
  <sebras> to do "do { ... break ... } while (0);" when you mean "goto" is kind of misleading imho.16:01.41 
  <sebras> if-else is best here.16:02.08 
  <Robin_Watts> I like it over goto, because it's clear that the flow is forwards. And it's backward goto's that get you in trouble.16:02.46 
  <sebras> yeah, I agree that breaking backwards is kind of difficult. πŸ™‚16:03.32 
  <Robin_Watts> New version up.16:04.06 
  <malc> Robin_Watts: do break while causes warnings for certain compilers/flags, think i've been bitten by it with gcc/clang and msvc... for (;;) break on the other hand is okay16:04.30 
  <malc> otherwise the condition is always ___ is being diagnosed by overly zeal/ous compilers16:05.10 
  <Robin_Watts> I've not seen that problem with msvc.16:06.06 
  <Robin_Watts> and clang/gcc give so many spurious warnings that I don't propose to lose sleep over them.16:06.29 
  <Robin_Watts> for (;;) is just horrid.16:07.08 
  <sebras> @Robin_Watts can I ask for a line feed after the else block before the debug prints in pdf_update_appearance()?16:07.16 
  <Robin_Watts> Ask, and it is done.16:08.14 
  <sebras> "On local xref destruction, purge the store of all local_xref keyed objects" needs a trailng period to make @ator happy, but the code LGTM.16:08.19 
  <Robin_Watts> done.16:09.44 
  <Robin_Watts> (and the line shortened)16:09.58 
  <sebras> LGTM, I'm clustering the previous version now.16:10.46 
  <Robin_Watts> I already did that.16:10.59 
  <Robin_Watts> 2 diffs, and I'm stuck behind you for the bmpcmp πŸ™‚16:11.14 
  <sebras> oh, sorry. πŸ™‚16:11.33 
  <Robin_Watts> no worries.16:11.40 
  <sebras> $ ./build/debug/mutool run trace.js && echo success16:12.55 
  <sebras> success16:12.56 
  <sebras> $ ./build/debug/mutool run trace2.js && echo success16:12.57 
  <sebras> success16:12.58 
  <sebras> $ ./build/debug/mutool run trace3.js && echo success16:13.00 
  <sebras> warning: FT_Load_Glyph(NimbusSans-Regular,26725,FT_LOAD_NO_HINTING): invalid argument16:13.01 
  <sebras> warning: FT_Load_Glyph(NimbusSans-Regular,26725,FT_LOAD_NO_SCALE|FT_LOAD_IGNORE_TRANSFORM): invalid argument16:13.02 
  <sebras> warning: cannot render glyph16:13.04 
  <sebras> 16:13.05 
  <sebras> wtf! didn't we just fix this?!16:13.08 
  <Robin_Watts> maybe more than one issue?16:14.52 
  <sebras> probably. let me share the case.16:15.41 
  <Robin_Watts> No, I'm seeing the issue here still. What did I break?16:15.43 
  <sebras> you added doc == key_doc. I didn't have that.16:16.50 
  <sebras> I other than that I can't see any real changes.16:17.01 
  <sebras> wait, you did change one thing.16:17.12 
  <Robin_Watts> OK, if I make the filter thing do if (doc == key_doc), I get the right result.16:17.24 
  <sebras> I called fz_empty_store() from prepare_object_for_alteration() but you do it from pdf_annot_pop_and_discard_local_xref().16:17.33 
  <sebras> I remember that I never saw pdf_annot_pop_and_discard_local_xref() being called!16:17.39 
  <Robin_Watts> If I make if if (doc == key_doc && ....) it does wrong.16:17.42 
  <Robin_Watts> pdf_is_indirect.16:18.26 
  <Robin_Watts> Right. Let me try something.16:18.33 
  <Robin_Watts> ok, new version pushed.16:28.24 
  <sebras> " whether the xref is in force or not (purely that it exists). The" shoudl there be a not at the start of the parenthesis?16:29.33 
  <Robin_Watts> No. I'll just remove all the parenthesis.16:30.31 
  <sebras> ok, the grammar confused me.16:30.55 
  <Robin_Watts> updated.16:30.59 
  <Robin_Watts> And me on re-reading.16:31.04 
  <malc> *shou_l_d *the parenthes_e_s16:31.10 
  <Robin_Watts> "A parenthesis is a word, phrase or sentence that is inserted into writing using brackets."16:33.55 
  <Robin_Watts> Hence sebras was correct.16:34.00 
  <sebras> @Robin_Watts do we need to call pdf_purge_local_font_resources() and pdf_purge_locals_from_store() from pdf_drop_document_imp() when we drop the document? that seems reasonable to me.16:35.03 
  <Robin_Watts> Don't we already filter everything from that doc in that case ?16:35.34 
  <malc> Robin_Watts: okay, but what does at the start of the parenthesis means?16:35.36 
  <sebras> @Robin_Watts oh, we call pdf_empty_store(doc) there!16:35.47 
  <Robin_Watts> this is a sentence (and this is the parenthesis).16:36.06 
  <Robin_Watts> so "and" would be "at the start of the parenthesis".16:36.19 
  <sebras> in Swedish we use parenthesis both to mean the character ( and to mean the entire thing enclosed in parentheses. I use it the same way in English, whether that is correct or not. πŸ™‚16:37.10 
  <malc> https://xkcd.com/859/16:37.19 
  <Robin_Watts> I suspect that is also correct.16:37.28 
  <Robin_Watts> I have a T-shirt that says: "Not only am I a master of suspense, I also..."16:37.50 
  <malc> ... don't spell all that well16:38.23 
  <Robin_Watts> Anyway... @sebras There is a niggling thing that's been bothering me about the local_xref stuff.16:39.53 
  <sebras> ok..?16:40.01 
  <Robin_Watts> The callers loop over pdf_update_annot.16:40.10 
  <sebras> I all my existing test cases work fine now.16:40.11 
  <Robin_Watts> That calls pdf_update_appearance.16:40.23 
  <Robin_Watts> So imagine that I have 2 widgets on the page.16:40.41 
  <malc> in Russian "(" = skob[k]a (sg.); "()" = skobki (pl), and sexp is "Π²Ρ‹Ρ€Π°ΠΆΠ΅Π½ΠΈΠ΅ Π² скобка", and this keeps us sane and peaceful folk16:41.02 
  <Robin_Watts> We call pdf_update_annot on the first one, and it gets a local synthesis done.16:41.08 
  <Robin_Watts> We then call pdf_update_annot on the second one, and it gets a non-local synthesis done, that throws away the local_xref and so undoes the first one.16:41.48 
  <sebras> yes.16:41.50 
  <Robin_Watts> At the moment, I think most clients survive because they tend to 'over call' pdf_update-annot.16:42.14 
  <Robin_Watts> I am tempted to rejig stuff slightly.16:42.36 
  <Robin_Watts> Firstly, can we make pdf_update_appearance a static ?16:42.47 
  <sebras> @Robin_Watts that does seem like a plausible scenario, yes.16:42.51 
  <sebras> we expose pdf_update_appearance() via jni/js16:43.12 
  <Robin_Watts> We can unexpose it.16:43.20 
  <sebras> it seems as if smartoffice calls pdf_update_annot().16:43.45 
  <Robin_Watts> Anyone that is calling it can call pdf_update_annot instead.16:43.51 
  <sebras> I have a question though. pdf_update_page() iterates over first all annots then all widgets. waht you would want is to iterate over all that have proper resynthesis (whether they are annots or widgets) and then iterate over all that need local synthesis at the end.16:45.19 
  <Robin_Watts> No, what I'd want to do is just to iterate over them a second time if any change πŸ™‚16:45.51 
  <sebras> then you should have an assert at the second time through that none change, right?16:47.14 
  <Robin_Watts> We could assert, yes.16:47.27 
  <sebras> if that assert() never triggers I understand your idea.16:47.46 
  <Robin_Watts> AIUI, that assert should never trigger.16:48.03 
  <sebras> agreed.16:48.10 
  <sebras> so lets not put it there! πŸ™‚16:48.17 
  <Robin_Watts> The only way we can need to run a second time is if the local_xref is cleared during the first pass.16:48.30 
  <Robin_Watts> That can only happen if 'needs_new_ap' is set.16:48.40 
  <Robin_Watts> and that always gets cleared on the first run.16:48.45 
  <sebras> right.16:48.51 
  <sebras> that does sound reasonable.16:49.00 
  <Robin_Watts> I can't see any nice way to hide this under an interface so people can pdf_update_annot as they do now.16:49.27 
  <sebras> but I agree with paul that I'd like to have found these issues earlier. let's hope I get to the point of checking in my test cases _this_ time.16:49.35 
  <Robin_Watts> (without requiring them to rerun)16:49.38 
  <Robin_Watts> (paul has mentioned this specific issue to me)16:50.01 
  <sebras> appkit's updatePagesRecalc() seems very similar to pdf_update_page() with one significant difference: they collect all the rects of the updated annots/widgets so that they know what parts to redraw.16:52.04 
  <sebras> pdf_update_page() doesn't do that, it only returns a flag changed/not changed.16:52.27 
  <Robin_Watts> Right. I think basically we are forcing this 'retry earlier ones if you get a change' logic onto all callers. And I think I'm fine with that, as long as we state it clearly.16:53.09 
  <sebras> so if you change pdf_update_page() paul would need to change appkit code too.16:53.10 
  <Robin_Watts> yes.16:53.15 
  <sebras> if pdf_update_page() had taken a callback for each changed annot they could have used that to create the list.16:54.55 
  <sebras> and in that case you could update pdf_update_page() to do the actual reiteration.16:55.22 
  <Robin_Watts> yes, but shoehorning that in now may not be nice.16:57.26 
  <sebras> appkit for androd uses PDFPage.update().16:57.44 
  <sebras> prior to release you mean? or even after the release?16:58.19 
  <Robin_Watts> changing the API is not nice whenever we do it.16:58.39 
  <sebras> appkit needs to change its code regardless.16:59.15 
  <sebras> and appkit/android will not benefit the change of appkit/ios since they are not doing the same thing.16:59.37 
  <Robin_Watts> yes.16:59.56 
  <sebras> @Robin_Watts well, in your proposal we do not need to _do_ any more changes, we just tell appkit to fix it.17:11.06 
  <Robin_Watts> We need to fix pdf_update_page.17:11.24 
  <Robin_Watts> I am just writing a commit message now.17:11.31 
  <sebras> @Robin_Watts does sebras/bug-704045 with the added removal of pdf_field_dirties_document() look reasonable to you?17:11.36 
  <Robin_Watts> Yes.17:12.34 
  <Robin_Watts> https://git.ghostscript.com/?p=user/robin/mupdf.git;a=shortlog;h=refs/heads/bug-70404517:15.49 
  <sebras> I added a test case that repeatedly calls pdf_set_text_value() for a text field like I've been told appkit does. and when doing so it only indicates changes in the text field and any unsigned signatures.17:16.45 
  <Robin_Watts> So, it's looking good?17:17.19 
  <sebras> yes. I'm going to review your commit, and if it clusters and I can't fault it, then I'd like paul/fred to take this for a spin.17:17.52 
  <Robin_Watts> The bmpcmp looks plausible to me.17:18.07 
  <Robin_Watts> It shows 2 files that have gained the "sign here" thing.17:18.24 
  <sebras> same file, just one in color and one in grayscale.17:19.04 
  <sebras> and that signature is indeed unsigned.17:19.26 
  <sebras> I agree about the bmpcmp, now I'll read the last commit.17:19.56 
  <Robin_Watts> @sebras Paul is standing by to give this all a spin first thing tomorrow.17:23.45 
  <sebras> @Robin_Watts question: should all of these commit messages be prefixed with Bug 704045?17:26.07 
  <Robin_Watts> possibly, but not the last one, maybe?17:26.36 
  <sebras> agreed.17:28.00 
  <sebras> also f63d74f91 please.17:28.17 
  <sebras> @Robin_Watts but in general I'm happy with robin/bug-70404517:34.44 
  <Robin_Watts> I've updated the branch now.17:34.51 
  <Robin_Watts> There are a couple of commits I didn't put the bug name in for, cos they aren't part of the fix.17:35.17 
  <sebras> makes sense to me.17:35.52 
  <sebras> I'm happy with robin/bug-70404517:36.06 
  <Robin_Watts> cool. I'll give that one last cluster spin and then push it. ta.17:36.14 
  <sebras> thanks for helping out debugging and fixing the final bits.17:36.54 
  <sebras> wait...17:37.33 
  <sebras> @Robin_Watts docs/manual-mutool-run.html mentions updateApperance().17:37.51 
  <Robin_Watts> I don't understand the <dl> it's in.17:38.50 
  <Robin_Watts> should I just remove the <dt> for updateAppearance? Or the following <dd> as well?17:39.15 
  <sebras> both. Define Term and Define Description or something like that.17:39.41 
  <Robin_Watts> yeah, but none of the previous <dt>'s have a <dd>17:39.56 
  <sebras> no, because we haven't bothered to add descriptions to those.17:40.10 
  <sebras> yet.17:40.12 
  <Robin_Watts> OK.17:40.14 
  <sebras> it does say "WORK IN PROGRESS" in rather big font just above. πŸ™‚17:40.27 
  <sebras> I guess I should be adding things here at some point.17:40.46 
  <Robin_Watts> I'm just going to change it from updateAnnotation to update17:41.27 
  <Robin_Watts> I'm just going to change it from updateAppearance to update17:41.48 
  <sebras> that ought to work fine, we expose PDFAnnotation.update() both in js and in jni.17:42.28 
  <sebras> @Robin_Watts LGTM.17:44.42 
  <Robin_Watts> Ta.17:44.49 
  <sebras> @Robin_Watts tomorrow let's see what paul/fred says. and let's try to work my test cases into the cluster.17:45.05 
  <Robin_Watts> Fab.17:45.13 
  <sebras> since I want to have more subdirectories I'm anticipating that something in the cluster needs to change, but I don't know what.17:45.37 
  <Robin_Watts> build.pl will need a tweak. That's easy.17:46.23 
  <sebras> ok, let's do it tomorrow.17:46.33 
  <clam_> not sure how this whole discording works, but anyhow:20:47.57 
  <clam_> @Lucas-C: i completely forgot that long time ago i've implemented page dim caching (mainly for gargantuan comic books)20:48.52 
  <clam_> @Lucas-C: and now i've tried it with undying-dusk... it works... lading time went from >10 to <1 seconds20:49.59 
  <clam_> comes at a price though20:51.07 
  <clam_> - du -bh undying.dcf20:51.08 
  <clam_> 276undying.dcf20:51.09 
  <clam_> guess i have to learn how to live with 276bytes cache file20:51.36 
 <<<Back 1 day (to 2021/07/20)Forward 1 day (to 2021/07/22)>>> 
ghostscript.com #ghostscript
Search: