Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2017/02/09)20170210 
sebras Robin_Watts: in mupdf:1912de5f when can oldbot be != -1?13:15.28 
  it seems to me it must always be >= 0 since gbot starts out at 0 and may only be set to whatever value gtop has, and that must necessarily be >= gbot..?13:16.14 
Robin_Watts sebras: If we throw an error before we get to the point where oldbot is set ?13:16.16 
  oldbot is only every not -1 if we make it to pdf_process_contents.13:16.57 
sebras ah, yes of course.13:16.59 
  why are there two calls to pdf_gsave()?13:17.15 
  wouldn't one be sufficient?13:17.22 
Robin_Watts possibly.13:17.40 
  I was making the minimum changes I could to avoid introducing more thinkos.13:18.00 
sebras Robin_Watts: I don't tink fz_var(gstate) is necessary anymore since it is not used in fz_alway()/fz_catch().13:25.07 
  other than that I can't fault the logic. without knowing any details it seems unecessary to do two gsaves and have three calls to grestore in the cleanup logic.13:27.17 
  also I'm perplexed by gparent any why it is necessary to store in the processor state. wouldn't it be sufficient to have it as a local? git history sheds no light on why it is needed.13:28.15 
  Robin_Watts: oh and what is blocking merging 696870? I recall having looked at that before..?13:29.07 
tor8 sebras: 696870 is not required; not sure why robin still has it on his branch13:36.15 
sebras tor8: the "but it seems we do" appears to tell a different story though.13:37.21 
tor8 sebras: Robin_Watts: commit 515c0106845a7dafd71abba6b29305e39c88380e adds the second gsave13:46.39 
  I can't claim to understand they why, better ask Robin about it.13:47.48 
sebras tor8: mm, I also don't understand the story in the commit message. I'm slightly worried that we might be complicating the code because we don't understand it. :-/13:52.23 
 Forward 1 day (to 2017/02/11)>>> 
ghostscript.com
Search: