| <<<Back 1 day (to 2012/11/28) | 2012/11/29 |
sebras | wart____: hi! I would suggest that you ask again in about 12h when most of the devs working on mupdf are online. :) | 00:21.23 |
Robin_Watts | wart____: It can't be done currently. It's on our list, but it's unlikely to get done before feb at least. | 00:23.08 |
sebras | kanru: btw, there have been two new versions of mupdf released which have not made it into Debian. would you mind packaging mupdf 1.1 as a .deb? :) | 00:23.40 |
| Robin_Watts: oh, sorry. I though you had left already. | 00:24.14 |
Robin_Watts | I have :) | 00:24.29 |
sebras | Robin_Watts: I never knew that you could detect irc movement through closed eyelids while sleeping, but now I know. ;) | 00:25.32 |
wart____ | Robin_Watts: thanks. i'll keep my ear to the (git) ground tho | 00:31.47 |
| i take it its on someone's list | 00:31.57 |
kens | chrisl can you take a quick look at #693474 please, its probably simple enough to address. | 08:00.52 |
chrisl | kens: sure. The difficult bit be convincing git to to accept the permission change...... | 08:01.53 |
kens | Hmm, well the other scripts seem to be OK, so I guess its *possible*... | 08:02.16 |
| THere's alos somethiing in gs-devel that I haven't looked at in detail yet | 08:02.31 |
chrisl | I'm answering that now - pretty trivial | 08:02.45 |
kens | AH, OK, I'll await your reply :-) | 08:02.59 |
chrisl | Well, git is better at handling permissions changes that svn was - that was easy :-) | 08:07.50 |
kens | That's good :-) | 08:08.10 |
Robin_Watts | Morning tor8. | 11:21.30 |
| I'm going to run through bug 693463 now. | 11:21.43 |
tor8 | Robin_Watts: morning. great! | 11:22.21 |
| I see you went through and assigned yourself a handful of other bugs too | 11:22.48 |
Robin_Watts | tor8: Yeah, the ones I closed yesterday, I think. | 11:23.02 |
kens | Hmm, well thre's definitely something wrong with our TrueType writing code, again..... :-( | 11:29.30 |
Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=94b2a364223143dc7f749862c6983173d8b47a66 | 12:01.02 |
| http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c3fa0d45ff96eefe6effaeffc45516c6f85587bd | 12:01.11 |
tor8 | Robin_Watts: nod. nod. | 12:02.28 |
Robin_Watts | Thanks. Just cluster testing, then I'll push. | 12:02.50 |
tor8 | I'm surprised there aren't more in the xps code, or maybe he just hasn't found them yet :) | 12:02.51 |
| Robin_Watts: btw, did you put the renamed sumatra test files somewhere? | 12:03.24 |
| I have a suspicion I need to resync all my test files... | 12:03.38 |
Robin_Watts | tor8: They are in tests_private/pdf/sumatra I believe. | 13:09.11 |
kens | chrisl ping | 13:26.42 |
Robin_Watts | tor8: ping | 13:39.55 |
kens | Lots of pings.... | 13:40.59 |
Robin_Watts | But no pongs :( | 13:41.15 |
kens | Sadly no | 13:41.21 |
sebras | pong! | 13:45.40 |
kens | aha, I see a chrisl | 13:50.51 |
chrisl_r61 | kens: pong | 13:50.56 |
kens | chrisl can you look at a TrueType font for me, and tell me what's wrong with it ? | 13:51.16 |
chrisl_r61 | sure | 13:51.23 |
kens | Let me zip it and mail it. | 13:51.32 |
| on its way chrisl | 13:55.24 |
chrisl_r61 | Hmm, well, fontforge doesn't complain about it..... | 13:57.24 |
kens | Intriguing | 13:57.41 |
| It doesn't work (try the out.pdf file) | 13:57.52 |
| and ttfdump gets quite cross with the glyf table | 13:58.09 |
chrisl_r61 | evince says "some font thing failed" - helpful! | 13:59.10 |
kens | Lol | 13:59.18 |
| I believe the first loca entry should be 0, and its not | 13:59.29 |
chrisl_r61 | Hmm, I need to go back up to my office - this laptop doesn't have all the tools on it...... | 14:02.26 |
kens | well no rush | 14:05.47 |
chrisl | Interesting, Freetype's tools interpret the font okay, although I get no glyphs displayed | 14:07.05 |
kens | yes, that's what happens | 14:07.14 |
| but I believe ttfdump,. I think the font is broken | 14:07.26 |
Robin_Watts | checks seat availability on the flight for next week. | 14:07.35 |
kens | You don't have a seat yet RObin ? | 14:07.54 |
Robin_Watts | I do. Was just wondering how full the flight was. | 14:10.47 |
| And I'm not averse to a last minute shuffle of seats if it looks like I can wangle a free seat next to me. | 14:11.10 |
| Flight back looks packed. | 14:11.14 |
chrisl | kens: well, the opentype validation tool says "Incorrect format of loca", and "Unable to start validation of 'glyf' table Table 'loca' has incorrect format" | 14:17.03 |
| kens: well, the opentype validation tool says "Incorrect format of loca", and "Unable to start validation of 'glyf' table Table 'loca' has incorrect format" | 14:21.30 |
kens | Well, that would do it.... | 14:21.41 |
| ttfdump thinks the loca is OK though | 14:21.48 |
| I guess I need to look at the loca format | 14:25.03 |
chrisl | I'm just trying to remember where freetype reads the glyf and loca tables | 14:26.31 |
| Oh, darn, it doesn't :-( It relies on us doing it, via the incremental interface - doh! | 14:28.23 |
henrys | kens, Robin_Watts:got the cluster machines on power line networking, seems to be working okay so far. | 14:35.22 |
Robin_Watts | fab. | 14:35.30 |
kens | henrys cool | 14:35.41 |
chrisl | kens: the number of locations is less than the number of glyphs - which seems wrong..... | 14:40.18 |
kens | odd, there'sd a specific check for that | 14:40.49 |
chrisl | Well, I'm looking at what freetype's ftview is doing with the font file you sent.... | 14:41.46 |
kens | not doubting you | 14:42.01 |
chrisl | Do you know the first glyph index you expect a marking glyph to be in? | 14:42.27 |
kens | 0x53 I think | 14:42.43 |
chrisl | kens: do you know how many glyphs you expect in the font? | 14:50.53 |
kens | 9 including notdef | 14:51.09 |
chrisl | But with a bunch of "empty" glyphs, too? | 14:51.43 |
kens | many | 14:51.48 |
chrisl | Freetype is getting the number of glyphs as 89 - which seems plausible | 14:52.31 |
kens | correct I believe | 14:52.41 |
henrys | bbiab | 14:55.28 |
chrisl | OKay, so for glyph 0x53, the starting offset comes out as 0, and the ending offset as 0, and (obviously) the length is 0 - hence no error, but no glyphs displayed | 14:55.34 |
kens | not what ttfduymp says | 14:56.03 |
| offset 0x36 | 14:56.11 |
chrisl | Well, my guess is that because the number of locations is less than the number of glyphs, Freetype is rejigging the loca table into something it thinks is sensible, but something is going awry | 14:57.42 |
kens | Hmm, could be, I will look at loca table more closely | 15:03.14 |
chrisl | kens: the number of locations is 45, that's not enough to cover the number of glyph indices we expect to use | 15:09.19 |
kens | ok thx chrisl | 15:09.45 |
chrisl | FWIW, both freetype and our own PS parsing code get the same answers | 15:10.19 |
Robin_Watts | tor8: ping | 15:13.28 |
| henrys, tor8: zeniko asks if bug 693290 is sufficient for a bounty. | 15:14.40 |
| It's a collection of issues (and fixes) found by fuzzing. It looks plausibly bounty sized to me. | 15:15.07 |
henrys | fine by me | 15:16.09 |
| it should pass regression tests | 15:16.31 |
Robin_Watts | I'm sure it will. | 15:17.23 |
| I was about to start looking at the patch in detail, but thought we should agree whether it's bountiable or not up front. | 15:17.58 |
henrys | marcosw:ping | 15:39.58 |
kens | chrisl, I see Dwight 'fessed up | 16:04.53 |
tor8 | Robin_Watts: bounty sounds fine to me | 16:05.04 |
Robin_Watts | tor8: cool. I have a couple of small reviews, please. | 16:05.24 |
| http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=82b666579e02a4d35b3087b79353373c355d107f | 16:05.47 |
chrisl | kens: That's a little surprising. We'll see if Scott gets anywhere, this time. The problem he reported is a sod, too :-( | 16:06.14 |
kens | Hmm, is it a real problem ? I mean can you reproduce it ? | 16:06.34 |
| Because it seems to be in my code | 16:06.43 |
chrisl | That's a different, secondary issue. The problem in pdfwrite is easy. | 16:07.36 |
kens | Oh, OK | 16:07.42 |
tor8 | Robin_Watts: that one LGTM | 16:07.46 |
chrisl | kens: actually, I meant to ask you about that...... | 16:08.34 |
kens | :-( | 16:08.42 |
Robin_Watts | tor8: Thanks. | 16:08.46 |
| tor8: THere is one part of zenikos patch that I didn't take on. | 16:09.12 |
| http://bugs.ghostscript.com/attachment.cgi?id=9100 | 16:09.16 |
chrisl | kens: in pdf_add_subset_prefix() in gdevpdtb.c...... | 16:09.24 |
Robin_Watts | penultimate chunk. | 16:09.26 |
| If TR2 is present, and it's Identity or Default, then we need not warn. | 16:09.50 |
| hence I think the code is correct currently. | 16:10.06 |
chrisl | kens: you've got it accessing ushorts, but incrementing in bytes, was that intentional? | 16:10.22 |
kens | chrisl I shouldn't think so for a momnet, can yoiu give me a line number ? | 16:10.38 |
chrisl | Line 166 | 16:11.06 |
| I mean, given that it's doing hashing, it probably doesn't really matter | 16:11.38 |
kens | No, as long as its consistent it doesn't matter, but it is wrong I think | 16:11.53 |
| lket me just look at hash | 16:12.14 |
| which does tkae a short stupidly | 16:12.31 |
chrisl | Well, leave it with me, because for safety strict alignment systems it would be better to pull individual bytes out | 16:12.35 |
kens | chrisl sure, change it that way, its only a hash, so as long as its based on the md5 we are good | 16:13.08 |
| changing it all to byte/byte * seems easiest, but whatever you think best | 16:13.45 |
| ah, later I *do* use shorts | 16:14.26 |
| but again its a byte * | 16:14.43 |
| how ridiculous | 16:14.47 |
| chrisl keep an eye on the hashing of the 'used' array | 16:15.31 |
chrisl | it's easy enough to fix - I'll ping you for a check before I commit | 16:15.32 |
kens | OK np | 16:15.39 |
chrisl | kens: should I change it to increment two bytes at a time, too? | 16:17.16 |
kens | chrisl it does, I think, let me look | 16:17.28 |
| yes, it adds i+=sizeof(short) | 16:17.48 |
chrisl | But the md5_hash doesn't | 16:18.12 |
kens | Nope, but I think it should | 16:18.18 |
| SOrry, was that the question ? | 16:18.27 |
| If so, then yes | 16:18.34 |
chrisl | Yes | 16:18.38 |
kens | As long as that's OK with your alignement stuff, that seems best to me | 16:19.05 |
| increment i by 2 each time and count from 0 to 4 | 16:19.21 |
chrisl | Yes, that's no problem | 16:19.33 |
kens | D'oh! I mean 8 | 16:19.35 |
| Its late, I'm sure you know what I mean | 16:19.51 |
chrisl | No worries, as I say, this is the easy problem..... the original one is a bit more horrid | 16:20.33 |
kens | THat's teh iref I guess ? | 16:20.50 |
chrisl | Yes, but again, the real issue seems to be alignment. Weirdly, it doesn't happen on gcc 3.x.x, nor with the Sun cc, only gcc 4.x.x :-( | 16:22.14 |
kens | Odd. | 16:22.28 |
chrisl | I think the root of the problem is that recent SPARC32 architectures have 4 byte pointers, but pointer *alignment* is 8 bytes | 16:25.19 |
kens | boggles | 16:25.44 |
chrisl | IIRC, it's because "under the hood", it's 64 bit - the 32 bit-ness is a sort of "overlay". It's pretty sh*t :-( | 16:27.24 |
kens | Hehe Wow32 :-) | 16:27.41 |
| hmm, for me Gemma's latest file seems to run forever with tiffsep | 16:28.21 |
paulgardiner | Robin_Watts, tor8: tiny commit on paulg/master | 16:28.51 |
chrisl | kens: I can try it on their build, I suppose | 16:29.02 |
kens | Well she says it GPFs there, but for me it never seems to end, I was going to leave it for Marcos :-) | 16:29.26 |
chrisl | She says "it crashes", which could mean a lot things | 16:30.15 |
kens | True, I thought we had educated her about 'crash' but maybe not | 16:30.31 |
chrisl | That type of education doesn't always take..... | 16:31.03 |
kens | God, sticking XML In a PDF file was such a bad idea | 16:31.47 |
| And having Evince check it was even stupider | 16:33.11 |
paulgardiner | Robin_Watts: another little commit - sorting the file picker as you requested | 16:47.10 |
Robin_Watts | paulgardiner: Ah, thanks. | 16:47.19 |
| I'll look at them in just a sec. | 16:47.27 |
| oname needs to be set to NULL, I think. | 16:57.33 |
| If pdf_jsimp_from_string throws an exception, then we end up returning an uninitialised oname. | 16:58.06 |
| paulgardiner: ^ | 16:58.09 |
| Otherwise both look good. | 16:58.19 |
paulgardiner | Damn! Well spotted. I had it initialised to NULL a first and then stupidly removed the initialisation | 16:59.18 |
kens | OK I've had enough, night all | 17:00.40 |
Robin_Watts | night kens | 17:00.45 |
paulgardiner | Robin_Watts: updated | 17:02.58 |
Robin_Watts | Lovely. | 17:03.20 |
| I shall pull/push | 17:03.26 |
| pushed | 17:06.04 |
| tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=70e18ba1458ed62f46a5da879a889b776b4deb38 | 17:07.16 |
| tor8, paulgardiner: I am tempted to rearrange the VS projects slightly. | 17:10.14 |
| At the moment,we have a whole batch of files that are in both libmupdf and libmupdf-v8. | 17:10.32 |
| I'd be tempted to create a libmupdf-nojs, and have that and libmupdf-v8 depend on libmupdf. | 17:11.36 |
| That way every file needs only to appear in 1 library, which will stop searching throwing up double matches. | 17:12.02 |
| and will help compile time too. | 17:12.09 |
paulgardiner | Yeah. That makes a lot of sense | 17:12.24 |
| Hang on. You can do it with configurations in VS. That might be better | 17:14.59 |
| Two targets rather than two projects | 17:15.43 |
Robin_Watts | No, I want to be able to hit make once, and have it make both mudraw and mudraw-v8 | 17:16.05 |
| or mupdf and mupdf-v8 even. | 17:16.14 |
paulgardiner | Well you can do a batch build of multiple configs | 17:20.33 |
Robin_Watts | Not as nice, IMHO. On unix we build 'mupdf' and 'mupdf-v8' so nicer to be consistent on windows, I feel. | 17:22.22 |
| And separating the projects makes it clear which files change between v8 and non v8 builds. | 17:23.14 |
paulgardiner | I'm easy either way. With that last point: it is common for different configurations to include a few different files in VS | 17:26.27 |
Robin_Watts | paulgardiner: right | 17:26.49 |
| tor8: some mumblings in the logs. | 17:27.09 |
paulgardiner | Consistency with linux makes sense | 17:27.20 |
tor8 | Robin_Watts: re the VS projects? | 17:27.41 |
Robin_Watts | yeah. | 17:27.46 |
tor8 | Robin_Watts: go ahead. | 17:27.50 |
Robin_Watts | And a review. | 17:27.58 |
| soon to be 2 reviews. | 17:28.01 |
| and a question in just a sec... | 17:28.06 |
tor8 | three targets seem better than more configurations | 17:28.09 |
Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=70e18ba1458ed62f46a5da879a889b776b4deb38 | 17:35.19 |
| tor8: And look at the last part of pdf/pdf_xref.c in this diff: http://bugs.ghostscript.com/attachment.cgi?id=9098 | 17:36.01 |
| Does that make any sense to you? | 17:36.07 |
mvrhel_laptop | good morning | 17:43.53 |
Robin_Watts | mvrhel_laptop: Morning | 17:44.13 |
| Did you see the ETS mail I sent to the max? Does that seem a reasonable way to proceed? | 17:44.36 |
| s/the max/max/ Ahem. | 17:45.39 |
mvrhel_laptop | Robin_Watts: yes thanks for sending that out | 18:01.26 |
| I have not had a chance yet to see if I can print here with this printer that I have | 18:01.45 |
Robin_Watts | I was just a bit worried that you might go "no, that's not the right way to find thresholds!" | 18:02.07 |
mvrhel_laptop | Robin_Watts: really to get things perfectly tuned for a device requires lots of printing and microscope work | 18:03.30 |
Robin_Watts | mvrhel_laptop: Right. | 18:03.46 |
| Ideally I guess, we want a "Tuning ETS for Dummies" guide. | 18:04.03 |
mvrhel_laptop | sometimes, some modeling of the dot shape and splatter in a tool like matlab can be done to do some degree of optimization. | 18:04.21 |
| in that case you "print" in matlab, push the image through a model of the human visual system and find the smoothest result | 18:04.47 |
| this is the sort of thing I worked on years ago | 18:05.16 |
Robin_Watts | The visual equivalent of the kind of psychoacoustical modelling that happens with audio compression, I guess. | 18:05.31 |
mvrhel_laptop | right | 18:05.38 |
| try to make mistakes where you cant seem them | 18:06.01 |
| or push the error out there that is | 18:06.07 |
| it would be good to have him printing with the changes that you have done | 18:06.36 |
| he does have the latest code right? | 18:06.45 |
| Robin_Watts: ^^ | 18:06.49 |
Robin_Watts | He doesn't. | 18:06.57 |
| In the last email I offered it to him when he got back, but had no reply. | 18:07.12 |
mvrhel_laptop | looking over the email strand I would give him a link or send him a snap shot of what we have | 18:09.23 |
Robin_Watts | mvrhel_laptop: I'll wait until I hear back from him. If we don't hear back within a few days, then we can send some code along as a nudge. | 18:13.20 |
mvrhel_laptop | ok sounds good | 18:13.30 |
| I have not heard from my customer that I did all that work for in a month. Just pinged him now | 18:13.54 |
| I don't want him to be getting back to me with issues 1 week before the release | 18:14.07 |
Robin_Watts | "hurry up and wait!" | 18:14.09 |
marcosw | henrys_mac: is building pcl with ufst still broken or do I have a problem with the weekly regression configuration? | 18:27.58 |
Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=f251b656c1cc925ca38c7f543177df19911fadf4 | 18:28.21 |
chrisl | marcosw: it's broken - I'm working on fixing it. | 18:28.34 |
| marcosw: actually it should build, but it won't work | 18:30.13 |
| marcosw: you did read my e-mail a few weeks back about the next generation FAPI stuff? | 18:35.35 |
marcosw | Robin_Watts: your latest clusterpush is timeout and confusing the cluster; I'm working fixing it. | 19:38.01 |
Robin_Watts | oops. | 19:38.34 |
marcosw | chrisl: you mean UFST 6.2? I haven't moved the regression tests to that since I thought you said our customers weren't using it. | 19:38.49 |
chrisl_r61 | marcosw: yes, I doubt the old UFST 5 integration with PCL will still work, now. | 19:40.14 |
marcosw | chrisl_r61: so we are going to force our customers to switch to UFST 6.2 with the next release or do you plan on fixing UFST 5 at some point? | 20:25.32 |
chrisl_r61 | marcosw: I was planning to give customers 6.2. | 20:30.52 |
| Unless there is a very solid reason not to....... | 20:31.52 |
mvrhel_laptop | Robin_Watts: you around? | 21:02.39 |
| I know it is a bit late there | 21:02.44 |
| ndk-build does not work for me but I think I now understand the issue. I am on 64 bit linux and the prebuilts are for x86 32 bit | 21:09.37 |
| will beat on this more later. bbiab | 21:10.01 |
tor8 | Robin_Watts: the 'prevent use-after-free' hunk? no, makes no sense at all | 21:29.11 |
| I'm a bit suspicious about some of the jpeg and png patches too. | 21:29.45 |
| skip_input_data, that ought to be an assert or something instead | 21:30.09 |
| and what's with the magic number 12 in the png decoder? | 21:30.22 |
| s/do_read_xref_sections/pdf_read_xref_sections_imp/ please | 21:31.00 |
| I don't like that patch at all though... | 21:32.10 |
| it's a complete abuse of fz_buffer for nefarious purposes. shouldn't that be a flag in the pdf_xref table instead? | 21:32.38 |
| or a linked list on the stack | 21:32.57 |
| would be preferable, and more obvious what's going on, without dynamic allocation thrown in the mix | 21:33.26 |
| oh, right, I understand the png patch now. ugh, I hate signed/unsigned int messes :( | 21:34.21 |
| if ((int)size + 12 > total) ... that (int) cast is useless, since size is already int | 21:35.15 |
chrisl_away | away away | 22:23.42 |
Robin_Watts | tor8: I have to go out now, but we should talk about the patch tomorrow. | 22:36.21 |
tor8 | Robin_Watts: sure. | 22:36.31 |
Robin_Watts | I'll rejig it to avoid fz_buffer. (Though I have to say I was grudgingly impressed by his use of it :) ) | 22:36.46 |
| Forward 1 day (to 2012/11/30)>>> | |