| | <<<Back 1 day (to 2013/01/06) | 2013/01/07 |
| JakeSays | Robin_Watts: ah i think i figured it out - the coordinates generated by -ttt are transformed back to points. they match the MediaBox in the pdf. | 00:48.10 |
| | or more accurately the default user space units defined in the pdf, which happen to be points in my case | 00:50.26 |
| | grocerybike | 00:56.26 |
| | bah wrong channel | 00:56.52 |
| sebras | JakeSays: I have to admit to being a bit curious about in what #channel "grocerybike" would be on topic. :) | 06:31.44 |
| | kens: I woke up before you! | 06:32.04 |
| kens | sebras, you are indeed up and about early today, I still beat tor8 though | 07:59.08 |
| ray_laptop | Hi, kens | 07:59.36 |
| kens | and ray_laptop is up late ;-) | 07:59.48 |
| | Hi ray | 07:59.57 |
| Robin_Watts | morning ray | 08:00.05 |
| ray_laptop | did you also try the performance for bug 693535 ? | 08:00.14 |
| Robin_Watts | and kens | 08:00.19 |
| kens | ray_laptop : I downloaded the file and was about to start testing it myself | 08:00.27 |
| ray_laptop | Note that I tested it on my Win 7 64-bit system | 08:00.33 |
| | Hi, Robin_Watts | 08:00.41 |
| kens | ray I was going to try win 7 and Linux (in a VM) | 08:00.47 |
| | Morning Robin_Watts, you too are up early | 08:01.01 |
| | I **think* one of my Linux VMs has an 8.71 installation. I wonder if he's using 32 or 64-bit (and if this could be related) | 08:01.48 |
| ray_laptop | kens: on linux, I didn't think there was much 32 vs. 64 bit performance hit. | 08:02.28 |
| kens | ray_laptop : I don't know, I'll see if I can try both ways | 08:02.45 |
| ray_laptop | FWIW, even though I am on Win 7 64-bit, I run the 32-bit build. | 08:02.53 |
| kens | :-) I use both indiscriminately | 08:03.08 |
| ray_laptop | I'll build and test the 64-bit now... | 08:03.09 |
| kens | ray_laptop : feel free to leave it with me | 08:03.22 |
| | It must be pretty late in California | 08:03.34 |
| ray_laptop | kens: no problem -- I'm just curious... | 08:04.38 |
| kens | yeah, me too | 08:04.45 |
| | I'm fairly sure I would have noticed a 10x slowdown | 08:04.57 |
| ray_laptop | Don't worry, I'll get my 'beauty sleep' ;-) | 08:05.01 |
| kens | Robin_Watts : if you have a moment, this loon needs some help: | 08:05.36 |
| | http://stackoverflow.com/questions/14171612/mupdf-error-on-building-using-ndk-build | 08:05.36 |
| | Oh, I wonder if the bicubic downsampling has changed | 08:08.14 |
| ray_laptop | kens: sounds like he expects to be 'spoonfed' solutions to show how valuable he is to his company :-/ Or am I just not making it past the language barrier | 08:08.23 |
| | kens: I don't think so -- I think GS totally ignores Bicubic downsampling | 08:09.04 |
| kens | ray_laptop : you could be correct. Why he expects it to build after he removes 3 components I have no idea. Surely an undefined reference is exactly wht he would exepct | 08:09.10 |
| | ray_laptop : not with pdfwrite | 08:09.19 |
| ray_laptop | kens: really ? We have a BC downsampler ??? | 08:09.44 |
| kens | Not sure, but it does 'something' | 08:09.53 |
| | I'm not saying its bicubic mind you | 08:10.03 |
| ray_laptop | kens: FWIW, I did a 64-bit build with HEAD and (on Win 7 64bit) it still is < 4 sec. | 08:11.09 |
| kens | OK. He's tried our binary and says it is still slower | 08:11.27 |
| | Welcome back chrisl :-) | 08:11.35 |
| ray_laptop | kens: I didn't think we distributed a 64-bit binary on linux | 08:11.46 |
| chrisl | thanks kens...... | 08:11.50 |
| kens | ray_laptop : He seems to think we do | 08:11.56 |
| ray_laptop | hi, chrisl | 08:11.56 |
| chrisl | hi ray_laptop | 08:12.08 |
| ray_laptop | chrisl: do we distribute a 64-bit binary for linux ? | 08:12.28 |
| chrisl | ray_laptop: yes we do - against my wishes, tbh | 08:12.43 |
| ray_laptop | chrisl: (re: bug 693535) | 08:12.44 |
| kens | ray thre's a 15Mb executable where he says it is | 08:12.51 |
| ray_laptop | chrisl: you might as well try that simple 52 page file as well (if you don't mind) | 08:13.18 |
| chrisl | ray_laptop: I'll do so in a minute..... | 08:13.39 |
| ray_laptop | chrisl: np. | 08:13.53 |
| | I expect it is early for you folks. Have to have your tea or coffee or whatever your wake-up drug of choice is ... | 08:14.27 |
| | OTOH, I am about to cuddle with my pillow :-) | 08:15.06 |
| kens | Its taking a lot more than 4 seconds for me | 08:15.32 |
| ray_laptop | I'll check the logs in the AM and see what you folks have found... | 08:15.47 |
| kens | goodnight ray | 08:15.54 |
| ray_laptop | nite, kens | 08:16.02 |
| | et al. | 08:16.05 |
| chrisl | 'nite ray | 08:16.11 |
| ray_laptop | u2, chrisl | 08:16.46 |
| kens | well, it took under a minute, I need a better timer | 08:17.35 |
| ray_laptop | kens: I used "time gs ..." (or under msys: "time gswin64c ..." ) | 08:18.20 |
| kens | time in command shell doesn't work that way | 08:18.41 |
| ray_laptop | bad shell | 08:18.51 |
| | msys shell is at least (mostly) bash consistent. The most irritating thing is that is substitutes "c:/" for '/c/' no matter what escapes I use :-( | 08:20.30 |
| kens | 321 and 64 bit current code takes 22 seconds on my machine | 08:20.55 |
| | Under Windows | 08:21.16 |
| ray_laptop | kens: 321 ??? | 08:21.24 |
| kens | 32 | 08:21.28 |
| | huh, don't have 8.x installed | 08:21.45 |
| ray_laptop | kens: OK. So you have a slow machine. | 08:21.56 |
| chrisl | I do see a ten times performance hit between 8.71 and 9.06 :-( | 08:22.00 |
| ray_laptop | kens: get a faster one | 08:22.03 |
| kens | ray_laptop : its not a slow machine | 08:22.08 |
| ray_laptop | chrisl: REALLY. Damn. | 08:22.16 |
| | I tested on my 2.8GHz i7 laptop. | 08:22.41 |
| kens | THIs is a 3 GHz quad core with a SSD primary disk and 16Gb ram | 08:23.05 |
| chrisl | kens: looking at the command line, are there any on there we used to ignore, and now honour? | 08:23.36 |
| kens | No, I don't think so, but using /PDFSETTINGS is a pain. | 08:23.55 |
| | Because that bundles in *many* settings | 08:24.03 |
| | 1st thing I'd try is dropping the bicubic downsampling | 08:24.21 |
| chrisl | kens: the PDFSETTINGS seems to be the big thing - with it it takes ~30 seconds, without it ~4 seconds | 08:25.46 |
| kens | Yeah, but that has *so* many things in it.... | 08:26.03 |
| chrisl | If you can get me a list, I can narrow it down further | 08:26.39 |
| kens | Let me see if I can reproduce it here, I've just picked up 8.71 for WIndows | 08:26.56 |
| chrisl | Oh, I should try master, too | 08:27.06 |
| kens | chrisl, yes 871 is *much* faster | 08:28.58 |
| chrisl | kens: sure, but is that because we're now doing something (correctly) in the "ebook" settings that we weren't previously? | 08:31.01 |
| kens | Probably. Its going to take me some time to find out unfortunately | 08:31.22 |
| | I *hate* these canned settings | 08:31.28 |
| chrisl | Well, let me know if you want me to help | 08:31.50 |
| kens | THanks but I think what I need to do now is reproduce the settings individually, prove its still slow then binary chop them out | 08:32.15 |
| | Until I can isolate the one which is bad | 08:32.27 |
| | OK, at least they are all defined in one place :-) | 08:33.54 |
| | Hmm, I wonder if its the ColorConversionStrategy=/sRGB | 08:34.17 |
| | Coffee I think | 08:34.26 |
| | Well, the slowdown is caused by /AutoRotatePages /All. If its left at PageByPage, its fast. | 09:24.16 |
| | Oh, actually no | 09:24.38 |
| | Well it turns out to be my first thought. ColorConversionStrategy /sRGB is what causes it | 09:32.00 |
| | The default is LeaveColorUnchanged, since the PDF file is 52 pages of RGB images, the time is taken by converting from RGB to sRGB. | 09:32.49 |
| chrisl | Is that down to the new color management? | 09:33.02 |
| kens | Good question. | 09:33.10 |
| | TO which the answer is 'I don't think so' | 09:33.18 |
| | But I could be wrong | 09:33.29 |
| | I suspect I 'fixed' a case where it wasn't doing a conversion, Its a bit hard to tell for sure, there have been quite a few changes since 8.71 | 09:34.18 |
| | I suppose I could bisect it | 09:35.48 |
| chrisl | I realise the predefined settings aren't our definitions, but I can't help but feel that sRGB is OTT for "ebook"...... | 09:36.15 |
| kens | I think the problem is that there is no other way to get RGB | 09:36.51 |
| | That is, to convert all colours to RGB | 09:37.06 |
| chrisl | I suppose that makes some sense | 09:38.17 |
| kens | Our new pdfwrite will have additional options which allow this, so I think that this problem will disappear in the next release anyway. | 09:38.59 |
| | I don't suppose anyone knows the hash of the 8.71 release in Git ? | 09:40.19 |
| chrisl | It should be tagged | 09:41.04 |
| kens | I think I found it | 09:41.40 |
| chrisl | 9206f30376b9cd2c7b194bed2a7464ebceee5df8 | 09:41.42 |
| kens | OK thanks | 09:41.52 |
| chrisl | You can see all the tags: http://git.ghostscript.com/?p=ghostpdl.git;a=tags | 09:42.06 |
| kens | THat's handy, thanks | 09:42.29 |
| Robin_Watts | Hmm. I just imported openjpeg 2.0 into mupdf, and it compiled with no warnings. Something somewhere must be terribly wrong. | 11:13.25 |
| kens | You cpmiled the wrong code ? :-) | 11:13.38 |
| | Or compiled even.... | 11:13.48 |
| paulgardiner | Has to be | 11:13.59 |
| Robin_Watts | That would have been my guess too... | 11:14.35 |
| | Ah. All the files have moved directory, so I now have copies of both versions. So yes, wrong source version. Phew. | 11:18.13 |
| kens | :-) | 11:18.21 |
| paulgardiner | That's a relief! The alternative doesn't bear thinking about. :-) | 11:23.25 |
| sebras | Robin_Watts: I could have told you that. :) | 12:41.38 |
| | Robin_Watts: openjpeg bug #205 might apply both to 1.5.1 and 2.0. | 12:42.06 |
| | I'm not able to deduce if that is the case from winfrieds comments though. | 12:42.27 |
| Robin_Watts | sebras: AFAICT they've changed the API completely for v2. | 12:42.53 |
| sebras | if it is, then this means there's a regression compared to tghe 1.5.0 version we use. | 12:42.57 |
| Robin_Watts | so I'm trying to make it work with the new API now. | 12:43.17 |
| sebras | Robin_Watts: yeah, probably. I'm just focusing on what can be decoded. | 12:43.20 |
| | Robin_Watts: what prompted you to attempt the upgrade? | 12:44.02 |
| | a customer bug? | 12:44.08 |
| Robin_Watts | We had a large number of files in from customer 395 that show problems. | 12:44.55 |
| | I've run through all of them fixing them except for the libopenjpeg ones. | 12:45.07 |
| | and so before we spend hours and hours of effort fixing bugs in 1.5, we should at least try v2 to see if they are fixed. | 12:45.38 |
| | ooh. It's possible that the new interface will admit of stream based working. | 12:50.05 |
| sebras | nice! | 12:53.36 |
| | Robin_Watts: I wonder if their new decoder is less problematic when it comes to fuzzing. | 12:54.03 |
| Robin_Watts | I strongly suspect it's a new interface on the old decoder. | 12:54.27 |
| | i.e. all the same bugs, just stirred around a bit. | 12:54.35 |
| sebras | Robin_Watts: ok, then I still need to dig deeper into j2k and their decoder I guess. :-/ | 12:58.03 |
| | I have seen many examples of crashing when fuzzing both in the case of j2k and jbig2... | 12:58.31 |
| | I think I filed a bug or two for jbig2dec though. | 12:58.40 |
| Robin_Watts | tor8: ping | 14:21.36 |
| tor8 | Robin_Watts: hi | 14:21.44 |
| Robin_Watts | I have an updated openjpeg git repo here. | 14:21.57 |
| tor8 | Robin_Watts: openjpeg 2? | 14:22.13 |
| Robin_Watts | Yes. | 14:22.20 |
| | Along with a hacked together mupdf to drive it. | 14:22.31 |
| tor8 | how does it compare with openjpeg 1.5 in terms of file layout and build system? | 14:22.35 |
| Robin_Watts | Everything has moved. | 14:22.50 |
| tor8 | ugh. as I feared then. | 14:23.01 |
| Robin_Watts | I'd like to push the new version to git, cos then I can cluster test it. | 14:23.23 |
| | but the git setup on gs won't let me write - possibly I'm not in the permitted users. | 14:24.37 |
| | Do you know about this? | 14:24.42 |
| tor8 | Robin_Watts: did you make any modifications to the openjpeg source or it's just a 2.0 tarball unpack? | 14:24.43 |
| Robin_Watts | It's a cp -pr from the current svn checkout. | 14:24.59 |
| tor8 | Robin_Watts: the thirdparty gits from tarballs are created by some special scripts | 14:25.02 |
| Robin_Watts | revision 2272 | 14:25.13 |
| | I have previously been able to update the freetype git. | 14:25.45 |
| tor8 | Robin_Watts: freetype is a pure git mirror though | 14:26.01 |
| Robin_Watts | right. | 14:26.09 |
| tor8 | you should still be updating it from /home/git/thirdparty/freetype.git with "git remote update" not by pushing stuff to it | 14:26.17 |
| | as stated in the /home/git/thirdparty/README file | 14:26.44 |
| Robin_Watts | ah, I will double check that. | 14:27.11 |
| tor8 | and for the tarballs, I would prefer if we base our code off released versions where possible | 14:28.07 |
| Robin_Watts | ok, that's fine. artifex is currently freetype/master | 14:28.15 |
| tor8 | (to make it easier for distros) | 14:28.16 |
| Robin_Watts | ok, that's fine. artifex is currently freetype/master~4 | 14:28.18 |
| tor8 | Robin_Watts: "artifex" has just been purged :) | 14:28.30 |
| Robin_Watts | fair enough. | 14:28.45 |
| tor8 | Robin_Watts: do we point to 2.4.11 + a few commits for our thirdparty/freetype submodule? | 14:29.06 |
| Robin_Watts | We point to 2ef0a19 | 14:29.27 |
| | which is freetype/master~4 | 14:29.41 |
| | or 2.4.11 + a few, yes. | 14:29.51 |
| tor8 | Robin_Watts: are the "+ a few" really critical? | 14:30.10 |
| Robin_Watts | Critical in so much as the last one of them was specifically to fix a customer 395 bug. | 14:30.39 |
| tor8 | Robin_Watts: right. so then we have a motivation for it (as I vaguely recall checking when reviewing the commit) | 14:31.02 |
| | I'd like to stick to released versions where we can get away with it | 14:31.26 |
| Robin_Watts | The plan with the openjpeg stuff was to try the latest and greatest version to see if it solves the outstanding openjpeg problems. | 14:31.59 |
| tor8 | Robin_Watts: right. I'll make a tarball snapshot commit for openjpeg-2.0.0 | 14:32.43 |
| Robin_Watts | I could import the v2.0 release tag into git, and then bring each new svn version since in too. | 14:32.52 |
| tor8 | Robin_Watts: I tried a git-svn import but that got too messy | 14:33.27 |
| | with all their third party and java viewer crap that just bloats things | 14:33.50 |
| Robin_Watts | I was proposing a manual import of every trunk revision since openjpeg-2.0.0 | 14:33.58 |
| tor8 | Robin_Watts: I'll stick 2.0.0 in there and then we can make a snapshot of the trunk you want to test against | 14:34.21 |
| Robin_Watts | Right, but when we inevitably hit problems, what do I do? | 14:35.02 |
| | I will want to test against the latest version to see if the bug is solved. | 14:35.44 |
| | (So I think 2.0.0 is a good first step, but we probably want the bleeding edge in there too) | 14:36.14 |
| tor8 | Robin_Watts: oh, right, so the release tarballs of openjpeg we already have in the thirdparty git have the thirdparty cruft in them too | 14:37.22 |
| | Robin_Watts: shall we set up a git-svn mirror that takes trunk from 2.0.0 and forward then? | 14:37.44 |
| Robin_Watts | tor8: That sounds ideal. | 14:38.01 |
| tor8 | Robin_Watts: I'll have to refresh my memory about how to use git-svn then :/ | 14:38.27 |
| Robin_Watts | tor8: presumably we need to ensure that the current SHAs remain valid? | 14:38.47 |
| tor8 | Robin_Watts: doesn't matter, we can just make a new branch for the git-svn import | 14:39.11 |
| | or we can make it graft the parent onto the tarball imports | 14:39.25 |
| | I'll see what I can do | 14:39.31 |
| Robin_Watts | Ah, right, perfect. | 14:39.31 |
| tor8 | Robin_Watts: I have pushed onto /home/git/thirdparty/openjpeg.git a 2.0.0 tarball import | 14:40.58 |
| | if you want to try that while I sort out the git-svn | 14:41.14 |
| Robin_Watts | Same 3 warnings in the lib itself... | 14:45.09 |
| | and it seems to work, yeah. | 14:46.18 |
| JakeSays | Robin_Watts: did you see last my msg about the coordinate units? | 14:46.53 |
| Robin_Watts | JakeSays: That you'd got it sorted? | 14:47.05 |
| JakeSays | Robin_Watts: yeah. does my thinking make sense? | 14:47.20 |
| Robin_Watts | JakeSays: Kinda. | 14:49.32 |
| JakeSays | Robin_Watts: which part isnt making sense? | 14:58.14 |
| | ray_work: you around? | 14:58.21 |
| tor8 | Robin_Watts: okay, I have a git-svn checkout of their trunk grafted on top of the tarballs in /home/tor/thirdparty/openjpeg ... I'll set up a remote in /home/git/thirdparty/openjpeg.git so that "git remote update" will pull from that staging repo (since git-svn repos can't be bare) | 15:03.05 |
| | and maybe put all that stuff in a crontab job | 15:03.25 |
| Robin_Watts | tor8: cool. | 15:09.50 |
| | JakeSays: No particular part doesn't make sense. To be 100% sure you'd be right, I'd have to dive back into the code to understand exactly what -ttt outputs, and I haven't the time for that now. | 15:11.52 |
| JakeSays | Robin_Watts: no prob. for what i'm doing it appears to work - no need to spend time on it | 15:12.37 |
| | just wanted to make sure i wasn't totally off | 15:12.49 |
| Robin_Watts | tor8: oddness. | 15:18.00 |
| | http://git.ghostscript.com/?p=thirdparty/openjpeg.git;a=summary | 15:18.08 |
| | That's showing master == 2.0.0 to me. | 15:18.17 |
| tor8 | Robin_Watts: try again. | 15:18.33 |
| | Robin_Watts: I just fixed that :) | 15:18.37 |
| Robin_Watts | but on casper itself I see HEAD == master == git svn | 15:18.41 |
| | Aha! | 15:18.49 |
| | What was wrong? | 15:18.51 |
| tor8 | I just fixed it five seconds ago | 15:19.02 |
| | had to jiggle the .git/config to fetch the refs as a mirror | 15:19.27 |
| | not under origin/* | 15:19.34 |
| Robin_Watts | Ah, ok, thanks. | 15:19.44 |
| | Right, so now I'll tidy it up and try some cluster tests. | 15:19.59 |
| | At the moment jpx's are a special case. My dodgy memory says that's because they can't be driven from streams. | 15:20.22 |
| | Am I remembering that right? | 15:20.37 |
| tor8 | Robin_Watts: yeah, because of the colorspace needing to be fed as a special case | 15:20.58 |
| | Robin_Watts: now thirdparty.git and openjpeg.git should be updated @daily in my crontab | 15:22.21 |
| | s/thirdparty/freetype/ | 15:22.27 |
| henrys | Robin_Watts, tor8 :I wonder if the openjpeg can be worked on by alex freeing both of you up for other problems. | 15:36.06 |
| tor8 | henrys: the new openjpeg.git is already live, no more for me to do there | 15:36.31 |
| Robin_Watts | henrys: The openjpeg stuff is all that remains of the customer 395 issues. | 15:36.53 |
| | If these problems turn into a big deal, I was thinking that we could pass them to shelly or to zeniko/ | 15:37.33 |
| henrys | oh I didn't know that. | 15:37.45 |
| Robin_Watts | Actually, I should rephrase that. | 15:38.04 |
| | I have run through all the 395 issues with memento on windows. | 15:38.30 |
| | Other than the openjpeg issues, we don't SEGV or leak any more. | 15:38.50 |
| | I can't tell if we have UMRs of course (in so far as no files crash, but might still be accessing out of bounds). | 15:39.17 |
| chrisl | henrys: I can't remember if I mentioned - Shelly was asking about going ahead with the OpenJPEG 2.x integration for Ghostscript | 15:39.17 |
| Robin_Watts | My plan was to see if the openjpeg 2.0 stuff solves many/some/any of the 395 issues. | 15:40.04 |
| | Then we can see if Zenikos fixes apply to it, and that may solve some. | 15:40.29 |
| | And then I was going to try running the files through valgrind. | 15:40.47 |
| henrys | well alexcher owns that openjpeg for gs, alexcher do you want to integrate 2.0 or are you tied up with something? | 15:41.23 |
| | 395 wow! | 16:12.48 |
| Robin_Watts | henrys: customer 395 that is, not 395 issues. | 16:14.16 |
| henrys | oh duh - wow monday | 16:14.58 |
| | chrisl:I'll email alexcher and then follow up with shelly about gs + openjpeg 2.0 | 16:25.30 |
| chrisl | henrys: okay, thanks | 16:26.00 |
| kens | chrisl I just decompressed that file with the 'off by 1 glyph' and it went from 2,9 Mb to 63Mb ! | 16:43.40 |
| chrisl | kens: I've got it down to a 32k decompressed PDF | 16:44.55 |
| kens | :-) | 16:45.02 |
| | Well the text in hte PDF is ascii decoded to the same as Acrobat shows, so that's wqeird | 16:45.24 |
| chrisl | Yeh, my first thought was incompatible subsets, but my file's only got one font in it | 16:45.54 |
| kens | Yes, really od because the non-numeric/symbol text is OK | 16:46.17 |
| | Oh, the font isn't embedded ? | 16:46.50 |
| ray_work | Robin_Watts: the "tricky" thing about JPX's is that the color space and other stuff come from the JPX, overriding or supplementing what's in the PDF Image dict | 16:47.34 |
| kens | D'oh, no there it is, I missed the FOntFile | 16:47.53 |
| chrisl | kens: the font is embedded | 16:47.57 |
| | And I think it's marked non-symbolic | 16:48.15 |
| kens | flags is 32 | 16:48.21 |
| | which I *think* is non-symbolic | 16:48.29 |
| kens | wonders what happens if I pdfwrite it | 16:48.43 |
| | Well, the pdfwrite outptu is the same as the GS rendering | 16:49.47 |
| ray_work | kens: bit 6 is non-symbolic | 16:49.52 |
| kens | ray_work : yes but you have to remember to count from 1 | 16:50.05 |
| ray_work | kens: right. so bit 6 == 32 | 16:50.34 |
| | kens: so you are correct | 16:51.11 |
| chrisl | Changing it to symbolic doesn't help..... | 16:52.02 |
| kens | I'm not too surprised. Its a strange one | 16:52.30 |
| JakeSays | so the pdf spec declares /Differences "(Optional; should not be used with TrueType fonts)" - if /Differences is being used with a truetype font, does mupdf support it? | 16:52.31 |
| alexcher | henrys: Yes, I'm familiar with OpehJpeg and wold be glad to help. | 16:55.20 |
| henrys | well let's get a 2.0 branch going I don't think we want it in trunk - release in Feb? chrisl? | 16:57.11 |
| chrisl | henrys: no, you're right, I think we're too close to make the change for 9.07 | 16:57.53 |
| Robin_Watts | alexcher: are we going to have the softmasks fixed for 9.07 ? | 16:58.20 |
| JakeSays | also, given /Encoding 690 0 R in a pdf, once i get a pointer to the /Encoding object, how do i then get the referenced object? | 16:58.45 |
| Robin_Watts | (Bug 693115 I mean) | 16:59.03 |
| alexcher | Robin_Watts: Most likely. | 16:59.35 |
| Robin_Watts | excellent. Will be really glad to see that one fixed ! :) | 16:59.52 |
| kens | OK off for a pizza, goodnight all | 17:01.17 |
| JakeSays | ah. pdf_resolve_indirect i think | 17:05.34 |
| Robin_Watts | JakeSays: Well, presumably you want to do something with that object, right? | 17:06.17 |
| JakeSays | Robin_Watts: right | 17:06.26 |
| Robin_Watts | So if it's a dictionary you'll want to look up in it, or something? | 17:06.42 |
| | So you do pdf_dict_gets() or something. | 17:06.52 |
| | And that has the resolve stuff rolled into it. | 17:07.05 |
| JakeSays | ah ok so i dont need to do anything special | 17:07.15 |
| | cool | 17:07.17 |
| mvrhel_laptop | good morning | 17:10.44 |
| JakeSays | hmm. pdf is an interesting file format | 17:16.53 |
| henrys | Curious if any of you windows folks ever got .net source code debugging to work. I followed the instruction and met with doom like many others who tried ⦠I don't really need it anymore but it would be nice to have it available. | 17:23.25 |
| Robin_Watts | I've always avoided .not | 17:24.30 |
| mvrhel_laptop | henrys: I had dabbled a bit in that stuff years ago with xps. did you find the issue in your file? | 17:27.51 |
| henrys | not yet just getting back to it. I know it is not the xps but the zip. | 17:28.30 |
| mvrhel_laptop | oh | 17:28.45 |
| henrys | from my reading this weekend .net users should not be given gun permits. | 17:33.12 |
| Robin_Watts | henrys: Or they should all be given loaded guns to play with within their padded cells. | 17:37.26 |
| tor8 | Robin_Watts: s/padded/bullet proof/ | 17:41.34 |
| Robin_Watts | tor8: I have 264 files that are now giving errors rather than rendering with 2.0 instead of 1.5.0 | 17:42.13 |
| sebras | Robin_Watts: sounds like a serious regression..? | 18:33.12 |
| Robin_Watts | sebras: Previously, if the lib hit more tile parts than it expected it warned, and continued. | 18:33.45 |
| | now it gives up. | 18:33.50 |
| | I've raised issue 208 on their bug tracker, so we'll see what they say. | 18:34.06 |
| sebras | Robin_Watts: in my experience they take good long while before answering... | 18:34.44 |
| Robin_Watts | My attempts to change the code to ignore the problem did not work :) | 18:36.18 |
| | It may be possible to work around it by moving the decoding tiling logic out. | 18:43.39 |
| mvrhel_laptop | Robin_Watts: are you here? | 19:18.13 |
| Robin_Watts | mvrhel_laptop: I am. | 19:45.54 |
| mvrhel_laptop | oh hi Robin_Watts. I think I got it figured out now | 19:46.08 |
| Robin_Watts | fair enough :) | 19:46.20 |
| mvrhel_laptop | playing around with mupdf and my windows c++ app | 19:46.25 |
| Robin_Watts | ah. how goes it? | 19:46.41 |
| mvrhel_laptop | slooooowwww | 19:46.47 |
| Robin_Watts | slow progress or slow app ? :) | 19:47.02 |
| mvrhel_laptop | took me a bit to get some c++/c issues sorted out | 19:47.02 |
| | slow progress | 19:47.08 |
| | :) | 19:47.09 |
| | and some windows runtime mismatch issues | 19:47.21 |
| Robin_Watts | joy. | 19:47.36 |
| mvrhel_laptop | and now I just realized that the mupdf library and the third party library were different | 19:47.46 |
| | I would have thought the mupdf.lib had everything | 19:48.10 |
| Robin_Watts | We could rejig the build process so it did, probably. | 19:48.50 |
| | (except possibly v8) | 19:48.58 |
| mvrhel_laptop | no worires | 19:48.59 |
| | I just could not figure out why it was not linking | 19:49.17 |
| | but I think I may finally be close to getting this to open something | 19:49.41 |
| | then its back to the windows UI fun stuff | 19:50.09 |
| | Robin_Watts: so you are all recovered from the flu | 19:51.23 |
| | ? | 19:51.25 |
| Robin_Watts | pretty much. | 19:51.33 |
| | still sound a bit tubercular, but I'm feeling *much* better. | 19:51.45 |
| mvrhel_laptop | thats good. my son came down with a fever last night. he is the last one to get this stuff here. my cough is slowly going away | 19:52.23 |
| Robin_Watts | It's horrid when it burns through families. | 19:57.29 |
| j | help | 20:10.48 |
| | ; | 20:10.51 |
| | man | 20:10.54 |
| Guest85434 | help | 20:11.14 |
| | ; | 20:11.17 |
| | man | 20:11.22 |
| | ; | 20:11.23 |
| | mmmm | 20:11.26 |
| JakeSays | question regarding this function: fz_currentpoint(fz_context *ctx, fz_path *path) - does it return the last point defined in the path? | 20:38.49 |
| mvrhel_laptop | bbiaw | 20:39.35 |
| tor8 | JakeSays: yes. | 20:48.03 |
| JakeSays | tor8: thanks | 20:48.19 |
| | hmm. it looks to me like the text extractor driver in mudraw ignores font encodings | 20:58.02 |
| henrys | Robin_Watts:I guess mupdf should be made Affero as well, for8 just left, can you change it or should I send him email? | 21:28.21 |
| henrys | must figure out how to stop colloquy from respelling my words | 21:29.49 |
| | tor8:are you about? | 22:24.16 |
| tor8 | henrys: briefly | 22:24.28 |
| henrys | miles wants to go ahead and make the affero change now. | 22:24.48 |
| tor8 | henrys: okay. | 22:24.57 |
| | do you remember if we've given the sumatra folks a heads up that we've been considering the affero? | 22:25.30 |
| henrys | so as soon as you get a chance. thanks | 22:25.30 |
| tor8 | henrys: will change the COPYING and README files tomorrow. | 22:25.44 |
| henrys | I don't know that how would it affect them? | 22:26.00 |
| | oh right | 22:26.15 |
| tor8 | well, they'll need to change too | 22:26.24 |
| henrys | of course that is an issue | 22:26.26 |
| tor8 | I doubt there'll be any problems, but it would be polite to give them some warning or just a mail to let them know. robin is in regular communications with zeniko so I think he should be the one to do it. | 22:27.22 |
| | Robin_Watts: ^ | 22:27.32 |
| henrys | makes sense, I'll remind Robin_Watts, he usually pops in late in the evening. | 22:29.53 |
| JakeSays | out of curiosity whats the reasoning behind the move to agpl? | 23:16.15 |
| | Forward 1 day (to 2013/01/08)>>> | |
IRC Logs