IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<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 tho00:31.47 
  i take it its on someone's list00: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 yet08:02.31 
chrisl I'm answering that now - pretty trivial08: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 too11: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=94b2a364223143dc7f749862c6983173d8b47a6612:01.02 
  http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c3fa0d45ff96eefe6effaeffc45516c6f85587bd12: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 ping13:26.42 
Robin_Watts tor8: ping13:39.55 
kens Lots of pings....13:40.59 
Robin_Watts But no pongs :(13:41.15 
kens Sadly no13:41.21 
sebras pong!13:45.40 
kens aha, I see a chrisl13:50.51 
chrisl_r61 kens: pong13: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 sure13:51.23 
kens Let me zip it and mail it.13:51.32 
  on its way chrisl13:55.24 
chrisl_r61 Hmm, well, fontforge doesn't complain about it.....13:57.24 
kens Intriguing13:57.41 
  It doesn't work (try the out.pdf file)13:57.52 
  and ttfdump gets quite cross with the glyf table13:58.09 
chrisl_r61 evince says "some font thing failed" - helpful!13:59.10 
kens Lol13:59.18 
  I believe the first loca entry should be 0, and its not13: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 rush14:05.47 
chrisl Interesting, Freetype's tools interpret the font okay, although I get no glyphs displayed14:07.05 
kens yes, that's what happens14:07.14 
  but I believe ttfdump,. I think the font is broken14: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 though14:21.48 
  I guess I need to look at the loca format14:25.03 
chrisl I'm just trying to remember where freetype reads the glyf and loca tables14: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 cool14: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 that14: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 you14:42.01 
chrisl Do you know the first glyph index you expect a marking glyph to be in?14:42.27 
kens 0x53 I think14:42.43 
chrisl kens: do you know how many glyphs you expect in the font?14:50.53 
kens 9 including notdef14:51.09 
chrisl But with a bunch of "empty" glyphs, too?14:51.43 
kens many14:51.48 
chrisl Freetype is getting the number of glyphs as 89 - which seems plausible14:52.31 
kens correct I believe14:52.41 
henrys bbiab14: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 displayed14:55.34 
kens not what ttfduymp says14:56.03 
  offset 0x3614: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 awry14:57.42 
kens Hmm, could be, I will look at loca table more closely15:03.14 
chrisl kens: the number of locations is 45, that's not enough to cover the number of glyph indices we expect to use15:09.19 
kens ok thx chrisl15:09.45 
chrisl FWIW, both freetype and our own PS parsing code get the same answers15:10.19 
Robin_Watts tor8: ping15: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 me15:16.09 
  it should pass regression tests15: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:ping15:39.58 
kens chrisl, I see Dwight 'fessed up16:04.53 
tor8 Robin_Watts: bounty sounds fine to me16: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=82b666579e02a4d35b3087b79353373c355d107f16: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 code16:06.43 
chrisl That's a different, secondary issue. The problem in pdfwrite is easy.16:07.36 
kens Oh, OK16:07.42 
tor8 Robin_Watts: that one LGTM16: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=910016: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 16616:11.06 
  I mean, given that it's doing hashing, it probably doesn't really matter16:11.38 
kens No, as long as its consistent it doesn't matter, but it is wrong I think16:11.53 
  lket me just look at hash16:12.14 
  which does tkae a short stupidly16:12.31 
chrisl Well, leave it with me, because for safety strict alignment systems it would be better to pull individual bytes out16:12.35 
kens chrisl sure, change it that way, its only a hash, so as long as its based on the md5 we are good16:13.08 
  changing it all to byte/byte * seems easiest, but whatever you think best16:13.45 
  ah, later I *do* use shorts16:14.26 
  but again its a byte *16:14.43 
  how ridiculous16:14.47 
  chrisl keep an eye on the hashing of the 'used' array16:15.31 
chrisl it's easy enough to fix - I'll ping you for a check before I commit16:15.32 
kens OK np16: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 look16:17.28 
  yes, it adds i+=sizeof(short)16:17.48 
chrisl But the md5_hash doesn't16:18.12 
kens Nope, but I think it should16:18.18 
  SOrry, was that the question ?16:18.27 
  If so, then yes16:18.34 
chrisl Yes16:18.38 
kens As long as that's OK with your alignement stuff, that seems best to me16:19.05 
  increment i by 2 each time and count from 0 to 416:19.21 
chrisl Yes, that's no problem16:19.33 
kens D'oh! I mean 816:19.35 
  Its late, I'm sure you know what I mean16:19.51 
chrisl No worries, as I say, this is the easy problem..... the original one is a bit more horrid16: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 bytes16:25.19 
kens boggles16: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 tiffsep16:28.21 
paulgardiner Robin_Watts, tor8: tiny commit on paulg/master16:28.51 
chrisl kens: I can try it on their build, I suppose16: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 things16:30.15 
kens True, I thought we had educated her about 'crash' but maybe not16: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 idea16:31.47 
  And having Evince check it was even stupider16:33.11 
paulgardiner Robin_Watts: another little commit - sorting the file picker as you requested16: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 initialisation16:59.18 
kens OK I've had enough, night all17:00.40 
Robin_Watts night kens17:00.45 
paulgardiner Robin_Watts: updated17:02.58 
Robin_Watts Lovely.17:03.20 
  I shall pull/push17:03.26 
  pushed17:06.04 
  tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=70e18ba1458ed62f46a5da879a889b776b4deb3817: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 sense17:12.24 
  Hang on. You can do it with configurations in VS. That might be better17:14.59 
  Two targets rather than two projects17:15.43 
Robin_Watts No, I want to be able to hit make once, and have it make both mudraw and mudraw-v817:16.05 
  or mupdf and mupdf-v8 even.17:16.14 
paulgardiner Well you can do a batch build of multiple configs17: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 VS17:26.27 
Robin_Watts paulgardiner: right17:26.49 
  tor8: some mumblings in the logs.17:27.09 
paulgardiner Consistency with linux makes sense17: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 configurations17:28.09 
Robin_Watts tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=70e18ba1458ed62f46a5da879a889b776b4deb3817:35.19 
  tor8: And look at the last part of pdf/pdf_xref.c in this diff: http://bugs.ghostscript.com/attachment.cgi?id=909817:36.01 
  Does that make any sense to you?17:36.07 
mvrhel_laptop good morning17:43.53 
Robin_Watts mvrhel_laptop: Morning17: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 out18:01.26 
  I have not had a chance yet to see if I can print here with this printer that I have18: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 work18: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 result18: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 right18:05.38 
  try to make mistakes where you cant seem them18:06.01 
  or push the error out there that is18:06.07 
  it would be good to have him printing with the changes that you have done18: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 good18:13.30 
  I have not heard from my customer that I did all that work for in a month. Just pinged him now18:13.54 
  I don't want him to be getting back to me with issues 1 week before the release18: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=f251b656c1cc925ca38c7f543177df19911fadf418: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 work18: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 there21: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 bit21:09.37 
  will beat on this more later. bbiab21:10.01 
tor8 Robin_Watts: the 'prevent use-after-free' hunk? no, makes no sense at all21: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 instead21: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/ please21: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 stack21:32.57 
  would be preferable, and more obvious what's going on, without dynamic allocation thrown in the mix21: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 int21:35.15 
chrisl_away away away22: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)>>> 
ghostscript.com
Search: