| | <<<Back 1 day (to 2013/09/25) | 2013/09/26 |
| JS__ | anyone online? | 09:30.53 |
| kens | Yes | 09:31.33 |
| JS__ | converting doc or docx file to pdf is possible with ghostscript? | 09:32.26 |
| | is that a two step process? convert to ps and then from ps2pdf? | 09:32.44 |
| kens | No. Ghostscript is a PostScript and PDF interpreter | 09:32.47 |
| | Yes, you can print to PostScirpt then convert teh PostScript to PDF, ps2pdf is just a script, you can use GS directly | 09:33.11 |
| JS__ | ok. so any ps will be converted to pdf? i mean if i convert doc, xls to ps then it will be converted? | 09:34.02 |
| kens | It doesn't matter where the PostScript comes from. | 09:34.27 |
| JS__ | ok. will it convert embedded objects? | 09:34.46 |
| | like images or ole objects.. | 09:35.04 |
| kens | You cannot have 'embedded objects' in PostsCRIPT | 09:35.11 |
| JS__ | so images will be not displayed if they are in the doc? | 09:35.49 |
| kens | PostScript is a programming language intended for printing, so it depends what your application considers to be 'printavble' | 09:36.08 |
| | When it generates the PostScript description | 09:36.21 |
| JS__ | ok | 09:38.33 |
| Robin_Watts | chrisl: you about? | 11:23.08 |
| chrisl | Robin_Watts: I'm here | 11:23.53 |
| Robin_Watts | private tab. | 11:24.11 |
| kens | Robin_Watts : ping | 15:28.50 |
| Robin_Watts | pong. | 15:29.10 |
| kens | can you spare me a couple of minutes to do some Gitness ? | 15:29.24 |
| Robin_Watts | Gladly. | 15:29.32 |
| kens | I need to get some stuff off a branch and squash it, last time I messed it up | 15:29.42 |
| | I've checdked out and updated master, and rebvased my branch to that. | 15:29.56 |
| Robin_Watts | kens: OK. Want to paste me a git logg so I can see ? | 15:30.20 |
| kens | SO its the business of pulling over to master nad squashing the commits into one I need to do | 15:30.22 |
| | OK one second | 15:30.27 |
| | * 3e2f61f (cluster/ken) WIP on high_level_forms: 5b52cbb update makefile with | 15:30.54 |
| | |\ | 15:30.54 |
| | | * 866514c index on high_level_forms: 5b52cbb update makefile with dependencies | 15:30.54 |
| | |/ | 15:30.54 |
| | * 5b52cbb (HEAD, high_level_forms) update makefile with dependencies for zform.c | 15:30.54 |
| | * 6eebc18 pdfwrite - add UNROLLFORMS option to prevent form preservation | 15:30.55 |
| | * 05c3f56 ps2write - allow high level forms with ps2write | 15:30.55 |
| | * 9d5ab9a pdfwrite - sort out clipping for capture of high level forms | 15:30.56 |
| | * 83bcac3 pdfwrite - add a new variable to track when we are in a high level for | 15:30.56 |
| | * 6015396 PDF interpreter - add some comments about high level forms | 15:30.57 |
| | * 494854d PDF interpeter and pdfwrite - unwrap CTM from forms | 15:30.57 |
| | * f595bac pdfwrite - don't apply clipping if in a form | 15:30.58 |
| | * 9c32688 PDF interpreter - run PDF forms without high level support | 15:30.58 |
| | * 54f42ac correct a few errors caused by switching branches inappropriately | 15:30.59 |
| | and that got me a nastygram from freenode ;-) | 15:31.18 |
| Robin_Watts | And wasn't enough. I need to see master in there too. | 15:31.29 |
| | pastebin ? | 15:31.32 |
| kens | OK | 15:31.36 |
| | freenode throttled my paste... | 15:31.47 |
| | http://pastebin.com/5cA2EqxE | 15:32.13 |
| Robin_Watts | ok, so... | 15:33.32 |
| | git checkout master | 15:33.36 |
| | git stash | 15:33.42 |
| | That makes sure you haven't got any stray changes lying around that the next step will destroy. | 15:33.58 |
| kens | oh oops, I forgot to commit a change, one second | 15:34.02 |
| Robin_Watts | ok. | 15:34.10 |
| kens | OK checkout master and stashed (No local changes ot save) | 15:34.53 |
| Robin_Watts | git reset --hard high_level_forms | 15:35.27 |
| kens | OK | 15:35.46 |
| Robin_Watts | That says "make the current branch point to the same thing that high_level_forms points to" | 15:35.47 |
| kens | yep | 15:35.50 |
| Robin_Watts | so you should end up with master having all your commits on. | 15:35.59 |
| kens | Yes, looks like it, want to see the logg ? | 15:36.25 |
| Robin_Watts | no, that's fine. | 15:36.39 |
| | Now do: | 15:36.41 |
| | oh, do you have EDITOR set to something sane ? | 15:36.56 |
| kens | Its VIM but I'll struggle with it | 15:37.04 |
| Robin_Watts | ok. | 15:37.07 |
| kens | I cna do enough | 15:37.09 |
| Robin_Watts | git rebase -i HEAD~20 | 15:37.14 |
| | That should produce you a vim with the last 20 commits listed. | 15:37.29 |
| | with the newest at the bottom. | 15:37.34 |
| kens | Its thinking.... | 15:37.42 |
| | OK got it, hideous colour scheme | 15:37.51 |
| | All seems to be there | 15:38.10 |
| Robin_Watts | OK, so are you wanting to squash all your commits into 1? or to squash selected ones into other ones ? | 15:38.14 |
| kens | all my commits into 1 | 15:38.26 |
| | I don't think I need the complex history.... | 15:38.37 |
| Robin_Watts | OK, so your first commit was b7ac99d | 15:38.49 |
| kens | correct | 15:38.55 |
| Robin_Watts | change all the lines *AFTER* that (i.e. not including that) to have 's' at the start instead of 'pick' | 15:39.06 |
| kens | OK done, I think that's where I went wrong before | 15:40.11 |
| | So I can save and exit I think ? | 15:40.42 |
| Robin_Watts | yeah. | 15:41.11 |
| kens | ok says rebasing | 15:41.30 |
| | And now I'm back in VIM with the commit messages | 15:42.17 |
| Robin_Watts | ok, edit the commit messages into a single one. | 15:42.32 |
| paulgardiner | Instead of from git rebase -i HEAD~20 onwards, I think you could have done: git reset b7ac99d; git commit -a --amend | 15:43.01 |
| Robin_Watts | paulgardiner: Yes, there is more than one way to do it. | 15:43.54 |
| | but git rebase -i is worth knowing how to use, as it lets you rewrite history very flexibly. | 15:44.21 |
| | and Ken would have had to construct the commit message from scratch that way. | 15:44.51 |
| kens | I have to anyway, none of the interim ones are useful ;-) | 15:45.18 |
| paulgardiner | That would have rolled it all into the first commit. | 15:45.35 |
| kens | And this is theway I have done it before, I don;t know what I did wrong last time :-( | 15:45.36 |
| paulgardiner | On the other hand, that was my guess at the command-line version of what I do in gitk, and actually it might not be quite right, in that form: it might pick up changes but not new files | 15:46.31 |
| Robin_Watts | kens: I'd guess that you did one too many 's' and squashed everything too far. I've done that before. | 15:46.44 |
| kens | I think maybe I squashed to the end instead of the beginning or something. THe code all worked out,the commit messages were barking | 15:47.16 |
| paulgardiner | Ah, I should have said git reset --soft b7ac99d; git commit -a --amend | 15:48.33 |
| kens | OK so saved the commit message and exited | 15:48.40 |
| | well it says its done :-) | 15:48.53 |
| Robin_Watts | kens: cool. | 15:49.01 |
| kens | git logg looks OK | 15:49.06 |
| | SO now I'll push it and break everything. Fortunately I;'m not going out for another hour | 15:49.30 |
| | BTW for Star Wars fanshttp://www.theregister.co.uk/2013/09/26/boffins_have_constructed_a_new_light_sabre_their_skills_are_complete/ | 15:50.52 |
| paulgardiner | kens: git diff high_level_forms master will tell you if your one commit is indeed equivalent to the original set | 15:50.56 |
| kens | http://www.theregister.co.uk/2013/09/26/boffins_have_constructed_a_new_light_sabre_their_skills_are_complete/ | 15:50.57 |
| henrys | Robin_Watts: all I need for memento is XCFLAGS="-DMEMENTO", yes? | 15:50.58 |
| Robin_Watts | henrys: To use with pcl? | 15:51.10 |
| kens | paulgardiner : Hmm lets see | 15:51.12 |
| | paulgardiner : said nothing, I guess that's good :-) | 15:51.39 |
| Robin_Watts | henrys: make pcl-memento | 15:51.45 |
| paulgardiner | kens: excellent | 15:51.48 |
| henrys | and gs? | 15:51.53 |
| Robin_Watts | make memento | 15:51.59 |
| kens | I won't believe it until I see the cluster run, this has been one headache after another | 15:52.06 |
| ray_laptop | kens: BTW, in vim you can get rid of colors with :set syntax=off | 15:52.18 |
| kens | ray_laptop : I don't use VIM enough to warrant learning any new commands :-) | 15:52.37 |
| Robin_Watts | henrys: That way the binaries are in membin, rather than bin or debugbin etc. | 15:52.50 |
| | (or memobj rather than obj or debugobj) | 15:53.02 |
| henrys | got it thanks | 15:53.13 |
| ray_laptop | Sometimes the colors chosen for syntax highlighting make things really hard to read, so I turn it off. For C and PS the colors seem sane enough that I haven't bothered tweaking | 15:53.18 |
| kens | Its a Git one, so pick is in yellow and 's' comes out in green, the commit messages are in bright cyan which is hard to read.... | 15:54.08 |
| Robin_Watts | ray_laptop: Unofficially, I've heard from Len that my stuff has got them around a second. | 15:54.09 |
| ray_laptop | kens: for when you use vim for git, you can put that in your ~/.vimrc | 15:54.20 |
| kens | Robin_Watts : so that's 20% of your 20% :-) | 15:54.25 |
| Robin_Watts | so the hopes of the rebellion lie with you, I think :) | 15:54.27 |
| ray_laptop | Robin_Watts: I have hopes, but I am going to remind them again in email about that mysterious 5.7 seconds on the first page that should be more like 1.2 to 1.5 seconds | 15:55.36 |
| Robin_Watts | ray_laptop: It's not that mysterious. | 15:55.57 |
| | They said that that time included the time taken to transfer the file into memory. | 15:56.16 |
| | The main problem there is that under their profiling it was being blamed on us. | 15:57.03 |
| | Of course, if they can reduce it that'd be great :) | 15:57.21 |
| kens | Yay! 9 year old bug report closed...... | 16:01.43 |
| ray_laptop | Robin_Watts: but it's only a 1.4Mb PDF. That seems inordinately slow to transfer to memory. Even over a wireless network. | 16:03.51 |
| Robin_Watts | ray_laptop: Yes, but we have no idea of the amount of overhead imposed by setting up an airprint session etc. | 16:04.34 |
| ray_laptop | Robin_Watts: still, if there is a bottleneck there, they should be looking at it! That's a big percentage of time, and that'll hit EVERY job | 16:05.26 |
| mvrhel_laptop | good mornig | 16:08.43 |
| kens | morning mvrhel_laptop | 16:08.52 |
| ray_laptop | Robin_Watts: something screwy. The file has a PDF 1.3 header, but uses transparency on page 2 | 16:11.14 |
| Robin_Watts | morning mvrhel_laptop | 16:11.15 |
| kens | ray_laptop : it wouldn't be the first time we've seen that | 16:11.31 |
| Robin_Watts | ray_laptop: Ah! Can we make gs ignore transparency if it's a 1.3 file? That'd get the speed up. | 16:11.45 |
| | :) | 16:11.47 |
| ray_laptop | kens: Producer (Mac OS X 10.8.4 Quartz PDFContext) Author (Apple Inc.) | 16:12.54 |
| kens | modified ? | 16:13.03 |
| ray_laptop | Robin_Watts: well, you can do a page comparison with and without -dNOTRANSPARENCY | 16:13.37 |
| | Robin_Watts: it'd be easy to implement that :-) | 16:14.08 |
| | Robin_Watts: on this file the difference is minimal | 16:16.23 |
| Robin_Watts | As far as I can tell -dNOTRANSPARENCY doesn't make a difference. | 16:16.36 |
| kens | dthe file really does use transparency ? | 16:17.12 |
| Robin_Watts | kens: An image has a softmask. | 16:17.22 |
| | but the image is on a white background anyway... | 16:17.35 |
| ray_laptop | kens: yes, there's a DeviceGray image on page 2 with an SMask | 16:17.36 |
| kens | Well then it really does, even if its a 100% trnsparent mask :-) | 16:17.38 |
| ray_laptop | oops. no, it's another ICCBased DeviceRGB picture, not monochrome | 16:18.30 |
| kens | customers do tend to complain if we do things like insisting that the PDF version matches the actual features used by the PDF file though | 16:18.32 |
| ray_laptop | kens: well, I can't really see that the SMask is doing much. Lots of pixels differ, but the gray shades differ by less than 15/255 | 16:21.23 |
| | I can't even tell the difference on the screen easily | 16:21.43 |
| kens | yeah, we've seen 'nonsensical' use fo transparency before too | 16:21.47 |
| | THough amditteldy usually from Cairo :-) | 16:22.15 |
| ray_laptop | kens: yes, Cairo is particularly offensive | 16:22.32 |
| | Robin_Watts: I've sent the email off to Len, pinging him to have someone look at that extra 4 seconds or so on page 1 | 16:23.28 |
| Robin_Watts | ray_laptop: I saw. | 16:24.08 |
| ray_laptop | and now back to finding out why my parameter to the DCT filter /ForceGrayOut true isn't making it into the parameters. | 16:24.09 |
| Robin_Watts | It does bug me that we keep asking them for things, and they never actually deliver them. | 16:24.27 |
| ray_laptop | once that works, I'm ready to test | 16:24.32 |
| | I'm doing it on HEAD so I can submit a cluster run :-) | 16:25.04 |
| | it'll be easy enough to port to their code | 16:25.26 |
| Robin_Watts | ray_laptop: It's not safe to do it in general on HEAD though, is it? | 16:25.43 |
| | Cos it'll screw up color management. | 16:25.50 |
| | (I could have a profile set to convert from the RGB I get out of the JPEG decoder that would give me wildly different results than I'd get by getting greyscale out of the JPEG decoder, and then processing that, right ?) | 16:26.49 |
| | Do we need to ping mvrhel_laptop on this? | 16:27.12 |
| ray_laptop | Robin_Watts: well, we could check that the Alternate colorspace is DeviceGray, DeviceCMYK or DeviceRGB. Screwy ICC profiles are discouraged since using the Alternate won't work. | 16:32.35 |
| | Part of the reason for cluster testing is to have a look for such (screwy) cases so we can skip the optimization for them | 16:33.57 |
| Robin_Watts | Maybe I'm worrying about nothing here - I'd be the first to admit that color management is not my thing. | 16:34.08 |
| | mvrhel_laptop: In examining the profiles of gs processing this file from the customer, it turns out that we are getting an RGB JPEG that gets eventually fed into a mono device. | 16:35.05 |
| ray_laptop | Recall that the change is only for JPEG files, so they tend to be fairly sane | 16:35.13 |
| Robin_Watts | Currently that means we decode YUV -> RGB, then RGB into the clist, then RGB out of the clist and into the device. | 16:35.39 |
| | Ray has some code that means if we spot that the device is mono, we'd arrange to get greyscale values out of the jpeg decoder. | 16:36.23 |
| | This should save us lots of decode time, time in the clist writing/reading and in the device. | 16:36.50 |
| mvrhel_laptop | I would think just grabbing the Y component would still be just fine | 16:36.54 |
| Robin_Watts | With 'sane' profiles, yes. | 16:37.16 |
| | Am I right in thinking that your stuff lets people supply different profiles for RGB and/or CMYK data than for greyscale data ? | 16:38.03 |
| | If this is fine, then I'm really glad ray has coded this in HEAD. I'd assumed it was a non-starter for color managed stuff. | 16:39.21 |
| mvrhel_laptop | Robin_Watts: If the real source data were not some sort of sane RGB prior to going to YCC then the JPEG encoding would be rather poor and there would be other issues | 16:39.22 |
| | oh you are talking about with head | 16:39.38 |
| | when going out to a gray device? | 16:40.01 |
| Robin_Watts | mvrhel_laptop: Yes. It sounds like a great idea for the customers 8.71 based workflow. | 16:40.02 |
| | Their device is 600dpi mono. | 16:40.24 |
| mvrhel_laptop | I still think forcing transparency blending to be done in gray would also be a win performance wise | 16:41.07 |
| Robin_Watts | The question is whether it's a change we can take on in HEAD. | 16:41.29 |
| | This code will do that (for this file) anyway, I believe. | 16:41.43 |
| mvrhel_laptop | I think it has to be a command line option though | 16:41.57 |
| Robin_Watts | the image will appear to be DeviceGray rather than DeviceRGB, so the blending with the softmask etc will be in gray won't it? | 16:42.19 |
| mvrhel_laptop | Robin_Watts: It depends upon the specified color space for the group | 16:42.26 |
| | not the image contents | 16:42.30 |
| | oh if it is a softmask that is different | 16:42.48 |
| | then all the colors are forced to gray | 16:42.54 |
| | Robin_Watts: so it all depends upon the PDF content. I could push a group with CMYK blending | 16:43.36 |
| | and have a gray image | 16:43.40 |
| Robin_Watts | right. | 16:43.45 |
| mvrhel_laptop | and the blending will be done in CMYK | 16:43.46 |
| Robin_Watts | but *for this file*, we should be OK, yes? | 16:43.58 |
| mvrhel_laptop | I don't have the file so I dont know | 16:44.12 |
| Robin_Watts | No group specified. | 16:44.18 |
| | the Image says /Colorspace [ /ICCBased .... /ALternate /DeviceRGB ] | 16:44.53 |
| | so presumably ray is changing that to be /Colorspace /DeviceGray | 16:45.07 |
| mvrhel_laptop | if there is no group color space specified, then the group will inherit the target device color space | 16:46.25 |
| | which is gray in this case | 16:46.29 |
| | so we are good | 16:46.31 |
| | ok. back to beating away at transparency code for non-isolated knockout. Robin_Watts a quick question for you | 16:48.54 |
| Robin_Watts | uh oh. | 16:49.05 |
| mvrhel_laptop | so does mupdf maintain a separate group alpha and shape plane in addition to the RGB + alpha data during its transparency stack? | 16:49.38 |
| | the blending procs in gs use this stuff to undo a blend and reblend during the non-isolated stuff | 16:50.29 |
| kens | RIght, goodnight all | 16:50.39 |
| mvrhel_laptop | bye kens | 16:50.44 |
| | I guess I can look myself too... | 16:51.13 |
| | I just didn't know if you knew. | 16:51.24 |
| Robin_Watts | mvrhel_laptop: mupdf keeps data for shape and alpha | 16:51.29 |
| mvrhel_laptop | ok | 16:51.35 |
| Robin_Watts | I'm trying to figure out if it's group alpha or not. | 16:53.25 |
| | I get confused when there is more than 1 alpha. | 16:53.41 |
| mvrhel_laptop | yes. me too | 16:53.46 |
| | essentially, what gs does is create a new alpha_g plane when the group is not isolated | 16:54.06 |
| | and then when it does its blending it uses this alpha_g plane to undo a blend and the reblend | 16:54.28 |
| | or something of the sort. I need to dig a bit more | 16:54.41 |
| | does mupdf use the same blending procs as gs? | 16:54.53 |
| Robin_Watts | mvrhel_laptop: No. | 16:55.17 |
| mvrhel_laptop | time for me to look myself. Sorry to bother you Robin_Watts | 16:55.21 |
| | oh ok. for some reason I thought tor said he lifted them | 16:55.40 |
| Robin_Watts | Oh, well, the core blending routines might have come from gs. | 16:56.08 |
| mvrhel_laptop | that is what I mean | 16:56.15 |
| Robin_Watts | but until I had a bad meth trip and got all enthusiastic one week mupdf didn't have a transparency stack. | 16:56.56 |
| | so there were no group alpha planes or shape planes etc. | 16:57.28 |
| mvrhel_laptop | :) | 16:57.45 |
| | and you added these? | 16:57.54 |
| Robin_Watts | I suspect you might do better to look at the code than for me to try to explain what my dodgy memory of my broken implementation of my confused understanding of what the code does. | 16:58.27 |
| | The phrase to keep in mind is probably "WTF?" | 16:58.41 |
| mvrhel_laptop | wow. the blending procs in mupdf look so neat and clean.... | 16:59.11 |
| | ok. I found what I am looking for. | 17:01.42 |
| | so it looks like mupdf just carries around shape and alpha | 17:01.55 |
| | and the shape is used in the non-isolated case | 17:02.09 |
| Robin_Watts | mvrhel_laptop: And you need an additional "group alpha" ? | 17:02.21 |
| mvrhel_laptop | gs has it. But I don't see why it would need it | 17:02.47 |
| Robin_Watts | I am fairly sure that the mupdf blending is not perfect. | 17:02.51 |
| mvrhel_laptop | I am tempted to remove it | 17:02.53 |
| | but I think I will do this in two steps | 17:03.03 |
| | one is to get knockout non-isolated working first | 17:03.16 |
| | and then do a serious clean up | 17:03.24 |
| Robin_Watts | sounds good. | 17:03.30 |
| mvrhel_laptop | if I try to do this in one step I am certain to screw things | 17:03.43 |
| | up | 17:03.47 |
| Robin_Watts | and you'll find that you DID need it, and you won't be able to unpick the two commits. | 17:04.01 |
| | yeah, been there, done that :) | 17:04.07 |
| mvrhel_laptop | exactly | 17:04.25 |
| ray_laptop | mvrhel_laptop: git branch is your friend | 17:10.45 |
| | that or stashing with your own comments to remind you what's in a stash | 17:11.36 |
| | Got It! (a stoopid PS error, adding my parameter to the wrong dict pulled from the stack) | 17:47.08 |
| | gray shades a a bit lighter than going through all of the YCC->RGB->Gray logic. | 17:49.46 |
| | but I think I'll port it over to the customer's code | 17:50.02 |
| Robin_Watts | ray_laptop: Excellent! | 17:51.11 |
| willschm | ray_laptop: you mentioned alignment on PPC with long doubles as a potential trouble spot. Are there any debug flags or specific areas in the code I should be looking closely at? | 17:56.44 |
| ray_laptop | willschm: I don't know if it is a potential trouble or not, but since you mentioned you were having trouble with those, alignment comes to mind. | 17:58.14 |
| | willschm: if you have a debugger, you should get a break on unaligned access (if that is an issue as it is with SPARC) | 17:58.50 |
| willschm | ray_laptop: Ok. The generated obj/arch.h header file seems OK, but overall i'm not entirely familiar with the code. :-) | 17:59.23 |
| ray_laptop | willschm: really chrisl (who will be on vacation until Tuesday) is more knowledgeable on these issues | 17:59.25 |
| | willschm: unfortunately, genarch (and configure) aren't too good sometimes at spotting all required alignment issues. jmp_buf was a recent issue. On some chips the FPU or SSE instructions have data alignment requirements more stringent than the normal CPU instructions | 18:01.11 |
| willschm | ray_laptop: Yeah, I noticed he seemed to be missing today, not a problem. :-) | 18:01.22 |
| ray_laptop | willschm: he was around earlier. He's in the UK and is taking vacation, so he might have left a bit early | 18:02.01 |
| willschm | ok, does gdb have an option for that? (break on unaligned access) | 18:02.32 |
| ray_laptop | Robin_Watts: oops. I forgot that I need to add code to make doing this conditional on the printer being monochrome | 18:02.43 |
| Robin_Watts | ray_laptop: I'm sure no one will notice. Who needs colour JPEGs after all? :) | 18:07.57 |
| ray_laptop | Robin_Watts: yeah, but it'll create even more noise in my cluster test :-) | 18:10.59 |
| mvrhel_laptop | henrys: nexus arrived today | 18:33.04 |
| henrys | mvrhel_laptop: oh good | 18:33.21 |
| ray_laptop | I expect a lot of diffs. | 18:33.35 |
| mvrhel_laptop | new kitten here in the house. we have not had a cat in probably 7 years so this is going to be an adjustment | 18:34.28 |
| ray_laptop | henrys: the ipad is supposed to be delivered today (on truck) | 18:34.29 |
| henrys | mvrhel_laptop: I bet the kids like that. | 18:37.26 |
| | mvrhel_laptop: the chickens not so much. | 18:37.40 |
| mvrhel_laptop | yes. there have been many tears for the past 6 months as I tried to delay the kitten. | 18:37.59 |
| | it will be interesting to see how the cat and the chickens interact | 18:38.17 |
| | my hope is that with the kitten young she will learn not to fool with them | 18:38.29 |
| ray_laptop | bbiab. | 18:43.58 |
| chrisl_r61 | willschm: I don't think you're seeing an endian issue, the trio source *should* be endian agnostic, and works fine on x86..... | 19:03.57 |
| | willschm: The lines along which I was thinking was that the trio source seems to assume that long doubles are 64 bit. If your environment drops them to 32 bits, that could be a problem. | 19:04.09 |
| willschm | chrisl_r61: Ok. Should be no 32-bit here, so thats probably not an issue. | 19:07.02 |
| chrisl_r61 | willschm: Okay, well, I'm at a bit of a loss, then. The code does okay on x86, x86_64, SPARC, little endian arm, and big endian PPC (Mac OS X, and Linux). | 19:09.31 |
| willschm | yeah, I don't doubt it. :-) | 19:09.57 |
| chrisl_r61 | willschm: is your platform easily available? | 19:10.06 |
| willschm | chrisl_r61: nope, still quite early in it's lifetime. ppc64 LE, firmware/etc still in bringup, not available externally yet. | 19:10.59 |
| | I've got gdb running in ppc64 BE , ppc64 LE, x86_64 sessions, so working through the flow to see where they diverge. | 19:11.36 |
| | I have found a lcms2 ppc==BE assumption, which i've hacked up locally. so i'm tentatively expecting to find a couple more similar things, somewhere.. :-) | 19:12.28 |
| chrisl_r61 | willschm: Hmm, I thought we overrode that kind of thing in LCMS. If you stick that in a bug report, it's something we should probably look at fixing. | 19:13.46 |
| | willschm: one of the reasons I settled on using trio was because the code allegedly is endian agnostic, so it didn't required extra configuration stuff in the ghostscript build. | 19:15.59 |
| willschm | chrisl_r61: yeah, i'll do that shortly to get it logged. bugs.ghostscript.com is the right place for that ? ( lcms2 bug ) | 19:16.25 |
| chrisl_r61 | willschm: yeh, we'll either fix it, and pass the patch upstream, or pass the report upstream, depending on what's needed to fix it | 19:17.08 |
| | willschm: Personally, one of the things I'd check is whether the claims made around TRIO_DOUBLE_INDEX() are proving correct on your system | 19:19.11 |
| willschm | chrisl_r61: Ok, I'll check that out shortly. Thanks for your help and insights. :-) | 19:26.11 |
| chrisl_r61 | willschm: np. As Ray mentioned, I'll be on vacation until Tuesday. I'll be happy to swap notes when I return.... | 19:27.47 |
| henrys | Robin_Watts: have you been asking GPL users to change their code to AGPL if they use MuPDF? | 22:01.26 |
| | I don't feel strongly about it but if that is what you've been doing I'll follow suit. | 22:02.01 |
| Robin_Watts | henrys: I haven't been in touch with anyone that's using it under the GPL except maybe malc_. | 22:54.02 |
| | Forward 1 day (to 2013/09/27)>>> | |
IRC Logs