| | <<<Back 1 day (to 2013/08/29) | 2013/08/30 |
| chrisl | kens: we still test with DisableFAPI until PCL/FAPI has matured a little, and then I'll pull the option for all products. That seems easier than doing it for some, and not for others. | 08:29.47 |
| kens | chrisl OK but I still don;'t see how I cna fix a problem I can't reproduce. | 08:30.06 |
| chrisl | No that's fair enough, I just wanted to clarify that point. | 08:30.30 |
| kens | I carefully set up the filenames so that they were the length Marcos was suing, and neither the release nor debug versions of the current code cause a problem for me | 08:30.34 |
| | I *could* 'fix' the uninitialised variables, but I don't think that's really the problem, because at least one fot he variables is definitely initialised, so I think its actually using uninitialised memory. | 08:31.32 |
| chrisl | I wasn't arguing with your conclusion, just explaining why DisableFAPI tests are still present | 08:32.20 |
| kens | Fair enough :-) | 08:32.29 |
| | I have to say I'm even less inclined to try and fix problems with FAPI disabled when the input is PDF or PostScript htough. | 08:33.00 |
| chrisl | If Marcos gets antsie about it, assign to me, and I'll debug it on a cluster node | 08:33.19 |
| kens | OK, no doubt you;ll see the bug traffic :) | 08:33.38 |
| chrisl | Or I might be wilfully ignoring it.... | 08:34.02 |
| kens | Thoguh Marcos did say it didn't exhibit under a debugger, presumably it moves the memory enough to mask the problem | 08:34.03 |
| | I will now go and fetch the morning coffee | 08:34.25 |
| Robin_Watts | http://www.amazon.co.uk/Afterliff-ebook/dp/B00D0UYUSU/ref=sr_1_1?ie=UTF8&qid=1377851387&sr=8-1&keywords=Afterliff | 11:16.00 |
| | tor7: I got the PNG banding working. | 15:28.56 |
| | So robin/master now has 6 commits on all ready to go if you're happy with them. | 15:29.36 |
| henrys | ray_laptop:are you about? | 15:38.00 |
| | or anybody - why do the languages call gsicc_init_device_profile_struct if the device parameter machinery sets it up anyway? In pcl customer 801's profile is getting pulled out in favor of the default cmyk because of that init call. | 15:39.48 |
| | wow ubuntu download defaults to charging 16.00 US. | 16:05.41 |
| ray_laptop | henrys: sorry, I was getting coffee. w.r.t the gsicc_init calls, you'd have to discuss with Michael. I know he struggled a bit with getting things initialized | 16:13.01 |
| henrys | ray_laptop:yes the way I read the code the language can only use the standard builtin device profiles. | 16:14.52 |
| Robin_Watts | henrys: It makes you transition past a contribution page. | 16:14.54 |
| ray_laptop | hmm.. I just downloaded ubuntu and didn't see the contribution page somehow | 16:16.02 |
| henrys | Robin_Watts: yes I was just surprised to see I needed to set each of 6 or 7 entries to 0.0 before proceeding. | 16:16.05 |
| Robin_Watts | henrys: There is a link at the bottom "not right now" or something like that. | 16:16.25 |
| henrys | Robin_Watts: reading is fundamental ;-) | 16:17.14 |
| Robin_Watts | tor7: And an SVG device commit too to make some more obscure pattern cases work. | 17:43.03 |
| | actually, ignore the SVG one for now, just found a file that doesn't quite work. | 17:48.43 |
| henrys | thinks dual repositories must be banned at any cost (jbig2dec etc) | 18:22.47 |
| Robin_Watts | henrys: OK, so we'll have a single jbig2dec repo, and use git submodules then ? | 18:35.48 |
| | tor7: SVG commit fixed and ready to go. | 18:36.06 |
| | henrys: Either we take the pain of dual repos, or we take the pain of git submodules. | 18:36.51 |
| | The current scheme (of generating a jbig2dec repo from the gs one, and hence only allowing commits to the gs one) seems to work OK, does it not? | 18:37.23 |
| henrys | zeniko applied his patch to mupdf no? | 18:37.50 |
| Robin_Watts | henrys: yes. | 18:38.06 |
| | so patch reapplication requires a tiny amount of tweaking of the patch by hand. | 18:38.32 |
| | Either you edit the hash in the patch, or you edit it to strip off the commit message and apply it with patch, then commit it manually. | 18:39.14 |
| henrys | we can just have a separate repo for jbig2dec and treat it like we do any other 3rd party library - I fear submodules will be vetoed. | 18:39.23 |
| Robin_Watts | henrys: "Just like we do for any other 3rd party library". You mean, we clone it into the gs source tree? | 18:39.53 |
| sebras | henrys: what are the problems with submodules? | 18:40.02 |
| henrys | Robin_Watts: yes I just said that in bugziall it should have been emailed out. | 18:40.04 |
| Robin_Watts | How do we then stop people committing fixes to that? You're back to 2 repos. | 18:40.06 |
| | sebras: Luddites :) | 18:40.11 |
| sebras | Robin_Watts: oh. :) | 18:40.23 |
| Robin_Watts | henrys: actually, is it just the paths in the patch that are the problem? | 18:41.07 |
| | that's not hard to fix with an editor. | 18:41.25 |
| henrys | Robin_Watts: no I believe it is the hash - see my email. | 18:41.36 |
| Robin_Watts | What error message do you get? | 18:42.51 |
| henrys | or comment here http://bugs.ghostscript.com/show_bug.cgi?id=694111 | 18:42.58 |
| Robin_Watts | When I try to apply a git format-patch generated patch, it doesn't need to go onto the same hash. | 18:43.15 |
| | In fact, I just nobbled the hash, and it applied just fine. | 18:43.58 |
| | I suspect the problem is that the patch that zeniko generated came from the standalone jbig2dec repo (i.e. the one he sees in mupdf thirdparty). | 18:44.33 |
| | So the paths will be different to the equivalent patch in the gs repo. | 18:44.55 |
| | and git ain't smart enough to figure that out when reapplying it. | 18:45.20 |
| henrys | Robin_Watts: That may be, but nonetheless we want jbig2dec updated one place, that is the real issue. | 18:47.00 |
| Robin_Watts | henrys: OK, and how do you suggest we solve that without going to submodules? | 18:47.56 |
| henrys | I'd vote for submodules but assuming that is vetoed the permissions on the mupdf third party repository must be read only. | 18:50.30 |
| Robin_Watts | henrys: I've downloaded the patch, changed the pathnames and reuploaded it to the bug. | 18:50.37 |
| | The permissions on the mupdf third party repo ARE read only. | 18:50.50 |
| chris_99 | hey, any mupdf devs around per chance, i'm just wondering how easy you guys reckon it'd be to parse text out of a pdf using the mupdf sources | 18:51.00 |
| Robin_Watts | zeniko cannot commit to that. | 18:51.01 |
| henrys | then how did zeniko commit to mupdf's jbig2dec? | 18:51.19 |
| Robin_Watts | He didn't commit to mupdf's jbig2dec. | 18:51.33 |
| | He committed to HIS CLONE of mupdfs jbig2dec. | 18:51.44 |
| | We can't stop people doing what they want with their local clones. | 18:52.19 |
| | all we can do is stop stuff getting into our copy. | 18:52.29 |
| henrys | okay fine than we don't have a problem, I didn't understand that. | 18:52.47 |
| Robin_Watts | henrys: You should find the patch on the bug will apply now. | 18:52.53 |
| | henrys: It's a pain that we need to tweak zenikos patches to apply them, but it is just a matter of changing paths. | 18:53.18 |
| | chris_99: hi | 18:53.21 |
| | Should be very easy. | 18:53.28 |
| henrys | Robin_Watts: can he apply them himself? | 18:53.38 |
| chris_99 | Robin_Watts, hi, is there any particular example that would explain that, or would i need to hack the parser myself | 18:54.07 |
| Robin_Watts | If he had a checkout of gs, he could apply his changes and commit that, yes. | 18:54.11 |
| | but he's resisting touching the gs tar baby :) | 18:54.25 |
| | chris_99: mudraw -t in.pdf ? | 18:54.36 |
| | chris_99: or: mudraw -tt in.pdf ? | 18:55.25 |
| chris_99 | ooh thanks a lot! | 18:55.28 |
| Robin_Watts | chris_99: or: mudraw -ttt in.pdf ? | 18:55.39 |
| chris_99 | hehe | 18:55.44 |
| henrys | Robin_Watts: thanks | 18:56.11 |
| Robin_Watts | henrys: np. | 18:56.26 |
| chris_99 | one other question, if i wanted to know things like the size of different text elements, i assume then i'd need to hack the parser | 18:56.27 |
| Robin_Watts | no. | 18:56.40 |
| | MuPDF works by interpreting the page and sending all the graphic operations to our "device interface". | 18:57.19 |
| | We have various implementers of this device interface. | 18:57.33 |
| | one is the draw device, that actually renders stuff. | 18:57.45 |
| | another is the text extraction device, that records details of the text on a page. | 18:58.00 |
| | That information is what is used to give the -t, -tt and -ttt output. | 18:58.22 |
| | we have other code that spits out html. | 18:58.30 |
| chris_99 | oh awesome this sounds brilliant, i've been searching for ages for a C pdf parsing lib. this looks like it'll do th job perfectly then! | 18:58.34 |
| Robin_Watts | You should find that the information gathered has everything you need. | 18:58.54 |
| | One problem is that PDF doesn't always send text in quite the order you'd hope, so we have some hairy logic in there to plug it back together again. | 18:59.25 |
| | but the raw information is all there. | 18:59.33 |
| | Let us know how you get on. | 18:59.39 |
| | afk for a bit. | 18:59.55 |
| chris_99 | thanks a lot for the help! | 19:00.13 |
| sebras | tor7: ok so I gave tor/opengl2 and tor/opengl3 a whirl. | 23:52.04 |
| | tor/opengl2 worked without problems. | 23:52.13 |
| | but tor/opengl3 crashed with: | 23:52.25 |
| | X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 136 (GLX) Minor opcode of failed request: 34 () Serial number of failed request: 40 Current serial number in output stream: 41 | 23:52.32 |
| | I'm unsure of how to debug this. | 23:52.42 |
| | I also briefly looked at the patches over at tor/master and I can't see anything strange in there. | 23:53.58 |
| | Forward 1 day (to 2013/08/31)>>> | |
IRC Logs