| | <<<Back 1 day (to 2014/02/27) | 2014/02/28 |
| kens | Hi Michael, heading home ? | 08:03.22 |
| mvrhel_laptop | yes. at airport | 08:03.40 |
| | hi kens | 08:03.43 |
| kens | Hope you had a decent time | 08:03.50 |
| mvrhel_laptop | yes it was all good meetings | 08:03.59 |
| kens | Great, you can tell us all about it next week ;-) | 08:04.10 |
| mvrhel_laptop | yes. sounds like scott has quite the set up for us. should be quite the meeting | 08:06.35 |
| | usually I am able to get some real work done at this trips but this time no | 08:06.57 |
| | we have had some very long days | 08:07.12 |
| kens | Yeah I got that impression | 08:07.25 |
| | There's a bug that I think will have to wait for you, I don't understand the colour index stuff well enough to deal with. The customer's patch looks OK but I just can't tell | 08:08.01 |
| mvrhel_laptop | kens; ok. I need to get this gsview stuff wrapped up so I can get back to work on gs. Although I fear that I am going to get sucked into smart office | 08:10.04 |
| kens | SOunds like we all might :-) | 08:10.14 |
| mvrhel_laptop | flight boarding. talk to you later | 08:12.46 |
| kens | have a good flight home | 08:12.54 |
| mvrhel_laptop | thanks | 08:14.33 |
| sebras | morning tor5 | 09:49.58 |
| | tor5: having internet problems again? | 09:50.07 |
| Robin_Watts | tor8: ping ? | 11:43.49 |
| kens | hey robin have you looked at #695077 ? | 11:46.18 |
| Robin_Watts | I have not. | 11:46.57 |
| kens | Do you have a minute to tlak about it (briefly) ? | 11:47.11 |
| Robin_Watts | Sure. | 11:47.22 |
| | Let me have a quick poke. | 11:47.30 |
| kens | The code is in gp_mswin.c | 11:47.32 |
| | gp_open_scratch_file | 11:47.40 |
| | I'm no expert on this but I htink there's a problem if GetTempFPath returns an array of WCHAR | 11:48.37 |
| | But that can only happen (I think) if we have UNICODE defined | 11:48.49 |
| Robin_Watts | Let's walk through this (I'm not as up to speed on this as you obviously are) | 11:50.03 |
| kens | I wouldn't say I wa up to speed | 11:50.23 |
| Robin_Watts | We are given a prefix for the name. | 11:50.34 |
| kens | I did read through it a bit this morning and got myself confused :( | 11:50.35 |
| Robin_Watts | Let's assume it's not an absolute path. | 11:50.42 |
| | as I believe that's the common case. | 11:50.49 |
| kens | I think that's reasonable, as its a distdv temp file | 11:51.00 |
| | err I mean pdfwrite | 11:51.15 |
| chrisl | Agh! Flashback..... | 11:51.25 |
| Robin_Watts | Then we call gp_gettmpdir which looks for TMPDIR or TEMP. | 11:51.25 |
| kens | Does it ? | 11:51.45 |
| chrisl | In the environment, then in registry | 11:52.11 |
| kens | OK so it returns the value of TEMP | 11:52.19 |
| | (because that's what he has set) | 11:52.26 |
| | That won't be a UTF8 encoded string, or will it ? | 11:52.47 |
| chrisl | I think we expect those to be in UTF8 | 11:53.00 |
| Robin_Watts | We call getenv, which means we get char *'s back. | 11:53.24 |
| kens | The %TEMP% environment variable or the GS argument ? | 11:53.25 |
| Robin_Watts | The code clearly expects that to be in utf8. | 11:53.36 |
| | But possibly that's a crap assumption. | 11:53.46 |
| kens | I think it may be | 11:53.51 |
| | GetTempPath returns TCHAR | 11:54.00 |
| | But I have to say I don't know what getenv will return | 11:54.15 |
| Robin_Watts | On windows we should probably call _wgetenv and utf8 encode what we get back. | 11:54.20 |
| kens | THat sounds much more reasonable | 11:54.30 |
| Robin_Watts | That way we know we'll get valid utf8 regardless of codepage etc. | 11:54.45 |
| kens | Yeah, sticking with UTF8 makes sense to me | 11:55.00 |
| Robin_Watts | So, let's assume that we've made that change and keep walking to see if there are more pitfalls. | 11:55.19 |
| | If we found a tmpdir we're fine, if not, we call GetTempPath | 11:55.49 |
| kens | I think its OK if we do that, except that if we go to GetTempPath and have UNICODE defined, we will get an array of WCHAR | 11:55.58 |
| | Which won't be UTF8 | 11:56.10 |
| chrisl | We should probably call GetTempPathW() explicitly so we know it's WCHARs | 11:56.26 |
| Robin_Watts | Right. We should explicitly call GetTempPathW and then utf8 encode it. | 11:56.33 |
| kens | And tehn UTF8 it, that again makes some sense | 11:56.41 |
| chrisl | Only thing we should check is if there are version restrictions on GetTempPathW | 11:57.08 |
| kens | gp_gettmpdir is in gpmisc.c, not a platform file :( | 11:57.17 |
| Robin_Watts | Urgh. Looks like GetTempFileName has the same issues. | 11:57.35 |
| kens | Yes, I believe it does | 11:57.45 |
| | BUt aqt least those ones are in the Windows platform file | 11:57.56 |
| | I think we will have to forgo using gp_tmpdir and do that in dp_mswin.c too | 11:58.28 |
| chrisl | If we handle the encoding in gp_getenv.c gp_gettmpdir() should be fine | 11:59.24 |
| kens | I think you're ahead of me there | 11:59.41 |
| Robin_Watts | chrisl: Yes. | 11:59.47 |
| | but that still leaves us with GetTempPath and GetTempFileName to fix. | 12:00.05 |
| kens | So we just call wchar_to_utf8 on the result after calling them ? | 12:00.51 |
| chrisl | Those are for WinRT? | 12:00.55 |
| kens | No, regular Windows | 12:01.04 |
| | If we have no TEMP orTMPDIR | 12:01.17 |
| Robin_Watts | GetTempPathWRT and GetTempFileNameWRT are the WinRT equivalents. | 12:01.32 |
| chrisl | GetTempFileNameW | 12:01.49 |
| Robin_Watts | chrisl: Indeed. | 12:01.55 |
| kens | Yes, and then UTF8 them | 12:02.06 |
| Robin_Watts | I wonder if it might be easiest to make this entire function work in unicode, and then UTF8 the results. | 12:02.18 |
| kens | Which function ? | 12:02.48 |
| Robin_Watts | gp_open_scratch_file | 12:03.20 |
| kens | But it doesn't need a UTF8 result, it wants a wchar | 12:03.32 |
| chrisl | Doesn't that break the API? | 12:03.48 |
| Robin_Watts | kens: sorry, you're right. | 12:04.22 |
| kens | NP< I've been so confused with this today I could easily have been wrong | 12:04.39 |
| Robin_Watts | chrisl: gp_open_scratch_file passes in utf8 things. | 12:04.57 |
| | but what we should do is convert those to unicode, then call unicode functions (whereever possible) throughout this function. | 12:05.21 |
| | At the end we'll end up with a unicode pathname/filename. | 12:05.35 |
| | and we should call the unicode file opening function to use that. | 12:05.43 |
| | so we'd need to cope with utf8->unicode converting the results of gp_gettmpdir | 12:06.43 |
| | and doing a unicode version of gs_file_name_check_separator. | 12:07.06 |
| chrisl | Yeh, okay, that makes sense | 12:07.57 |
| Robin_Watts | Looks like we're already calling the unicode CreateFile, we just do utf8_to_wchar beforehand, so we could drop that conversion. | 12:08.05 |
| kens | Yes, that looks sensible | 12:08.18 |
| Robin_Watts | kens: Well, have fun :) | 12:08.31 |
| kens | (moving everything to Unicode), it seems like more work. | 12:08.41 |
| kens | wasn't volunteering.... | 12:08.50 |
| chrisl | I initially thought you meant changing gp_gettmpdir() to return unicode | 12:08.56 |
| Robin_Watts | If you want to assign the bug to me, that's fine. | 12:09.05 |
| kens | OK I'll do that then Robin, it would be great ot get this before the release if we possibly can | 12:09.25 |
| Robin_Watts | but I'm in the middle of mupdf at the mo, so it won't happen instantly. | 12:09.29 |
| | Can't promise that. | 12:09.37 |
| kens | Instantly is not a problem ;-) | 12:09.37 |
| | I'll just ask Chris to hold up the release ;-) | 12:09.55 |
| chrisl | Fine by me.... | 12:10.09 |
| Robin_Watts | tor8: ping! | 12:10.14 |
| chrisl | kens: How about September?? | 12:10.27 |
| kens | :-) | 12:10.34 |
| chrisl | okay, back to truetype notdefs..... :-( | 12:11.02 |
| kens | Ugh | 12:11.13 |
| | I want one of these: | 12:12.09 |
| | http://www.theregister.co.uk/2014/02/28/seaorbiter_vessel/ | 12:12.09 |
| Robin_Watts | There is a dive pit for divers. | 12:14.14 |
| chrisl | Are you planning to be a Bond villain? | 12:14.18 |
| kens | Of course! What other reasson is there to have one ? | 12:14.32 |
| chrisl | Christ, I wrote that before I read the reference to Dr. No! | 12:14.53 |
| kens | :-) | 12:15.03 |
| | THe dive pool would be good for launching the sharks | 12:15.13 |
| Robin_Watts | Now, normally when you have submersibles that have a dive pit they are safe, because the submersible is sealed airtight. | 12:15.24 |
| | But with this, if someone opens the wrong door, presumably the whole thing would just sink. | 12:15.49 |
| kens | I'd guess its in an airtight room/deck with an airlock | 12:15.50 |
| Robin_Watts | Got to make it nice and easy for the French Secret Service to scuttle it. | 12:16.08 |
| kens | The French ? Surely Mr Bond | 12:16.23 |
| Robin_Watts | I was referring to the Rainbow Warrior etc. | 12:16.43 |
| kens | I'd guess that only ocunts if they actually build one, I was still thining in the realm of fiction ;-) | 12:17.10 |
| Robin_Watts | Ah, Deck: -11.60 and below are pressurised. | 12:17.11 |
| kens | lunches | 12:21.09 |
| paulgardiner | Worrying. Received two spoof facebook friend requests. Not unusual, but the second one said "MIles wants to be friends with you on Facebook" I wonder how they'd have connected the name Miles with my email address. Wasn't even my artifex address. | 12:57.14 |
| kens | Never underestimate co-incidence.... | 13:02.57 |
| paulgardiner | Yeah. I often remind people but forget myself that every 100th occurance of something is likely to come out with 1/100 outcome. | 13:04.19 |
| tor8 | Robin_Watts: pong. | 13:05.14 |
| kens | I was readin a nice articel in Scientific Americna about 'hidden combinations' which explained the people in a room sharing a birthday problem, and why people get it wrong :-) | 13:05.21 |
| paulgardiner | Interesting. I've been told the solution for a particular case in the past and I remember being surprised | 13:15.56 |
| kens | You only need 23 people to make it more likely than not that a pair share a birthday (51% chance IIRC) | 13:16.34 |
| paulgardiner | I'm trying to create a spreadsheet now. :-) Must try not to lose the rest of the day. | 13:18.01 |
| kens | ROFL. The key is that people tend to think that the chance of themselves sharing a birthday is 1/365 so they instantly jump to 183 as the answer. THey for get teh 'hidden combinations'; for each person in the room they can share a birthday that does not contain the first candidate. So If we have A, B and C, there are not 2 combinations (A+B and A+C) but 3 because there is also B+C. Those combinations start to go up *very* quickly when you add more people | 13:20.08 |
| paulgardiner | Oh it worked 23 -> 0.507297 | 13:20.47 |
| kens | Well, that mathces my recollection pretty well :-) | 13:21.06 |
| paulgardiner | 99% certaintly with 57 people, assuming my spreadsheet isn't just getting the 23 case correct by luck | 13:25.03 |
| kens | No I'd guess that's correct, the combinations really mount up fast | 13:25.20 |
| | Surprising though, isn't it ? | 13:25.32 |
| paulgardiner | yeah very | 13:25.42 |
| tor8 | kens: it's obvious, but very non-intuitive. | 13:25.56 |
| kens | tor8 its easy when you do the math, but intuition sends you off wrong if you aren't careful | 13:26.16 |
| | The article I was reading was really about these 'hidden' combinations that people really don;t realise are there | 13:26.44 |
| Robin_Watts | tor8: hi | 13:36.22 |
| | I wanted to talk about this filtering stuff. | 13:36.36 |
| | Did you get a chance to look over the commit ? | 13:36.43 |
| | When I do fz_printf("%f", 1.0f); I get 1.000000 rather than 1 | 14:14.58 |
| | According to how I read http://www.cplusplus.com/reference/cstdio/printf/ that's not what I should expect. | 14:15.17 |
| | Bah. Googling suggests that there is no easy way. | 14:18.19 |
| kens | sprintf, truncate at '.' then printf with a %s ? | 14:18.56 |
| chrisl | Spot that it's an integer value, and use %d? | 14:23.37 |
| kens | It might not be integral | 14:23.49 |
| | Or even integer | 14:23.58 |
| | You might want to truncate the floating point | 14:24.12 |
| chrisl | True, but the example is an integer | 14:24.40 |
| | I thought %.02f was the syntax for a specific precision | 14:25.30 |
| | Replacing 02 with the precision you want | 14:25.48 |
| tor8 | %f defaults to always printing with 6 decimal positions | 14:26.12 |
| kens | Yes I think that shold work | 14:26.14 |
| tor8 | what you want is %g | 14:26.14 |
| kens | %.0f should work shouldn't it ? | 14:26.34 |
| Robin_Watts | tor8: No. %g changes to exponent notation. | 14:26.49 |
| | which I can't write into a pdf file. | 14:26.58 |
| kens | %g uses whatever is shorter | 14:27.04 |
| tor8 | Robin_Watts: right. | 14:27.12 |
| kens | I wouldn't use it normally, you can't be certain what you'll get | 14:27.17 |
| tor8 | %.9g is the canonical way to print lossless floats to ascii (and %.17g for doubles) | 14:27.29 |
| | but it does use exponential notation | 14:27.37 |
| Robin_Watts | and %.0f means never write more than 0 figures after the decimal point. | 14:27.39 |
| kens | Robin_Watts : isn't that what you wanted ? | 14:27.51 |
| | Or are you getting '1.' ? | 14:28.03 |
| Robin_Watts | kens: if I print 1.00000001 I want to get 1.0000001 | 14:28.18 |
| | if I print 1.23, I want to get 1.23, not 1.23000000 | 14:28.30 |
| | If I print 1.0 I want to get 1 | 14:28.46 |
| tor8 | Robin_Watts: so you want %g-like without exponents (and severely truncate the number if it is very small)? | 14:28.56 |
| kens | I think the only way to guarantee that is to sprintf it and look for the trailing zeroes yourself | 14:29.00 |
| Robin_Watts | According to professor google... what kens said. | 14:29.08 |
| | kens: How does pdfwrite handle it ? | 14:29.15 |
| kens | I very much doubt that it does | 14:29.24 |
| | It probably just writes lots of zeroes | 14:29.34 |
| Robin_Watts | Right. | 14:29.40 |
| kens | If you cna give me an example where this is used I can look specifically | 14:29.51 |
| tor8 | Robin_Watts: %f and strip "\.0*" from the tail? | 14:30.17 |
| | would be the most robust solution I think | 14:30.25 |
| chrisl | pdfwrite defaults to compressing the output, so the extra zeros probably matter less | 14:30.31 |
| kens | That's true too | 14:30.40 |
| Robin_Watts | Well, pdfwrite gets numbers like: 896.215 4472.64 359.613 4629.09 250.25 4430.25 | 14:31.09 |
| | So it looks like it's managing it. | 14:31.17 |
| | Those were numbers for a 'c' | 14:31.26 |
| kens | Hmm, if you give me an example I'll look into it. | 14:31.37 |
| Robin_Watts | kens: tiger.eps :) | 14:31.45 |
| kens | OK one second, I'll have to sitch | 14:32.02 |
| | switch* | 14:32.06 |
| chrisl | How is fz_printf() implemented? | 14:32.13 |
| Robin_Watts | it ends up calling vsnprintf | 14:32.28 |
| | perhaps I need to reimplement vsnprintf for myself :( | 14:34.03 |
| tor8 | Robin_Watts: frexp() and do the toascii bits manually? | 14:34.28 |
| chrisl | You'll need to watch for locale problems, if you're writing to pdf output | 14:34.38 |
| Robin_Watts | chrisl: Yes, so maybe reimplementing is the best thing to do anyway. | 14:34.57 |
| chrisl | That's why I used "trio" | 14:35.13 |
| kens | pdfwrite seems to use pprintg2 and "%g" | 14:36.01 |
| tor8 | Robin_Watts: if you do, can we please get %m and %r for fz_matrix and fz_rect? | 14:36.19 |
| Robin_Watts | kens: And how does it avoid exponent problems ? | 14:36.30 |
| | tor8: Gladly. | 14:36.53 |
| kens | Robin_Watts : not sure yet, its not as simple a function as I expected | 14:36.53 |
| Robin_Watts | tor8: frexp is C99. | 14:37.12 |
| kens | Robin_Watts : it looks for exponent specifically in the output string | 14:37.14 |
| chrisl | Robin_Watts: the issue I had was that implementing vsnprintf() isn't a massive challenge, but getting the results to be consistent with various stdclib ones looked like a ball-ache | 14:37.29 |
| tor8 | and %q for a quoted/escaped string :) | 14:37.30 |
| kens | and uses "%f" if it finds it | 14:37.37 |
| Robin_Watts | kens: right. | 14:37.52 |
| tor8 | well, I think we only need/want a subset of printf-qualifiers | 14:38.12 |
| kens | Look in spprint.c, ppringg1 at around line 118 | 14:38.35 |
| | Robin_Watts : ^^ | 14:38.35 |
| Robin_Watts | kens: ta. | 14:38.41 |
| | Using %g and %f will lead to locale problems though? | 14:39.07 |
| chrisl | Those functions end up using trio, which ignores the locale | 14:39.34 |
| Robin_Watts | right. | 14:39.46 |
| kens | My this spprint stuff is icky | 14:39.47 |
| chrisl | You're not kidding! | 14:40.08 |
| kens | You're welcome | 14:40.54 |
| | Robin_Watts : note the special handling for locale where . is not '.' | 14:41.49 |
| | The ickiness ? | 14:41.59 |
| chrisl | Icky is not the word I'd use - disaster is probably closer.... | 14:43.08 |
| kens | :-) I'm sure Robin can come up with a tidier version of this stuff | 14:43.35 |
| Robin_Watts | I'm sure there is a version in smart office we can lift ;) | 14:44.10 |
| chrisl | I think Pooh Bear could come up with a tidier version | 14:44.19 |
| kens | THat would work too | 14:44.21 |
| Robin_Watts | their code has %S for unicode strings, and %u for urls etc :) | 14:44.28 |
| chrisl | Is their %f, %g etc consistent with the stock implementations? Maybe we could ditch trio for gs, then | 14:45.14 |
| Robin_Watts | chrisl: probably not exactly. | 14:45.26 |
| | I suspect that pulling theirs in will be trickier than just implementing the specific subset that we want. | 14:45.51 |
| ray_laptop | marcosw: what machine(s) runt the nightly ? Can log into it to try and duplicate the 4 segfaults -- I can't duplicate on peeves. | 15:18.16 |
| Robin_Watts | ray_laptop: Have you tried using the cluster binaries? | 15:19.16 |
| | /home/marcos/cluster/gs/bin/ on peeves/peeved IIRC. | 15:19.45 |
| | tor8, paulgardiner, sebras: Any reason why pdf_array_delete doesn't have a RESOLVE(obj); at the top? | 15:20.06 |
| paulgardiner | Not that I know of | 15:21.10 |
| tor8 | Robin_Watts: not a clue. probably an oversight. | 15:23.25 |
| Robin_Watts | ok, ta. | 15:23.55 |
| sebras | Robin_Watts: did it use to have one? | 15:25.32 |
| | Robin_Watts: maybe it was lost in some reorg. | 15:25.44 |
| Robin_Watts | sebras: it does not currently have one. | 15:25.48 |
| ray_laptop | Robin_Watts: thanks for the suggestion, but that also doesn't fail (on either the pxl creation or the subsequent ppmraw run | 15:26.29 |
| Robin_Watts | ray_laptop: Are you using exactly the same args etc? | 15:26.57 |
| ray_laptop | Robin_Watts: I guess I'll take it up with marcosw. It may be the nightly cluster command line | 15:27.05 |
| Robin_Watts | (you can see from the logs what the exact args were) | 15:27.08 |
| ray_laptop | Robin_Watts: I don't know where the nightly logs are | 15:27.20 |
| Robin_Watts | oh, nightlies. right. | 15:27.22 |
| ray_laptop | only the nightly bothers with pxlcolor, AFAIK | 15:27.45 |
| Robin_Watts | tor8, paulgardiner, sebras: 2 small fixes. | 15:28.48 |
| sebras | Robin_Watts: as far as I can see the function was invented during the reorg into pdf-object.c. so I guess tor8 might have forgotten it back then. | 15:28.53 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=1ed27a8243b5335040a4d9d9fac9d239a13b0602 | 15:28.57 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=3341fa7ecdbf87b630c054775b076784806393ed | 15:29.13 |
| | The first causes 1 bitmap difference, that I am bmpcmping now. | 15:29.28 |
| tor8 | RESOLVE LGTM! | 15:30.09 |
| Robin_Watts | and bmpcmp can't see any differences. | 15:30.11 |
| tor8 | (yay! all caps!) | 15:30.13 |
| kens | Emphatic | 15:30.44 |
| tor8 | Robin_Watts: both look reasonable | 15:31.13 |
| Robin_Watts | Ta. | 15:31.17 |
| tor8 | odd that you got a bmpcmp diff though | 15:31.22 |
| | or well non-bmpcmp diff | 15:31.30 |
| sebras | Robin_Watts: doesn't the code in pdf_copy_dict() look strange too? concerning RESOLVE()..? | 15:31.38 |
| tor8 | sebras: yeah, that looks like a copy-paste error | 15:32.10 |
| Robin_Watts | sebras: harmless, but yes, odd. | 15:32.32 |
| Robin_Watts | will tidy, ta. | 15:32.53 |
| sebras | what about pdf_set_int()? | 15:33.13 |
| tor8 | sebras: that one is for a specific use by paul I think, and should not resolve | 15:33.42 |
| | sorry, s/paul/linearization/ | 15:34.18 |
| | it's changing the int value after the int object has been created, as a bit of a hack. | 15:35.04 |
| sebras | tor8: in pdf_dict_get() how can be look at key->kind without resolving it? | 15:35.16 |
| tor8 | pdf_obj integers should normally be immutable | 15:35.16 |
| sebras | tor8: right, then it makes sense I guess. | 15:35.31 |
| | tor8: pdf_dict_get() ought to RESOLVE(key) just as pdf_dict_put() does, right? | 15:35.57 |
| tor8 | sebras: pooh. dict_put oughtn't resolve the key IMO. | 15:36.23 |
| sebras | tor8: ok. so while I apparently don't understand the code, I can spot patterns that are off... :) | 15:36.54 |
| tor8 | but you're better off asking Robin_Watts these questions, he's the villain who last messed with the object resolving logic | 15:37.04 |
| | sebras: the basic idea is if you get an indirect reference, using it as a value should automatically resolve to the object it points to | 15:37.46 |
| | sebras: commit e5213366409d28029cfa137f2c19d6ab4a828c4a | 15:38.22 |
| sebras | exactly, and so in pdf_dict_get() we attempt to use the key and we want to get a complaint if it is not a Name. I assume that we would wnt to resolve indirect names in this context too. | 15:38.40 |
| tor8 | sebras: no, using an indirect reference as an object key should be an error | 15:39.03 |
| | (though it should never happen) | 15:39.20 |
| sebras | tor8: why is that? | 15:39.44 |
| | tor8: why should it be an error I mean. | 15:39.54 |
| tor8 | in 99% of instances, you'll be calling dict_puts | 15:40.42 |
| | and the remaining 1% are when we're loading name trees and similar stuff | 15:40.53 |
| | so really, it should not matter but if you get an indirect reference into dict_put, something has gone terribly wrong | 15:42.19 |
| sebras | tor8: what if we are looking up an object name in the page resources? | 15:42.48 |
| | tor8: can the name be indirect in that case? | 15:42.55 |
| tor8 | sebras: no. | 15:43.11 |
| sebras | tor8: because the name would be explicit in the stream? | 15:43.33 |
| tor8 | all resource names are from /Name tokens in the content stream | 15:43.36 |
| sebras | tor8: got it. | 15:44.02 |
| tor8 | if you grep for 'pdf_dict_put(' you can see that every instance the key is retrieved from either an explicit name or string, or extracted from another dictionary with pdf_dict_get_key | 15:44.56 |
| | sebras: the irregularities ought to be fixed though | 15:45.29 |
| sebras | tor8: unless Robin_Watts fixes them in his tidying I'll whip up a patch later. | 15:45.58 |
| tor8 | sebras: thanks. | 15:46.11 |
| Robin_Watts | tor8: I need a sanity check. | 15:48.34 |
| | Try this: | 15:48.53 |
| | pdfclean -difggg ../ghostpcl/tests_private/comparefiles/adesso8.pdf bug.pdf 1 | 15:49.03 |
| | The resulting file renders fine for me. | 15:50.21 |
| | Oh, ignore me. I'm such a fool. | 15:51.01 |
| | Sorry. | 15:51.04 |
| tor8 | okay. ignoring. :) | 15:51.11 |
| Robin_Watts | "As a tribute to Harold Ramis, the Prince Charles Cinema is showing a double bill of Groundhog Day and Groundhog Day." | 17:43.39 |
| | tor8: ping | 17:52.05 |
| | I've done a test where I've changed pdf_run_page_contents to clean the page contents before running them. | 17:53.13 |
| | I've got 441 diffs, but I'm hoping they are all tiny rounding errors. Going to schlep my way through them (at least part way) to check. | 17:54.04 |
| | I was thinking about adding a new feature to the filter thing too. | 17:55.38 |
| | Have the filter thing build up a resources dictionary of all the resources it uses. | 17:56.12 |
| | That way if we edit streams to remove a given image, the filtered resources dictionary will only contain references to the ones it actually uses. | 17:56.54 |
| | Also, it allows us to then clean each of those resources in turn. | 17:57.23 |
| | tor7: I've just been talking at your older brother :) | 18:03.03 |
| ray_laptop | in case you can't tell, power is out for peeves and peeved (and in my house) | 18:22.18 |
| | Forward 1 day (to 2014/03/01)>>> | |
IRC Logs