IRC Logs

Log of #ghostscript at

 <<<Back 1 day (to 2012/05/03)2012/05/04 
ghostgum good morning00:15.31 
henrys Robin_Watts:yes Arnie delivered the scarf thank you very much06:49.34 
tor8 Robin_Watts: morning.08:49.42 
Robin_Watts tor8: Morning09:10.01 
tor8 thinking of the jbig2dec situation, might help09:10.46 
Robin_Watts interesting.09:14.15 
tor8 supposedly an easy way to pull and push bits of code from a subdirectory of a mega-repo to a smaller one09:14.49 
Robin_Watts So we could use that on casper to generate a standalone jbug2dec from the gs master.09:15.21 
  And then disallow commits to the standalone one.09:15.37 
tor8 that was my thinking, yeah.09:15.41 
Robin_Watts So people would have to commit to the main gs one, and it would automatically appear in the standalone.09:15.56 
  I like that,09:15.58 
tor8 or if it works, we could commit to both and just use the subtree command to pull/push and merge changes between the two09:16.15 
  I've been doing the same thing manually for the last couple of times, but finding a command to do it for us would help.09:16.43 
  unless we decide to discontinue the standalone git, but I think that may be bad for the jbig2dec project's credibility09:17.07 
Robin_Watts Pulling changes automatically (untested) into gs sounds bad.09:17.17 
tor8 yeah, automatic (that direction) would be bad09:17.43 
  a crontab job to do the automatic the other direction would be swell09:17.53 
  we'll need to fix up the the makefile and configure differences first though, something I discussed with chrisl the other day09:18.32 
  chrisl: MuPDF 1.0 is out on the app store now!09:18.55 
Robin_Watts Would be nicer to trigger on commits to specific parts of the gs tree than just to do it "every 12 hours" or something.09:18.59 
tor8 the apple app store, that is.09:19.01 
  we could do it as part of the same triggers that start the cluster tests09:19.49 
ghostgum Is Artifex still using for anything ?09:19.54 
chrisl ghostgum: only the legacy stuff, there's nothing current of ours on there09:20.25 
  tor8: cool! (on the app store)09:20.54 
ghostgum has been turned off by Wisconsin. So I now need to put GSview and RedMon somewhere else, probably sourceforge.09:21.07 
chrisl ghostgum: Hmm, did I miss notice of that?09:21.42 
ghostgum I wasn't notified either. I just got emails from people saying they couldn't download GSview.09:22.02 
  Does Artifex want to host the downloads of GSview and RedMon?09:22.30 
Robin_Watts ghostgum: I think that would be sensible.09:22.53 
ghostgum If not, I'll set up a project on 
chrisl I saw a couple of mails, but the wisc site has been pretty unreliable for the last year or so, so I ignored them.09:23.20 
Robin_Watts but Henry would be the guy to decide, I think.09:23.21 
  And he's away with the sheep at the moment.09:23.37 
ghostgum Is he likely to be on IRC in 8 hours, or would email be better?09:24.11 
Robin_Watts He's in the UK at the moment, on holiday.09:24.32 
  Email is probably better.09:25.08 
chrisl Yeh, if Henry pops up here, we'll tell him about it09:25.38 
ghostgum Short term I'll put GSview on my own site, then watch monthly download limits carefully.09:26.37 
chrisl ghostgum: is still working, could we just rearrange the files a bit (for now)?09:27.39 
ghostgum I thought about putting the files on, but wasn't sure how much it would upset them. I'll try that short term for the current version only.09:32.08 
chrisl ghostgum: hopefully, they'll cut us some slack given that they pulled the mirrors pages without notice. I don't anticipate any objection to Artifex taking over the hosting, so hopefully it won't be for long.09:33.31 
kens Robin_Watts : or tor8 What's the git command to collapse a bunch of patches ? I don't really want to make 19 commits09:51.51 
tor8 kens: git rebase -i and change the lines of the commits you want to collapse to 'squash'09:53.52 
Robin_Watts git rebase -i hash09:54.18 
tor8 so you'll have a 'pick' for the commit you want to keep, and 'squash' on the commits you want to squash into the picked commit09:54.32 
kens Ah, a difference of opinion...09:54.42 
Robin_Watts where hash is the one before your first one.09:54.46 
  We agree - tor8 just didn't mention the need for the hash.09:55.07 
kens The one before my first one is the master09:55.11 
ghostgum They didn't just turn off the server, they removed the AFS mount.09:55.13 
Robin_Watts git rebase -i master then09:55.25 
kens git logg still shows 20 commits, is that right ?09:56.34 
  Hmm, let me put this a different way. I have a branch with 20 commits. It is rebased onto master. I want to 'aquash' all 20 commits into one, and update master so that I can commit it.09:58.39 
Robin_Watts OK. git rebase -i master10:00.00 
  That starts an "interactive rebase".10:00.11 
kens Which branch needs to be checked out ?10:00.15 
Robin_Watts Your branch with all the commits on.10:00.31 
kens OK one second10:00.36 
Robin_Watts That will open a window that lists all the commits between HEAD and the specified hash (i.e. master)10:00.58 
kens Yes, got that10:01.17 
Robin_Watts You now need to edit that file, save it back, and then the git history will be rejigged so it conforms to that list of instructions.10:01.30 
kens of the form pick xxxxx comment10:01.31 
Robin_Watts I typically use this to reorder lines so I can change the order of commits.10:01.52 
kens The order is OK.10:02.11 
Robin_Watts The last line is the most recent commit - you want to keep that, so leave it as 'pick'.10:02.21 
kens last one ? OK10:02.35 
  Others to squash ?10:02.41 
Robin_Watts All the others go to squash.10:02.47 
kens OK10:03.08 
Robin_Watts save the file and exit.10:03.20 
kens Won't let me10:03.50 
  path does not exist10:03.56 
Robin_Watts eh?10:04.15 
kens c:\ghostpdl\.git\rebase-merge\git-rebase-todo.txt is the path, WIndows says 'Path does not exist'10:04.32 
  the 'rebase-merge' directory indeed does not exist10:05.09 
Robin_Watts What editor are you using?10:05.15 
kens Wordpad10:05.23 
  Or write or something10:05.32 
Robin_Watts That path must have existed when the file was launched into the editor.10:05.47 
kens It doesn't exist now10:05.56 
Robin_Watts I suspect that because it's a windows app, git thinks the editor has closed down, and it's tidied up.10:06.16 
  How do you usually manage to get commit messages in ?10:06.29 
kens Seems likely, I have a command prompt in MingW10:06.34 
  I normally use git gui10:06.41 
Robin_Watts Ah.10:06.46 
  Well, you need to configure a less broken editor then.10:06.56 
  export EDITOR=emacs10:07.05 
  (or something like that)10:07.08 
kens Not using emacs10:07.10 
  Will do 20 commits rahter than that10:07.18 
Robin_Watts I feel the same about vi :)10:07.48 
kens Yes, don't wnat to use vi either10:08.00 
  MingW doesn't have emacs anyway10:08.19 
Robin_Watts btw, marcosw sent a link in an email about a webpage for helping to choose the meeting date. We should all use it.10:08.41 
  kens: right, but I'm sure you can find an editor that works.10:08.52 
kens Robin_Watts : the only editor appears to be vi in MingW10:09.10 
tor8 kens, Robin_Watts: squash squashes the commit into the *previous* commit, so you want the 'pick' to be the first commit. you get a chance to edit the commit messages later.10:09.11 
  and if you goof up, git-gui with 'amend' can let you rewrite the commit messages10:09.24 
kens All Windows editors cause MingW to go back to the command prompt10:09.31 
Robin_Watts Well, emacs is a windows editor, and it works for me.10:09.53 
kens I don't have emacs on Windows.10:10.06 
  Obvuiously :-)10:10.11 
Robin_Watts Right, but you should be able to find an editor that works - my point is that it doesn't need to be a special msys one.10:10.39 
tor8 kens: hm, msysgit on my windows box (with no special configuration) picks 'vi' as its editor10:10.54 
kens I can't find an editor that I have installed which it will work with10:11.00 
tor8 I think it has to be a command line editor, that keeps the console busy until it's done10:11.13 
  so the typical gui editors probably won't work because they detach from the console, leaving git to think you're done10:11.46 
kens export EDITOR=vi doesn't work, still launches write.exe10:11.57 
Robin_Watts msys can be kept busy by windows apps too - if you run procexp for example, that starts procexp up, and doesn't give you the command line back until you exit it.10:12.19 
  If I run emacs I need to run emacs & to get the command line back instantly.10:12.33 
kens Thats unusual behaviour in Wndows10:12.47 
Robin_Watts Yes. msys is different to windows.10:12.59 
kens Still, I can't use hte MingW emacs, it doesn't launch it10:13.07 
tor8 kens: I don't have any EDITOR setting anywhere. maybe you've set it up with 'git config'?10:13.08 
kens tor8 yes possibly10:13.19 
  How do I tell ?10:13.32 
tor8 kens: git config -l to list your config options10:13.33 
Robin_Watts core.editor="D:/Program Files/emacs-21.3/bin/emacs.exe"10:13.53 
kens Yes, core.editor is set to write.exe10:13.56 
tor8 kens: 
kens SO how do I change that ?10:14.59 
tor8 a wrapper exe to let you use notepad.exe as your editor10:15.13 
  git config core.editor "new setting"10:15.21 
kens Well its better than using vi or emacs....10:15.42 
tor8 certainly, if you're not used to either :)10:15.54 
chrisl emacs is evil, at least vi is just deranged.......10:16.45 
kens Well gitpad has installed itself, but doesn't do anything useful10:19.27 
tor8 kens: I think you need to set your core.editor to it as well10:19.45 
kens Yeah, I just can't find out how10:20.02 
tor8 git config core.editor "c:/program files/wherever/gitpad.exe" ?10:20.31 
  or am I misunderstanding your question?10:20.59 
kens Gitpad has set itelf up in 'AppData' and added an environment variable EDITOR which begins with a ~10:21.17 
  So its obviously not a windows command10:21.24 
  But if I do git confgi core.editor EDITOR it doesn't work either10:21.44 
tor8 git config --unset core.editor10:21.57 
kens Nope straight back to command prompt10:22.55 
  "sucessfully rebased..."10:23.03 
tor8 did you start a new command prompt, so the gitpad EDITOR setting has taken effect?10:23.42 
kens Yes10:23.54 
tor8 grasping at straws here...10:23.56 
  and there is no more core.editor config setting?10:24.16 
kens I just reset the core.editor to the GitPad executable.10:24.39 
chrisl Is there a global core.editor setting?10:24.52 
kens Now it says C;/Program: No such file or directory10:24.58 
  Sio its getting confused by spaes in filenames10:25.08 
  Which is pretty crap since its a Windows app I presume10:25.24 
  Trying to launch notepad10:25.31 
tor8 kens: hm, I can't get gitpad.exe to work either...10:25.44 
kens Well at least its not just me10:25.58 
  OK if I set git config to vi it works.10:26.27 
  I'll struggle with that for now.10:26.35 
  SO I leave the *initial* commit as pick and change the later ones to squash ?10:26.59 
tor8 kens: you could probably get an msys binary for nano or pico or one of those other notepad-like editors :)10:27.00 
kens nano would be OK if I could find it.10:27.14 
tor8 kens: yes, the first of your commit should be pick and the following ones squash10:27.21 
kens Slowly doing that now10:27.41 
tor8 then it pops back into the editor to let you edit the commit message10:27.42 
kens Seems to be a reasonably usable version of vi, though I don't think much of the syntax coloring10:28.42 
chrisl It's probably vim10:29.35 
tor8 kens: I think it's vim.10:29.43 
kens It may be10:29.53 
tor8 which thankfully allows cursor keys :)10:30.06 
kens Having to press 'esc' puzzled me for a bit10:30.07 
  it si now doing something, I don't know what10:30.19 
  OK new file to edit with all the commit messages10:31.08 
  Well, again its doign something10:34.53 
  ANd it seems to be complete10:34.59 
  Yay, only one commit now.10:35.10 
  OK so how to get that back into master nad push it ?10:35.19 
tor8 hopefully the one you wanted :)10:35.19 
kens tor8 I hope so, but I'm ceasing to care...10:35.33 
tor8 kens: are you on a separate branch?10:35.34 
kens yes10:35.42 
Robin_Watts kens: git checkout master10:35.54 
  git rebase other_branch10:36.01 
tor8 kens: checkout the master branch (git checkout master) then pull in the other branch (git rebase my-other-branch)10:36.07 
Robin_Watts plop10:36.24 
kens Done all that.10:36.25 
Robin_Watts and git logg should show master and the new branch all being the same ?10:36.41 
kens Hmm I think so10:36.50 
Robin_Watts (HEAD, master, new_branch)10:36.57 
  THen git push.10:37.11 
kens HEAD new branch master10:37.12 
Robin_Watts and if you want to be neat: git branch -D new_branch10:37.31 
tor8 kens: you can then get rid of the branch with "git branch -D old_br....what robin just said :)10:37.39 
kens lots of echos, but I'm grateful, thnks10:37.55 
Robin_Watts tor8: We should just nominate one of us to answer a query in future :)10:38.01 
tor8 Robin_Watts: but we usually don't pay attention to irc at the same time!10:38.21 
kens And the cluster is running, lets hope its all OK !10:38.26 
  Looked at the commit and it seems to have everything in there10:41.15 
  I'm going to keep the branch until I see the cluster result10:41.36 
Robin_Watts The 'branch' is merely a record that says "the head of this branch is hash xxxxxx"10:42.25 
  and master and HEAD are both records that point to the same hash number.10:43.06 
kens But if I undo the commit, the branch will still point to the altered code, correct ?10:43.44 
  Seems like an easy way to keep a pointer until I'm sure its OK10:43.53 
Robin_Watts sure.10:43.59 
ghostgum ghostscript files weren't completely removed. They are in ~ghost/old_mirror. These are accessible only by the ghost account.10:57.54 
Robin_Watts Could we get shelley to look at bug 693025 as a bountiable thing ?11:58.20 
kens which one is that ?11:58.36 
Robin_Watts zenikos jbig2dec fixes.11:59.05 
kens OK then that makes good sense11:59.16 
Robin_Watts IME, many of his fixes are spot on, but many of them actually just patch around a deeper problem.11:59.30 
kens check with henry but I would think it would be oK11:59.54 
Robin_Watts so taking them on or not requires a certain understanding of the underlying code - and I don't have that for jbig2dec.12:00.03 
  kens: sure.12:00.23 
sebras tor8 Robin_Watts: did you find the type3-bug eventually?12:07.47 
Robin_Watts sebras: Nope. I didn't look.12:11.05 
  tor8: Got a couple of minutes?12:13.42 
tor8 Robin_Watts: yes.12:15.05 
Robin_Watts The idea about making mupdf not have to load everything in streams into memory...12:15.27 
tor8 talking about the content streams?12:15.44 
Robin_Watts The problem with that is that we might get competing seeks on the underlying files, right?12:15.52 
  Yes, exactly.12:15.54 
  I believe the pattern of use we might see is that we'll be part way through reading/executing a content stream, and then we'll have to zap off somewhere else to read a resource object.12:17.02 
tor8 quite12:18.23 
Robin_Watts What we need to be able to do is to store the stream pointer before we move off elsewhere, and to put it back when we come back (i.e. ftell, fseek).12:18.27 
  I had an idea about how to get that done automatically for us for streams, but it's just dawned on me that objects are a problem too.12:18.55 
tor8 and not mess up the internal buffers of the chain of filters12:18.56 
  yeah, any seeking of the underlying file while there is a stack of filters reading on top is problematic12:19.38 
Robin_Watts I had figured that we could change the fz_open_null function to read and store the original stream_pos. and then fseek back to it in close_null.12:19.56 
tor8 one solution would be to have each filter store the 'offset' of its chain12:19.58 
Robin_Watts Yes.12:20.05 
tor8 so every read would start with an offset or seek12:20.09 
  that should solve it most elegantly I think12:20.18 
Robin_Watts I'd be tempted to roll the requested offset into the read.12:20.32 
tor8 then we can push and pop and read anywhere with nested chains etc12:20.40 
  so, pread(2) basically?12:20.53 
Robin_Watts possibly :)12:21.01 
tor8 as long as we don't do it from multiple threads we should be re-entrant at least12:21.21 
  or whatever the word I'm looking for is12:21.32 
Robin_Watts If we are prepared to change the fz_stream structure, then there are other things I'd like to do to it too.12:21.47 
tor8 one hitch though, the filters can't seek backwards12:21.51 
Robin_Watts Filters will never need to.12:22.05 
tor8 the encryption, null and/or copy filters might need to (but I'm not sure)12:22.53 
  what other changes do you want to do?12:23.00 
Robin_Watts An alternative approach would be to wrap the initial stream into one that can be cloned.12:23.18 
  or wrap it in a 'cloner' stream when we make a filter out of it.12:24.20 
  The cloner would do nothing but ensure that it always seek/reads and used its local storage.12:24.46 
  That could be achieved with no changes to the stream functions/structures at all, I think.12:25.12 
  In fact, the null stream may be perfectly placed to do that already.12:25.46 
  Other changes?12:26.37 
  It offends my sensibilities that for every stream we a) have a 4K buffer, and b) have to do 2 mallocs.12:27.00 
  Rather than having a separate 'state' pointer to a second block, I'd rather switch to doing a 'derived class' thing where every fz_stream_blah starts with an fz_stream.12:28.24 
  BUT... there may be a strong argument to be made for not changing the structure if we can get away with it, and updating the null filter may offer us a cheap(free) way of getting around this problem.12:29.05 
tor8 2 mallocs? there's only one malloc...12:30.05 
  oh, you mean the state thing12:30.20 
Robin_Watts Yes.12:30.23 
  I mean have the state and the stream in the same block.12:30.35 
tor8 doesn't bother me one bit. streams are not numerous.12:30.38 
Robin_Watts Right. It's not a showstopper by any means.12:31.07 
  but if we were changing it anyway...12:31.19 
tor8 subclassing with embedded structs I consider an evil but sometimes worthwhile hack :)12:31.23 
Robin_Watts but I hope that by tweaking the null device we can avoid any nasty changes. I'll give it a whirl.12:31.44 
tor8 and the void* userdata thing makes it trivial for clients to extend12:31.45 
  and makes the binary api a bit more stable12:32.03 
  if we are to change it, I think making read() take an explicit offset would make it more robust against mistakes with the filter pushing and popping12:32.40 
  not sure how you envision the cloner / null device to work, but I look forward to see what you come up with12:33.21 
Robin_Watts Every filter is based on the 'null' device already.12:33.41 
  Whenever the filter sucks data, the null device calls the underlying stream to suck data into the null devices 4K buffer.12:34.09 
tor8 we start every stream with the null filter just to set the EOF to the stream length12:34.10 
Robin_Watts So if the null device keeps track of the desired position in the underlying file, and always 'seek/reads' rather than just reading, we'll always get the data we want.12:34.55 
tor8 so turn the null device into said clone device that remembers the offset and allows multiple copies on top. right. I see what you're getting at.12:35.09 
  allows multiple null streams on top of a base stream, i.e.12:35.28 
Robin_Watts "allows multiple copies on top" = something we get for free.12:35.42 
tor8 actually, that's a pretty smart idea :) wish I'd come up with it!12:35.44 
Robin_Watts :)12:36.00 
tor8 that lets us seek in the underlying stream while filters are still on top12:36.01 
Robin_Watts yes.12:36.13 
  I was worried about introducing a new stream just to do that, but there is one in exactly the right place already :)12:36.36 
tor8 fz_open_null could be extended to take three arguments (chain, offset, length) rather than just the two if you want to make it more clear12:36.36 
Robin_Watts tor8: Yes.12:36.47 
tor8 it's in the internal header so no worries there12:37.03 
Robin_Watts Either that or it needs to read chain->pos, and we need to fz_seek before making an fz_open_null.12:37.13 
  But changing the function is nicer.12:37.22 
tor8 I think changing the function makes it clearer that it isolates the stream and seeking outside its context is 'okay'12:37.53 
Robin_Watts Oh, wait... fz_open_null is called from pdf_open_filter12:37.54 
  Hmm. I mean it's called from other places.12:38.27 
tor8 Robin_Watts: with icky fragile bits of code to make sure the stream is at the right offset12:38.29 
Robin_Watts so they would need to change a bit.12:38.37 
  but that may be neater overall.12:38.44 
tor8 Robin_Watts: that's where you want the changes isn't it?12:38.46 
Robin_Watts Yes. I'll bash on this this afternoon and upload a patch for your comments.12:39.37 
tor8 pdf_open_inline_stream is the only one you have to worry about12:39.38 
  since that's used for inline image data streams12:39.48 
Robin_Watts stream->pos is the offset of the start of the buffer? or the offset of the current point?12:40.38 
  Ah, fz_tell :)12:41.07 
  Well, it builds. I'll test it after lunch, so I can have 30 minutes of happiness :)12:45.59 
tor8 Robin_Watts: it should be the offset of the end of the buffer IIRC12:46.12 
kens Hmm, still have to work on freeing CIDFont resources :-(12:51.06 
spencer Hey all, I'm trying to use the @filename switch on windows, but ghostscript crashes. Can I mix it with other cmd line args, or do I have to put all args into the file?13:10.55 
kens I believe you cna m ix and match13:11.39 
  but I've never tried13:11.44 
spencer Hmm, then why would it be crashing? I'm using it to get around the Windows error 87 problem.13:12.21 
kens don't know.13:12.36 
  Woudl have to debug it13:12.41 
spencer So I bumped into an unused portion of the code base?13:13.22 
kens Perhaps, or perhaps its 'something else'13:13.36 
  IIRC you are using Windows 713:13.42 
spencer Win 7 64 bit and a Win XP 32 bit13:13.59 
kens Both the same ?13:14.06 
spencer Yup13:14.12 
kens When you say 'crash' what exactly do you get ?13:14.23 
spencer Pop up message saying that gswin32c has crashed. I can give you the dump windows attaches.13:15.06 
kens NO, that's fine13:15.14 
  Just sometimes people describe erors messages as 'crash'13:15.28 
  I think the best thing is to open a bug report13:15.51 
spencer Hmm, just ran a test and the option does work if I strip out practically all the cmd line args13:16.15 
kens There you can attach your command line and a file to exhibit the problem13:16.21 
spencer I must have something off in the cmd line13:16.28 
kens spencer : then it sounds like you ahev come across some incompatible opption13:16.38 
  Obviously it shouldn't crash though13:16.49 
  So still worth opening a bug report13:17.07 
spencer I'll create a bug report so it's documented then13:17.11 
  It might also be the ordering of the, I hadn't thought of that13:17.54 
kens well it still shoudn't crash....13:20.21 
spencer bug report created, I need a work around for this now though, so I'm going to investigate having all of the cmd args inside the @file.13:35.24 
kens Makes sense, thanks for the report13:35.35 
spencer Question though, since gs is handling the contents of the @file, how does it parse cmd line args?13:37.17 
  I had been doing the parsing using a modified version of the envoy library13:38.00 
kens @file is a command line argument13:40.47 
  So its just another argument (at least, as far as I know)13:41.00 
chrisl spencer: can you get around the problem by putting your options in a Postcript file?13:41.07 
  The problem is (it seems) GS is trying to open the options file before IO has been initialised - no idea how we'd get around that.......13:41.54 
spencer chrisl: I haven't tried that. I'm not sure how all of the options would translate into postscript. You can check the bug 693026 for the full set13:43.28 
chrisl spencer: you haven't stated what's in your @tmpfile13:44.02 
spencer A list of pdf file names13:44.12 
  It's dynamically generated, and I tried with one file name and the whole set13:44.38 
chrisl Okay, so instead of putting that list in the @tmpfile, you could create a with contents like: 
spencer That might work, I'll try it in a little bit13:48.41 
chrisl spencer: basically, that all that GS does internally with the list of file names you give on the command line.13:49.25 
Robin_Watts mvrhel_laptop: Morning13:53.11 
  What's the difference between tiffsep and tiffsep1? Just that tiffsep1 is 1bpp ?13:53.48 
  1bpc, even.13:53.55 
  Would a neater solution not be to have a -dBitsPerComponent option on tiffsep ?13:54.30 
chrisl Robin_Watts: mainly, it also doesn't produce a contone proof13:54.48 
  Robin_Watts: using a option is possibly more viable if it's a planar device? (guessing)13:55.41 
Robin_Watts chrisl: That was my thought.13:55.53 looks almost unreadable on a kindle :(13:56.30 
chrisl Because of the grays?13:56.45 
Robin_Watts yes. It'd be fine in black.13:56.59 
mvrhel_laptop good morning13:57.11 
mace Robin_Watts: vs 
mvrhel_laptop Robin_Watts: to tiffsep1 is just like teffsep, except the composite image is not create, and after rendering to contone it is halftoned13:58.14 
  kind of odd13:58.17 
Robin_Watts mace: MUCH better on the kindle.13:59.44 
  and I have to say, that personally, I prefer it on chrome too.13:59.56 
  Less washed out.14:00.10 
mace fine by me, makes for a faster download ;-)14:00.57 
Robin_Watts Anyone else here have any opinions on vs ?14:01.41 
mace on the other hand the 20 bytes saved by that change are more than going to get eaten up by the change of the big buttons from jpeg to png :/14:01.45 
mvrhel_laptop Robin_Watts: not sure if you the whole tiffsep1 stuff is of interest to you. It would be pretty easy for me to move it over to planar since I just did the other 2 sep devices. 14:02.29 
Robin_Watts mvrhel_laptop: I have to say that I'd prefer to concentrate on mupdf and/or gs scan conversion.14:03.01 
  but if henrys wants me to look at it, then so be it.14:03.12 
mvrhel_laptop Robin_Watts: I think that is a better use of you time14:03.15 
Robin_Watts It did strike me that it might be easier to just add a -dBitsPerComponent option (or something similar) to tiffsep and lose tiffsep1 entirely.14:03.50 
mvrhel_laptop dont spend any time on it until we talk to henry14:03.52 
  Robin_Watts: yes I will think about that a bit14:04.09 
Robin_Watts Seems silly to maintain 2 separate devices that basically do the same thing to me.14:04.11 
kens for some stuff the is OK but for most I prefer the black text14:04.17 
chrisl Robin_Watts, mvrhel_laptop: I'm guess it was done as two devices because of the post-process halftone in tiffsep114:05.02 
Robin_Watts chrisl: Yes. But now we can halftone as part of the core, that may no longer be the overriding factor.14:09.21 
chrisl Robin_Watts: That's what I meant when I said making it planar probably removes the need14:10.02 
mvrhel_laptop right14:10.41 
Robin_Watts tor8: ping15:57.48 
  For type3 fonts and for patterns we load the contents into a buffer.15:58.18 
  Should we keep doing that, or should they go to read from the file too ?15:58.35 
tor8 Robin_Watts: I'd keep them in buffer for now.16:20.23 
Robin_Watts That may not be trivial.16:20.43 
tor8 Oh? open_buffer works does it not?16:21.03 
Robin_Watts Currently I'm changing them to be pdf_obj *'s rather than fz_buffer *'s, but we can revert that if required.16:21.41 
tor8 alright16:24.37 
  I don't have a convincing argument for either case :)16:25.00 
Robin_Watts TBH having one done one way and one done the other is probably not hard.16:25.20 
tor8 I just figured leaving them as buffers would mean less things to change16:25.40 
Robin_Watts but it requires me to duplicate a function and edit 2 copies.16:25.43 
tor8 or fewer as it were16:25.55 
Robin_Watts At the moment I'm changing pdf_run_buffer to be pdf_run_contents where it takes an fz_obj *contents rather than an fz_buffer *contents.16:26.20 
tor8 not a fz_stream then?16:27.09 
Robin_Watts pdf_run_contents will make a stream from the obj.16:27.26 
  (I'm changing my mind here as I go - don't expect consistency :) )16:27.45 
tor8 ah wait, we already have a pdf_run_stream16:27.52 
  right, so change the run_buffer to whatever fits best16:28.02 
Robin_Watts tea16:30.54 
  tor8: Can you remember by pdf_open_image_stream is in mupdf-internal.h (rather than being static)16:51.50 
tor8 no...16:52.20 
Robin_Watts ok.16:52.33 
  tor8: Cor.16:55.48 
  I get locking warnings (which are to be expected), but it works.16:56.00 
tor8 sweet!16:56.07 
Robin_Watts (on my exhaustive 1 file, 2 page test :) )16:56.25 
  tor8: ping 18:12.43 
  This change has put me into locking hell.18:13.03 
  It used to be that we'd take the file lock before we did any seeks on the main file, and release the lock afterwards.18:14.13 
  Hmm. poorly expressed. Let me try again.18:14.29 
  It used to be that we'd take the file lock before we did any seeks on the file handle, and released the lock once we'd finished all the reads based upon that seek.18:14.58 
  We are now reading from the file during interpretation, so when we try to perform actions that involve fetching resources/resolving indirections etc, those things try to access the file too, and the locking gets confused.18:18.09 
  One simple solution would be to make the FZ_FILE_LOCK recurseive.18:18.35 
  (or recursive)18:18.41 
  but I'm wondering whether we can safely just remove the FZ_FILE_LOCK entirely.18:19.22 
tor8 Robin_Watts: silly question, but why do we even need the lock? to prevent accidents when idiot clients try to use the file from mroe than one thread?18:19.33 
sebras Robin_Watts: why can't you just release the lock before doing the fetching of resources?18:19.50 
tor8 cocking up threading by accessing the document from more than one thread is going to fail miserably one way or another anyway, so I don't really see the point of the file lock18:20.00 
sebras and take it again afterwards (i.e. why keep the file locked?).18:20.12 
Robin_Watts sebras: I could, but that would produce a plethora of lock/unlocks throughout the code.18:20.17 
  sebras: Currently that's done pretty much automatically by the stream code.18:20.37 
sebras wouldn't the resource fetching be located in just one place..?18:20.56 
Robin_Watts no. We can need to access the file whenever someone does a: pdf_is_int etc.18:21.23 
tor8 all file access should still happen in only the main thread. unless you wanted the image resource decoding callbacks?18:21.30 
Robin_Watts tor8: Originally, I think I'd hoped that the file lock would allow us to get away with doing stuff in 2 threads (albeit inefficiently).18:22.23 
  but I think that's gone by the by.18:22.37 
  Decoding images from files might be nice to aspire to one day.18:23.07 
tor8 well, no need to complicate today's work by worrying about that, IMO. just rip out the file lock and mandate all file access must be in one thread. we can figure out how to decode images from files in a separate thread another day. you already save them compressed in the fz_image struct and I think that's good enough for quite some time now.18:24.26 
Robin_Watts Part of the attraction of having the lock is that the debugging then checks that mandate.18:26.19 
  but you may well be right.18:26.29 
tor8 anyone using the high level api:s won't ever see the file (hopefully)18:26.55 
Robin_Watts tor8: Well, I think we're going to be expecting people to use fz_open_document_with_stream at some point, right?18:27.25 
tor8 assert(get_current_thread == original_thread) would be nice to have though :)18:27.37 
  Robin_Watts: yeah, especially for the thing we discussed yesterday with appending data to it18:27.59 
Robin_Watts tor8: That's what a recursive lock would give us nicely.18:28.05 
tor8 but the locks should be per file then IMO and not just a global 'all files are locked now' in the context18:28.24 
  but file locks for multithreading, I dunno, it just stinks. files aren't a multithreaded resource.18:28.47 
Robin_Watts I can use the FZ_LOCK_FILE to implement a recursive per file lock.18:29.20 
tor8 now a threadsafe "readp" call for files, that might work better.18:29.29 
  but then you want a different api than open/read/close for data access altogether.18:30.02 
Robin_Watts Actually, no I can't.18:31.25 
  I need a lock + a semaphore (or a mutex or something equivalent)18:31.50 
  Do we need a lock to be able to safely implement the appending stream thing ?18:32.17 
  Do you forsee us using multiple documents with a single context?18:33.29 
  (I don't, I think)18:33.45 
  If not, then we have one file lock per document.18:33.58 
  I'm going to rip out the file lock entirely (well, leave it in there, but unusued).18:34.57 
  And we can reuse it to do the appending stream thing.18:35.06 
kens Robin_Watts : tor8 can you answer the email about 'Linear PDF' please ? As its MuPDF18:41.49 
  I'm sure the answer is 'yes' but ti might be ebst to some from one of you18:42.02 
Robin_Watts mace: miles likes the black text too.18:42.55 
kens God my typing is bad tonight18:42.58 
Robin_Watts kens: I will answer.18:44.06 
kens Thanks18:44.13 
mvrhel Gigs: you around?19:03.40 
mace Robin_Watts: ok i'll switch to that21:11.09 
mvrhel hi marcosw: how has the show been?"21:23.52 
  ok so still a few DeviceN sep planar issues...21:30.12 
  we will need to get the customer an update probably early next week21:30.25 
  alexcher: are you around?22:29.18 
  alexcher: I just gave you a bug.22:39.24 
  If you could take a lok at it, I would appreciate it22:39.37 
  fairly certain it is a PDF interpreter issue22:39.49 
 Forward 1 day (to 2012/05/05)>>>