| | <<<Back 1 day (to 2011/10/19) | 2011/10/20 |
| arthurf | tor8 or Robin_Watts: I can help with testing the iPad version of mupdf. I have a developers account - and an original iPad - along with the first 4 iPhones (should I have admitted that?) :) | 03:20.07 |
| | tor8 or Robin_Watts: I have to earn $ during the day, but after hours I would have some time. | 03:21.33 |
| | tor8: typically the NSObject class method alloc is not used by itself, it is used in conjunction with init which can return nil, as in object = [[class alloc] init]; | 03:36.10 |
| mvrhel2 | henrys: you there? | 04:23.32 |
| henrys | mvrhel2: now I am. | 05:28.03 |
| mvrhel2 | henrys: no worries. I figured it out | 05:46.30 |
| | good night all | 06:57.28 |
| kens | goodnight | 06:57.34 |
| | chrisl I now know what's going on with teh GlyphDirectory srtuff, at least on the input side. | 07:36.33 |
| chrisl | kens: I don't think it should be very complicated, on the input side, at least | 07:38.38 |
| kens | Its a pretty basic problem | 07:39.34 |
| | We alway scopy fonts, presumably in case they go away during garbage collection | 07:39.50 |
| | The copy we make only includes glyphs as they are used. | 07:40.05 |
| | When they are used we copy the glyph data into a table of glyphs | 07:40.19 |
| | The problem is that its a simple array 0->NumGlyphs in the original font. | 07:40.40 |
| | Of course if we have a diciotnary GlyphDirectory then the CIDs may exceed the NumGlyphs. | 07:41.04 |
| | This can't happen in a regular or array GlyphDirectory font. | 07:41.20 |
| chrisl | True | 07:41.44 |
| kens | I think the only way to 'address' this will be to make the table the size of the largest CID. | 07:42.04 |
| | Which will mean enumerating the GlyphDirectory to find the highest CID and will involve using more memory | 07:42.25 |
| | And that's before I figure out how this gets used to write the font out.... | 07:42.39 |
| chrisl | Well, that was my first suggestion - the other solution would be to use a dictionary type structure so you save both the CID key, and the glyph - bigger change, though. | 07:43.11 |
| kens | *much* bigger, too big really. | 07:43.27 |
| | The same code gets used for all font types, so I don't really want to change it for the benefit of one subtype | 07:43.46 |
| | Its ugly, but I can't see a better solution | 07:44.06 |
| chrisl | In general, I don't think it's a big deal - even with large CID font, the array itself isn't going to take up *too* much memory, in the context of modern software trends | 07:45.13 |
| kens | Looks like 10 bytes * largest CID | 07:46.31 |
| | In this case 87k -> 650k of storage | 07:47.40 |
| chrisl | Like I said, not that big in the context of multi-gigabyte memoried computers..... | 07:48.02 |
| kens | True, but it is quite a bit. If this was anything other than pdfwrite I might be concerned. | 07:48.22 |
| | Bearing in mind that this is per subset font, and this file contains at least 5 of tehm.... | 07:48.45 |
| | But still.... | 07:48.54 |
| chrisl | Well, the other argument is: we can get it wrong and use little memory, or get it right, and use more memory......... | 07:49.03 |
| kens | I guess I should try and move my head into the 21st Cenrtury wrt memory | 07:49.12 |
| chrisl | And it's "only" this form of font, others should be unaffected | 07:49.48 |
| kens | Yes, true. Well better get started I suppose, I'll have to look into the output stage after I've got the input working.... | 07:50.24 |
| | Hmm, well a quick hack gets 'better' results. Not right but surprisingly much better. | 09:03.33 |
| | OK Lookslike some glyphs still go AWOL, and when they do they have a Width of 0, which causes the remaining text to be shifted around. | 09:06.36 |
| | SO I need to find out why some of the glyphs are still missing and that should fix it (amazingly) | 09:07.01 |
| | I think I'll do a cluster test while I work on this, just to be sure I haven't broken anything | 09:08.29 |
| Robin_Watts | Can we have clists of > 4 Gig I wonder... | 10:07.03 |
| kens | Should be possible I think | 10:07.17 |
| | Not sure about offsets on 32-bit machines though, do clists contain offsets ? | 10:07.31 |
| Robin_Watts | Yes, that was the root of my question. | 10:07.47 |
| | The offset field is a ulong. On windows that's always 32bits. | 10:08.09 |
| | on linux 64bits it's 64. | 10:08.16 |
| kens | I think the streams cna handle it (I did this for pdfwrite, though its not complete yet), the problem is if something is using an int to store an offset | 10:08.29 |
| chrisl | I think there was a recent bug where Ray was talking about >4Gb clists | 10:13.39 |
| | Robin_Watts: Bug 692158 Ray mentions "Good thing we have 64-bit clist file support. The final clist size is 273 Gb!" | 10:16.35 |
| Robin_Watts | Ok. | 10:20.13 |
| kens | Well, my quick hack introduces loads of differences, and several failing files. That *is* a surprise.... | 10:30.27 |
| | D'oh, CIDs start from 0.... | 10:52.42 |
| tor8 | Robin_Watts: this is a reassuring compiler error ... /var/folders/XY/XYh3SInRH5K9vhUvCio5HU+++TI/-Tmp-/cc-VNT3kV.s:574:garbage following instruction -- `orr r1,r12,lsl#16' | 12:26.33 |
| Robin_Watts | Well... that's 'new' ARM. | 12:27.03 |
| | traditional ARM would say ORR r1,r1,r12,LSL #16 | 12:27.23 |
| tor8 | trying to build libfreetype for arm using clang | 12:27.29 |
| Robin_Watts | some asms will complain about the lack of space before the #. | 12:27.37 |
| | that's poor... | 12:27.47 |
| tor8 | I didn't write that line... it's all in the compiler! | 12:28.00 |
| sebras | tor8: why do you use clang? | 12:28.09 |
| tor8 | sebras: because apple wants you to? | 12:28.25 |
| | apparently it's supposed to generate much better arm code than gcc | 12:28.35 |
| sebras | tor8: right. I tend to forget that they went gcc->clang... | 12:28.41 |
| tor8 | but as you can see, it can't even generate compilable code... | 12:28.47 |
| Robin_Watts | gcc generates MASSIVELY sucky ARM code. OR at least did until very recently. | 12:29.03 |
| | I think I've found my clist problem. | 12:30.39 |
| tor8 | Robin_Watts: maybe I'll have better luck with llvm-gcc | 12:30.42 |
| | hah! nope... | 12:31.10 |
| | same error, with different wording | 12:31.26 |
| Robin_Watts | Is there any inline assembler in there, perchance ? | 12:31.50 |
| kens | cinsistency is nice ;-) | 12:31.51 |
| Robin_Watts | runs test, and gets lunch | 12:33.05 |
| tor8 | google sucks today. the top 4 results for the search "freetype arm llvm" do not even contain the word freetype... | 12:39.53 |
| arthurf | tor8 sebras or RobinWatts: I guess my posting during the swing shift wasn't particularly effective. :) Since my wife woke me up because I was snoring - thought I'd ask with everyone here if any iPad testing assistance is needed or wanted yet with mupdf | 12:41.14 |
| kens | I read the post, but it's not my area | 12:41.57 |
| tor8 | arthurf: I saw it in the log :) we would certainly appreciate testing on older and various platforms. I've only got access to an iPad 2 and a very old iPhone 3. | 12:42.26 |
| arthurf | tor8: cool - okay I'll try it out tonight | 12:43.23 |
| tor8 | next week would probably be better | 12:43.43 |
| | I'm tweaking the build flags today | 12:43.54 |
| arthurf | tor8: okay - sounds good to me | 12:44.05 |
| | tor8: I have both Xcode 3 and 4. Still getting used to 4. | 12:44.47 |
| tor8 | I only have Xcode 3. paying for an upgrade to a tool that has been free for a decade is wrong on so many levels... | 12:45.38 |
| arthurf | tor8: Hmmm - I wasn't asked to pay for Xcode 4 - but I'm still on Snow Leopard, been a little leery of jumping into Lion. | 12:47.45 |
| tor8 | when they released Xcode 4 on the app store, they charged a symbolic sum of I think $5 for it | 12:48.09 |
| arthurf | ah | 12:48.24 |
| tor8 | which completely weeds out anyone who doesn't want to give apple their credit card information ... or don't have one to begin with | 12:48.42 |
| Fandekasp | hey there | 12:57.37 |
| | I see that you fixed some of my problems with mupdf ... I can open the link (thanks for the xdg-open) and the PRIMARY selection finally works | 12:58.26 |
| | But you didn't push the hack you gave me to give a search pattern from the command line :( | 12:59.11 |
| | So I have to keep my own version and make it, which is not really cool now that I made the sabayon team put mupdf on their repo lol | 12:59.47 |
| | it's the case 'f': initial_search = fz_optarg; break; | 13:01.36 |
| Robin_Watts | discovers the 'start' command in windows. | 14:02.49 |
| | Works at the git command line too; start out.png will do the same as double clicking out.png in an explorer window. | 14:03.40 |
| kens | Or just out.png if you have assigned an action for .png files | 14:10.15 |
| Robin_Watts | Not at the git command line. | 14:10.29 |
| | Which is the attraction of start :) | 14:10.44 |
| kens | not that bothered myself, but if you find it useful.... | 14:11.18 |
| Robin_Watts | I frequently want to run gs to make a .pam, then convert to png , then launch the .png into a viewer. | 14:11.56 |
| tor8 | Robin_Watts: I always get confused when swapping between mac and windows ... I type 'open' on windows and 'start' on mac and wonder why nothing happens... | 14:12.08 |
| Robin_Watts | and now I can do that all in one hit from inside msysGit | 14:12.17 |
| | alias open to start? and have an open.bat ? :) | 14:12.39 |
| tor8 | I have considered it :) | 14:12.53 |
| kens | chrisl re 692619 | 14:19.22 |
| chrisl | kens: yes? | 14:19.37 |
| kens | I should tell Raed to upgrade to 9.04 since that includes Luratech I think ? | 14:19.42 |
| | Customer release that is | 14:19.52 |
| chrisl | I think so, yes. I can't see us fixing Jasper at this stage! | 14:20.10 |
| kens | Not if we intend to move to OpenJPEG | 14:20.27 |
| | Assuming they don't want toupgrade, I wonder if we could let them use Luratech with the old version, that should work, right ? | 14:20.56 |
| chrisl | Yes, but they'll need to do the make file changes themselves. Try to get them to upgrade, and if they *really* won't, then we can tell them how use it with an earlier release. | 14:21.42 |
| kens | Right, I'll do that now, thanks | 14:21.53 |
| chrisl | I really just wanted to check it wasn't a FAPI problem ;-) | 14:22.13 |
| kens | Oh I was sure it was the images. | 14:22.28 |
| | DIdn't occur to me it might be JasPer | 14:22.36 |
| chrisl | I just read "should render with some text"..... | 14:23.03 |
| arthurf | tor8: I get it - the reason I don't have to pay for Xcode 4 is because I already pay $99 a year for the iOS Developers Program. If one is not a member of either the iOS or the Mac program - then one has to pay about $5 for Xcode 4 through the App Store. | 14:23.17 |
| tor8 | arthurf: right, so I could get it now since I renewed the ios dev program | 14:23.48 |
| chrisl | kens: To be honest, when I saw the output, my first thought was jbig2, not jp2k! | 14:23.58 |
| Robin_Watts | For those of you who miss ctrl-left and ctrl-right (move by words) in msysGit, add the following lines to the /etc/inputrc file: | 15:04.05 |
| | "\e[D": backward-word# Control Left | 15:04.20 |
| | "\e[C": forward-word# Control Right | 15:04.22 |
| | actually, scratch that. | 15:09.59 |
| ray_laptop | chrisl: well, I tried adding the following to base/configure.ac, then re-running ./autogen.sh and I don't see the expected -DHAVE_SYS_SYSINFO=1 in the resulting Makefile and I don't see the expected line: "checking sys/sysinfo.h presence..." | 15:28.11 |
| | if test "x$ac_cv_header_sys_sysinfo_h" = xyes; then (new lines 269-271) | 15:28.13 |
| | GCFLAGS="$GCFLAGS -DHAVE_SYS_SYSINFO_H=1" | 15:28.15 |
| | fi | 15:28.17 |
| chrisl | ray_laptop: you haven't actually added the test for the header - you need to add an AC_CHECK_HEADER macro call | 15:31.35 |
| Robin_Watts | God, another corner case. | 15:32.42 |
| chrisl | ray_laptop: it may be easier to add sys/sysinfo.h to the AC_CHECK_HEADERS list, though | 15:34.06 |
| Robin_Watts | Hey marcosw_. Good luck today. | 15:36.32 |
| marcosw_ | thanks. A bit late, we finished today's qualification stage already. OUr time was 5:32, which I have no idea how good it is, but it will be better than the four cars we saw off the side of the road in the bushes (one 911 and three I couldn't identify since we were going pretty fast). | 15:38.24 |
| ray_laptop | chrisl: thanks, I'll give it a try | 15:38.55 |
| Robin_Watts | Are you driving? or is miles? or are you taking turns? | 15:38.58 |
| chrisl | ray_laptop: I can send you a patch if you like - it won't take a minute | 15:39.14 |
| ray_laptop | chrisl: I added it to the AC_CHECK_HEADERS list and that did the trick. Thanks | 15:42.35 |
| chrisl | ray_laptop: cool. | 15:43.13 |
| kens | congrats so far marcosw and Miles | 15:43.46 |
| Robin_Watts | marcosw_: Do you know the GPS tracker URL yet? | 15:45.12 |
| marcosw_ | Robin_Watts: miles and I are taking turns driving, one will drive the morning section and the other the afternoon, then the next day we'll switch off. Miles drove today. | 15:46.01 |
| | don't know the GPS URL yet, they are checking the GPS at the beginning and end of every speed section, but I suspect they won't upload the data until that evening, so it's won't be anywhere near real time. | 15:49.48 |
| Robin_Watts | marcosw_: I thought it was a live thing ? i.e. that the GPS tracker was a cellphone thing? | 15:50.38 |
| marcosw_ | I thought so too, but they keep removing the car to sync it with a computer, so it must not be transmitting a signal. | 15:52.26 |
| kens | Folks, I am correct that with 9.04 all our commercial clients get a royalty-free licence for the Luratech decoder am I not ? | 15:54.42 |
| ray_laptop | I've got the serialnumber working for Windows, but the docs I had found for 'sysinfo' were bogus :-( Off looking for some way to get something on linux/unix | 15:54.51 |
| | kens: you are correct | 15:54.59 |
| kens | Just replyign to Raed, want to make sure my factoids are correct. | 15:55.00 |
| ray_laptop | in fact, it's shipped as part of the commercial 9.04 release and built-in by default | 15:55.34 |
| kens | Yeah, I'm just trying to find a form of words that will allay his fears, without suggesting that they can use it in earlier relesaes. | 15:56.02 |
| | Mainly because I'd like them to move to 9.04 :-) | 15:56.13 |
| ray_laptop | kens: they _can_ use it in earlier releases, but there _have_ been JPXDecode bug fixes related to luratech w/ gs prior to 9.04 | 15:56.59 |
| kens | Yes, and I'd rather not try to explain that, or have to help them integrate it with an earlier release :-) | 15:57.55 |
| | I'll see if he asks about it. | 15:58.07 |
| ray_laptop | kens: we did test it with earlier releases and have quite a few customers using it (cust 531 for at least 3 years) | 15:58.57 |
| kens | I know, but he's on 9.02 already, so its not a bvig step | 15:59.33 |
| | Why does the support list always get busy when Marcos is on vacation ? | 15:59.46 |
| kens | realises that lest regression test was bogus, tested the wrong coe :-( | 16:04.40 |
| | mvrhel2 is here, time for me to bail out. | 16:06.11 |
| mvrhel2 | good night kens | 16:06.23 |
| kens | henrys, support is yours now, I hope its quieter for you :-) | 16:06.28 |
| | Night all. | 16:06.31 |
| mvrhel2 | tor8: are you fine with me just fixing these xps bugs (i.e. without your reviewing the fix). I am trying to keep with the style that you have in there and I think most of the changes are/will be relatively small. | 16:15.55 |
| | I already did two without asking.... | 16:16.08 |
| henrys | yikes I slept in... | 16:20.51 |
| mvrhel2 | :) | 16:21.01 |
| Robin_Watts | henrys: It's OK, the boss is late today. | 16:23.04 |
| henrys | mvrhel2:nice fixing the xps bugs. | 16:27.42 |
| mvrhel2 | I should be able to get these in relatively short order. But I now have a P1 customer segv to figure out. | 16:29.22 |
| | looks like a pattern transparency memory issue. fun | 16:31.04 |
| | hmm.. I am not getting a segv but it does error out | 16:31.38 |
| henrys | sure maybe ray_laptop can help with that one too. | 16:31.46 |
| | a bisect might be useful. | 16:32.33 |
| ray_laptop | mvrhel2: did you try a debug build with -Z@$? ??? | 16:33.12 |
| mvrhel2 | well I am actually getting an error not a segv | 16:33.28 |
| henrys | if you want me to give bisect a go I will since I'm on support duty, let me know. | 16:33.33 |
| mvrhel2 | just getting started with this one | 16:33.35 |
| ray_laptop | mvrhel2: let me know if you want me to see if I can duplicate it (or try it on 64-bit) | 16:34.18 |
| mvrhel2 | ok. let me take an initial look at it | 16:34.34 |
| | ray_laptop: so I end up with 229632 non encodable pixels | 16:35.29 |
| | on line 1706 in gdevtsep.c | 16:35.45 |
| | never saw that one before | 16:36.09 |
| | I am running the same command line as the bug, but without the antialiasing options | 16:36.34 |
| | bug 692618 | 16:36.51 |
| | This thing has 9 spot colors | 16:37.48 |
| ray_laptop | mvrhel2: well, that can happen if there are lots of separations and lots of combinations. The question is "what _colors_ are not encodable" (not necessarily the number of pixels) | 16:37.59 |
| mvrhel2 | yes | 16:38.07 |
| ray_laptop | AA makes it worse since the edges of objects create 'blended' colors with whatever is underneath | 16:39.01 |
| mvrhel2 | there are going to be a lot of combinations in this file. there are gradiants with spots | 16:39.29 |
| | overlapping with process colorants | 16:39.36 |
| ray_laptop | mvrhel2: does it work without the **AlphaBits=4 ??? because it's hard to imagine that he really needs AA at 300 dpi | 16:41.00 |
| mvrhel2 | no | 16:41.04 |
| | I have antialiasing off | 16:41.12 |
| | the problem is the gradiants | 16:41.37 |
| | make a lot of combinations | 16:41.48 |
| | at least that is my suspicion | 16:42.10 |
| henrys | ray_laptop:I was thinking (you probably considered this) was to have him send -Z# output for the new build (broken) and old working build then we can compare them for 692600. I could do that if you want to assign it to me. | 16:43.04 |
| mvrhel2 | what is interesting is that without -dMaxBitmap=500000000 it runs fine | 16:46.44 |
| ray_laptop | henrys: i haven't been paying much attention to him, but I'll suggest running with -dSETPDDEBUG -- this dumps the stack when the 'trying' step fails showing the parameter it barfed on. Also I asked for -dOSTACKPRINT -dESTACKPRINT | 16:47.00 |
| mvrhel2 | however, the rendering is bad | 16:47.39 |
| ray_laptop | mvrhel2: is that -dMaxBitmap big enough to cause it to use page mode ? | 16:47.43 |
| mvrhel2 | so it does not error out but clearly has color encodings that failed | 16:48.03 |
| | in that gradiant. Which is probably a transparency actually | 16:48.28 |
| | hold on let me do -dNOTRANSPARENCY and also check about the page mode clist mode | 16:49.04 |
| ray_laptop | mvrhel2: or run gswin32c -- toolbin/pdf_info.ps _____.pdf | 16:49.44 |
| | mvrhel2: -Z: will tell you if it is using clist | 16:50.02 |
| mvrhel2 | hehe. all the product information is gone if I do no trans | 16:50.16 |
| | yes let me do -Z: now | 16:50.23 |
| | that was next | 16:50.26 |
| | yes so -dMaxBitmap=500000000 make it do page mode, which catches the failed encodings. when in clist mode, we dont get them, we just get white regions that failed to encode | 16:52.24 |
| | i.e. we dont get the error, but still have failed encodings | 16:52.45 |
| | so... | 16:53.04 |
| | we really can't do compressed color encoding (at least the way we do it) with this file as we reach our limit | 16:54.45 |
| | I wonder if we really should allow a solution that simply packs in N colors uncompressed for cases like this. | 16:55.50 |
| | which will never fail | 16:55.59 |
| | we could do some sort of dumb compression | 16:56.09 |
| | but you get my point | 16:56.19 |
| ray_laptop | mvrhel2: with -Z? I see .\psi\ilocate.c(535): Object 0x2112518 not in any chunk! | 16:56.35 |
| | .\psi\ilocate.c(541): Reference to free object 0xc6a02a8(13), in chunk 0x6854950! | 16:56.37 |
| mvrhel2 | are you doing anti-aliasing? | 16:56.50 |
| | ray_laptop | 16:56.55 |
| ray_laptop | mvrhel2: that's after the rangecheck in showpage and the Unrecoverable error | 16:57.36 |
| | mvrhel2: no | 16:57.39 |
| mvrhel2 | ah ok | 16:57.53 |
| henrys | alexcher:are you around? | 16:57.58 |
| ray_laptop | mvrhel2: with AA I get almost the same errors -- just 313184 non encodable pixels | 16:59.17 |
| mvrhel2 | ok | 16:59.22 |
| | makes sense | 16:59.30 |
| ray_laptop | mvrhel2: so the 'ilocate' problems relate to the crash | 16:59.44 |
| | (probably) | 16:59.50 |
| mvrhel2 | I am not seeing those | 16:59.52 |
| ray_laptop | mvrhel2: are you running a debug build with -Z@$? | 17:00.12 |
| mvrhel2 | ah. you had -Z? | 17:00.20 |
| | above | 17:00.22 |
| | let me add the @$ | 17:00.34 |
| ray_laptop | mvrhel2: well -Z? is the thing that does the ialloc_validate stuff | 17:00.57 |
| mvrhel2 | well that gave me nothing | 17:01.20 |
| | I still get nothing | 17:01.36 |
| | other than the error and the stack dump | 17:01.46 |
| | maybe I should pass this one to you.... | 17:02.18 |
| ray_laptop | mvrhel2: I get the ilocate errors even with -Z? (as I expected) | 17:02.22 |
| | mvrhel2: that's fine with me. | 17:02.32 |
| mvrhel2 | ok | 17:02.35 |
| | and the handoff is done. ray_laptop, let me know if you want me to help with it | 17:04.59 |
| ray_laptop | mvrhel2: I'm plenty familiar with the method to track ilocate errors -- they usually aren't too bad. I'll look into the compressed encoding problems as well | 17:05.02 |
| mvrhel2 | I wonder why I don't get the ilocate errors | 17:05.31 |
| | that bothers me | 17:05.44 |
| | oh. something is screwy | 17:08.34 |
| | I do hit the breakpoint at line 535 in ilocate.c | 17:08.49 |
| | oh there is it | 17:09.00 |
| | it is | 17:09.04 |
| | my breakpoint at the end was too early and I was missing the ilocate error | 17:09.20 |
| | or at least the print of it | 17:09.33 |
| ray_laptop | mvrhel2: OK. At least it isn't my build that's funny. | 17:10.02 |
| mvrhel2 | do you want me to help with this thing at all or just let you go with it? | 17:10.30 |
| ray_laptop | mvrhel2: I'll let you know if I need help or just want to chat about it. | 17:10.54 |
| mvrhel2 | ok sounds good | 17:11.01 |
| henrys | mvrhel2:if you think the xps bugs are going to fall quickly I'll hold off on reporting to the customer the progress so far. | 17:13.14 |
| Robin_Watts | Windows Users: I've been having to reinstall stuff since I moved to windows 7; rockscroll is now superseded by Metalscroll. I can't tell the difference personally, but supposedly, it's 'improved'. | 17:13.45 |
| mvrhel2 | henrys: I hope so. | 17:13.47 |
| Robin_Watts | Also, GitExtensions for VS is worthwhile. | 17:14.02 |
| | Lets you do git stuff direct from visual studio. | 17:14.13 |
| ray_laptop | mvrhel2: I wonder if we can recognize "PANTONE Process" C and Y and just treat those as normal C and Y (and if it will help avoid non-encodable pixels) | 17:14.20 |
| Robin_Watts | (in particular blame/merges etc) | 17:14.23 |
| henrys | mvrhel2:wonder why the bugs don't show up in mupdf | 17:14.29 |
| Robin_Watts | (and diffs) | 17:14.37 |
| ray_laptop | fires up the debugger to look at that file some | 17:14.41 |
| | henrys: you mean muxps ? | 17:15.05 |
| henrys | well yes | 17:15.22 |
| mvrhel2 | I have not looked at muxps yet | 17:15.26 |
| henrys | muxps | 17:15.27 |
| mvrhel2 | does it use the same parser? | 17:15.33 |
| | if it does, then they will be in there | 17:15.43 |
| henrys | that's what I thought, a question for tor8? | 17:15.50 |
| ray_laptop | probably because the second time, tor did the parser from scratch ;-) why re-use code | 17:15.58 |
| mvrhel2 | :) | 17:16.07 |
| | I guess I need to check the project out.... | 17:16.18 |
| henrys | well tor8 said these problems all work in muxps so that ought to shortcut the problem solving process somewhat. | 17:16.41 |
| ray_laptop | mvrhel2: if you have a mupdf git then you already have it | 17:16.43 |
| tor8 | mvrhel2: no, I saw your fixes and they're good. if I see anything I hate I'll shout at you don't worry ;) | 17:16.52 |
| mvrhel2 | tor8: ok sounds good | 17:17.02 |
| ray_laptop | mvrhel2: in mupdf there is an 'xps' directory | 17:17.40 |
| tor8 | henrys, mvrhel2: muxps is a fork of the ghostxps parser. I'll need to backport some of mvrhel's fixes to it. | 17:19.04 |
| henrys | I thought you said these problem files worked in muxps. | 17:19.35 |
| ray_laptop | tor8: I see lots of sscanf in mupdf/xps/*.c I wonder why you don't trip over the whitespace | 17:19.48 |
| tor8 | henrys: that was the color and image problems | 17:19.50 |
| henrys | okay | 17:20.06 |
| mvrhel2 | tor8: ok, so I will just concentrate on gxps and let you do the port | 17:20.44 |
| tor8 | ray_laptop: the spec is actually pretty specific about where whitespace is allowed or not. but I guess we're starting to see the same thing as with PDF -- people throwing random stuff in a file and calling it a day | 17:20.53 |
| henrys | tor8:ios is definitely the priority so don't worry about any of this now. | 17:20.55 |
| tor8 | mvrhel2: yeah. I can dig through the git history to see what you changed and backport it after the iOS stuff has settled down. | 17:21.27 |
| ray_laptop | tor8: Ii wouldn't be surprised. I wonder if we should spew out '*** Warning ..." messages with XPS like we do with PDF ? | 17:22.14 |
| mvrhel2 | well windoze xps viewer handles the file just fine without warnings | 17:23.01 |
| ray_laptop | is there an XPS validator tool ? if not, we could do one | 17:23.07 |
| tor8 | mvrhel2: well, the scanfs were me being lazy. tokenizing and calling atof is definitely a better approach. | 17:24.05 |
| mvrhel2 | I think the guys at quality logic have one but I dont believe we need to send them any more money | 17:24.09 |
| ray_laptop | mvrhel2: right, that kind of thing is what we run into with PDF's as well. People say "well, Adobe Reader didn't give any warnings" with LOTS of broken PDF's | 17:24.18 |
| | mvrhel2: I agree with the comment about QL | 17:25.02 |
| mvrhel2 | actually according to the spec the white spaces are OK to have | 17:25.31 |
| | section 2.3.4 in the 1.0 spec | 17:26.13 |
| | XPS Documents allow flexible whitespace usage in markup | 17:26.27 |
| tor8 | mvrhel2: maybe I'm confusing it with the optional commas and/or whitespace allowed in the path data | 17:26.51 |
| mvrhel2 | where you can have one white space you can have many and you can have white space before and after a comma | 17:27.11 |
| | this is certainly not the best written spec by any means | 17:27.38 |
| | there are plenty of contradictions, especially in color | 17:28.10 |
| | anyway, I will push on | 17:28.27 |
| | hmm so I did a check out of mupdf. built the visual studio solution and all the projects failed | 17:30.30 |
| | Robin_Watts: does this work for you? | 17:30.56 |
| Robin_Watts | mvrhel2: Normally, yes. | 17:31.15 |
| mvrhel2 | looks like I am missing all the third party libs | 17:31.19 |
| Robin_Watts | Right. You need to download the 'thirdparty' zipfile. | 17:31.33 |
| mvrhel2 | gotcha. | 17:32.23 |
| Robin_Watts | See win32/README.txt :) | 17:33.07 |
| mvrhel2 | yes | 17:33.12 |
| Robin_Watts | I don't think I wrote that. I'd have been much more verbose :) | 17:33.48 |
| chrisl | henrys: I never got a link for a commercial MuPDF download, so the downloads page doesn't have it. | 17:36.27 |
| henrys | okay where shall I tell customers to get the release tor8? | 17:37.58 |
| | can we fix that? crazy me thinking it should work ;-) | 17:38.31 |
| mvrhel2 | ok. now it builds | 17:39.50 |
| | tor8: if you want me to port my fixes into muxps that will be easy enough for me now | 17:40.07 |
| chrisl | henrys: we probably need a second customer downloads directory with different password. | 17:40.18 |
| mvrhel2 | Now I can also compare the two to catch diffs | 17:41.16 |
| henrys | I'm fine with the same password we usually catch folks using more than one product. | 17:41.51 |
| | can you fix it? Or should I respond to the customer with a new link. | 17:42.19 |
| chrisl | henrys: I don't have a MuPDF commercial release to put in there, once I have that, I can get that, I can fix the web page | 17:43.46 |
| tor8 | henrys: I put tarballs and binaries on the google code page for mupdf | 17:44.16 |
| | if we want to host those with the other customer files that's fine by me | 17:44.28 |
| chrisl | tor8: what's different between the GPL and commercial releases? | 17:44.51 |
| tor8 | do you change the LICENSE or COPYING files for customer releases? | 17:44.52 |
| | chrisl: for mupdf, no diffs. we don't use the luratech codecs in mupdf. | 17:45.12 |
| chrisl | tor8: but the license etc should be different, shouldn't it? | 17:45.33 |
| tor8 | chrisl: I suppose. I don't know anything about it. | 17:46.03 |
| henrys | you should be able to just stick the gs license and change a few words right? | 17:46.35 |
| | is "gpl noise" scattered throughout the code? | 17:46.57 |
| tor8 | henrys: no, I've put up heavy resistance against "gpl noise" copyright blobs in every file | 17:48.45 |
| | only the COPYING and README files need to be changed | 17:49.12 |
| chrisl | henrys: I don't have time to sort out the web page right now anyway (I need to finish real soon). If you and tor8 can agree what needs to in the MuPDF commercial archive, I'll do it tomorrow. | 17:49.39 |
| tor8 | there is still a COPYING file in every source directory though | 17:49.53 |
| henrys | chrisl:okay | 17:50.12 |
| tor8 | strip the copying and rewrite the README (should be done for the gpl release too, it's not very good) | 17:51.02 |
| | and add in whatever you need for the commercial license | 17:51.13 |
| henrys | tor8:can you send an email to chrisl with exactly all files that need to change so he can start on it when he return - you COPYING also right? | 17:51.53 |
| | s/you COPYING/you said COPYING | 17:52.25 |
| tor8 | */COPYING and README .. hmm, I'm getting a sense of deja vu now. haven't we discussed this before? | 17:52.25 |
| | anyway, the COPYING files and README are the only things that mention GPL | 17:52.50 |
| henrys | no I don't remember discussing this. I do remember looking at the commercial web site for mupdf and thinking "ah that's really cool we got that done" ;-) | 17:55.59 |
| | but it was a trick ... | 17:56.18 |
| ray_laptop | henrys: Miles had asked me and I had done a commercial mupdf release. | 17:56.35 |
| | I 'sanitized' it | 17:56.50 |
| henrys | ah so you asked tor8 what to change hence his dejavu | 17:57.13 |
| ray_laptop | I also asked Miles how a 'commercial' mupdf was supposed to differ from a GPL release and he had no opinion -- so I just winged it. | 17:58.10 |
| | henrys: I just forwarded the message to 'tech' that I had sent to Miles back on 9/5. Sorry that I forgot to cc everyone back then | 18:00.51 |
| | henrys: in it I describe what I did | 18:01.11 |
| henrys | okay so that should be enough for chrisl to fix it. | 18:02.02 |
| ray_laptop | henrys: oh, for a 0.9 version ? | 18:02.32 |
| chrisl | henrys: It looks like Ray's e-mail has everything I need (thanks ray_laptop) for the mupdf release, so I'll sort out the web page first thing tomorrow (I'll probably not be back until late tonight). | 18:10.42 |
| | right, gotta go - night all...... | 18:11.47 |
| henrys | wonders if there are any other commercial one off releases that the rest of engineering doesn't know about. I'll let him finish his race before I start the obligatory ranting. | 18:13.51 |
| mvrhel2 | bbiaw. | 18:38.32 |
| henrys | yuck more support | 18:40.34 |
| Robin_Watts | Damn. I need to speak to mvrhel2... | 19:41.22 |
| Robin_Watts | does the mvrhel2 summoning dance... | 19:43.19 |
| | mvrhel2: Hi. Found it, I think. | 23:12.38 |
| mvrhel2 | hi Robin_Watts: thats good | 23:12.51 |
| | sorry I was not able to help | 23:12.59 |
| Robin_Watts | no worries. | 23:13.47 |
| | I was going to ask how masks were accounted for in tile_by_steps. | 23:14.07 |
| | But I found the clip device. | 23:14.17 |
| | Then I found the place where the code wasn't calling the clip device :) | 23:14.30 |
| mvrhel2 | good deal | 23:16.41 |
| | hmm. I wonder if our dash cap rendering in the graphics library needs a bit more functionality to handle the way xps has end and start caps that can be different than the caps that are internal to the dashing. this is a function beyond dashing in PS | 23:32.33 |
| | hmm there seem to be calls into the graphics lib to set them all though | 23:34.11 |
| | oh I think I see the issue | 23:35.20 |
| | looks like a goof up in the graphics lib | 23:55.50 |
| | Forward 1 day (to 2011/10/21)>>> | |
IRC Logs