| <<<Back 1 day (to 2013/07/07) | 2013/07/08 |
kens | tor8 Robin_Watts_ there's a couple of new bugs for MuPDF on stack overflow. This one might merit an answer: | 08:36.20 |
| http://stackoverflow.com/questions/17511769/error-while-rendering-pdf-using-mupdf | 08:36.20 |
| This one is on hold, and maybe doesn't but it woul dbe good if you could at least take a quick look in case its something obvious: | 08:36.20 |
| http://stackoverflow.com/questions/17517927/mupdf-doesnt-work | 08:36.20 |
Robin_Watts_ | kens: I've replied to the first. I am minded to leave the second as closed. | 09:20.33 |
kens | Robin_Watts_ : I thought that might be the case | 09:20.44 |
Robin_Watts_ | Neither really has enough information to answer them, afaict. | 09:20.53 |
kens | Probably true, SO questions rarely do | 09:21.08 |
sebras | kens: actually it's the same here on irc, but people sometimes stick around long enough for you (or me) to ask questions that paint the bigger picture. | 09:25.06 |
kens | Indeed | 09:25.13 |
kens2 | Robin_Watts_ : how do I squash a bunch oof commits from a local branch into my master ? | 10:42.55 |
Robin_Watts_ | kens2: change onto your local branch. | 10:43.19 |
| git rebase master | 10:43.23 |
kens2 | OK | 10:43.26 |
Robin_Watts_ | That will move your current branch up so it's all sat on the end of the master. | 10:43.44 |
kens2 | done | 10:43.49 |
Robin_Watts_ | All you then need to do is to change 'master' so that instead of pointing to a point back from the tip, that it now points to the tip. | 10:44.10 |
| Do you have any other changes in your tree ? | 10:44.17 |
kens2 | Only a stashed interim fix | 10:44.28 |
Robin_Watts_ | but it's stashed, so that's not in your tree, great. | 10:44.41 |
| So... git checkout master | 10:44.49 |
kens2 | Yes, that much I know :-) | 10:44.51 |
Robin_Watts_ | then git reset --hard HASH | 10:44.59 |
kens2 | hash is the branch commit ? | 10:45.16 |
Robin_Watts_ | where HASH is the hash or the name of the branch that points to the tip. | 10:45.18 |
| yes. | 10:45.21 |
kens2 | Hmm, OK | 10:45.43 |
| seemed to work | 10:45.48 |
| I was exepcting to squash in there somewhere | 10:46.05 |
Robin_Watts_ | squashing is where you take a series of commits and compress them into one. | 10:46.31 |
kens2 | Ah, I am now 5 commits ahead of origin | 10:46.38 |
Robin_Watts_ | Were you wanting to squash all the commits into 1 ? | 10:46.51 |
kens2 | Yes | 10:46.54 |
Robin_Watts_ | OK, so: git rebase -i HEAD~10 | 10:47.04 |
| That will open an editor window with the top 10 commits showing. | 10:47.16 |
| Unless you've set it to something different it will probably be vi. Is that OK ? | 10:47.46 |
kens2 | I don't think its vi.... | 10:47.57 |
| Ah, its VIM, no better :-( | 10:48.07 |
Robin_Watts_ | OK, can you get out of it? | 10:48.18 |
| Esc :q RETURN | 10:48.24 |
kens2 | Well I can always quit :-) | 10:48.26 |
Robin_Watts_ | ok. do so. | 10:48.31 |
kens2 | Hmm succesfully rebased it says | 10:48.43 |
| But I geuss that did nothing | 10:49.00 |
Robin_Watts_ | kens; Right. If you made no changes to the file, the "successful rebase" should be a nop. | 10:49.03 |
| export EDITOR=<your favorite editor here> | 10:49.26 |
kens2 | Lets try write | 10:49.36 |
Robin_Watts_ | Is 'write' on your path? | 10:49.45 |
kens2 | Should be | 10:49.57 |
Robin_Watts_ | Mine is set to "emacs" and emacs is on my path. | 10:49.57 |
| OK. Obviously you can test whether it's on your path by typing write and hitting return :) | 10:50.20 |
| Assuming it is, and you're happy, try git rebase -i HEAD~10 again. | 10:50.36 |
kens2 | Its is and it works. rebase still uses VIM | 10:50.56 |
Robin_Watts_ | exit again | 10:51.24 |
| echo $EDITOR | 10:51.27 |
kens2 | write | 10:51.41 |
| :-( | 10:51.45 |
| I'm guessing I should change a config file for permanent effect | 10:52.15 |
| and possibly even temporary effect | 10:52.23 |
Robin_Watts_ | git config core.editor="write" | 10:52.55 |
kens2 | invalid key: core.editor=write | 10:53.38 |
tor8 | git config --global core.editor "c:\program files\windows nt\accessories\write.exe" | 10:53.51 |
Robin_Watts_ | wot tor8 said :) | 10:54.04 |
kens2 | I'll have to find the right path, just a moment | 10:54.31 |
Robin_Watts_ | kens2: which write | 10:55.35 |
kens2 | THe one I have here :-) | 10:55.44 |
Robin_Watts_ | says /c/Windows/system32/write | 10:55.48 |
| no, which is a command. It's a very useful command that tells you where on the path things are. | 10:56.02 |
kens2 | OK soreted that, no errors, rebase still uses VIM | 10:57.01 |
| git config -l shows core.editor correctly set | 10:58.02 |
| ah, core.editor=vi as well :-O | 10:58.59 |
| seems I have 2 entries | 10:59.17 |
Robin_Watts_ | kens2: Same command as tor8 gave you, without the --global | 10:59.55 |
kens2 | OK | 11:00.00 |
Robin_Watts_ | You've obviously got a global and a local setting. | 11:00.16 |
kens2 | I was guessing that yes | 11:00.30 |
Robin_Watts_ | You could just delete the local one, but I can't remember the command offhand for that :) | 11:00.34 |
kens2 | OK 2 settings both the same. I think --unset is what you need | 11:00.48 |
| aha, now it works :-) | 11:01.08 |
Robin_Watts_ | So, you should see a list of 10 commits. | 11:01.26 |
kens2 | Yes | 11:01.30 |
Robin_Watts_ | The first word on each line is 'pick'. | 11:01.36 |
kens2 | last 5 are mine | 11:01.37 |
| Yes | 11:01.46 |
Robin_Watts_ | This means that when you exit the editor, git will 'pick' each of those commits. i.e. nothing will change. | 11:02.01 |
kens2 | OK | 11:02.07 |
Robin_Watts_ | What you want to do is to change 'pick' to 'squash' for the last 4 commits. | 11:02.17 |
kens2 | So I can change the last ones to squash ? | 11:02.18 |
Robin_Watts_ | git will then squash the last 5 together, and present you with a window to edit the new merged commit message in. | 11:02.50 |
kens2 | Fair enough done that. OK so I exit the editor now.... | 11:03.05 |
Robin_Watts_ | yes | 11:03.11 |
kens2 | Well it says it was succesful, let me see | 11:03.37 |
| Ah, but no window to edit the commit | 11:03.51 |
| Nope, no changes | 11:04.06 |
| I suspect I can't use a Windows editor for this | 11:04.24 |
Robin_Watts_ | Michael uses notpad2 | 11:04.35 |
kens2 | :-( | 11:04.42 |
Robin_Watts_ | So I'm sure it can work. | 11:04.46 |
| Do it again, and look at what the path of the file given is? | 11:05.03 |
| When you saved the file back did it add .txt onto the name or something braindead? | 11:05.28 |
kens2 | I don't think that's the problem. As soon as the editor starts its says "succefully rebased" | 11:05.30 |
| And yes I think it does add .txt | 11:05.42 |
Robin_Watts_ | kens2: It sounds to me like it's not seeing the file once you save it back. | 11:05.45 |
| so it follows the original instructions (i.e. a file full of picks) and nothing changes. | 11:06.03 |
| So the .txt is the problem. | 11:06.07 |
| Can you persuade it to save without doing that? | 11:06.21 |
kens2 | It seems not, I'll kick it again | 11:06.35 |
| But... I do see it exiting the rebase while the editor opens | 11:07.02 |
| Possibly it is releasing the file ? | 11:07.11 |
Robin_Watts_ | kens2: Maybe. | 11:07.21 |
| What editor do you use on unix ? | 11:07.34 |
kens2 | nano | 11:07.41 |
| Which I don't have in msys | 11:07.49 |
Robin_Watts_ | http://www.nano-editor.org/download.php | 11:08.08 |
kens2 | Notepad works better but screws up the line endings | 11:08.57 |
Robin_Watts_ | right. Michael uses notpad2, which I think is better at that. | 11:09.49 |
| but if I was you I'd just download nano for windows - at least we know that will work, and be consistent across platforms. | 11:10.21 |
kens2 | I don't actually like nano either.... | 11:10.35 |
Robin_Watts_ | kens2: I like 'Zap'. I make do with emacs. | 11:11.03 |
kens2 | Grr and notepad2 uses the 7zip compressor.... | 11:11.17 |
Robin_Watts_ | brackets looked interesting last time I looked. | 11:11.23 |
kens2 | great zonealarm reckons notepad2 is a malicious program.... | 11:15.55 |
kens2 | will struggle with vi | 11:17.25 |
| OK should the last commit on origin/mast be included ? It seems to be | 11:19.53 |
Robin_Watts_ | kens2: We said rebase -i HEAD~10 | 11:20.19 |
| That means it will show the last 10 commits. | 11:20.25 |
kens2 | Right, but I mean after doing the edit | 11:20.34 |
| I now get the opportunity for a commit message | 11:20.43 |
Robin_Watts_ | kens2: You only changed the last *4* lines to squash, right? | 11:21.04 |
kens2 | Robin_Watts_ : 5, because I want the last 5 commits | 11:21.20 |
Robin_Watts_ | kens: No. | 11:21.28 |
kens2 | But its saying tis a combination of 6 | 11:21.30 |
Robin_Watts_ | You want to squash the last 4 lines into the preceeding commit. | 11:21.43 |
sebras | doesn't wordpad work for you? | 11:21.45 |
Robin_Watts_ | Hence *4* squashes, not 5. | 11:21.55 |
sebras | I seem to recall it doesn't mess up line endings at least. | 11:22.02 |
kens2 | sebras : no | 11:22.04 |
Robin_Watts_ | kens2: so, we need to start again. | 11:22.12 |
kens2 | Roq OK so how can I abort this halfway ? | 11:22.14 |
| Robin_Watts_ | 11:22.18 |
Robin_Watts_ | save the file and exit the editor, the rebase will finish. | 11:22.32 |
kens2 | ah OK | 11:22.37 |
Robin_Watts_ | Then rerun the "git reset --hard" command you did before | 11:22.53 |
| That will put the state back to before the rebase. | 11:23.01 |
kens2 | Hmmm OK I htink | 11:23.42 |
| one second | 11:23.46 |
| Yes, thats fine | 11:23.56 |
Robin_Watts_ | Now git --rebase HEAD~10 again | 11:24.06 |
kens2 | Yeah, will be a minute | 11:24.18 |
kens2 | remembers -i | 11:24.54 |
Robin_Watts_ | sorry, yes. | 11:25.01 |
kens2 | OK last 4 edited, the initial one left alone | 11:25.44 |
| That looks better | 11:26.22 |
| well git log looks a bit confusing, but I expect it'll look better after I push the change :-) | 11:33.36 |
sebras | kens2: git commit --amend and fix the message. | 11:33.50 |
kens2 | sebras, the message is OK | 11:33.58 |
| its the confusion of branches and squashes | 11:34.09 |
| lines all over the place | 11:34.14 |
Robin_Watts_ | kens; Well, you should see master pointing to the correct history. | 11:34.24 |
kens2 | Robin_Watts_ : it looks ok (I think), just a little confusing | 11:34.46 |
Robin_Watts_ | And your original branch name pointing to the unsquashed version. | 11:34.47 |
sebras | Robin_Watts_: kens2: btw, you guys have noticed the "fixup" alternative to "squash" in git rebase -i? that's comes really handy when you only want to keep the first commit's commit message. | 11:35.16 |
Robin_Watts_ | sebras: Yes, I use that all the time, but I don't jump right into to explaining it to people. | 11:35.48 |
kens2 | sebras in this case the commit messages weren't useful, I didn't want to wast time writing messgaes if the code didn't work | 11:35.50 |
| and the remaining 4 messages were of the 'lets try this and see what happens' sort | 11:36.15 |
| I wouldn't have done a commit at all, but it semed to be the only way I could do a cluster test with the additional (PostScript) file | 11:36.44 |
sebras | Robin_Watts_: ah. it took me a looong time to notice it. :) | 11:37.17 |
| kens2: ok, nevermind then. :) | 11:37.42 |
kens2 | and now... lunch :-) | 11:38.12 |
Robin_Watts_ | tor8: So, looking forwards... | 11:46.37 |
| Are you happy for us to introduce curl as another thirdparty dependency? | 11:46.54 |
| It seems the easiest way to get a cross platform http fetcher. | 11:47.20 |
tor8 | Robin_Watts_: it would also help for form submission, I reckon | 11:49.15 |
Robin_Watts_ | tor8: ooh, good point. | 11:49.28 |
tor8 | and it seems to be the most standard library around for it, but is it any easier than just naively implementing http over a socket? | 11:49.55 |
Robin_Watts_ | tor8: Yes. | 11:50.11 |
tor8 | I mean, there's a lot of stuff in libcurl that we probably don't ever want to use | 11:50.12 |
sebras | tor8: if we have curl then we coudl also choose not to use $BROWSER in x11... | 11:50.24 |
tor8 | sebras: you mean for http-linked pdf files? | 11:50.44 |
sebras | tor8: exactly. | 11:50.50 |
tor8 | and I haven't looked at the api but if it makes it trivial to write stuff I'm not against having it | 11:50.53 |
| optional or mandatory though? | 11:50.59 |
Robin_Watts_ | tor8: curl has more than we need, but not stupidly much more, AIUI. | 11:51.20 |
sebras | tor8: we could use curl to do an HTTP HEAD and check Content-type. if it is pdf then we download into a memory buffer and render. | 11:51.27 |
| tor8: optional. | 11:51.33 |
tor8 | adding more and more dependencies does get us deeper into security vulnerability territory | 11:51.42 |
Robin_Watts_ | and it keeps our platform independence from threading crap, pretty much. | 11:51.44 |
tor8 | Robin_Watts_: how is building libcurl? gobs and megabytes of source with a bunch of configure crap or a trivial make && install? | 11:52.34 |
Robin_Watts_ | tor8: On windows, it's a simple new project. | 11:52.55 |
| (i.e. a new thing alongside libthirdparty etc) | 11:53.18 |
| was dead easy. | 11:53.24 |
tor8 | I'm thinking whether to bring it in as we did with openssl or as we've done with previous (smaller, saner) thirdparty libraries | 11:53.38 |
sebras | tor8: if you want to pick and choose what files to compile like you do for jpeg, then it is more difficult. | 11:53.41 |
Robin_Watts_ | I'll try linux in a bit, but I don't expect it to be configure and crap. | 11:53.42 |
tor8 | sebras: I don't necessarily care about picking and choosing files, but avoiding their configure stuff is necessary for cross-platform builds | 11:54.23 |
Robin_Watts_ | tor8: There are optional things like SSL support for curl, but we can skip that. | 11:54.36 |
sebras | Robin_Watts_: isn't that used for https? | 11:54.48 |
Robin_Watts_ | and people can add that back if they want. | 11:54.50 |
| sebras: Right. And we won't support https. | 11:55.00 |
sebras | Robin_Watts_: ok. | 11:55.17 |
tor8 | both the openssl and curl stuff *could* be done with pipe() / fork() / exec() | 11:55.34 |
Robin_Watts_ | Given that we may have openssl in there anyway for the digitial signature stuff, maybe we can add that back in. | 11:55.35 |
| tor8: not on windows. | 11:55.49 |
| But the curl dependency is on pdfapp, currently, not on mupdf itself. | 11:56.34 |
| or rather it's pdfapp that depends on curl, not mupdf depending on curl. | 11:56.49 |
tor8 | Robin_Watts_: I would expect a fz_open_http() stream type | 11:57.01 |
Robin_Watts_ | tor8: Indeed. But that's a pdfapp provided class currently. | 11:57.20 |
tor8 | right. but if we pull in curl as a thirdparty dependency, it should move into the core, IMO | 11:57.44 |
Robin_Watts_ | tor8: Currently we have libmupdf and libmupdf-v8. | 11:58.17 |
tor8 | if desired, we could make it optional much like openssl. I'll have to try bashing on the curl build system before I decide. | 11:58.24 |
Robin_Watts_ | Do we want to have libmupdf, libmupdf-curl, libmupdf-v8, libmupdf-curl-v8 ? | 11:58.43 |
tor8 | but going with too many optional features is not a direction I like | 11:58.48 |
| Robin_Watts_: we don't have libmupdf-openssl and libmupdf-openssl-v8 though | 11:59.16 |
sebras | tor8: so openssl is required..? | 11:59.32 |
Robin_Watts_ | Personally, I liked having it external to the core lib, as it emphasises the fact that integrators can hook up their own http fetchers (and stream implementations) without needing to change the code. | 11:59.50 |
tor8 | sebras: it's optional, but either you have it or you don't ... you don't get two separate libs | 11:59.53 |
Robin_Watts_ | s/code/core/ | 11:59.53 |
tor8 | Robin_Watts_: right. so there's another option -- make it a thirdparty lib for the x11/win32 viewers only | 12:00.33 |
| and use a system provided one. much like we do for libX11 | 12:00.49 |
Robin_Watts_ | tor8: Right, that's actually the situation I have here. | 12:01.18 |
tor8 | I'm happy to go along with that for now | 12:01.34 |
Robin_Watts_ | So it's not a core dependency, it's an app dependency. | 12:01.49 |
tor8 | it does mean an explosion of win32 project targets doesn't it? | 12:01.59 |
| if it's optional | 12:02.07 |
Robin_Watts_ | tor8: No, I have a mupdf-curl target. | 12:02.17 |
| it's not in the configuration list. | 12:02.23 |
| akin to mupdf-v8 | 12:02.39 |
tor8 | mupdf-curl and mupdf-curl-v8 both? | 12:02.41 |
Robin_Watts_ | currently I don't have a mupdf-curl-v8, but I could. | 12:02.50 |
tor8 | right. that's what I mean by having an explosion of targets (not configurations) | 12:03.06 |
Robin_Watts_ | Right. | 12:03.12 |
tor8 | mupdf-bare and mupdf-bells-and-whistles targets for win32 | 12:03.43 |
| either you have only the source as checked out of git, or all the thirdparty binaries unzipped | 12:04.08 |
Robin_Watts_ | tor8: I could cope with that. | 12:04.21 |
tor8 | v8 and openssl and curl (and eventually freeglut) | 12:04.22 |
| to keep down the number of projects that need maintaining. I'll leave the decision up to you and paul since you're the ones who have to maintain the project files :) | 12:04.53 |
Robin_Watts_ | For things which are easy to just download into thirdparty, then there should be no problems with making them required for a bells and whistles build. | 12:05.42 |
| I mean, disc space is cheap, right? | 12:05.50 |
| rebuilding v8 is a bit of a git, but we provide built versions. | 12:06.28 |
| rebuilding openssl might be tricky, so again, we should provide build versions. | 12:06.51 |
tor8 | if building curl from source, we can drop it in as a regular git submodule | 12:07.22 |
Robin_Watts_ | curl seems to more in line with the other thirdparty libs (like jpeg etc) | 12:07.27 |
| tor8: Right. That's what I'll try after lunch. | 12:07.36 |
| along with making linux builds work with it. | 12:07.56 |
henrys | so if you are going to use curl miles has to update the contract right⦠provided that the above copyright notice and this permission notice appear in all copiesâ¦. same as the other libraries. | 13:06.32 |
Robin_Watts_ | henrys: It's only an issue if people pull in curl to their apps. | 13:07.35 |
henrys | haven't looked at other libraries. | 13:07.48 |
Robin_Watts_ | It's not a dependency for the core. | 13:07.54 |
| But if you want to use the example http fetcher, then either you need to pull in curl, or you need to rewrite the fetching bits. | 13:08.31 |
henrys | oh okay I thought we'd just have it in there and everything would just work. | 13:09.16 |
| but if it is as you say we'll leave the contract alone. | 13:10.05 |
Robin_Watts_ | henrys: We were discussing whether to have it as a core dependency or not this morning. | 13:10.35 |
| I think the consensus is to have it as an app dependency for now. | 13:10.49 |
henrys | argh too many fuzzing bugs ⦠oh well | 14:46.24 |
| bbiab | 14:49.48 |
molqr | is there a way to select text in mupdf? | 15:09.02 |
Robin_Watts_ | molqr: Yes. | 15:10.21 |
| What platform? | 15:10.28 |
| Right hand mouse drag, I think. | 15:10.35 |
molqr | Robin_Watts_: thanks. linux. | 15:10.44 |
sebras | moqlr: and if you want the text to end up in the clipboard then CTRL-c ought to work as expected after highlighting. | 15:52.46 |
kens | goodnight all | 16:21.29 |
henrys | robin_watts_mac:travelling? | 16:46.35 |
| marcosw: so the plotter printed it on separate sheets? | 17:08.03 |
Robin_Watts_ | henrys: no, just turned the mac on :) | 17:34.47 |
| tor8: ping | 17:38.16 |
| Is there an easy way to do an alert box in x11 I wonder. | 17:38.53 |
sebras | Robin_Watts_: we have the searchbox. | 17:45.58 |
| Robin_Watts_: I think currently we just print to stderr. | 17:46.41 |
Robin_Watts_ | we do. | 17:46.47 |
sebras | Robin_Watts_: e.g. when the search phrase can not be found. | 17:46.50 |
Robin_Watts_ | the searchbox may be an idea. | 17:46.56 |
sebras | Robin_Watts_: well, something like it perhaps. | 17:47.04 |
| Robin_Watts_: in anticipation of the GTK-viewer. ;) | 17:47.15 |
Robin_Watts_ | sebras: I have progressive stuff working on X11 too, but on windows I pop up an alert box to say "this page is incomplete". On X11, it just retries instantly. | 17:48.41 |
sebras | Robin_Watts_: I think just retrying is good enough for X11 OTOH. | 17:49.55 |
Robin_Watts_ | sebras: Actually, just retrying isn't correct. | 17:50.20 |
sebras | Robin_Watts_: no? | 17:50.29 |
| Robin_Watts_: if the page data is never delivered I agree with you. | 17:50.50 |
Robin_Watts_ | If we try to open the file, it'll retry repeatedly until the first page arrives. | 17:50.58 |
sebras | but the normal case surely must be that all data arrives eventually. | 17:51.02 |
Robin_Watts_ | but then if go to page 2, and it can't load it, we get a crap rendering on the screen, and no alert. | 17:51.22 |
| In order to retry we have to go back a page/forward a page. | 17:51.37 |
| on windows we get an alert saying "Page rendering incomplete" | 17:51.51 |
| on linux we get nothing. | 17:51.55 |
sebras | Robin_Watts_: don't we paint the window gray before rendering the page? | 17:52.23 |
| Robin_Watts_: and is the assumption that the file is corrupt or is this for a valid file? | 17:52.40 |
Robin_Watts_ | sebras: We do, but if it can't get the page data, the page comes out the wrong size. | 17:52.45 |
| sebras: The app knows whether the error is because of a TRYLATER or not. | 17:53.07 |
sebras | Robin_Watts_: right and if it is because of !TRYLATER then we handle it the same way as we used to. | 17:53.44 |
| and if it is TRYLATER, we just retry immediately. | 17:53.52 |
Robin_Watts_ | sebras: If it's because of TRYLATER, I pop up an alert window on windows. | 17:54.09 |
| but that's just a stderr output on linux. | 17:54.20 |
| Is the search window actually just text in the top corner of the normal window on X ? | 17:54.39 |
sebras | Robin_Watts_: yeah, and I guess that's ok..? | 17:54.40 |
| Robin_Watts_: it is. | 17:54.45 |
| Robin_Watts_: there's no fancy toolkit. | 17:54.53 |
Robin_Watts_ | sebras: I'd really rather have a second window. | 17:55.02 |
sebras | Robin_Watts_: hence the lack of decent UTF-8 input e.g. | 17:55.06 |
| Robin_Watts_: why? | 17:55.11 |
| Robin_Watts_: (given the current implementation). | 17:55.27 |
Robin_Watts_ | Because it would be the same as windows. | 17:55.27 |
sebras | Robin_Watts_: when the GTK-viewer is done I would probably agree with you. | 17:55.45 |
| searching isn't the same on win/linux (or other platforms) right now either. | 17:56.12 |
Robin_Watts_ | sebras: Well, in the GTK viewer, I'd hope we could do better - pages that aren't loaded could have placeholders, and pages that are only part rendered could have an hourglass in the top corner or something. | 17:56.38 |
sebras | Robin_Watts_: mmm, and in the meantime I'd vote for doing something really simple. | 17:57.10 |
Robin_Watts_ | Well, on that basis, I'm there :) | 17:57.37 |
sebras | Robin_Watts_: so either stderr (which might be obscured) or possibly a status-like bar at the top of the window similar to the searchbar. | 17:57.48 |
| Robin_Watts_: we have serious issues with form-filling on x11 too... | 18:00.23 |
Robin_Watts_ | yeah. | 18:00.29 |
| which could be fixed (or patched at least) as part of the same project. | 18:00.52 |
sebras | not only are the inputs done via stdin, but additionally they require input _twice_ for eaach field. | 18:00.55 |
Robin_Watts_ | but then the GTK app (peace be upon it) will solve all this. | 18:01.16 |
sebras | Robin_Watts_: well, we're betting on it at least. :) | 18:01.32 |
| Robin_Watts_: I have only been slightly annoyed about the form-filling so far. but not enough to fix it. :) | 18:01.50 |
| (too much GStreamer :-( ) | 18:02.06 |
Robin_Watts_ | sebras: I bet the 'enter it twice' thing is easy to fix. | 18:02.14 |
sebras | Robin_Watts_: I though so beforse, but I never found the problem. | 18:03.56 |
Robin_Watts_ | Is it not that the first call is on a DOWN and the second is on an UP or something? | 18:04.20 |
sebras | Robin_Watts_: might be. | 18:05.17 |
Robin_Watts_ | sebras, tor8: So... we essentially have 2 ways of loading files now. | 18:28.15 |
| We can load 'normally' by following all the xrefs etc. | 18:28.38 |
| Or we can load 'linearized' by using the linearized object. | 18:28.59 |
| With pdf_reference17.pdf, the latter gives us a much faster rendition of page 1. | 18:29.20 |
| and then we get all the other pages fairly fast, but with the wrong fonts. | 18:29.46 |
| until a lot further through the file, we get them with the right fonts. | 18:30.01 |
| OR we can ignore the linearization object, and load normally. We have to load 1/4 of the file before we get anything meaningful displayed. | 18:31.05 |
| and other pages come along fairly swiftly after the first. | 18:31.21 |
| Neither of these seems to exactly match what (say) chrome does. | 18:31.49 |
| I'm wondering if we should attempt some sort of hybrid loading scheme. | 18:32.09 |
| Load the first page (and all its fonts) using the linearised object. | 18:32.23 |
| Then load subsequent pages using the normal page tree etc. | 18:32.50 |
sebras | Robin_Watts_: I wonder what poppler does. | 18:40.46 |
henrys | 600 dpi 12 foot plotter output - whoopee! | 18:44.57 |
Robin_Watts_ | henrys: Scan it! :) | 18:45.24 |
| mail it back as a 24bit uncompressed tiff and ask if it's now correct. | 18:45.46 |
henrys | that did occur to me. | 18:46.15 |
sebras | Robin_Watts_: poppler does appear to parse the hints table..! | 18:46.45 |
Robin_Watts_ | sebras: really? | 18:47.01 |
| Well, that's an excuse for me to parse the hints table too. | 18:47.17 |
| I'd have to detect a broken hints table and drop back to living without it though. | 18:47.36 |
sebras | Robin_Watts_: yes. | 18:47.37 |
| Robin_Watts_: but when you say we need to load 1/4th of the file, then you are not taking Range requests into account I assume? | 18:49.41 |
Robin_Watts_ | sebras: That's using range requests. | 18:50.03 |
sebras | Robin_Watts_: oh. | 18:50.11 |
Robin_Watts_ | 25% of the pdf_reference17.pdf file is first page, page tree, xrefs. | 18:50.35 |
| So linearised gets us a big boost for the first page. | 18:50.57 |
sebras | ok, so we could skip the page tree and xrefs if we read the linearization object. | 18:51.09 |
Robin_Watts_ | sebras: Right. | 18:51.20 |
sebras | how big are they? | 18:51.28 |
Robin_Watts_ | but without the hints object we can't get to subsequent pages. | 18:51.35 |
| xrefs are at least 20% of the file. | 18:51.42 |
| If I can use the hints object, then we can get subsequent pages quickly as I can easily grab the areas of the file that matter. | 18:52.20 |
| but chrome does a respectable job with a broken hints table. | 18:52.47 |
| I've studied the hints stream a fair amount due to producing linearised output from mupdf. | 18:53.39 |
sebras | Robin_Watts_: I guess making use of the linearizatin object is a good start. | 18:55.00 |
Robin_Watts_ | sebras: Right. That was the first thing I coded for progressive loading. | 18:55.26 |
sebras | Robin_Watts_: that at least gives an impression of a quick first page. | 18:55.29 |
| Robin_Watts_: oh, so this is already implemented? | 18:55.52 |
Robin_Watts_ | Using the linearisation object to get the first page out, then 'rough' renderings of subsequent pages is already implemented. | 18:56.24 |
| And it works nicely. | 18:56.33 |
sebras | ah, so the hints are what remains. | 18:56.43 |
Robin_Watts_ | and doesn't rely on byte requests. | 18:56.44 |
| right. | 18:56.48 |
sebras | well, it doesn't hurt to try to parse it. | 18:56.54 |
| doing the heuristics for detecting bogus ones will probably be difficult. | 18:57.06 |
Robin_Watts_ | I now have byte requests working, and hence can work better than you'd hope with non linearised files. | 18:57.15 |
| so the next thing to try is to add hints in and maybe we can get the best of all worlds. | 18:57.30 |
sebras | Robin_Watts_: after that it is only U3D remaining... | 18:59.37 |
Robin_Watts_ | OCG first :) | 18:59.56 |
tor8 | Robin_Watts_: I'd imagine a hybrid linearized-first-page + normal-remaining-pages mode would be ideal | 20:51.36 |
| but won't help much for android startup times if we've saved a location past the first page when reopening files | 20:52.10 |
| also, no, displaying an alert window on x11 is very complicated | 20:52.35 |
| you have to put it in the same event loop as the main window. there's no way to get a simple "modal" dialog box function. | 20:53.23 |
| rewiring it to display a 'broken page' image for a page and periodically retry should be easier | 20:53.47 |
| would be easier, I mean | 20:53.57 |
shelly | henrys: are you still on here? | 21:19.58 |
henrys | yes I am | 21:20.12 |
shelly | good to finally catch you, just wanted to make sure you got my last update about the remaining integration work | 21:20.56 |
henrys | I read that sometime back let me refresh my memory | 21:24.06 |
| the varying results suggest indeterms, right? | 21:26.01 |
shelly | I thought they were indeterms but now it has settled down, I was thinking of doing multiple runs before the final commit as a sanity check | 21:27.22 |
henrys | 694311 - why is that related to openjpeg2 integration? did openjpeg 1 support gcc? | 21:28.37 |
| ycc? | 21:28.45 |
| one dot difference are usually not significant. | 21:31.50 |
shelly | yes it did and the code still works but I can not find an official comment on why the option is removed | 21:32.16 |
| barring the dot difference, it now boils down to the 4 files listed | 21:33.41 |
henrys | and those are problems with mupdf as well | 21:37.09 |
| ? | 21:37.11 |
shelly | I believe so but will need to check on my other machine, will drop you a note tomorrow | 21:39.12 |
henrys | if you can reproduce it in mupdf simon can have a go at it and then your bounty will clear. | 21:39.30 |
| assuming you don't want to fool with it anymore | 21:39.48 |
| the bounty for the integration that is. | 21:40.06 |
shelly | there are a whole stack of fuzzing bugs that I am itching to tackle..... | 21:40.48 |
| I just need some quality debugging time to work on this, my hours are erratic at the moment | 21:42.14 |
henrys | is that all you need? I do process a lot of email sorry if I was non attentive to the issues you raised. | 21:42.34 |
shelly | I'm done, catch you another time, good night. | 21:43.12 |
| Forward 1 day (to 2013/07/09)>>> | |