| | <<<Back 1 day (to 2012/09/02) | 2012/09/03 |
| sebras | kens: now I know why it crashes. I screwed up the digest sizes in pdf/pdf_crypt.c... | 01:50.38 |
| | kens: while the digest arrays can be made 64 bytes long it still seems to be the case that too much data is copied at the end of fz_sha512_final(). I've got to sort out why, but not now... | 01:51.46 |
| ray_laptop | GOOD MORNING, EUROPE !!!! | 06:51.55 |
| | (paraphrasing Robin Williams) | 06:52.17 |
| | you probably already know that tomorrow is our US "Labor Day" on which no one works (oxymoron day). | 06:53.36 |
| | I'll be checking in however as work (for my wife to get ready for school on Tuesday) permits ;-) | 06:54.32 |
| kens | Hi ray_laptop | 06:54.46 |
| ray_laptop | hi, kens | 06:54.48 |
| kens | Did you stay in Curry village in Yosemite ? ;-) | 06:54.58 |
| ray_laptop | kens: no, we stayed in the "Housekeeping Camp", which now having experienced both, I prefer. It it particularly better for families, and driving in with cars. | 06:56.11 |
| kens | So you're safe from Hantavirus then, pleased to hear it :-) | 06:56.32 |
| ray_laptop | kens: We did walk through the Curry Village tent area (the night before it hit the news and my sister called me with the alert) and enjoyed the buffet there for several breakfasts and dinners. | 06:58.03 |
| kens | I exepct the risk is pretty low, even if you actually stayed there | 06:58.33 |
| | Nasty sounding disease though | 06:58.49 |
| ray_laptop | kens: actually, since the hanta virus has an 'exposure to symptom' period of up to six weeks, we are keepig watch... | 06:59.12 |
| kens | Yeah, our news reported teh incubation period. | 06:59.30 |
| | Good to keep an eye out, but like I said I suspect the risk is actually fairly low, or a lot more cases would already have come to light | 06:59.58 |
| ray_laptop | kens: and it DOES sound nasty, but 2 fatalities out of 200,000 visitors isn't that bad | 07:00.01 |
| kens | Yes, that's what I mean, I'd have thought there would be a lot more if it was a serious outbreak | 07:00.46 |
| ray_laptop | kens: I suspect that more people die from falls or drowning in Yosemite. While we were there, a family lost 2 boys at Vernal Falls where we hiked the day after. We saw the posted signs for the one still misssing boy. | 07:02.22 |
| kens | Yes in deed, people have a very bad idea about risks.... | 07:02.45 |
| ray_laptop | kens: needless to say, we did NOT venture into the pools along the hike. | 07:02.57 |
| kens | Its amazing how many people think that posted warnings somehow don't apply to them... | 07:03.35 |
| ray_laptop | kens: we ALL had a fun time in the relatively placid Merced river along the valley floor. There were a few sections of fast current and a few areas of deep pools, but that made it a lot of fun. | 07:04.29 |
| kens | Sure, and I've kayaked and swum over some small falls too, but if a sign said 'dont' do this here' I'd pay attention :-) | 07:05.12 |
| ray_laptop | kens: wrt the hanta virus, I understand that they closed off a (very small) section of the curry village tent camp area as a result | 07:06.05 |
| kens | So it was only a few of the mice then :-() | 07:06.42 |
| ray_laptop | kens: I think that was the area my kids wanted to go explore (past the yellow tape) after dinner one evening. There were some wood sided cabins that we didn't know why were not occupied. | 07:07.51 |
| | kens: now, I guess we can figure it out ;-) | 07:08.28 |
| kens | Sounds like it, yes, probably best they didn't go in there.... | 07:08.34 |
| ray_laptop | but (as long as no disease surfaces) we had a great time there and the scenery there is INCREDIBLE. There is no where else in the world that I've been that there is such a variety of valley, meadow, falls, steep cliffs and hiking trails from almost flat to almost vertical climbs. | 07:11.57 |
| kens | Yes, I'd like to visit there one day, and teh Gran Canyon and possibly Death Valley (in what passes for winter there) | 07:12.32 |
| ray_laptop | Even the areas I've been in Switzerland can't approach it | 07:12.53 |
| | kens: Death Vallley doesn't really have much to offer unless you are into boredom (IMHO) | 07:13.37 |
| kens | I've never really visited Switzerland. I have crossed the border a few time, but only while on mountains | 07:13.40 |
| ray_laptop | kens: The Grand Canyon is nice, but it is SO BIG that it doesn't "focus" in like Yosemite. But the GC _is_ worth visiting if you are in the area. The GC is about 8 hrs from LA. Yosemite is about 7 (not much advantage to a triangle trip -- coming back to LA in between is about the same) | 07:18.24 |
| kens | The distances are the problem .... | 07:18.46 |
| ray_laptop | kens: I LIKED Switzerland, but Austria (where you HAVE been) is similar | 07:19.08 |
| kens | But once Melanie leaves home...... :-) | 07:19.17 |
| ray_laptop | kens: yes, to visit those sites here you need 2 to 3 weeks in the CA area | 07:19.57 |
| kens | Maybe one day. | 07:20.15 |
| | OK back to linearisation, but first... more coffee | 07:21.15 |
| ray_laptop | kens: but Yosemite has the giant (2,000 yr old) Sequoia trees which I think are unique to CA (also exist outside Yosemite) | 07:21.20 |
| | kens: OK. I'll go to sleep and let you work... (linearisation, YUCK) | 07:22.26 |
| | g'nite, all... | 07:22.50 |
| sebras | Robin_Watts: when I get back home I'll take a look at that pesky crypto code again. :-( | 08:12.31 |
| | Robin_Watts: I'm afraid I might have messed up the copying of the digest in at least four places. | 08:13.16 |
| | hello tor8. | 08:13.24 |
| kens | doesn't see a tor8 | 08:13.39 |
| sebras | kens: I do. | 08:15.12 |
| kens | I do now | 08:15.22 |
| | joined here after I wrote that | 08:15.32 |
| tor8 | morning kens, sebras | 08:15.41 |
| sebras | tor8: I have already said good morning to you. you're late. ;) | 08:16.01 |
| | tor8: there are some patches over at sebras/master that I hacked together during the weekend. see the logs for details. | 08:16.56 |
| tes-com | hello does anyone has experiance in installing the ghostscript on a terminal server ? | 09:46.19 |
| kens2 | Not that I am aware of, no | 09:46.42 |
| | Perhaps if you were to explain your actual problem ? | 09:47.16 |
| tes-com | i need support for setting op the security. a normal user is not able to start ghost script. A power user can start it. | 09:47.32 |
| kens2 | That is nothgin to do with Ghostscript, that's something to do with Windows security | 09:47.58 |
| | Presumably you need to modify Windows' security settgins | 09:48.42 |
| | I would think a Windows forum would be a more productive place to ask. | 09:49.02 |
| | You might also try Stack Overflow | 09:49.08 |
| tes-com | thanks will go searching on windows form and manufacture of application that uses the ghostscript. | 09:53.58 |
| Robin_Watts | Hope ray is OK... http://www.medicaldaily.com/articles/11877/20120901/cdc-10000-risk-hantavirus-yosemite-outbreak.htm | 10:08.39 |
| kens2 | See earlier in irc..... | 10:08.49 |
| Robin_Watts | ah, right. | 10:10.45 |
| | tor8: ping | 10:54.12 |
| tor8 | Robin_Watts: morning | 10:55.29 |
| Robin_Watts | I'm going to try to kick mupdfwrite a bit more into shape before the meeting (assuming nothing higher priority drops on me) | 10:56.07 |
| | Next step = images. | 10:56.14 |
| | It would be nice to be able to avoid recompressing images. | 10:56.35 |
| | In the fz_device interface we get given an fz_image pointer. | 10:56.56 |
| | And currently that has w/h/colorspace/mask and a get_pixmap function. | 10:57.18 |
| | I was pondering adding a get_compressed_stream function. | 10:57.37 |
| tor8 | Robin_Watts: right. didn't you add compressed image data to that? | 10:57.41 |
| | or was that all opaque in the get_pixmap function? | 10:57.59 |
| Robin_Watts | yes, opaque. | 10:58.10 |
| tor8 | right. do we care about preserving non-jpeg compressed image data? | 10:58.39 |
| Robin_Watts | so I'm thinking that some formats can choose to export a get_compressed_stream function, and others won't bother. | 10:58.47 |
| tor8 | I'd imagine preserving JPEG and recompressing everything else with Flate + Predictor would be the way to go | 10:58.56 |
| Robin_Watts | For now, jpeg is the main one. | 10:59.04 |
| | I'd like to preserve fax and jpx too if possible. | 10:59.19 |
| tor8 | maybe extend that to jbig2 and JPX | 10:59.20 |
| Robin_Watts | and jbig2. | 10:59.26 |
| tor8 | fax is hairy with all the parameters though | 10:59.33 |
| Robin_Watts | True. | 10:59.40 |
| tor8 | and I'm not sure it's a significant saving over just flate+predictor | 10:59.55 |
| Robin_Watts | Maybe we should have 'get_compressed_params' and 'get_compressed_data'. | 11:00.05 |
| tor8 | but jbig2, jpx and jpeg are worth keeping | 11:00.12 |
| Robin_Watts | get_compressed_params would give us the type. | 11:00.16 |
| | and a parameter block. | 11:00.23 |
| | get_compressed_data would then give us the stream. | 11:00.34 |
| | So we can avoid things asking for the stream and constructing it, only to find it's a format that the output can't cope with ? | 11:00.58 |
| tor8 | we'd want to reuse this for xpswrite as well, which can only handle jpeg (and tiff and png, but not worth worrying about) | 11:01.33 |
| | so jpeg is really the main one if looking for common denominators | 11:01.46 |
| | I guess you could hack in so that fax streams get wrapped in a tiff for xpswrite but that's overkill IMO | 11:02.25 |
| | still, easy enough to ask for compressed_params, and fall back to get_pixmap if it's not in a format the output can deal with | 11:03.16 |
| Robin_Watts | yeah. I'll have a bash. | 11:04.24 |
| | Thanks. | 11:04.29 |
| tor8 | Robin_Watts: I was thinking of doing the forms -> master merge before the meeting | 11:05.03 |
| Robin_Watts | cool. | 11:05.11 |
| tor8 | I think the only thing we're holding back on is the renaming list from paul? | 11:05.21 |
| Robin_Watts | We should do TheBigRename first though. | 11:05.28 |
| | yeah, paulgardiner said he would look at that today. paulgardiner ? | 11:05.40 |
| tor8 | sebras also mentioned the CMaps having been updated upstream, I should look at that as well | 11:06.05 |
| | and maybe take a look at the droid fonts, see if there are any news there worth caring about | 11:06.19 |
| Robin_Watts | and ray was disapproving of mubusy. | 11:06.22 |
| paulgardiner | Yes. Good intentions, but nothing but destractions. Only just started work proper 15min ago. But as you asked, I was doing the diff from which to derive the list of calls | 11:06.43 |
| tor8 | I read parts of that discussion. was it just the name or the concept? | 11:06.43 |
| Robin_Watts | tor8: The name, I think. | 11:06.56 |
| paulgardiner | Robin_Watts: were you happy with the commits you looked over? Don't look to have been pushed yet. | 11:07.31 |
| Robin_Watts | Currently mubusy just does pdf related stuff, right? So should we call it mupdftool ? | 11:07.32 |
| | paulgardiner: I was. | 11:07.40 |
| tor8 | Robin_Watts: I'm not fussed about the name. I'd have picked mutool myself, but the linking with busybox has merit too | 11:07.50 |
| Robin_Watts | I thought I'd pushed them, let me double check. | 11:07.53 |
| | paulgardiner: I pushed to the wrong repo, sorry. | 11:08.37 |
| | Pushed properly now I hope. | 11:08.42 |
| paulgardiner | Ta muchly | 11:08.49 |
| tor8 | Robin_Watts: yeah, at the moment it's all pdf specific and non-rendering | 11:08.57 |
| | mudraw is where we'd put the pdfwrite device isn't it? | 11:09.12 |
| Robin_Watts | tor8: I think so. | 11:09.22 |
| | It's where it's living at the moment. | 11:09.30 |
| tor8 | Robin_Watts: we *could* merge mudraw into mutool as well | 11:09.43 |
| Robin_Watts | That would suck XPS and rendering into it. | 11:10.03 |
| tor8 | in theory we could put the GUI tool in there as well... | 11:10.04 |
| Robin_Watts | and that would suck loadsacrap in too :) | 11:10.19 |
| | and add library dependencies etc. | 11:10.33 |
| knobo | Looks like I can not print documents reated with go 9.06 | 11:10.34 |
| tor8 | quite, and add dependencies on x11 and gui framework libraries which I'd rather not do for a command line tool | 11:10.43 |
| knobo | with gs 9.06 | 11:10.47 |
| Robin_Watts | I'd be happy to keep mubusy as 'just the pdf non rendering stuff'. | 11:11.03 |
| | hence mupdftool | 11:11.06 |
| tor8 | Robin_Watts: name's too long though | 11:11.28 |
| Robin_Watts | I could live with mutool | 11:11.37 |
| tor8 | mutool or mubusy would be my choices | 11:11.57 |
| | but renaming must annoy both users and distro maintainers... | 11:12.32 |
| paulgardiner | Worrying! The forms branch makes changes to cbz/mucbz.c. Does that sounds like a merging accident? | 11:18.41 |
| Robin_Watts | Sounds like an fz_document change to pass the context somewhere? | 11:20.23 |
| paulgardiner | I've been trusting git merge on files it doesn't show conflicts in. Maybe that was unwise. | 11:21.49 |
| Robin_Watts | http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=blobdiff;f=cbz/mucbz.c;h=f557236fa0963733bf3f92424a7b09abb84af2f8;hp=df6be18facfb844d99fbe9e436131823d9c89453;hb=forms;hpb=293ea3cb17baf14ad935880345092fbc531ab705 | 11:23.33 |
| tor8 | paulgardiner: no, I made one patch to how fz_document functions were inited on the forms branch | 11:23.36 |
| Robin_Watts | Doesn't look like a merge change. | 11:23.40 |
| tor8 | which affects cbz and xps | 11:23.50 |
| paulgardiner | WTF | 11:24.32 |
| Robin_Watts | How did I not spot that in review? | 11:24.36 |
| | Ah, maybe this happened in the git surgery you did? | 11:24.46 |
| paulgardiner | That's a messed up cherry pick | 11:25.12 |
| tor8 | http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=commit;h=acfcf144a708aa3afc739904dfafccbec48e64bb | 11:25.19 |
| Robin_Watts | Time for a force push :) | 11:25.23 |
| paulgardiner | ... but can't be because of the headline | 11:25.25 |
| tor8 | I put that commit on the forms branch because it affected the fz_interact function pointer too | 11:27.12 |
| paulgardiner | Phew! | 11:27.27 |
| | I still don't understand Robin_Watts's link having "Forms: rework..." as the title | 11:28.32 |
| tor8 | paulgardiner: it's a diff link | 11:31.48 |
| | not a commit | 11:31.53 |
| Robin_Watts | Sorry. It was the merge, I think. | 11:32.17 |
| paulgardiner | Ah right. Panix over. | 11:32.18 |
| | Panic even | 11:32.28 |
| | I should have realised that there are commits on the forms branch that I'm not going to recognise, anyway. | 11:33.38 |
| Robin_Watts | no, i'm still confused. | 11:33.53 |
| | tor8: Are you saying that the forms branch is correct, currently? | 11:34.29 |
| paulgardiner | I'm clinging to "it's a diff link" as an explanation of all. :-) | 11:34.30 |
| Robin_Watts | "diff to current". What the hell is "current" ? forms or master ? either way, I wouldn't expect to see that change in the diff. | 11:34.59 |
| | git diff forms master -- cbz | 11:35.43 |
| | That should be empty, but it's not. | 11:35.51 |
| | (or at least small) | 11:35.58 |
| paulgardiner | I'd have thought it should be empty if a merge has been done since the change was added to both master and forms | 11:37.09 |
| | On the other hand the diff shows the change being made not being reverted, so I'd guess things are ok. | 11:37.42 |
| Robin_Watts | master was merged into forms at 6a5b887 | 11:38.29 |
| | git diff 6a5b887..forms -- cbz | 11:39.01 |
| | That shows that something between the merge and the head of forms changed cbz. | 11:39.22 |
| | No, ignore it, that's me. | 11:39.45 |
| | OK, so tor8 has changed cbz in master after the forms merge. Sorry, finally caught up. | 11:40.31 |
| paulgardiner | Damn! And now I'm confused again | 11:41.50 |
| | But I've been diffing the point in master just before the merge with the head of forms. | 11:44.39 |
| tor8 | Robin_Watts: paulgardiner: I diffed master and forms a few days ago, and all diffs in cbz were expected | 11:48.40 |
| paulgardiner | tor8: Ah. I thought you were implying that you put the commit on both master and forms. Was this a commit to just the forms branch? Or was it different versions on each? | 11:48.51 |
| tor8 | just on forms | 11:48.59 |
| paulgardiner | Great fine. | 11:49.05 |
| | sorry | 11:49.08 |
| kens2 | ping chrisl | 12:10.28 |
| Robin_Watts | tor8: Do we support ColorTransform for DCT images? | 12:10.59 |
| tor8 | Robin_Watts: I've had difficulty finding and testing that feature | 12:11.31 |
| Robin_Watts | tor8: OK, so I'll preserve the flag even though we've never seen it used. | 12:11.53 |
| tor8 | Robin_Watts: hm, not good for xpswrite though | 12:12.21 |
| | how about not preserving it and refusing if it's set instead? | 12:12.36 |
| Robin_Watts | xpswrite can choose to drop back to recompressing. | 12:12.57 |
| tor8 | your choice though, just thinking about keeping down the complexity of the interface | 12:13.22 |
| chrisl | kens2: pong | 12:17.12 |
| mvrhel | Robin_Watts: you there? | 12:22.52 |
| sebras | tor8: droid has been updated. 2.51 -> 2.54b. in addition there is now a droidsanefallbackfull. no idea what the diffs are. | 12:23.00 |
| Robin_Watts | I am. | 12:23.01 |
| mvrhel | So I am looking at the 693312 | 12:23.18 |
| kens2 | chrisl could you have a poke at #693316 sometime this week please ? No rush | 12:23.19 |
| chrisl | kens2: I'm just cranking the handle on the SPARC now | 12:23.43 |
| Robin_Watts | mvrhel: Ok. | 12:23.44 |
| kens2 | chrisl I tried their file on Windows using the 9.05 and 9.06 releases and got noone of teh errors or warnings they describe | 12:23.51 |
| mvrhel | Robin_Watts: did alexcher ever finish up the softmask stuff that had your fix depending upon? | 12:23.52 |
| Robin_Watts | No. | 12:23.56 |
| mvrhel | Robin_Watts: ok. | 12:24.23 |
| Robin_Watts | If you want me to tickle it with memento, please say. | 12:24.37 |
| chrisl | kens2: The error does vaguely ring a bell, but I can't quite place it | 12:24.41 |
| Robin_Watts | Did you see my mail to marti this morning? | 12:24.45 |
| kens2 | chrisl the error with teh ICC profiles sounds vaguely familiar to me | 12:25.02 |
| mvrhel | Robin_Watts: ok. I am going to fool with it to see if I can get the memory leak stopped | 12:25.05 |
| kens2 | But they also give warnings when using -dUseFastColor and my release 9.05 doesn't | 12:25.21 |
| mvrhel | Robin_Watts: yes I did. I probably wont get to that until I get these 2 customer bugs done and my halftone stuff done. | 12:25.32 |
| Robin_Watts | If you're interested, my bmpcmp area currently contains the results for a gs run with 2.4 with the non-halftoning devices, and a threshold of 8. | 12:25.34 |
| | Fair enough. | 12:25.43 |
| mvrhel | I still have one last issue with copy_mono in the clist code | 12:25.49 |
| kens2 | chrisl of course, its entierly possible that these are also caused by the ICC profile link error | 12:25.59 |
| Robin_Watts | I'm hoping that Marti may say "Ah, well, I fixed some intent stuff in this version"... | 12:26.05 |
| chrisl | kens2: we will still use ICC profiles for non-base color spaces | 12:26.15 |
| kens2 | chrisl I wonder (given that they must be building it themselves) if they are not using a ROM file system and have screwed up their configuration. | 12:26.41 |
| | I have no confidence in their technical ability whatever | 12:26.58 |
| | And I fully believe it wouldn't occur to them to mention that they had built in a non-standard manner | 12:27.19 |
| chrisl | I'm not sure I'd credit them with the knowledge to build without the romfs | 12:27.53 |
| Robin_Watts | Has Miles said where we are staying yet ? | 12:28.00 |
| kens2 | Robin_Watts : not that I've seen | 12:28.11 |
| chrisl | Not that I've seen, no | 12:28.13 |
| kens2 | Maybe we can pick our own hotel ? :-) | 12:28.21 |
| | Mine's in Sydney, where are you guys going ? | 12:28.49 |
| Robin_Watts | The Mark Thomas is nice :) | 12:28.51 |
| | Mark Hopkins, even. Gah. | 12:29.42 |
| mvrhel | Robin_Watts: so these diffs dont appear to be so extreme | 12:29.49 |
| kens2 | Ah, wondered why I couldn't find it | 12:29.55 |
| mvrhel | I wonder if there is some diff in the black point stuff he his doing | 12:30.03 |
| Robin_Watts | mvrhel: Number 20 was the one I was worried about. | 12:30.14 |
| kens2 | Oh, near Nob Hill I see | 12:30.30 |
| Robin_Watts | kens: Pretty much at the top of Nob Hill, I think. | 12:31.25 |
| kens2 | OK so I now have a PDF file which is ordered the same as the output from mubusy, opens without error in Acrobat and is still not 'optimised for fast web view' | 12:31.52 |
| mvrhel | Robin_Watts: ok. I do see some saturation diffs in those | 12:32.10 |
| kens2 | Now I need to make the objetcs look more like the mubusy output | 12:32.11 |
| Robin_Watts | kens2: 1 or 2 pages ? | 12:32.14 |
| | I find that 1 page docs are not "optimised for web view" and I don't know why. | 12:32.34 |
| | mvrhel: And I'm at a loss to explain 168, but then that file is weird. | 12:33.41 |
| mvrhel | Robin_Watts: I will take a close look at this later in the week. Since file 20 is a special extreme case that I made, I am not too worried about it | 12:34.06 |
| Robin_Watts | mvrhel: OK. I'm out of my depth when it comes to stuff like this, hence me just flagging it up. | 12:34.34 |
| | I shall return to the nice shallow waters of mupdf :) | 12:35.10 |
| mvrhel | who knows what the deal is with 168... | 12:35.31 |
| | ok. back to softmask leaks | 12:35.39 |
| kens2 | Robin_Watts : the same old 2 blank page file | 12:39.27 |
| | Maybe when I find out why my fiel isn't optimised I can tell you why yours isn't ;-) | 12:39.54 |
| Robin_Watts | woo hoo! :) | 12:40.08 |
| kens2 | I wouldn't count on it though, I still can't see a problem with this file. | 12:40.36 |
| chrisl | kens2: a default 9.05 build completes without error for that file, with as much of their command line as I can reasonably. It *seems* they are disabling the romfs, given their -I options | 13:03.32 |
| kens2 | Pretty much wha I thought | 13:04.22 |
| | I bet tehy haven't supplied the profiles properly | 13:04.34 |
| chrisl | Do you want me to write that up on the bug? | 13:04.39 |
| kens2 | Please, I think they need to know | 13:04.47 |
| chrisl | Okay, I'm going to do a build without the romfs, and see if I can provoke the same error | 13:05.23 |
| kens2 | My guess is you will need t specify paths without the profiles | 13:06.04 |
| chrisl | I think they probably haven't got the icc profiles in <generic resource dir>/../iccprofiles | 13:08.06 |
| kens2 | Yes exactly | 13:08.17 |
| paulgardiner | Robin_Watts, tor8: I have a file containing a list of the functions added on the forms branch (I've included most of the static ones, perhaps unnecessarily). Whereever I've seen a need for a name change, I've inserted an @ at the beginning of the line and then added the alternative name at the end of the line. | 13:29.05 |
| | Should I send it to tech at artifex dot com ? | 13:29.48 |
| | When we've agreed the changes, I'll turn it into a script | 13:33.17 |
| Robin_Watts | paulgardiner: Sounds good to me. | 13:34.03 |
| chrisl | kens2: I'm getting strange (but the same the customer) errors when I set GenericResourceDir | 13:35.36 |
| kens2 | with 9.06 too ? | 13:36.02 |
| chrisl | Haven't tried it yet - has anything changed in that area. | 13:36.20 |
| | ? | 13:36.22 |
| kens2 | I don't remember :-( | 13:36.32 |
| | Just thought it was worth a try | 13:36.38 |
| paulgardiner | Ok, sent | 13:39.05 |
| chrisl | kens2: yep, the current master code - if I set GernericResourceDir, it fails to find any fonts | 13:40.59 |
| ||arifaX | I want to create a bounding file with gs on windows with gswin64.exe -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox input.pdf>bounding 2>&1 - it does not work where is the mistake (bounding file is 0 bytes) | 13:41.07 |
| kens2 | chrils I don't know who gets that one then | 13:41.15 |
| | try wihtout reidrection first ||arifaX | 13:41.45 |
| ||arifaX | kens2: that works. shows me gs widndows and seems to do the right thing | 13:42.03 |
| Robin_Watts | gswin64c.exe | 13:42.31 |
| | not gswin64.exe | 13:42.40 |
| ||arifaX | Robin_Watts: thanks, seems to work now.sorry for bothering you, that was an easy one :) | 13:44.14 |
| Robin_Watts | np. | 13:44.20 |
| | paulgardiner: pdf_get_field | 13:45.59 |
| | Why pdf_get_field_by_name ? | 13:46.04 |
| | Is there some other way to get a field? | 13:46.10 |
| paulgardiner | No. I wasn't altogether sure about that one either. | 13:46.44 |
| | I was also tempted by pdf_lookup_field, but probably best leave it as it is. | 13:47.11 |
| Robin_Watts | I'd personally vote for leaving it as is. The only reason to change it would be if there is another get method that is more common. | 13:47.33 |
| paulgardiner | Yeah. Sounds sensible to me | 13:47.54 |
| Robin_Watts | IIRC we had a naming convention in mind between lookup and get. | 13:47.57 |
| | but I can't remember what it was, or figure it out from the code. | 13:50.45 |
| | pdf_jsimp_toType needs renaming. | 13:52.11 |
| paulgardiner | Ta. Missed that one | 13:52.43 |
| Robin_Watts | Otherwise looks good to me. tor8? | 13:53.14 |
| | (and sebras?) | 13:53.23 |
| | Might need to mail it direct to sebras if he's got his mupdf hat on today. | 13:53.51 |
| paulgardiner | I still have some camelcase-named statics in pdf_js.c, but they are callbacks with names matching the javascript methods. I deleted them from the file to avoid confusion | 13:54.20 |
| | Good idea | 13:54.44 |
| tor8 | Robin_Watts: lookup and find was what we had | 13:54.50 |
| paulgardiner | sebras: ping | 13:54.50 |
| Robin_Watts | tor8: What was the difference? :) | 13:55.06 |
| | find returns something with a bumped refcount? | 13:55.27 |
| | That makes sense. | 13:55.34 |
| tor8 | refcounting | 13:55.35 |
| | find returns ownership, lookup just points you at it | 13:55.46 |
| Robin_Watts | yeah, I was trying to find evidence of that in lookup/get and failing :) | 13:56.06 |
| paulgardiner | tor8: are you happy with the suggested renamings, or have you not had a chance to look yet? | 13:56.30 |
| tor8 | paulgardiner: let me read through the list first :) | 13:57.53 |
| paulgardiner | No. No. Much more likely you'll have objections after reading it. :-) | 13:58.57 |
| sebras | paulgardiner: pong. I'll be with you proper in an hour or so. | 13:59.53 |
| tor8 | in general I have avoided "get" in accessors, but kept "set" for setters | 13:59.59 |
| | paulgardiner: like fz_pixmap_width, or pdf_cmap_wmode & pdf_set_cmap_wmod | 14:00.16 |
| paulgardiner | sebras: Thanks. I'll email the file to you | 14:00.21 |
| | tor8: Ok. I'll have a go - see how that works out. | 14:01.16 |
| Robin_Watts | Gah. Sanity check. If I do: o = pdf_new_int(blah); Then pdf_dict_puts(somedict, "SomeKey", o); I still need to pdf_drop_obj(o), don't I ? | 14:01.35 |
| tor8 | Robin_Watts: yes. you create it, you drop it. | 14:01.48 |
| Robin_Watts | Hmm. I wonder about a pdf_dict_puts variant that guarantees always to drop o. Would save a lot of boilerplate. | 14:02.43 |
| tor8 | paulgardiner: so for example, fz_first/next_widget if you want to be more "OO" I'd accept fz_widget_first (but not fz_widget_get_first, the get is just a filler word) | 14:03.48 |
| paulgardiner | tor8: fz_get_screen_update has to called repeatedly until there are no more screen updates. For some reason, I feel like leaving the 'get' in that name. Is that just me? | 14:03.50 |
| | tor8: fz_widget_get_first - yes agreed | 14:04.21 |
| tor8 | paulgardiner: well, it's not a regular "accessor" so I'm more okay with that use of get | 14:04.30 |
| | but for looping like that maybe fz_poll_screen_update ? | 14:04.43 |
| Robin_Watts | fz_widget_first. First what? | 14:04.49 |
| paulgardiner | Ah yes. Excelllent | 14:04.54 |
| tor8 | Robin_Watts: which is why I prefer fz_first_widget (but given the type, it probably should be fz_page_first_widget) | 14:05.34 |
| | (but not liking that name at all) | 14:05.54 |
| Robin_Watts | tor8: Yeah, I like fz_page_first_widget. | 14:05.58 |
| tor8 | or well, the asymmetry with next_widget probably | 14:06.15 |
| Robin_Watts | fz_widget_first means (to me) 'Get the FIRST from the WIDGET'. | 14:06.37 |
| | fz_first_widget/fz_next_widget is better. | 14:06.55 |
| paulgardiner | I like fz_page_first_widget too | 14:06.58 |
| tor8 | Robin_Watts: agreed. actually, now that I've both typed it and seen it typed, it's not so bad (fz_page_first_widget) | 14:06.59 |
| Robin_Watts | but fz_page_first_widget/fz_page_next_widget is nicer still (IMO) | 14:07.19 |
| | fab. | 14:07.23 |
| tor8 | Robin_Watts: was just about to say, we should make fz_page_next_widget(idoc, page, previous) | 14:07.57 |
| | and same for annots and other iterators | 14:08.16 |
| | or leave as it is with the old names | 14:08.49 |
| paulgardiner | tor8: because later implementations may need the page? | 14:08.50 |
| tor8 | paulgardiner: fewer exceptions to remember :) | 14:09.01 |
| paulgardiner | Yes | 14:09.08 |
| Robin_Watts | At the moment we don't pass in page. | 14:09.16 |
| | I'm wondering what that means about stuff that changes the list of widgets on a page while it's traversing a list. | 14:09.48 |
| paulgardiner | It possiblye makes sense to pass in page even if not used at the moment. | 14:09.48 |
| Robin_Watts | Suppose I ask for fz_page_first_widget, and then walk down the list, and delete every other widget I come to from the page. | 14:10.21 |
| paulgardiner | For now though I just want to change the names. Changing parameters with a script would be fun | 14:10.32 |
| Robin_Watts | Do we expect you to be able to continue iterating after a widget has been deleted? | 14:11.18 |
| | Anyone have any huge objections to (or a better name for) pdf_dict_putsd ? | 14:12.58 |
| | pdf_dict_puts_drop ? | 14:13.08 |
| paulgardiner | pdf_dict_puts_drop: what does it do in the failure case? | 14:14.05 |
| | Being forced to drop everything you create can be good thing | 14:14.21 |
| Robin_Watts | paulgardiner: From the moment you make the call, ownership is passed in. You are guaranteed it will be dropped, failure or not. | 14:15.41 |
| | That's the point of it. | 14:15.44 |
| | At the moment i'm having to do: | 14:15.50 |
| paulgardiner | If it drops even when it throws then it allows you to avoid using try/catch, but then there is danger if you insert a call to something else between creating and put | 14:16.02 |
| | I can see the attraction, but you might be setting up a trap for someone altering the code. | 14:16.46 |
| Robin_Watts | pdf_obj *o = NULL; ... fz_var(o);... o = pdf_new_int(...); pdf_dict_puts(dict, "Blah", o); pdf_drop_obj(o); o = NULL; .... } fz_always(ctx) { fz_drop_obj(o); } ... | 14:17.04 |
| | I'd rather be able to do: pdf_dict_putsd(dict, "Blah", pdf_new_int(...)); | 14:17.37 |
| paulgardiner | Ah. When used all on one line, it's much less setting a trap. | 14:18.07 |
| Robin_Watts | Yes. It's clearer and much less prone to error, I reckon. | 14:18.23 |
| paulgardiner | Rolling the pdf_new_int in too might be safer still, but then you need a whole family of such calls for the different cases | 14:18.53 |
| Robin_Watts | yeah. | 14:18.59 |
| paulgardiner | ... still might be worth it. | 14:19.00 |
| Robin_Watts | I dislike that much expansion in the number of calls, I think. | 14:19.46 |
| paulgardiner | I have loads of places in my code where pdf_dict_putsd would help | 14:19.56 |
| | I think it has my vote | 14:20.11 |
| Robin_Watts | pdf_write has a lot too. | 14:21.47 |
| paulgardiner | Back to fz_next_widget/fz_first_widget: shall I just leave it as it was for now? | 14:22.03 |
| Robin_Watts | And loads in my new pdf_device. | 14:22.08 |
| | paulgardiner: What I said before about using a sed script being good because it can be used on calling code too - that's not really an issue, as no one has written code to call the forms stuff yet. | 14:22.57 |
| | paulgardiner: Rename it to fz_page_first_widget/fz_page_next_widget and just don't change the params yet ? | 14:23.40 |
| paulgardiner | Yes, that just occurred to me a moment ago - which means a few hand-made changes too are no problem | 14:23.42 |
| | Ok | 14:23.52 |
| Robin_Watts | Though we (or I at least) have a poor track record at remembering to do such things later. | 14:24.20 |
| paulgardiner | ... and being that we don't need it to all be script driven, I could mabe change the parameter too. | 14:24.27 |
| | Hmmm. pdf_get_field? Somehoe pdf_field seems wrong. Should I make it pdf_find_field? | 14:28.38 |
| | pdf_name_to_field? :-( | 14:28.54 |
| Robin_Watts | It finds a field in a page? | 14:34.10 |
| | pdf_page_get_field | 14:34.20 |
| | Should that be lookup ? | 14:35.11 |
| | pdf_form_lookup_field ? | 14:35.35 |
| paulgardiner | Sounds ok to me. The returned object doesn't need freeing. Does that fit with other uses of lookup? | 14:38.06 |
| Robin_Watts | yes. | 14:38.45 |
| | find would imply needing freeing. | 14:38.55 |
| paulgardiner | Great. That'kl do nicely | 14:39.11 |
| | Sent an updated version of the file | 14:40.02 |
| tor8 | pdf_lookup_field sounds good | 14:43.27 |
| | or pdf_*_lookup_field. I still prefer pdf_first_widget over pdf_page_first_widget, unless you can enumerate widgets from more than one place (so the page is an implicit obvious thing, thus no need for it in the name) | 14:44.26 |
| Robin_Watts | Hmm. Does pdf_dict_puts look like it might leak in the case of an error to anyone else? | 14:45.12 |
| paulgardiner | Possibly not because it looks like pdf_dict_put cannot throw. | 14:46.51 |
| | It warns instead | 14:46.56 |
| tor8 | Robin_Watts: fz_*_puts_drop is my vote | 14:48.14 |
| Robin_Watts | pdf_dict_grow can throw. | 14:48.16 |
| | tor8: OK. | 14:48.22 |
| paulgardiner | Oh yes. That's unprotected | 14:49.18 |
| tor8 | but if you prefer the shortness of pdf_*_putsd that's fine too | 14:49.22 |
| Robin_Watts | shortness vs "being likely to spot the difference". | 14:49.57 |
| | I'd be happy either way I think. | 14:50.09 |
| tor8 | yeah, I think _drop might be safer | 14:50.19 |
| Robin_Watts | _drop it is. | 14:50.25 |
| tor8 | it's easy to miss the lone 'd' | 14:50.26 |
| Robin_Watts | Do we want putp_drop too ? | 14:50.39 |
| paulgardiner | Robin_Watts, tor8: Sent another copy of the file out | 14:50.42 |
| Robin_Watts | (I've not used putp yet personally) | 14:51.07 |
| paulgardiner | There are very few calls to it, but the majority would benefit from the drop version | 14:52.34 |
| tor8 | paulgardiner: pdf_choice_widget_set_value vs pdf_set_choice_widget_value (the latter is more in line with existing code, but less hierarchical naming) | 14:53.47 |
| | s/focussed/focused/ for US spelling | 14:54.15 |
| paulgardiner | Not sure about pdf_choice_widget_set_value. We seemed to have picked a fair number of hierarchical names amongst the ones we discussed before. | 14:55.45 |
| tor8 | fz_bound_annot should probably stay too (or be fz_annot_bounds / bbox) | 14:55.49 |
| | we have fz_bound_* for a lot of things already | 14:56.13 |
| | fz_make_ui_pointer_event ... what does it do? | 14:56.43 |
| paulgardiner | It sets up the passed in event to be a "mouse pointed" event using the other parameters | 14:57.52 |
| Robin_Watts | fz_make_ui_pointer_event is certainly better than fz_ui_event_pointer. | 14:59.23 |
| | (The latter sounds like a type, or a pointer to the current fz_ui_event) | 14:59.49 |
| paulgardiner | If we have pdf_set_choice_widget_value, should pdf_field_set_value become pdf_set_field_value? | 15:00.04 |
| | Robin_Watts: Yes, definitely an improvement | 15:00.24 |
| tor8 | paulgardiner: yes, pdf_choice_widget was just an example. I'm not sure which of the two forms to prefer. | 15:03.12 |
| Robin_Watts | My vote would be for hierarchical naming. | 15:03.40 |
| tor8 | paulgardiner: hm, we've used _init_ rather than _make_ for similar functions (to initialise a struct without allocating) | 15:03.41 |
| paulgardiner | I see good reasons for either and struggle to form an oppinion | 15:03.44 |
| | tor8: ah yes. Init makes more sense | 15:04.02 |
| | I guess I do have a slight preference for the hierarchical naming | 15:08.45 |
| | The hierarchical naming helps particularly when you have a single .h file defining the api | 15:09.59 |
| knobo | Where can I donwload old version of ghostscript to see if it will create printable pdf documents for my printer? | 15:12.14 |
| kens2 | knobo the downloads page for Ghostscript has an 'older versions' link at teh bottom | 15:12.44 |
| knobo | aha... | 15:13.02 |
| | Any known problems lately? | 15:14.30 |
| | Any recomended version? | 15:14.39 |
| kens2 | see bugzilla | 15:14.42 |
| | always recommended to use the latest version | 15:14.51 |
| knobo | Looks like the latest version produces documents that my printer does not want to print. | 15:15.24 |
| | I'm not sure what the problem is yet. | 15:15.40 |
| kens2 | Your printer prints PDF files ? | 15:15.42 |
| knobo | yes | 15:15.53 |
| Robin_Watts | knobo: You said that earlier, but as far as I can see you didn't tell us what printer or what system or... any details at all. | 15:15.56 |
| kens2 | Then I would suggest raising a bug report with your printer vendor ;-) | 15:16.16 |
| knobo | I had ubuntu installed, then I installed arch linux, now it does not work. | 15:17.02 |
| kens2 | Are you *SURE* your printer supports printing PDF files and that you are not using CUPS to convert the PDF fiels into PostScript ? | 15:17.33 |
| knobo | I don't use CUPS | 15:18.01 |
| | I use usb memory stic | 15:18.07 |
| kens2 | CUPS = Common Unix Printing System | 15:18.19 |
| | DOn't know what that has to do with a USB memory stick | 15:18.31 |
| Robin_Watts | You put the PDF file on the usb stick, put the stick into the printer, and it prints from the stick ? | 15:18.35 |
| knobo | Yes | 15:18.47 |
| Robin_Watts | Right. What printer? | 15:18.55 |
| kens2 | Ah right, NOW it makes sense | 15:18.55 |
| chrisl | knobo: what's the printer? | 15:19.02 |
| knobo | canon pixma mg5250 | 15:19.27 |
| kens2 | Well, I still suggest raising a problem report with Canon | 15:19.48 |
| knobo | But it worked fine as a network printer with ubuntu | 15:19.49 |
| kens2 | And you are sure Ubuntu wasn't converting it to PostScript ? | 15:20.06 |
| knobo | I don't know wich version of gs was there | 15:20.07 |
| | And I don't know of gs was used. | 15:20.24 |
| Robin_Watts | knobo: WIth ubuntu it probably went through cups, which would have called gs to conver the PDF -> PCL and sent the PCL to the printer. | 15:20.32 |
| kens2 | Exactly my thinking | 15:20.44 |
| Robin_Watts | Which requires *much* less smarts in the printer. | 15:20.51 |
| chrisl | There's no mention of PDF *printing* support on the canon page for that printer, that I can see | 15:21.03 |
| knobo | Well.. pdf files that is generated on the printer (scanner), and then printed out works fine. | 15:21.22 |
| Robin_Watts | how do you "print out" such pdf files ? | 15:21.39 |
| knobo | I put in the USB memory stick and choose the pdf file on the printer, and click ok. | 15:22.13 |
| Robin_Watts | It may just be that it can spot it's own pdf files (which are just images wrapped up in a known way) and extract the data from them, | 15:22.18 |
| | It doesn't mean it can cope with all PDF files. | 15:22.30 |
| knobo | I checked the version of the pdf file, and it was pdf 1.3, then I created an 1.3 versioned pdf file with gs, and it would not print. | 15:23.12 |
| kens2 | The Canon spec sheet is not exactly forthcoming about input formats | 15:23.18 |
| Robin_Watts | Try doing: gs -sDEVICE=pxlcolor -o out.pxl in.pdf | 15:23.37 |
| | Then copy out.pxl onto the usb stick and try printing that. | 15:23.53 |
| | (I'm sure chrisl will correct me if pxlcolor is the wrong thing to pick) | 15:24.15 |
| knobo | Aha.. I see.. You can print PDF files from a memory card/USB flash drive which satisfy the following conditions: PDF files made using MP Navigator EX (application software bundled with the machine) with PDF Compression on the PDF Settings dialog box set to Standard or High (Extension: .pdf) | 15:24.34 |
| chrisl | I dunno, as kens2 says, the spec page is not very clear...... | 15:24.42 |
| kens2 | I think that last statement is the important one knobo | 15:24.54 |
| | It can print its *own* PDF files, not anyone elses | 15:25.05 |
| knobo | then I understand | 15:25.17 |
| | it has it's own format, looking like pdf, named pdf, but it's not pdf. | 15:25.33 |
| chrisl | knobo: on the canon FAQ page it specifically excludes: "PDF files saved using application software other than MP Navigator EX (application software bundled with the machine)" | 15:25.34 |
| knobo | That makes sense. | 15:25.39 |
| chrisl | knobo: it's probably a "real" PDF, with something else "special" that the printer understands in the metadata] | 15:26.23 |
| knobo | So, then i should make pcl files, then. with the right driver. | 15:26.26 |
| Robin_Watts | yes | 15:26.35 |
| chrisl | Only if the printer uses PCL, which I'm certainly not sure about.... | 15:26.54 |
| Robin_Watts | chrisl: Canon pixmas are pcl based. | 15:28.57 |
| | (At least, mine is, I believe) | 15:29.05 |
| chrisl | Okay, well, it would be nice if they mentioned that in the tech specs - given that canon have their own PDLs, too | 15:29.36 |
| knobo | is PCL a standard format? Or is it like any other properatery format, that nobody knows except the producer? | 15:31.01 |
| kens2 | Its standard sort of | 15:31.13 |
| | HP publishes the specifications | 15:31.23 |
| | And tehn their printers conform in excitingly different ways to the spec | 15:31.35 |
| Robin_Watts | chrisl: You're right, I can't find it explicitly stated anywhere :( | 15:34.20 |
| | But canon do provide printer drivers and scanner drivers for linux. | 15:35.11 |
| | With sources even. | 15:35.15 |
| chrisl | knobo: here's a thought: if it worked on Ubuntu using cups, you could install the cups driver for the printer, and select "print to file" - that should get you a file you can put on your USB stick to transfer over. | 15:35.47 |
| Robin_Watts | kens/chrisl: http://freecoke.com - print a voucher, collect at heathrow on saturday :) | 15:47.33 |
| | tor8: OK. New issue. | 15:48.33 |
| kens2 | Hmm, doesn't seem to work properly in FireFox | 15:48.38 |
| Robin_Watts | freecoke.co.uk, sorry | 15:49.28 |
| kens2 | :-) | 15:49.35 |
| Robin_Watts | tor8: Are you transiting via the UK? | 15:49.54 |
| kens2 | Am I missing something it says on Monday 3rd | 15:50.42 |
| Robin_Watts | Right. Get the voucher today. | 15:51.02 |
| | but you have a while to redeem it. | 15:51.08 |
| kens2 | Ah, ok | 15:51.12 |
| Robin_Watts | Until the 17th I think. | 15:51.30 |
| knobo | Canon use this one I think: /usr/lib64/cups/filter/pstocanonij | 15:53.04 |
| Robin_Watts | tor8: When we pass an fz_image into the fz_device, we have no way of spotting that it's the same image several times. | 15:55.58 |
| | kens: presumably pdfwrite depends on the bitmap id for that? | 15:56.09 |
| mvrhel | kens2: is there an issue with pdfwrite and Bug693000.pdf | 16:01.26 |
| kens2 | ro no, we MD5 hash all objects and compare the hashes | 16:02.32 |
| | mvrhel not that I know of, let me look | 16:02.58 |
| Robin_Watts | kens2: ok. | 16:03.32 |
| kens2 | My tab completion isn't working :-( | 16:03.49 |
| | mvrhel, what problem are you seeing with this file ? I haven't tried it with pdfwite because it wasn't a pdfwrite problem | 16:04.22 |
| mvrhel | it errors out | 16:04.32 |
| | with pdfwrite output device for me | 16:04.37 |
| kens2 | What error ? | 16:04.44 |
| mvrhel | on a cluster push for a test it error out | 16:04.54 |
| kens2 | is fetching the file | 16:04.58 |
| mvrhel | so I ran it locally | 16:04.58 |
| kens2 | I bet this is a file marcos added recently | 16:05.32 |
| mvrhel | typecheck error | 16:05.53 |
| kens2 | I see | 16:06.20 |
| mvrhel | kens: I just want to verify that this is not my issue. I can't see how it can be based upon my change | 16:06.28 |
| kens2 | My immediate guess is that its something in the PDF itnerpreter | 16:06.36 |
| mvrhel | but the cluster came back with tests_private/comparefiles/Bug693000.pdf.pdf.pkmraw.300.0 i7b Error_reading_input_filetests_private/comparefiles/Bug693000.pdf.pdf.ppmraw.300.0 feet Error_reading_input_filetests_private/comparefiles/Bug693000.pdf.ps.pkmraw.300.0 alex_x6 Error_reading_input_filetests_private/comparefiles/Bug693000.pdf.ps.ppmraw.300.0 meters Error_reading_input_file | 16:06.46 |
| kens2 | mvrhel I don't believe it can be | 16:06.47 |
| | I suspect you are simply the lucky soul who first ran a test after marcos uploaded new test files | 16:07.12 |
| mvrhel | kens2: ok thanks | 16:07.34 |
| kens2 | Its trying to resolve outlines, which it will only do for pdfwrite, as rendering devices don't care | 16:07.48 |
| | I suspect its a PDF interpreter problem though. | 16:08.07 |
| mvrhel | kens2: do you want to open a bug on this or should I? | 16:08.29 |
| kens2 | mvrhel you found it :-) | 16:08.43 |
| mvrhel | ha. its going to be a pdfwrite bug... | 16:08.53 |
| chrisl | kens2: I suspec it's more likely the file is broken...... | 16:08.55 |
| mvrhel | if I file it | 16:09.06 |
| kens2 | mvhrhel please open it as a PDFF interpreter bug | 16:09.09 |
| chrisl | s/suspec/suspect | 16:09.11 |
| mvrhel | kens2: ok | 16:09.18 |
| kens2 | alex can send it to me if its not the interpreter, but form the look of it, I think it is | 16:09.39 |
| | and my tree is in some disorder at the moment so I can't debug it | 16:10.00 |
| mvrhel | kens2: ok. I will assign it to him | 16:10.18 |
| kens2 | thanks | 16:10.29 |
| mvrhel | done | 16:12.45 |
| | Robin_Watts: how come the commits don't chime in on #ghostscript-logs anymore? | 16:14.45 |
| Robin_Watts | No idea, sorry. | 16:15.00 |
| mvrhel | ok just curious | 16:15.07 |
| Robin_Watts | That's one for either ray or chrisl, I think. | 16:15.14 |
| | or possibly tor8. | 16:15.22 |
| mvrhel | ok. P1 mem leak fixed. labor day so off to pick some blueberries with the kids. bbiaw | 16:16.38 |
| Robin_Watts | have fun. | 16:17.19 |
| chrisl | Hmm, I'd never heard of #ghostscript-logs...... | 16:19.10 |
| kens2 | robin_Watts | 16:21.32 |
| Robin_Watts | KeNs | 16:21.38 |
| kens2 | in home/ken on casper are 2 PDF files | 16:21.41 |
| | out.pdf and mubusy.pdf | 16:21.47 |
| | If you open them in Acrobat munusy.pdf is linearised, out.pdf is not. can you see *anything* which looks like a problem ? | 16:22.13 |
| | Because for the next step I have to change the way I write objects, at the moment I copy them, MuPDF clearly doesn't | 16:22.42 |
| Robin_Watts | mubusy is not web optimised according to my one. | 16:23.00 |
| | according to my acrobat, sorry (Reader) | 16:23.12 |
| kens2 | acrobat pro says it is..... | 16:23.20 |
| | let me check again | 16:23.25 |
| | maybe I broke it | 16:23.30 |
| | Damn, looks like I did. I'll remake it | 16:23.47 |
| | Not good. | 16:24.38 |
| | Now when I remake it it isn't optimised either :-( | 16:24.47 |
| Robin_Watts | Well, we have consistency :) | 16:25.00 |
| kens2 | I'm sure it was OK before :-( | 16:25.11 |
| | Well, looks like your linearisation code has the same problem as mine then | 16:25.34 |
| | :-P | 16:25.42 |
| | Drat though, I was working on this by making my output look more like MuPDF | 16:27.20 |
| | I guess I'm going to have to work on making it more like Distiller, yuck | 16:28.48 |
| Robin_Watts | or making distiller more like your output. | 16:29.06 |
| | And seeing what you have to change to break it. | 16:29.16 |
| kens2 | I can't change the way Distiller works :-( | 16:29.19 |
| Robin_Watts | Text editor. | 16:29.31 |
| kens2 | Doens't help with object ordering, its hard to change that | 16:29.46 |
| Robin_Watts | hard, but not impossible. | 16:29.59 |
| kens2 | Not impossible I grant you, but still.... | 16:30.09 |
| | Well I'm going to put my code back the way it was this morning :-( | 16:30.25 |
| Robin_Watts | At some point I'll try fiddling with pdfclean some more to correct the (I thought harmless) mispositioning of the catalogue objects) | 16:31.11 |
| kens2 | Well my code positioned it 'correctly' before and it didn't help me ;-) | 16:31.35 |
| Robin_Watts | ALTHOUGH... I like having the catalogue objects up front, because if you implement a linearised reader the SANE way (where you just block on reading until the data is here), you need that up front. | 16:32.02 |
| kens2 | I agree, but that's not what the spec says :-) | 16:32.25 |
| | I know because I didn't believe it when I frist read it. | 16:32.38 |
| | But the point is that the hint stream gives you everything so you don't need the catalog or xref | 16:32.55 |
| | Assuming, of course, you actually use it. | 16:33.09 |
| Robin_Watts | Yeah. I suspect that most linearised readers read the object number of the first page from the dictionary in the hint stream, and then do everything else by blocking. | 16:34.58 |
| kens2 | If anyone actually uses this crap | 16:35.14 |
| Robin_Watts | Chrome will show the first page of a file as it downloads. | 16:36.46 |
| | but only the first page. | 16:36.52 |
| kens2 | Sure, but you can do that without even reading the hint stream | 16:37.01 |
| Robin_Watts | Right, that's what I'm saying. | 16:37.11 |
| | You have to read the object number of the first page from... somewhere. | 16:37.26 |
| | it's either in the linearisation dict or the hint stream dict. I can't remember which. | 16:37.39 |
| kens2 | Well, you could just look for /Page | 16:37.42 |
| Robin_Watts | but that's all you need. | 16:37.43 |
| | kens2: Hmm. You could I guess, but... | 16:38.01 |
| kens2 | Its in the hint stream dict, but you can find the end of the first page form teh linearisaation dict. | 16:38.03 |
| | So you can read everything to the end of page 1 | 16:38.13 |
| | BTW there's a implementation note that says the linearisation dict /H entry, the '[' has to be followed by a white space | 16:39.06 |
| | for Acrobat. | 16:39.12 |
| Robin_Watts | sheesh | 16:39.25 |
| kens2 | Damn, code is broken again. Well, I'll fix it tomorrow. | 16:39.53 |
| | Goodnigth everyone. | 16:39.58 |
| Robin_Watts | Night. | 16:40.11 |
| | Bah. mupdf pixmaps have alpha planes in them. | 17:26.58 |
| | I can't just make a stream from 'em. | 17:27.17 |
| | tor8: Does mupdf hold images upside down from PDF or something? | 18:04.30 |
| | I have mupdfwrite working for images (for my test file at least), but it's as if the image data is upside down. | 18:04.59 |
| | sorted. | 18:18.58 |
| tor8 | Robin_Watts: no, transiting via paris | 18:28.29 |
| | Robin_Watts: so which way was the image data? | 18:31.04 |
| Robin_Watts | It was upside down. | 18:31.16 |
| | My bitmaps.pdf file (same image flipped all 8 ways) is now rendering correctly. | 18:31.35 |
| ray_laptop | I saw in the logs about about TheBigRename. I assume that is renaming 'mubusy' to something more descriptive to a wider group | 18:35.05 |
| Robin_Watts | ray_laptop: Nope. | 18:35.39 |
| ray_laptop | In the initial discussion I mentioned that 'tool' (singular) vs. tools has an unfortunate slang usage (referring to the male anatomy) | 18:36.26 |
| Robin_Watts | This is renaming some of the functions within the forms branch to be in the same style as master. (i.e. camelCaseStyle to camel_case_style) | 18:36.38 |
| | ray_laptop: Yeah, but that doesn't in itself mean we shouldn't use the correct term. | 18:37.16 |
| ray_laptop | Robin_Watts: well, there was some discussion today about 'mutool' and 'mupdftool' -- I didn't understand what the 'BigRename' was, sorry | 18:37.36 |
| Robin_Watts | yes, it was discussed briefly. No firm conclusion was reached. | 18:37.58 |
| ray_laptop | Robin_Watts: yeah, but is is more than a single tool | 18:37.59 |
| Robin_Watts | It's a single tool with many blades. Like a swiss army knife :) | 18:38.17 |
| ray_laptop | Robin_Watts: or in this case more of a swedish army knife ;-) | 18:38.43 |
| Robin_Watts | MuBork! | 18:39.07 |
| ray_laptop | muknife ? | 18:39.26 |
| | mvrhel: so you are looking into the softmask buffer leak ? Great ! | 18:40.58 |
| Robin_Watts | ray_laptop: He's committed a fix already. | 18:41.21 |
| ray_laptop | mvrhel: Robin_Watts I just noticed. Hadn't gotten that far. | 18:43.02 |
| Robin_Watts | ray_laptop: Are you the guy with the CIA log in details? | 19:02.31 |
| | (ahem, I mean the website thing that spits out commits to #ghostscript-logs, not the other CIA) | 19:03.04 |
| | or marcosw or tor8? | 19:03.30 |
| marcosw | I'm not familiar with the CIA. | 19:04.09 |
| ray_laptop | Robin_Watts: sorry I just noticed your message. I am not familiar with that either. I think Ralph was the guy that did that. Why is there a log in for that ? | 19:58.08 |
| mvrhel | ray_laptop: did you get a chance to replicate the clist copy_planes issue that I have | 20:25.26 |
| ray_laptop | mvrhel: now that you fixed (mostly) the memory leak issue with cust 532's file, so I could verify that I had fixed the pattern issue I was having, I can move on to that. | 20:28.57 |
| | mvrhel: ahh -- test run just finished. I thought there was still a leak, but there isn't. instrumentation error. | 20:30.10 |
| mvrhel | ray_laptop: I would have been surprised that there was still a leak | 20:34.16 |
| | is that what you mean by mostly? | 20:34.47 |
| | ray_laptop: if you can't get the clist issue, I can work on it after I fix bug 693300 | 20:36.38 |
| ray_laptop | mvrhel: no, I can get to it now. I am just packaging up the fixes for cust 532 this PM | 20:38.34 |
| mvrhel | ray_laptop: ok thanks. I am seeing one extra byte between the read and the write when we get to the last plane (which happens to be the only one that gets compressed) | 21:02.33 |
| | I am going to work on bug 693300. But have to take the kids to the pool now. | 21:02.59 |
| | the other planes are shortened writes | 21:03.58 |
| ray_laptop | mvrhel: hmm... it wasn't an instrumentation problem. The original (not cut down) file still leaks :-( | 21:13.26 |
| | oh, the zzz.pdf cut down file leaks, but with -dBandHeight=128 (which is what the customer uses) | 21:15.26 |
| | mvrhel: sorry -- I just re-opened the bug with a variant command line that still leaks | 21:26.42 |
| | mvrhel: for the clist_copy_planes issue, there is a comment (that I guess documents some kind of invariant -- but not why): "/* We require that in the copy_planes case all the planes fit into a single cbuf. */ right after the label copy: | 22:09.50 |
| | but this doesn't take into account that even if it fits into a single 'cbuf' it _may_ not fit in the space remaining in the current buffer (from cldev->next to cldev->end). | 22:09.52 |
| | I don't know if this is part of the confusion or not -- still tracing, but I don't know what that comment is about. | 22:09.53 |
| | Robin_Watts: you appear to be the author of that code -- do you know what that comment means (why do we require this ?) | 22:27.33 |
| Robin_Watts | ray_laptop: Yeah, I'm probably the author of that. | 22:32.02 |
| | My ignorance of the code is showing there; I figured I might as well document my ignorance :) | 22:33.16 |
| | The non copy_planes code does a cmd_put_bits. | 22:34.23 |
| | The copy_planes bit then does additional cmd_put_bits. | 22:34.35 |
| | all of that happens within the RECT_RECOVER stuff. | 22:34.53 |
| | and if any of it fails to fit, we split the transfer. | 22:35.04 |
| ray_laptop | Robin_Watts: I think the problem is that we do the cmd_write_buffer in the cmd_put_list_op call and that inserts an 'end_run' for the band. I would expect this to confuse the reader since that extra byte (==0) gets inserted before the subsequent plane | 22:39.42 |
| | Robin_Watts: I think the 'fails to fit' test is the problem. It uses the 'cbuf_size' (which is 4095) but there are not 4095 bytes left in the BufferSpace (from cldev->next to cldev->end) | 22:41.19 |
| Robin_Watts | I think this is the code where we had a problem before. | 22:42.57 |
| ray_laptop | Robin_Watts: we may not need that cbuf_size bytes, but we do want to make sure that all the planes fit in the current bufferspace without writing the buffer | 22:43.12 |
| Robin_Watts | Previously the first plane fitted, but the others didn't, so we flushed the buffer, and then at the end we tried to go back and put the cmd header in, only to find it had gone already. | 22:43.32 |
| ray_laptop | Robin_Watts: probably so. I also looked at a similar description to this bug from mvrhel in bug 693234 | 22:43.44 |
| Robin_Watts | So I moved the cmd header writing stuff up. | 22:43.45 |
| ray_laptop | I think we need to do the cmd_write_buffer before the first plane if it isn't going to fit ALL planes in the cldev->cnext to cldev->cend area | 22:45.08 |
| Robin_Watts | ray_laptop: OK. I'll trust you on this because your knowledge of the clist is vastly more than mine. | 22:45.44 |
| ray_laptop | Robin_Watts: maybe. But it is a real mess ever since John DeRosiers added all that useless RECT_RECOVER stuff | 22:46.32 |
| | back in 1999 or so | 22:46.52 |
| | one of these days I may get ambitious and rip that stuff out. :-/ | 22:47.20 |
| | I _am_ getting rid of the band_complexity page_info hack (on one of my branches) | 22:48.06 |
| | so that there will ALWAYS be a per-band color_usage element | 22:48.37 |
| | that gets written to the clist and read back into a dynamically allocated array when rendering | 22:49.30 |
| | anyway, back to seeing if what I think is going on is the problem.... | 22:50.05 |
| sebras | tor8: 693314 updated and the decrypted object contents verified. | 23:10.51 |
| | Forward 1 day (to 2012/09/04)>>> | |
IRC Logs