| | <<<Back 1 day (to 2012/08/06) | 2012/08/07 |
| tor8 | Robin_Watts: ping | 09:26.50 |
| Robin_Watts | pong | 09:26.58 |
| tor8 | did you book flights for september yet? | 09:27.13 |
| Robin_Watts | ages ago, yes. | 09:27.24 |
| tor8 | right. which dates? there was some confusion there in the emails. | 09:27.42 |
| Robin_Watts | I fly (and land) on the 8th. | 09:27.55 |
| | I fly back on the 10th and land on the 11th. | 09:28.07 |
| | So the meeting is 9 and 10. | 09:28.13 |
| | Ken and Chrisl are on the same plane. | 09:28.21 |
| tor8 | right, sunday/monday meeting | 09:28.30 |
| kens | yup, sent mail to Miles last night confirming that | 09:28.36 |
| | Fly in Saturday pm out Monday pm | 09:28.50 |
| tor8 | thanks. | 09:29.06 |
| | sigh. my favorite afternoon flight has doubled in price :( | 09:39.35 |
| kens | Should havebooked it earlier ? | 09:39.55 |
| tor8 | probably. | 09:40.24 |
| Robin_Watts | booking a month before is going to be more expensive than booking 3+ months before when the dates were agreed, | 09:50.18 |
| | but even so, this trip was mor eexpensive than I remember the others being. | 09:51.41 |
| | (750ukp) | 09:51.52 |
| tor8 | Robin_Watts: not very much more expensive in my experience, just fewer options open | 09:52.09 |
| | but all prices were higher than they used to be | 09:52.27 |
| | and it looks like air france is back among the lower priced airlines again | 09:53.12 |
| Robin_Watts | They are one of the airlines in my "try to avoid" list. | 09:53.55 |
| kens | never flown with them | 09:54.24 |
| Robin_Watts | Better only than Ryan Air and Iberia. | 09:54.27 |
| | Air France merged with KLM, and I dislike KLM. | 09:54.44 |
| | run. bbs. | 09:55.48 |
| tor8 | odd, I used to like KLM :) | 09:58.20 |
| Robin_Watts | damn. flat ipod. run delayed. | 10:00.02 |
| | So 2400 diffs are caused by the openjpeg change. | 10:04.41 |
| | Let me run a test with all the changes *except* the openjpeg ones. | 10:04.56 |
| | Why does 90% of the bmpcmp time seem to be "waiting for n jobs to finish" ? | 10:36.01 |
| paulgardiner | In a PDF stream, if the filter is ASCIIHexDecode, is it odd for the stream to have a '>' at the end? | 11:00.31 |
| chrisl | The '>' is the EOD character for ASCIIHexDecode | 11:03.49 |
| paulgardiner | Oh ok thanks. | 11:06.20 |
| | I was aware of the use within strings(with < at the start), but not streams | 11:09.23 |
| chrisl | It's not unkown in PDF for the '>' to be missing | 11:10.11 |
| Robin_Watts | I just pushed sebras fixes onto golden. So why aren't they showing in the cluster? | 12:12.18 |
| sebras | Robin_Watts: yey! and I don't know. | 12:12.58 |
| kens | No idea, I have the commit emails | 12:14.21 |
| | and my test is runing already, so I'm happy :-) | 12:14.39 |
| | 5 more commit emails.... | 12:19.28 |
| Robin_Watts | If they don't trigger when kens test finishes I'll go digging. | 12:22.33 |
| | ok, mupdf on the cluster had got confused. | 12:29.04 |
| | That's better. | 12:33.06 |
| kens | Wow.... | 12:33.14 |
| Robin_Watts | yeah. | 12:33.29 |
| | Thankfully mupdf tests are fast. | 12:33.59 |
| kens | Hmm, lots of timeouts with my libearisation code, which is no surprise at all I suppose :-( | 12:34.00 |
| Robin_Watts | Queue should clear by 6-7pmish with luck. | 12:40.20 |
| kens | Well I can jumop in if needed | 12:40.36 |
| Robin_Watts | yes, user jobs get priority etc, and you only need to wait 6-7 mins to get a slot. It's better than being stuck behind gs pcl xps ls jobs. | 12:41.17 |
| sebras | Robin_Watts: is there a test run for each of my patches? | 12:43.48 |
| Robin_Watts | yes. | 12:43.55 |
| sebras | ah, then I understand kens' awe... | 12:44.10 |
| | it has got to be many. :) | 12:44.20 |
| Robin_Watts | If you ever do a change that you consider doesn't need a test run (say a change purely in comments) then you can put CLUSTER_UNTESTED in the commit message. | 12:44.31 |
| | http://ghostscript.com/regression/ | 12:44.43 |
| | sebras: I see that you aren't set up to use the cluster. | 12:44.51 |
| sebras | no, I'm not. | 12:44.58 |
| Robin_Watts | You have an account on casper, so you could be if you wanted. | 12:45.05 |
| sebras | oh, but why would we want to pollute the commit message with comments like that? | 12:45.25 |
| Robin_Watts | sebras: because all the cluster sees is the commit. | 12:45.45 |
| | And the assumption is that every commit gets tested (except for ones that are explicitly noted as not being tested). | 12:46.14 |
| sebras | mmm, I realized that. | 12:46.25 |
| | ok, good to know atleast. | 12:46.37 |
| Robin_Watts | Testing every commit isn't really a problem for mupdf (6-7 minutes is fine). For gs/xps/pcl/ls changes the cluster takes more like 35-40 (assuming no nodes are down) | 12:47.13 |
| | ANd I've spotted what's wrong with my linearised file. After lunch I shall try to find out why... | 12:57.36 |
| | Did anyone hear from henrys how his race went? I forgot to ask yesterday | 12:57.51 |
| kens | Didn't hear | 12:58.34 |
| sebras | Robin_Watts: what is wrong with the file? | 12:59.10 |
| Robin_Watts | sebras: on the trunk, many things. | 13:40.37 |
| | on my current local master, I'm outputting a short image. | 13:40.51 |
| mvrhel_laptop | chrisl, Robin_Watts and kens: I am probably going to miss the meeting this morning. But if you had anything for me I am here now | 14:13.54 |
| Robin_Watts | mvrhel_laptop: Hi. Nothing from me. | 14:14.09 |
| | Anything you want brought up at the meeting ? | 14:14.18 |
| kens | mvrhel_laptop : nope nothign from me | 14:14.30 |
| mvrhel_laptop | no. I am working on more color enhancements for customer 330 and also working on having the option of putting images already halftoned into the clist when the size makes sense (and the output device is halftoned) | 14:16.25 |
| | that last item is stuff that has been going on forever, since the days we did the SIMDI threshold stuff | 14:17.15 |
| henrys | Robin_Watts:I finished but very slow, crumbled in the half marathon because of temps, but now I've done the half, got to do the full. | 14:19.05 |
| mvrhel_laptop | nice | 14:19.16 |
| | is it the same time of the year each time there henrys? | 14:19.41 |
| henrys | yes the Boulder Half is always first week of August. | 14:20.37 |
| | I need sea level and cooler to do the full, I'm shopping. | 14:21.17 |
| Robin_Watts | henrys: Well, congratulations for making it anyway! | 14:21.25 |
| | henrys: Alcatraz! | 14:21.30 |
| mvrhel_laptop | henrys: the one at Core de Lane (spelling) looked interesting | 14:22.58 |
| henrys | I'll put in for alcatraz but it's a lottery and it isn't a full ironman. | 14:23.38 |
| Robin_Watts | But would look way cool on a race cv. | 14:23.58 |
| henrys | mvrhel_laptop:oh idaho - maybe | 14:26.12 |
| Robin_Watts | henrys: Hawaii? | 14:26.46 |
| | There is one on Big Island. | 14:26.55 |
| | Probably not 'cooler' though. | 14:27.18 |
| | (Cycling across lava flats in the burning sun...) | 14:27.41 |
| henrys | Kona is no longer for the mortals - qualifying wise. | 14:28.35 |
| Robin_Watts | paulgardiner, tor8, henrys: Meeting in 15 ? | 14:47.19 |
| paulgardiner | yep | 14:47.28 |
| henrys | right | 14:48.20 |
| | pipitas:is pdftk still active? the last news release I see is from 2010 and I know the mac os x port has been broken for some time now? | 14:52.41 |
| | (6) Saving yeah! | 15:00.04 |
| | I wanted to ask about documentation - I think we need some sort of write up about all of this so developers can get their heads around it. Thoughts? | 15:01.26 |
| | sorry that was for the pdf forms meeting. | 15:02.05 |
| Robin_Watts | henrys: You're probably right. | 15:02.45 |
| paulgardiner | yeah. Trying to think what we need to tell them | 15:03.13 |
| | I don't think I've seem the existing documentation. | 15:03.50 |
| Robin_Watts | yes you have. You've read it all. | 15:04.00 |
| henrys | maybe that should just go on the todo list. | 15:04.11 |
| paulgardiner | Robin_Watts: {} ? | 15:04.57 |
| Robin_Watts | The existing documentation is just the stuff in the headers. | 15:05.18 |
| henrys | paulgardiner:you mean for mupdf in general? | 15:05.23 |
| Robin_Watts | We have no higher level overview text. | 15:05.44 |
| paulgardiner | yes. That's what I was thinking. | 15:05.56 |
| Robin_Watts | Actually, that's not true, sebras did us some stuff in docs. | 15:05.58 |
| | doc/overview.txt, and the associated examples in doc. | 15:06.39 |
| | It's not a lot, but it's enough to get people up and started. | 15:06.51 |
| | If we have to do more documentation, I'd really like to do it on a Wiki. | 15:07.19 |
| henrys | something along the lines of the doc overview and some examples would be fine for a start, I think. | 15:09.02 |
| sebras | henrys Robin_Watts: if there is a need for more documentation, just let me know. | 15:10.02 |
| paulgardiner | I wondered, since saving hasn't seemed to throw up any problems and we have simple support for choice now, whether we should reconsider the August alpha release. | 15:10.10 |
| henrys | it might be worthwhile for sebras to do it. Have another set of eyes look at what we have would be usefult. | 15:11.01 |
| | is tor8 about? what do you want to do? | 15:11.24 |
| mvrhel_laptop | bbiaw | 15:11.47 |
| tor8 | august alpha for forms? I've no opinion either way, I'll go along with whatever robin and paul want. | 15:13.01 |
| Robin_Watts | I'm against putting a forms -> master merge in before the august release. | 15:13.32 |
| henrys | I'd certainly like it, but Robin_Watts vacation is coming up fast. | 15:13.43 |
| Robin_Watts | but I am not averse to the idea of doing a separate forms release. | 15:13.45 |
| henrys | or I hate to say it we delay the mupdf release to September w/ forms. | 15:14.20 |
| Robin_Watts | henrys: I'd still rather do 2 releases. | 15:14.37 |
| | Doing the merge is easy. | 15:14.48 |
| henrys | okay 2 releases is fine. | 15:14.57 |
| paulgardiner | Oh. I should mention I have another vacation coming up 10-14 sept | 15:14.59 |
| Robin_Watts | (paulgardiner merged master into forms, no problems the other day) | 15:15.12 |
| henrys | do we want sebras to flesh out some documentation? | 15:15.30 |
| | or hold off on that. | 15:15.40 |
| | ? | 15:15.41 |
| Robin_Watts | paulgardiner: We have a meeting from 8->11 in sf, so we'll be jet lagged for the forms meeting that we won't be having. | 15:16.00 |
| paulgardiner | :-) | 15:16.16 |
| Robin_Watts | My vacation is next week, btw. | 15:16.46 |
| paulgardiner | Might be an idea to hold off on docs until Tor has had a chance to look ove the api. It's likely to need name changes if nothing else. | 15:17.14 |
| Robin_Watts | I don't think it would hurt to have sebras do overview docs now. | 15:17.15 |
| | The doing of the docs may well provide the catalyst we need for checking the APIs. | 15:17.45 |
| paulgardiner | That's a good point. | 15:17.57 |
| Robin_Watts | I believe sebras has looked over the forms stuff a bit already. | 15:18.17 |
| henrys | sebras whatever hourly arrangement you had in place with artifex for the other documentation project should be okay. If there are any billing questions, email me. | 15:19.06 |
| Robin_Watts | And sebras is 1 day into his vacation and has maxed out the cluster already, so we need to slow him down a bit :) | 15:19.24 |
| tor8 | two releases it is. I've got an iOS bug fix in the works I want to squeeze in before release. I'll be away on thursday afternoon and friday so we should do the release candidate tomorrow. | 15:20.16 |
| sebras | henry: alright. | 15:20.35 |
| Robin_Watts | tor8: I'm trying to get the linearisation stuff fixed at the moment. | 15:20.38 |
| | I *think* (famous last words) that it's stable now. | 15:20.47 |
| henrys | Robin_Watts:I hadn't gotten through my mail, I see sebras really has been heating up my office. | 15:20.47 |
| tor8 | Robin_Watts: right, so maybe we should hold off for another week? | 15:20.48 |
| sebras | henrys: sorry about that. :) | 15:21.13 |
| Robin_Watts | but I still have 1 file that looks linearised to me, but acrobat says "no!" | 15:21.17 |
| henrys | sebras:no problem keep it up! | 15:21.41 |
| Robin_Watts | I'm hoping that the mad diffs with the new thirdparty.zip will calm down when I retest when the cluster catches up. | 15:22.11 |
| henrys | anything else for the meeting, progress looks great like always paulgardiner | 15:22.40 |
| Robin_Watts | tor8: Lets try to get a candidate out tomorrow. | 15:23.02 |
| | I'll get *something* committed for the linearisation stuff today. | 15:23.35 |
| | henrys: I'm done. | 15:23.50 |
| paulgardiner | I don't know much about the release procedure, but if there's anything I need to do, I'm sure someone will let me know. | 15:24.26 |
| Robin_Watts | paulgardiner: Release procedure = we all hide, and tor8 and chrisl swear a lot and throw things. | 15:24.55 |
| paulgardiner | I may get to point where I'm uncertain of priorities soon, but again I can easily ask here when I get there. | 15:25.00 |
| | Robin_Watts: that sounds like fun. We could do with web cams then, not just IRC. | 15:26.05 |
| henrys | harder to hide. | 15:26.32 |
| paulgardiner | True. Just web cams for tor8 and chrisl then | 15:27.00 |
| henrys | so we're adjourned | 15:27.06 |
| | paulgardiner:right | 15:27.12 |
| paulgardiner | Yep. Adjourned. I'll chip in again when I realise what I've forgotten to bring up. | 15:27.58 |
| Robin_Watts | paulgardiner: Did you get to check how it behaves after you save a file? | 15:28.28 |
| | (i.e. does link following still work, and page flipping go to the right pages etc?) | 15:28.50 |
| paulgardiner | Robin_Watts: no. Thanks for the reminder. I'll give that a go now. | 15:29.11 |
| Robin_Watts | Can anyone see why http://ghostscript.com/~robin/out.pdf is not a linearised file? | 15:31.17 |
| | kens in particular^ | 15:31.25 |
| paulgardiner | Robin_Watts: when you have a moment, could you take a look at my latest bmpcmps? | 15:37.55 |
| Robin_Watts | paulgardiner: Ah, sorry. | 15:38.18 |
| | I'm testing a new thirdparty.zip file, that contains a new freetype. | 15:38.31 |
| kens | give me a minute Robin_Watts | 15:38.47 |
| Robin_Watts | And that new thirdparty.zip is being used in the cluster for user based pushes at least. | 15:39.04 |
| | hence small text differences like that are probably down to freetype - sorry. | 15:39.23 |
| paulgardiner | Right. That explains it. Confused the hell out of me. The other day some of the fonts seemed to grow serifs. | 15:39.28 |
| Robin_Watts | The other day? | 15:39.40 |
| paulgardiner | That would have to be last week. | 15:39.53 |
| Robin_Watts | This has only been today and yesterday afternoon. | 15:40.02 |
| paulgardiner | Could the choice of cluster machine make a difference, say for a fallback font or something. | 15:40.46 |
| Robin_Watts | Shouldn't do. All mupdfs fonts are embedded. | 15:41.01 |
| paulgardiner | Definitley has one case of the diffs showing a font with serifs agaist another without. | 15:41.38 |
| | Sorry, should have mentioned it at the time. | 15:41.53 |
| Robin_Watts | What number? | 15:41.56 |
| | Was that after you merged master to forms? | 15:42.16 |
| paulgardiner | Ah yes | 15:42.22 |
| Robin_Watts | tor8 did some stuff which improved fallback. | 15:42.35 |
| paulgardiner | And that would make sense | 15:42.39 |
| Robin_Watts | (style simulations) | 15:42.43 |
| paulgardiner | Ok great. All makes sense. | 15:42.57 |
| Robin_Watts | If you want to rerun your test, I can put the old thirdparty back. | 15:43.13 |
| paulgardiner | I'd forgotten it was on the merge. That's why I wasn't too concerned at the time and didn't mention it. | 15:43.24 |
| kens | Robin_Watts : I can't see anything obviously wrong with your file | 15:44.53 |
| | I haven't checked all the ofcfset and lengths exhaustively | 15:45.09 |
| | Hmm Robin_Watts acording to the spec, teh pages tree shoud be in part 9 | 15:48.39 |
| | Not part 4 | 15:48.47 |
| Robin_Watts | I always put the pages tree in part 4, and other files are happy. | 15:49.46 |
| kens | OK I'm just trying to find anything which is 'wrong' according to the spec | 15:50.06 |
| Robin_Watts | yeah, I appreciate it. | 15:50.13 |
| kens | I suppose it could be the hint stream, I don't know anything about that yet | 15:51.53 |
| chrisl | kens: does Acro X PreFlight check linearisation? | 15:52.54 |
| kens | chrisl sadly not, I checked | 15:53.05 |
| | But the Acrobat properties dialog says its NOT 'optimised for fast web view' | 15:53.26 |
| chrisl | Of all the things it would be good to check, linearisation would be high on the list :-( | 15:53.48 |
| kens | I might have missed it, there's a lot of profiles in the dialog | 15:54.17 |
| chrisl | I just tried PDF Syntax Issues - since the Linearised key is there, if the file is *not* linearised, that should be a preflight error, I would say | 15:55.07 |
| kens | says its OK when I try that | 15:55.49 |
| chrisl | Yeh, me too - another epic fail for the Acrobat preflighter! | 15:57.18 |
| kens | Grr if I save it from Acrobat it comes out linearised, but a 1.5 PDF with compressed streams so I can't really figure it out | 15:57.56 |
| Robin_Watts | kens: yes, acrobat is a real ass here. | 15:58.39 |
| kens | I can save as PDF and go to version 1.4, if I do that it tells me there is an error saving the dopcument. | 15:59.21 |
| henrys | on to the meeting... | 15:59.30 |
| kens | But not what the error is.... | 15:59.31 |
| henrys | chrisl:are we good with the releases? | 15:59.40 |
| | I don't like the openjpeg change but I'm happy to be overruled. | 16:00.06 |
| chrisl | Which OpenJPEG change? | 16:00.26 |
| Robin_Watts | henrys: You don't like what openjpeg change? | 16:00.44 |
| henrys | weren't we debating an openjpeg security fix? | 16:00.46 |
| Robin_Watts | chrisl types faster. | 16:00.51 |
| chrisl | henrys: yes, alexcher did the patches for our 1.4+ and they are pretty trivial, so...... | 16:01.22 |
| Robin_Watts | we were either going to move to openjpeg 1.5 + security fixes, OR we were going to just take those security fixes into our existing 1.4. | 16:01.29 |
| ray_laptop | henrys: I think we have to be aggressive with security issues that are pointed out to us | 16:01.35 |
| kens | Robin_Watts : I got it to produce a linearised version 1.4 of your file. | 16:01.45 |
| Robin_Watts | The latter sounds sensible. | 16:01.49 |
| ray_laptop | alexcher: patched our 1.4 | 16:01.50 |
| Robin_Watts | kens: Ah. Can I see it please? | 16:02.09 |
| ray_laptop | so I think we should cherry pick that patch in | 16:02.16 |
| | (if it isn't already) | 16:02.21 |
| kens | I'll mail it, obviously all the offsets are different.... | 16:02.28 |
| | Robin_Watts : on its way now | 16:03.06 |
| chrisl | henrys: I think all but one of the openjpeg patches was increasing a buffer size, those should be very safe | 16:03.31 |
| henrys | okay you can simply put the path on the website and not fool with the release but I don't feel strongly about it. It's not the last security problem in gs | 16:03.33 |
| | s/path/patch | 16:03.43 |
| ray_laptop | henrys: probably not, but it is one that we know about that has been publicized and that heightens the seriousness | 16:05.05 |
| henrys | kens and all: I was asking pipitas about pdftk because I was thinking we should try to move into that niche - we already do mostly everything pdftk and it may get more folks looking at gs. What do you think? | 16:05.18 |
| | ray_laptop:fair enough | 16:05.41 |
| kens | henrys sounds more like a job for MuPDF than GS | 16:05.44 |
| | MuPDF is much better designed for that kind of work | 16:05.57 |
| | well, designed at all.... | 16:06.07 |
| henrys | kens:good point | 16:06.23 |
| chrisl | henrys: anyway, as far as I'm concerned, unless anyone tells me different, I intend to do the release tomorrow. | 16:06.31 |
| ray_laptop | kens: not as much a house of cards :-) | 16:06.34 |
| henrys | moving into that space might not be more that just be doing some better documentation. | 16:07.39 |
| | tor8? | 16:07.54 |
| kens | Robin_Watts : assuming your offsets and hint stream are OK there are only 3 major differences I can see. The Acrobat file has the page tree in part 9, your file has no Metadata and is also missing an Info dict | 16:08.00 |
| ray_laptop | henrys: certainly less work than fomrs in mupdf | 16:08.32 |
| henrys | anyway maybe I'll add it to the next agenda. It is not clear we'd get on potential customers radar with that move, but it's a thought. | 16:09.45 |
| Robin_Watts | So, let me try adding Info and Metadata | 16:10.18 |
| kens | Robin_Watts : It seems unlikely those are the problem, but, well I could be wrong | 16:10.36 |
| | Info dict is optional in the spec | 16:11.53 |
| henrys | the only other thing I had for the meeting was to remind everyone to hack on projects they signed up to do last meeting. I don't see a lot going on for a few of the projects. | 16:12.14 |
| kens | doesn't remember what he signed up for.... | 16:12.39 |
| henrys | PDF/A-2, pdf server which I believe you did. | 16:13.27 |
| kens | Oh good :-) | 16:13.41 |
| | Robinqq /Metadata is optional as well | 16:13.54 |
| pipitas | henrys: No, I don't know about any updates to pdftk since ca. Oct 2010 neither. Didn't use the MacPorts version often yet so I didn't notice any b0rkenness that's different from other ports. Which things did you have in mind? | 16:14.02 |
| henrys | kens:I think you are okay - there is still handling large files in pdfwrite 692290 which we agreed was sort of a background thing. | 16:15.01 |
| kens | Robin_Watts : I am interested to note that the Acrobat primary xref is 0->4 and not 0->9 which I woudl have expected based on the example in teh PDF spec | 16:15.04 |
| henrys | if anybody else needs their project let me know. | 16:15.21 |
| kens | henrys, that's still on my radar, learning mroe about it with this linearisation stuff too | 16:15.22 |
| Robin_Watts | kens: Removing the Info from robin3.pdf still leaves it linear. | 16:15.30 |
| kens | Robin_Watts : Not surprised | 16:15.41 |
| henrys | I guess tor8 and chrisl are coordinating a mupdf release. | 16:16.17 |
| | also | 16:16.25 |
| kens | I presume Acrobat is happy with the overall structure because it doesn't offer to 'save changes' on close. WHich it normally does if it fixes xrefs | 16:16.36 |
| Robin_Watts | kens: indeed. | 16:16.48 |
| chrisl | henrys: not much coordination needed, I just wait until tor8 does his release, then I'll do the commercial one.... | 16:16.58 |
| Robin_Watts | I've removed metadata from robin3.pdf and it's still linear. | 16:17.13 |
| kens | Robin_Watts : which leaves me struggling.... All I cna think of is the location of the page tree, or a fault in the primary hint stream | 16:17.35 |
| henrys | okay anybody else have stuff for the meeting? | 16:17.36 |
| kens | Not me | 16:17.44 |
| henrys | thanks for the info pipitas. | 16:17.54 |
| Robin_Watts | Corrupting the hint stream in robin3.pdf leaves it linear. | 16:18.14 |
| | I really get them impression that the hintstream is not used :( | 16:18.33 |
| henrys | pipitas:are you asking what is broken in pdftk. | 16:18.35 |
| | ? | 16:18.36 |
| | didn't understand the question | 16:18.44 |
| kens | Robin_Watts : great! I'll just write random garbage in mine then :-) | 16:18.56 |
| pipitas | henrys: Yes :) (I'd like to know if you saw different things which I hadn't noticed yet) | 16:19.34 |
| henrys | just running something simple like uncompress I get Null Pointer exception from the java runtime. | 16:20.17 |
| tor8 | chrisl: we're planning on doing the mupdf release candidate tomorrow | 16:20.29 |
| | henrys: what sort of pdftk things do you mean? | 16:20.53 |
| chrisl | tor8: how long do you like to leave between the rc and the actual release? | 16:21.05 |
| tor8 | chrisl: about a week | 16:21.21 |
| chrisl | tor8: cool, thanks. | 16:21.31 |
| henrys | http://www.pdflabs.com/docs/pdftk-cli-examples/ for starters | 16:21.32 |
| chrisl | Holy crap, another gold medal in the cycling...... | 16:21.55 |
| kens | The cyclists have done well this time round | 16:22.15 |
| ray_laptop | and round and round ... | 16:22.27 |
| Robin_Watts | chrisl: I think we got a triathlon one as well. | 16:22.39 |
| henrys | it's not just the cyclist, it's an amazing UK performance this olympics. | 16:23.03 |
| chrisl | Yeh, I didn't expect the gold in the women's omnium, though..... | 16:23.13 |
| kens | Oh the dressage team won gold too | 16:23.36 |
| tor8 | henrys: right, we have a lot of that stuff in pdfclean | 16:23.39 |
| henrys | so I was thinking if we had some documentation we might be able to easily move into that niche. | 16:24.24 |
| | the woman's triathlon was amazing - never seen a tri with a sprint photo finish | 16:25.29 |
| kens | Robin_Watts : apart from teh page tree being in the 'wrong' place, I really can't see what its complaining about | 16:25.31 |
| Robin_Watts | kens: Me either. So I plan to ignore it for now. | 16:25.50 |
| kens | :-) | 16:25.57 |
| pipitas | henrys: for uncompressing I usually run 'qpdf âqdf compressed.pdf uncompressed.pdf". Never tried it with pdftk⦠(Are you saying this problem occurs with the MacPort only?) | 16:27.47 |
| kens | Hmm, so turning on linearisation in my code produces 7116 seg faults in 7212 testes. Oops :-) | 16:27.52 |
| | Or even tests | 16:28.04 |
| Robin_Watts | kens: Welcome to my world. | 16:28.06 |
| kens | Robin_Watts : I'm not hugely surprised actually, its still quite rudimentary, the reason for running the tests was to see what I broke :-) | 16:29.12 |
| henrys | pipitas:yes, it a reported "port" bug which has been referred back upstream without response. | 16:29.15 |
| | pipitas:what is the engine for qpdf? | 16:29.49 |
| kens | OK on that note I'm going to head off, I'll look at my seg faults tomorrow. Goodnight all. | 16:31.11 |
| Robin_Watts | Night kens. THanks | 16:31.20 |
| henrys | pipitas:maybe qpdf is yet another pdf parser. | 16:31.25 |
| ray_laptop | bye, ksn | 16:31.31 |
| | kens even | 16:31.38 |
| marcosw | clearly I need someone to call me at 9:00 and remind me about the meeting | 16:32.03 |
| henrys | marcosw:I'll sms you next week. | 16:32.17 |
| | what about my machine henrysx6 and the memory test? | 16:32.32 |
| pipitas | henrys: its an independent development, CLI + lib. qpdf does "does structural, content-preserving transformations on PDF files". See http://qpdf.sf.net/ | 16:33.31 |
| marcosw | I ran 1000 test compiles and none of them failed. I also ran mprime for hours and hours and it didn't fail. | 16:33.51 |
| henrys | pipitas:yes I was just reading about it, thanks. | 16:33.55 |
| Robin_Watts | tor8, sebras: pdf_write.c changes on my repo on casper. | 16:34.28 |
| henrys | marcosw:ray_laptop has bad hardware kharma, it did break with his cluster push I think. | 16:35.54 |
| ray_laptop | one of my tests had the same problem marcosw saw (bad data in gsromfs1.c) but I thought that was a full file system | 16:36.54 |
| henrys | marcosw:I downgraded the recent pcl regression to a P4 enhancement which means it will not get addressed ever uhum, soon. | 16:40.33 |
| ray_laptop | Robin_Watts: can the writer in mupdf spit out PDF from an XPS input ? | 16:41.09 |
| Robin_Watts | ray_laptop: No. | 16:42.46 |
| | But I was pondering playing with that around the pool in Malta :) | 16:43.02 |
| henrys | yeah that's what I'd do in Malta ... | 16:44.02 |
| Robin_Watts | We got an enquiry the other week asking us if we could generate pdfs programatically, and we can't, but I don't think it's a huge effort. | 16:44.11 |
| | We'd need to be able to make an 'empty' pdf document, and then create a page, and open a device for writing onto that page. | 16:45.02 |
| | Then device calls would get translated into pdf operators. | 16:45.20 |
| ray_laptop | Robin_Watts: makes sense. | 16:45.44 |
| henrys | pipitas:well if you ever give mupdf a shot for doing basic pdf transformation stuff, we'd love to hear any feedback you might have. | 16:45.52 |
| Robin_Watts | Then we'd need a veneer over the device to allow people to make calls like: move, lineto, etc. | 16:45.58 |
| | open font, output text, output bitmap etc. | 16:46.23 |
| ray_laptop | Robin_Watts: note that the gs lib calls can do that also (already existing) in case the need is pressing. For graphics the calls are straightforward. For text, however ... | 16:46.53 |
| pipitas | henrys: that's actually on my TODO list⦠:) | 16:47.07 |
| chrisl | Robin_Watts: you'll need stuff to convert multibyte ttf fonts to CIDFonts | 16:47.14 |
| Robin_Watts | chrisl: la la la la. | 16:47.25 |
| sebras | Robin_Watts: I know it's a just a stylistic change, but would you mind making sizeof(page_objects *)*(newcap-oldcap) be (newcap-oldcap)*sizeof(page_objects *) so it matches the line above it? | 16:47.30 |
| henrys | Robin_Watts, alexcher:I forgot to ask about alexcher's bug which is blocking Robin_Watts bug. Is that still in alexcher's court? | 16:47.30 |
| Robin_Watts | henrys: it is. alexcher has been openjpegging, so has been busy, I suspect. | 16:48.08 |
| marcosw | henrys: I saw your comment about the missing pcl text bug, I'll let the customer know the output will vary by printer. | 16:48.22 |
| ray_laptop | henrys: bug 693115 is still open (P2) | 16:48.29 |
| Robin_Watts | sebras: fix pushed | 16:49.30 |
| henrys | alexcher:do you want to discuss/brainstorm on this one with others? | 16:49.47 |
| alexcher | henrys: not yet | 16:50.36 |
| ray_laptop | darn, I forgot to mention to kens that I really liked his ASCII-art to explain away that Orientation 3 bug | 16:50.40 |
| henrys | alexcher:but it is moving along? | 16:51.03 |
| ray_laptop | to make doing that kind of thing easier, maybe we need to do a -sDEVICE=ascii-art ;-) | 16:51.52 |
| Robin_Watts | tor8, sebras: Oh, damn. I just realised that in sebras changes that I pushed earlier, was the fz_too_deeply_nested stuff that tor8 didn't like. | 16:52.20 |
| alexcher | henrys: yes, I'd try to add one more parameter to the graphic state that points to the last soft mask. | 16:52.38 |
| sebras | Robin_Watts: ok. | 16:52.43 |
| | Robin_Watts: git revert SHA1? | 16:52.50 |
| | Robin_Watts: or do you want to rebase master and take that patch out? | 16:53.06 |
| Robin_Watts | sebras: Just thinking. | 16:53.11 |
| sebras | tor8: also, tor8 why didn't you like it and how do you propose to solve it nstead? | 16:53.34 |
| ray_laptop | alexcher: I don't have a problem with that. I presume it would be maintained by the pdf14 device | 16:53.49 |
| alexcher | henrys: If the soft mask changes, this can be detected during a drawing operation. | 16:53.57 |
| | henrys: No, it will be one more entry in the PS dictionary. | 16:54.57 |
| ray_laptop | alexcher: and what does that help with | 16:55.00 |
| Robin_Watts | sebras: I think I'd prefer the tests to be inside the functions. | 16:55.21 |
| ray_laptop | alexcher: Oh, you meant a parameter in the ExtGState in the PDF interp ? (not in the graphics list gstate) ? | 16:55.43 |
| Robin_Watts | sebras: Actually... what does this save us? | 16:56.40 |
| alexcher | ray_laptop: Yes, the extended graphic state. | 16:56.42 |
| sebras | Robin_Watts: the too deep nesting? | 16:57.06 |
| henrys | alexcher:this is in the interest of rendering the smask once? | 16:57.14 |
| Robin_Watts | sebras: Surely it would be better if fz_try() was just smart enough to call fz_catch() in the case when it was asked to nest too deeply? | 16:57.54 |
| alexcher | henrys: yes, rendering once and only when it's needed. | 16:58.31 |
| sebras | Robin_Watts: yes, currently it cannot and I resisted mucking about in the exception handling. | 16:58.32 |
| Robin_Watts | but it easily could. | 16:59.01 |
| sebras | Robin_Watts: the example case is a content stream consisting of 256 left brackets, each starting an array. | 16:59.07 |
| henrys | alexcher:well if you get stuck speak up, I am sure ray_laptop, Robin_Watts, or mvrhel_laptop can help | 16:59.20 |
| sebras | Robin_Watts: how so? | 16:59.30 |
| alexcher | henrys: thanks | 16:59.36 |
| ray_laptop | alexcher: sounds like what Robin documented in the original description -- rendering an SMask only once | 16:59.41 |
| sebras | the detection happens in fz_push_try() which is called before fz_setjmp | 16:59.45 |
| Robin_Watts | We make fz_push_try return an int. | 16:59.51 |
| chrisl | alexcher: wouldn't it be easier to render the SMask when it's created? We have to do a *lot* of faffing around to recreate the appropriate graphics state to render it lazily. | 17:00.03 |
| Robin_Watts | and we make the usual thing return 0. | 17:00.07 |
| | in the error case we return 1. | 17:00.20 |
| | and we make fz_try(ctx) be... | 17:00.33 |
| alexcher | chrisl: by some reason it was not done this way. | 17:00.46 |
| henrys | sorry I omitted chrisl above on the help list. | 17:00.54 |
| alexcher | chrisl: I just try to minimise the changes. | 17:01.22 |
| Robin_Watts | Sorry. We make the usual case return 1, and the error case return 0. | 17:01.46 |
| | and we change the , to a || in the fz_try(); | 17:02.03 |
| sebras | Robin_Watts: so how would we end up in fz_catch()? | 17:02.10 |
| Robin_Watts | we'd also need to make the error case set the code to be non zero. | 17:02.20 |
| chrisl | alexcher: fair enough, it's just that I haven't seen any real PDFs that define an SMask and then don't use it, so there's limited benefit in lazy evaluation, in this case.... | 17:02.28 |
| ray_laptop | chrisl: alexcher: rendering the SMask when it gets set would be OK, as long as when we did a begin_trans_group...end_trans_group it didn't get disturbed, but IS used for the blend of the end_trans_group(s) | 17:03.33 |
| | alexcher: chrisl: but we have to know when to discard that mask. I'm looking at it from the view of the pdf14 device that has the maskbuf in the context | 17:04.43 |
| Robin_Watts | sebras: We'd have to ensure that we always increment ctx->error->top in push_try. | 17:05.07 |
| henrys | bbiab | 17:05.17 |
| Robin_Watts | So we'd have to give the overflow one earlier, I suspect. | 17:05.31 |
| ray_laptop | i.e. we need to count begin end transparency stack ops to know when we can actually free the maskbuf | 17:05.48 |
| sebras | Robin_Watts: ok, then we basically have to reserve the top slot in he stack for the too deeply nested case. | 17:07.02 |
| Robin_Watts | sebras: Or have at least 1 more 'code' entry. | 17:07.20 |
| ray_laptop | freeing the current maskbuf if a new smask is set isn't a problem, so maybe we just need to transmit the 'null' SMask to pdf14 ??? | 17:07.21 |
| Robin_Watts | sebras: Let's just reserve the top entry on the stack :) | 17:07.39 |
| sebras | Robin_Watts: ! | 17:07.47 |
| ray_laptop | alexcher: I don't think this can be done entirely in the PDF interp, but if the PDF interp adds a begin_transparency_mask .. end_transparency_mask that the device can recognize as 'null' then it can know to discard the current SMask | 17:09.19 |
| chrisl | ray_laptop: I can't remember enough of this to be sure - I wrote the stuff that saves the gstate stuff when the SMask is created, and sets it when we render the SMask - and it's sufficiently convoluted, I can barely remember any of it, hence my interest if we could discard all that. | 17:09.31 |
| ray_laptop | (discard the current maskbuf, that is) | 17:09.34 |
| sebras | Robin_Watts: there's one thing I don't get though. | 17:10.33 |
| ray_laptop | chrisl: I agree that I don't see why we would need to defer the SMask rendering IFF we make a corresponding change in the pdf14 device handling of maskbuf | 17:11.00 |
| sebras | if we fz_longjump() from withing fz_push_try(), then how will we end up in fz_catch() on the level we are currently at? | 17:11.10 |
| | basically we'd be throwing to the parent level, no? | 17:11.56 |
| chrisl | ray_laptop: having said that, I fully understand Alex's preference for minimising the code changes! | 17:11.58 |
| Robin_Watts | sebras: We do the push, then 'throw' to the catch for the level we just pushed. | 17:12.25 |
| | but we don't actually throw, we short circuit it. | 17:12.31 |
| ray_laptop | chrisl: the way the EXGstate works (using the PS dict stack) whenever the SMask goes to null, we need to send the "null" begin/end transparency mask (I think) | 17:13.02 |
| sebras | right, just preparing the error stack. so, then what? setjmp will never be executed. | 17:13.22 |
| | oh... we need to set code to non-zero. | 17:13.32 |
| Robin_Watts | Right. | 17:13.39 |
| | See the patch on my repo. | 17:14.01 |
| | actually, that's broken. | 17:17.05 |
| sebras | Robin_Watts: no go, ctx must be supplied to fz_push_try(). | 17:17.17 |
| Robin_Watts | Damn. | 17:18.06 |
| sebras | Robin_Watts: doesn't matter much as far as I can see though. | 17:18.24 |
| ray_laptop | alexcher: I don't follow your approach of adding a SMask to the ExtGState -- it is already there, right ? What are you adding ? | 17:19.12 |
| sebras | Robin_Watts: also the same fprintf/exit() is still there... | 17:20.56 |
| Robin_Watts | sebras: Just preparing a new patch. | 17:21.09 |
| | I was thinking that we should keep the fprintf/exit as belt and braces, but I've reconsidered. | 17:21.25 |
| | New version on casper for your consideration. | 17:21.49 |
| alexcher | ray_laptop: I need to check wheter this SMask is a new one. | 17:21.56 |
| Robin_Watts | actually, we don't need context at all. | 17:22.19 |
| sebras | we could just -- on ex I guess. | 17:22.47 |
| ray_laptop | alexcher: I guess I need to see the patch, so I'll just wait. But I agree with chrisl that getting rid of the deferred SMask rendering (in gssmask) would be nice | 17:23.17 |
| sebras | Robin_Watts: hm.. testing your patch gives me a segmentation fault. | 17:23.27 |
| Robin_Watts | sebras? | 17:23.27 |
| | testing? | 17:23.34 |
| sebras | Robin_Watts: yeah, I have a pdf provoking the issue here. | 17:23.52 |
| Robin_Watts | New version on casper. | 17:24.03 |
| | What version were you testing? | 17:24.07 |
| ray_laptop | I have to run an errand. bbiaw. | 17:24.11 |
| sebras | Robin_Watts: the in between one. | 17:24.20 |
| | still a segmentation fault. | 17:24.54 |
| Robin_Watts | Does it ever hit the new code? | 17:25.14 |
| | Can I get a copy of your pdf please? | 17:25.21 |
| sebras | Robin_Watts: no it doesn. | 17:25.29 |
| | Robin_Watts: http://pastebin.com/bZB9cSK2 | 17:28.33 |
| Robin_Watts | I get no segv. | 17:30.11 |
| | What command are you using? | 17:30.16 |
| sebras | gdb --args ./build/debug/mudraw -m rjw.pdf | 17:30.26 |
| Robin_Watts | mupdf detects that as being a broken pdf and tries to repair it. | 17:30.37 |
| | I suspect that pastebin is not idea for transferring pdfs. | 17:30.46 |
| sebras | Robin_Watts: I made sure that the whitespaces were correct so it _ought_ to work. | 17:31.14 |
| Robin_Watts | 32 or 64bit linux ? | 17:31.22 |
| sebras | 64 bit. | 17:31.28 |
| Robin_Watts | Can you email me the file please? | 17:31.30 |
| | or scp it to casper? | 17:31.36 |
| sebras | Robin_Watts: ~sebras/tmp/rjw.pdf | 17:32.24 |
| Robin_Watts | Works on windows for me. | 17:33.20 |
| sebras | ==21356== Command: ./build/debug/mudraw -m rjw.pdf | 17:34.36 |
| | ==21356== | 17:34.36 |
| | ==21356== Conditional jump or move depends on uninitialised value(s) | 17:34.36 |
| | ==21356== at 0x404551: new_context_phase1 (base_context.c:65) | 17:34.36 |
| | ==21356== by 0x4045D4: fz_new_context (base_context.c:89) | 17:34.36 |
| | ==21356== by 0x403936: main (mudraw.c:488) | 17:34.38 |
| Robin_Watts | ??? | 17:35.17 |
| malc_ | tor8: hi. the large glyph rendering is slow to the point of me not having enough pateience to finish things render (nor there's an option to stop the job), is it normal? | 17:35.28 |
| chrisl | oh, heck, I'm late - bye all! | 17:36.14 |
| Robin_Watts | night chrisl. | 17:36.26 |
| | Interesting. It won't even build on linux for me :( | 17:37.13 |
| | SEGVs while dumping. What have I broken. | 17:37.25 |
| malc_ | tor8: not sure if you've seen the question (or maybe you parted because of 'orrible spelling in which case i'm sorry) | 17:38.15 |
| sebras | Robin_Watts: I think this comes down to order of evaluation in expressions. | 17:45.02 |
| Robin_Watts | sebras: || has defined ordering. | 17:45.18 |
| | Oh, but it's in an assignment. | 17:45.29 |
| sebras | Robin_Watts: in fz_try() you have fz_push_try() increment ex->top, however you then use ->top in the left hand of the expression... | 17:45.30 |
| | Robin_Watts: exactly. | 17:45.37 |
| Robin_Watts | ok. Simple fix. | 17:45.47 |
| sebras | Robin_Watts: something tells me that this patch was a tad more complicated than you first anticipated. ;) | 17:46.27 |
| Robin_Watts | These magros are always harder than you think :) | 17:49.00 |
| sebras | Robin_Watts: now you know why I refrained from changing thos macros at 3am... | 17:50.33 |
| Robin_Watts | New patch up. | 17:50.37 |
| | I've been hacking on these macros since around 1995 when paulgardiner first came up with them. | 17:51.10 |
| | I think that works. | 17:51.28 |
| sebras | Robin_Watts: partly, yes. I get an exception stack, however I never see the out of error stack message. and I think I should. | 17:53.43 |
| Robin_Watts | I get the cannot parse array message. | 17:54.05 |
| | Is that not enough? | 17:54.08 |
| | Would you rather see the exception overflow too ? | 17:54.19 |
| sebras | Robin_Watts: doesn't matter too much, but you _did_ strcpy() it... ;) | 17:54.43 |
| Robin_Watts | Yeah, I strcpy it, so that the catch can get it by using fz_caught(); | 17:55.07 |
| sebras | Robin_Watts: hm... and when I run it in rjw.pdf we leak memory. | 17:55.29 |
| Robin_Watts | the fact is that none of the catch clauses we hit do that. | 17:55.30 |
| | That, I think, is independent of this patch, surely? | 17:55.56 |
| sebras | Robin_Watts: the reason being that pdf_parse_array() allocates its pdf_new_array() outside of the fz_try() and I wonder if this gets cleaned up properly. | 17:56.30 |
| Robin_Watts | pdf_drop_array(ary). | 17:57.29 |
| sebras | Robin_Watts: pdf_drop_obj(ary) you mean? but it's already there!? | 17:59.11 |
| Robin_Watts | Yes, that was what I was pointing out (badly) | 17:59.30 |
| | Tweaked patch (doesn't help with this, but is nicer, IMHO) and I reordered the commits on my repo. | 18:00.16 |
| | So, let's see what memento makes of this. | 18:01.16 |
| sebras | Robin_Watts: hm.. is the load on casper supposed to be 1.64? | 18:01.30 |
| | Robin_Watts: or maybe it's just the network which is really slow just now.. | 18:02.58 |
| Robin_Watts | ok, memento shows me block 587 leaking. | 18:05.13 |
| sebras | Robin_Watts: looks like consolekit's daemon has gone haywire and is using a full core on its own. | 18:05.26 |
| Robin_Watts | marcosw: ping | 18:05.51 |
| | no, that patch is still broken. | 18:07.52 |
| | OK, new patch on line, that will work. Honest. | 18:11.03 |
| sebras | Robin_Watts: no more memory leaks! :) | 18:12.24 |
| Robin_Watts | sebras, tor8: Were there any other problems that tor8 had with your patches that I completely forgot? | 18:14.28 |
| sebras | I don't think so. if there are I'm happy to fix them. | 18:14.51 |
| | Robin_Watts: and thanks for sorting out this one. | 18:15.02 |
| Robin_Watts | no worries. It's an improvement in the macros, which can only be a good thing. | 18:15.37 |
| | sebras: Do the changes I made to the macros make sense to you? | 18:17.37 |
| sebras | Robin_Watts: yes, now it looks kind of obivous. | 18:19.19 |
| kens | ray_work : http://www.buzzfeed.com/tommywilhelm/see-the-world-in-ascii | 18:26.01 |
| Robin_Watts | http://www.asciimation.co.nz/ | 18:28.16 |
| | sebras: cool :) | 18:29.22 |
| sebras | Robin_Watts: still, nothing beats telnet towel.blinkenlights.nl | 18:30.39 |
| Robin_Watts | ah, right. | 18:31.44 |
| | marcosw: Did you see sebras comments earlier about a haywire process on casper? | 18:58.47 |
| | sebras, tor8: If one (or both) of you could look over the linearisation commit on my review I'd be grateful. | 18:59.16 |
| | s/review/repo/ | 18:59.25 |
| drbair | Is viewmiff used anymore? I'm attempting to use it to build a PDF from many large miffs but I'm getting "Error: /syntaxerror in (bin obj seq, type=128, elements=183, size=256, sequence too short)" | 19:51.10 |
| Robin_Watts | OK, tor8: The new thirdparty.zip file tests out nicely. 372 differences due to freetype. | 20:08.51 |
| | All fine. | 20:08.56 |
| | Forward 1 day (to 2012/08/08)>>> | |
IRC Logs