| | <<<Back 1 day (to 2013/10/28) | 2013/10/29 |
| kens | For the logs. Robin_Watts paulgardiner: | 08:10.30 |
| | http://stackoverflow.com/questions/19644508/mupdf-release-build-issue | 08:10.30 |
| Robin_Watts | Day 4, and Miles is getting faster. | 10:00.41 |
| kens | Probably helps when the car works | 10:01.23 |
| tor7 | Robin_Watts: http://www.w3.org/TR/compositing-1/#mix-blend-mode | 10:02.26 |
| Robin_Watts | tor7: The unholy mix of SVG and CSS makes me want to disconnect too :( | 10:03.29 |
| | tor7: http://caniuse.com/#cats=SVG | 10:06.42 |
| | Not sure that any browsers out there actually support it yet. | 10:06.53 |
| sebras-hotel | tor7: morning! | 13:25.59 |
| | tor7: tonight is my last night over here. tomorrow night I'll be in your time zone. | 13:26.22 |
| tor7 | sebras-hotel: godspeed! | 13:26.30 |
| sebras-hotel | a couple of days after that I might be tempted into hacking som mupdf again. :) | 13:26.38 |
| Robin_Watts | sebras-hotel: Have a safe flight! | 13:26.50 |
| tor7 | Robin_Watts: so, about the cmyk inversions... | 13:27.00 |
| | error #1 -- we were clearing the page to full black (CMYK 100% each channel) rather than white | 13:27.19 |
| | error #2 -- additive colorspaces are drawn inverted :( | 13:27.33 |
| sebras-hotel | Robin_Watts: I sincerely hope it will be better than flying in a typhoon... but something tells me that you have been sending your storm towards finland where I'll touch down briefly... | 13:27.33 |
| tor7 | correct thing #1 -- subtractive colorspaces (cmyk and separation/devicen with cmyk as base colorspace) are drawn correctly | 13:27.53 |
| | sebras-hotel: it ought to have passed by the time you land though | 13:28.09 |
| sebras-hotel | tor7: oh? that's nice. the typhoon induced turbulence was probably the worst I have experienced. :-P | 13:29.18 |
| tor7 | sebras-hotel: apparently the planes landed just fine yesterday, but the walkways couldn't be extended so the passengers were stuck on the ground in an airplane wobbling in the wind for hours... | 13:29.47 |
| henrys | oh my your clocks changed and our haven't hope that doesn't foul things up. | 13:29.49 |
| tor7 | though I expect they stopped all incoming flights after the wind picked up | 13:30.24 |
| sebras-hotel | tor7: probably. I wonder where the airlines have their planes land when things like this happen. it ought to be fairly expensive. | 13:31.31 |
| Robin_Watts | henrys: How long to the meeting? | 13:33.55 |
| | I'm guessing 1 hour. | 13:34.24 |
| | i.e 14:30 UK time. | 13:34.35 |
| henrys | 1 hour | 13:34.52 |
| sebras-hotel | this is my last night in Shanghai, but untunately I can not access youtube to listen to an excerpt of Jean-Michel Jarre's "Last night in Shanghai"... :-/ | 13:35.31 |
| Robin_Watts | tor7: So it's all working now? Nice. | 13:36.29 |
| | How does transparency work out? | 13:36.35 |
| tor7 | Robin_Watts: nope :( I've just about got my head around what's going wrong. | 13:36.50 |
| | page 1142 of pdfref 17 is most illustrative | 13:37.06 |
| | Robin_Watts: I suspect our xxx2cmyk functions are broken though | 13:47.22 |
| Robin_Watts | must grab lunc hbefore the meeting | 13:47.52 |
| kens | fetches meeting coffee | 14:20.46 |
| ray_laptop | morning, all | 14:31.26 |
| kens | morning | 14:31.31 |
| ray_laptop | Just made it for the meeting :-) | 14:31.35 |
| henrys | missing michael and chris | 14:32.03 |
| ray_laptop | so the UK switched times this weekend ? | 14:32.07 |
| kens | yes | 14:32.13 |
| henrys | marcosw: are you here? | 14:32.22 |
| kens | All of Europe I htink | 14:32.23 |
| henrys | I wanted to ask chris about this setjmp, why is this coming up now? | 14:34.06 |
| | paulgardiner: back from vacation? | 14:35.11 |
| ray_laptop | I believe we have a quorum | 14:35.25 |
| henrys | I hoped to have marcos and chris⦠oh well. | 14:36.04 |
| paulgardiner | Yep. Got back early hours of Fri | 14:36.05 |
| marcosw_ | I'm here | 14:36.09 |
| kens | chrisl may have forgotten the time change | 14:36.10 |
| tor7 | I'm here (sweden changed same time as the UK) | 14:36.25 |
| ray_laptop | marcosw_ just joined | 14:36.32 |
| paulgardiner | Been banging my head on the huge and hairy libreoffice | 14:36.42 |
| ray_laptop | paulgardiner: is it C++ ? | 14:37.12 |
| paulgardiner | I have to admit I still don't know for certain. :-) | 14:37.42 |
| mvrhel_laptop | :) | 14:37.48 |
| paulgardiner | The intended use is to drive it via UNO, which is like COM | 14:37.59 |
| henrys | paulgardiner: oh lord | 14:38.16 |
| Robin_Watts | paulgardiner: So the bits for dealing with the format are in C++, but the core of libre office might be in java? | 14:39.01 |
| | chrisl is stuck in traffic. | 14:39.08 |
| henrys | paulgardiner or anybody licensing/language wise do we have any other choices? | 14:39.14 |
| paulgardiner | My recent thoughts that we might be able to use it as is via dynamic linking and then perhaps the LGPL doesn't matter | 14:39.20 |
| Robin_Watts | paulgardiner: Is it LGPL? I thought it was MPL ? | 14:39.37 |
| henrys | I thought it dual | 14:39.49 |
| Robin_Watts | or rather I thought it was both LGPL and MPL | 14:39.51 |
| henrys | kens:how far off is your main project? | 14:40.18 |
| paulgardiner | Yes dual, although I'm not sure exactly what that means: presumably you aren't free to choose which | 14:40.45 |
| Robin_Watts | paulgardiner: I thought it was exactly that you were free to choose which. | 14:41.00 |
| kens | henrys at the moment I have 2 files that show problems | 14:41.18 |
| | 09-34.ps and an Altona test file | 14:41.27 |
| henrys | kens:wow so that is pretty close | 14:41.32 |
| kens | All other differences a\re progressions or 'don't care' | 14:41.37 |
| paulgardiner | Oh okay. I'd assumed not because I would imagine that MPL is always preferable to LGPL | 14:41.38 |
| kens | henrys this is with 'LeaveColorUnchanged' | 14:41.53 |
| | I have also teted my own test file with all the possible options and it works fine, but that did not detect the problems that the cluster did. | 14:42.17 |
| Robin_Watts | paulgardiner: Unless you have a project that's already LGPL, perhaps. | 14:42.19 |
| paulgardiner | True | 14:42.36 |
| kens | henrys so I hope to have the basic work done very shortly, but I expect a bug tail. Hence I will leave the old code in place for at l;east one release | 14:43.05 |
| mvrhel_laptop | 09-34.PS has lots of CIE color options | 14:43.07 |
| paulgardiner | Every file I've opened so far has said MPL at the top. But then there are a great many files and I have only scratched the surface | 14:43.22 |
| kens | mvrhel_laptop : yes, and one page shows prob;ems with pdfwrite and 2 with psd2write# | 14:43.29 |
| | All with CIE spaces of one kind or another | 14:43.43 |
| | Clearly I have missed something, but itsd fairly subtle | 14:44.02 |
| henrys | a new way to answer user questions: http://lmgtfy.com/?q=ghostscript+set+page+size | 14:44.13 |
| mvrhel_laptop | thats the file that had the range issue that we were fooling with | 14:44.19 |
| | and different versions of AR rendered differently | 14:44.30 |
| kens | mvrhel_laptop : yes, its different spaces this time :-) | 14:44.38 |
| mvrhel_laptop | of course it is.... | 14:44.45 |
| kens | THe differences I see are not subtle, whole swathes come out white | 14:44.58 |
| mvrhel_laptop | henrys: that is funny | 14:45.07 |
| kens | So it will be obvious when I find it | 14:45.09 |
| | mvrhel_laptop : The difficulty as I'm sure you will appreciate is that I get 42 pages of diffs to look through.... | 14:46.03 |
| mvrhel_laptop | I feel your pain | 14:46.17 |
| henrys | Robin_Watts: so is there some way we can set up a regression run against their old code? | 14:46.24 |
| Robin_Watts | kens: git cluster bmpcmp -t 16 ? | 14:46.25 |
| tor7 | paulgardiner: is there a command line utility to convert to some simpler format? like plain xhtml or so? | 14:46.29 |
| kens | Robin_Watts : I *want* to see the changes | 14:46.36 |
| Robin_Watts | kens: You'll see the differences - just not subtle ones. | 14:46.54 |
| kens | Robin_Watts : I want the aubtle ones too I'm afraid | 14:47.08 |
| Robin_Watts | You might also want --filter=ppmraw.200.0 | 14:47.13 |
| henrys | Robin_Watts: 801's device vs. their previous changes to gxclthrd.c | 14:47.19 |
| kens | Alrteady doing ppmraw | 14:47.22 |
| Robin_Watts | i.e. throw away the halftoned stuff. | 14:47.25 |
| | henrys: Not trivially. | 14:47.31 |
| kens | Yep halftoned was too much trouble | 14:47.33 |
| paulgardiner | tor7: I don't know. Do you think that might give us a cleaner solution? | 14:47.46 |
| Robin_Watts | Their code as supplied spews files all over the place. | 14:47.58 |
| | and it's windows specific. | 14:48.03 |
| henrys | Robin_Watts: oh I got everything working fine on linux | 14:48.21 |
| paulgardiner | I think it's too early to tell how nasty integration with libreoffice might be. I've just registered on their forum to see if I can get a better idea of exactly how it works. | 14:48.41 |
| Robin_Watts | henrys: So when you run the device, where do you get output? | 14:48.43 |
| tor7 | paulgardiner: it might. we have some halfway done xhtml+css code lying around from the (abandoned) epub reader project I was toying with a while back | 14:48.54 |
| henrys | Robin_Watts: ls /custom/print/9999/ | 14:49.33 |
| Robin_Watts | Also, they have screwed up their application of noise; they aren't allowing for the band offsets, so the noise 'repeats' incorrectly. | 14:49.39 |
| | I've fixed that in my version. | 14:49.49 |
| paulgardiner | tor7: but we'd still be relying on the conversion which might be any cleaner than to perform the render via libreoffice. | 14:49.56 |
| henrys | Robin_Watts: after a run I have 1.raw2.rawBlack_1.pgmCyan_1.pgmMagenta_1.pgm Blue_1.pgmYellow_1.pgm | 14:49.59 |
| | oh shit | 14:50.09 |
| ray_laptop | Robin_Watts: maybe they intended to lock the band height at 128 | 14:50.13 |
| Robin_Watts | I *could* fix their device, and make it output to a sane place. | 14:50.21 |
| | and then we could test theirs against mine. | 14:50.27 |
| tor7 | paulgardiner: easiest would be if we could hook libreoffice up to just deliver a pdf from the command line, IMO | 14:50.32 |
| marcosw_ | henrys: I'll edit the logs | 14:50.48 |
| paulgardiner | tor7: oh there's a thought. | 14:50.52 |
| ray_laptop | henrys: do you want someone to edit the IRC log ? | 14:50.52 |
| tor7 | but the performance of that may be worse than a proper integration, if their pdf generation is as bloated as the rest of libreoffice... | 14:51.03 |
| henrys | marcosw_: thanks | 14:51.25 |
| chrisl | henrys: I don't know why we're only just seeing the setjmp issues now: possibly it only applies to VS2010 and later, or possibly people haven't been using 64 bit PCL builds until recently..... I don't do 64 bit PCL or XPS binaries for the releases | 14:51.54 |
| paulgardiner | I guess one thing I'm still not certain of is what type of mupdf customer we are trying to support with this. And hence it's difficult to judge what is a good solution. | 14:51.55 |
| tor7 | paulgardiner: but even just getting it to drop one pdf per page might be helpful in not having to wait for ages while it's opening/converting | 14:51.59 |
| Robin_Watts | ray_laptop: Maybe. | 14:52.00 |
| henrys | chrisl: ah 32 bit is okay? | 14:52.19 |
| chrisl | henrys: yes, 32 bit is fine | 14:52.37 |
| henrys | chrisl: I should get rid of that it was peter's requirement and it is probably no longer necessary | 14:53.29 |
| chrisl | henrys: it does seem OTT to use setjmp for such a fairly simple error return situation..... | 14:54.17 |
| paulgardiner | Is it that we want to support people writing apps for Android, iOS Windows phone, and give them access to display of office documents with no need for programming over and above what they do for PDF/XPS? | 14:54.52 |
| Robin_Watts | paulgardiner: And for printer devices. Yes. | 14:55.31 |
| paulgardiner | Make it seem that MuPDF is a one-stop solution for displaying almost any document. | 14:55.38 |
| | Robin_Watts: printers. That's what worries me. If libreoffice core isn't just C++, and includes some java then it may not be useful to printer manufacturers | 14:56.34 |
| henrys | marcosw_: back in the logs I found a blog about setting up testing with vmware so we could test windows. I really think we need to look at this. | 14:56.51 |
| Robin_Watts | marcosw: Hey, leave it, that way we're safe from my customer tourettes for a bit :) | 15:59.29 |
| ray_laptop | Robin_Watts: sorry, I was looking through their PS code. | 16:03.35 |
| Robin_Watts | ray_laptop: No worries :) | 16:03.48 |
| ray_laptop | Robin_Watts: those procs are all hooked from .RKsetparam, called with a string to then call their device to pass in the param, and I agree that most are better done with device parameters. | 16:08.09 |
| Robin_Watts | ray_laptop: Yes. | 16:08.32 |
| ray_laptop | As far as changing the pgs mat, however, that's dicey | 16:08.51 |
| Robin_Watts | So the only one that actually does anything other than just set an unused value is rk_zoomrate. | 16:08.58 |
| henrys | chrisl: I seem to have a copy of plrm that errors out with **** Warning: Encoding not present. **** Warning: Encoding not presentâ¦. I wonder if I corrupted the file somehow | 16:09.16 |
| ray_laptop | They probably want to do this via a setpagedevice Install proc. That's what it's there for | 16:09.17 |
| Robin_Watts | It looks to me like it's setting a global zoom, presumably at the start of the page. | 16:09.28 |
| | ray_laptop: Could they not do it by hooking initialize_matrix in the device procs? | 16:10.05 |
| | setpagedevice install proc - is that PS/PDF specific? Would that work for PCL ? | 16:10.28 |
| ray_laptop | Robin_Watts: It's better done in the Install, IMHO | 16:10.29 |
| | Robin_Watts: None of this stuff will work for PCL | 16:10.53 |
| Robin_Watts | ray_laptop: Eh? What? What won't work for PCL ? | 16:11.10 |
| ray_laptop | the psi isn't there | 16:11.14 |
| Robin_Watts | ray_laptop: but get_params/put_params still works, right? | 16:11.30 |
| ray_laptop | so there isn't any zrkputparam proc to call the device procs | 16:11.45 |
| | Robin_Watts: yes, device params will still work | 16:12.00 |
| Robin_Watts | If they set these values on the command line, the new device will work. | 16:12.16 |
| | That's a reason why it's better to do it 'properly' than to do it by extending the PS interpreter. | 16:12.41 |
| | Now, if we hook initialize_matrix and add the zoomrate matrix modification in there, that will work for PS/PDF and PCL, right? | 16:13.26 |
| ray_laptop | Robin_Watts: yes, if they are set via the command line, or from plmain put param | 16:13.36 |
| Robin_Watts | ray_laptop: Right. Hence that would be the way I would be tempted to do this. | 16:13.55 |
| | I can't see any way of being more general. | 16:14.10 |
| ray_laptop | as far as the initial matrix for "zoom", that would also be best done in plmain | 16:14.31 |
| Robin_Watts | footles in code to look at plmain. | 16:15.56 |
| ray_laptop | Robin_Watts: but I don't see and use of RKZoomRate anywhere | 16:15.59 |
| Robin_Watts | ray_laptop: I haven't seen any use of it either. | 16:16.22 |
| ray_laptop | It may be they are trying to do something that we added (at least for PS and PDF) with -dFitPage | 16:16.53 |
| Robin_Watts | There is no use of any of these device params things as far as I can see in the code they have given us. | 16:17.15 |
| henrys | I don't think you can change the matrix in plmain.c pcl will blow away anything you do when it sets up the page in pcpage.c | 16:17.16 |
| Robin_Watts | henrys: right, that's what I was fearing. | 16:17.29 |
| ray_laptop | Robin_Watts: so I guess we need to ask them what zoomrate is used for. sigh | 16:17.34 |
| henrys | Robin_Watts: sounds to me like they didn't need it for pcl but I may be mistaken | 16:17.55 |
| Robin_Watts | The right place to do this would seem to be to do it when the matrix is initialized. Which, unless I am mistaken, means the initialize_matrix entry point seems a reasonable place to do it. | 16:18.28 |
| | henrys: If we're going to the trouble of converting their device from a grotty hack into a shiny example of 'best practice', then surely it's best to code something that works in all cases (unless that makes it stupidly hard) | 16:19.34 |
| | ray_laptop: Yes, at some point we're going to have to raise this stuff with them. I was vaguely hoping to have something plausible in place by then though. | 16:20.10 |
| henrys | Robin_Watts: I would leave it - hand in the "big" part and tell them all is left to do is the zoom rateâ¦. | 16:21.29 |
| ray_laptop | well, they haven't implemented any of this stuff in PCL AFAICT (I searched all of the .c files for "RK") | 16:21.30 |
| Robin_Watts | ray_laptop: OK, let's leave the zoomrate stuff for now and move on. | 16:21.51 |
| | next question for ray_laptop - can we safely use bg_output_page here? | 16:22.12 |
| | what are the requirements for that? | 16:22.40 |
| ray_laptop | Robin_Watts: at least for PS, we can suggest /Install { zoom dup scale } | 16:22.50 |
| Robin_Watts | I think we're going to need to ask them to explain their intentions for all the device params, frankly as lots of them may duplicate things we already have. | 16:23.51 |
| ray_laptop | Robin_Watts: for bg printing, the device can't modify anything in it's structure during printing that it expects to have modified in the device that is in the foreground. (the background is a copy of the device) | 16:24.26 |
| | Robin_Watts: that's why TIFF is problematic. The TIFF struct has "state" info needed for subsequent pages | 16:25.16 |
| Robin_Watts | I think we're safe here then. | 16:25.24 |
| ray_laptop | Robin_Watts: yes, I think so | 16:26.52 |
| Robin_Watts | OK, so next bit were the color questions that mvrhel_laptop is looking into now (do we need the equiv colors, and the color mapping procs and the get_color_comp_index etc) | 16:27.54 |
| | I'm guessing we do need the ret_devn_params, but I'll trust mvrhel_laptop to tell me the answer there too. | 16:28.27 |
| ray_laptop | cust 532 (Len) called. I'll get back to reviewing after I talk to him | 16:28.54 |
| Robin_Watts | Why do they have 6 components listed? Is that just a typo? I'd assume that we only need 5, but probably it doesn't hurt. | 16:29.00 |
| mvrhel_laptop | bbiab. need to eat some breakfast | 16:29.03 |
| Robin_Watts | ray_laptop: Sure. Thanks. | 16:29.03 |
| chrisl | henrys: pretty sure the PLRM works...... I'll try it | 16:29.15 |
| | henrys: btw, a PCL build in Win7 VBox on a vboxsrv share takes me ~41 minutes, vs 4 minutes on my laptop running on the real hardware. | 16:32.16 |
| henrys | chrisl: I thought mine was worse than that, but still that's not useable | 16:33.31 |
| | chrisl: I do get an encoding error on page 793 | 16:34.04 |
| | 792 I mean. | 16:34.11 |
| | and I haven't modified the file - the date is 2007 | 16:34.23 |
| chrisl | henrys: an encoding *warning*.... I see that | 16:34.47 |
| henrys | yes that is what I mean. | 16:35.03 |
| | I didn't recall seeing that before | 16:35.17 |
| chrisl | henrys: at least you didn't call it a crash ;-) I'll have a poke at it and see. It's possible we've tightened up something in the PDF interpreter | 16:35.50 |
| henrys | I just thought plrm was very vanilla stuff and we didn't expect something like that, but maybe not. | 16:36.24 |
| chrisl | It was produced by Adobe Distiller, it could have any old cr*p in it! | 16:36.56 |
| ray_laptop | have to run something over to the school. bbiab (about 30-45 min). | 16:43.48 |
| chrisl | henrys: well, the warning is accurate (the font object does not have an encoding), but the encoding entry is optional, so I'm not clear why we issue a warning. The warning was added by Alex in 2008, so has been there for a while...... Let me see if older version throw it too | 16:50.05 |
| Robin_Watts | Phew. I was scared by the #pragma omp stuff in the SSE code, but it's all commented out :) | 16:50.24 |
| chrisl | Hrm, nope, 9.10 does not issue the warning...... | 16:52.33 |
| mvrhel_laptop | ok. back from eating.. | 16:52.38 |
| kens | bisect ? | 16:52.54 |
| chrisl | Just going to do that | 16:53.06 |
| henrys | Robin_Watts: I don't see any great speed up for 16 byte alignment on mac os x. I was kind of curious because I know the mem* and str* routines have sse2 optimizations. | 17:04.28 |
| chrisl | Actually, 9.10 does throw the warning - I thought this Ubuntu was more up to date, but it's 9.06 installed | 17:04.41 |
| mvrhel_laptop | ok so I have a nice file with spots, deviceN colors, RGB and CMYK colors including some with the real name for the customers names. | 17:04.58 |
| | now I need to create a profile | 17:05.06 |
| | that will take a little longer | 17:05.12 |
| Robin_Watts | mvrhel_laptop: "Blue" or "XXXBlue" ? | 17:05.15 |
| mvrhel_laptop | both :) | 17:05.20 |
| Robin_Watts | mvrhel_laptop: Did they pass us a profile? | 17:05.31 |
| mvrhel_laptop | including those in DeviceN color spaces with other colors | 17:05.35 |
| | Robin_Watts: I don't know . did they? | 17:05.43 |
| henrys | mvrhel_laptop: they gave us a profile to use. | 17:05.50 |
| mvrhel_laptop | if they can, that would be helpful | 17:05.50 |
| | oh | 17:05.53 |
| henrys | we are using there command line and all right? | 17:06.02 |
| mvrhel_laptop | that saves me a ton of time | 17:06.02 |
| Robin_Watts | yeah, I have several here. | 17:06.13 |
| mvrhel_laptop | where do I find said profile | 17:06.15 |
| Robin_Watts | In the zip file that they mailed. Let me find the date etc. | 17:06.24 |
| henrys | they have an icc directory | 17:06.45 |
| Robin_Watts | 24/10/2013 01:03 | 17:06.58 |
| mvrhel_laptop | I found it | 17:06.59 |
| | oh maybe not | 17:07.40 |
| | that seems to just be a document | 17:07.47 |
| Robin_Watts | You're looking for the mail from Masaru-san called "Re: Regarding XXXX device" on 24/10/2013 at 01:03 | 17:08.27 |
| | with an attachment called 201302427245063.zipp | 17:08.48 |
| mvrhel_laptop | ok yes | 17:08.58 |
| | that has a pdf file in it | 17:09.11 |
| Robin_Watts | bugger. sorry. | 17:09.48 |
| henrys | I thought they were putting code on the ftp site - that is what mvrhel_laptop needs right? | 17:09.49 |
| mvrhel_laptop | Robin_Watts: is that where you are saying the profile is? | 17:09.49 |
| Robin_Watts | yes. | 17:11.00 |
| | mvrhel_laptop: Let me just zip you this directory. | 17:11.09 |
| mvrhel_laptop | ok sounds good | 17:11.27 |
| Robin_Watts | mvrhel_laptop: Sorry about that. icc.zip uploading to my home dir now. ETA 2 mins. | 17:11.58 |
| mvrhel_laptop | np | 17:12.07 |
| Robin_Watts | finished. | 17:14.11 |
| henrys | marcosw: did you see norbert's mail or is that something for ray? | 17:14.58 |
| mvrhel_laptop | got it | 17:15.17 |
| | wow. lots of profiles | 17:16.25 |
| | they clearly are fine with the ICC color flow | 17:16.48 |
| henrys | mvrhel_laptop: they have a read me with a sample invocation I only tested those. | 17:16.52 |
| | s/those/that | 17:16.59 |
| mvrhel_laptop | where is the read me? | 17:17.29 |
| | Robin_Watts: sorry... | 17:17.51 |
| henrys | I don't know what Robin_Watts wants you to do but I think you should have the original code - search for ftp marcos and the customer name in your email. | 17:18.24 |
| mvrhel_laptop | ok | 17:18.41 |
| kens | OK night all | 17:19.06 |
| Robin_Watts | henrys: I was hoping that mvrhel_laptop could verify that the new device is behaving as their old device was. | 17:19.08 |
| | w.r.t. color. | 17:19.21 |
| henrys | mvrhel_laptop: july 17th | 17:19.24 |
| mvrhel_laptop | ok | 17:19.27 |
| Robin_Watts | and he might be able to point out bits of the new device that aren't needed any more. | 17:19.42 |
| henrys | Robin_Watts: so he does nee the original code from the ftp site right? | 17:19.46 |
| | s/nee/need | 17:20.00 |
| mvrhel_laptop | ok found the informatio | 17:20.10 |
| Robin_Watts | henrys: Well, I'd have been happy with him verifying that the new code was acting sanely. | 17:20.16 |
| mvrhel_laptop | Robin_Watts: I was going to do that first | 17:20.27 |
| henrys | okay I'll butt out. | 17:20.31 |
| mvrhel_laptop | but I will do both | 17:20.37 |
| Robin_Watts | thanks. | 17:20.41 |
| mvrhel_laptop | I do want to know what I am talking about when I visit there | 17:21.19 |
| | hmm I can not connect | 17:23.15 |
| | marcosw: any thoughts on why I would not? | 17:23.34 |
| | the sever name has your name.... | 17:23.50 |
| | your email to the customer on 7/17 | 17:24.07 |
| Robin_Watts | mvrhel_laptop: I'm uploading the zipfile to my casper dir now. | 17:24.53 |
| | but it will take 20 mins. | 17:24.57 |
| mvrhel_laptop | ok. meanwhile I will look over these profiles and make a project with your updates | 17:25.27 |
| | and see if things will run | 17:25.38 |
| ray_laptop | henrys: as far as I know nothing changed on peeves. I'll email the "authorized_keys" to norbert (these are the piblic keys) so he can check it. | 17:26.09 |
| marcosw | mvrhel_laptop: sorry, what connection are you asking about? | 17:33.31 |
| mvrhel_laptop | marcosw: the ftp site for customer 801 | 17:33.50 |
| marcosw | mvrhel_laptop: I just tried it from casper and am able to connect. what error message(s) are you seeing? | 17:35.21 |
| mvrhel_laptop | unable to initialise SFTP: could not connect | 17:35.43 |
| ray_laptop | henrys: I thought you asked about the FTP for norbert | 17:35.57 |
| marcosw | mvrhel_laptop: it's not sftp, it's ftp (old skool) | 17:36.40 |
| mvrhel_laptop | aha! | 17:36.54 |
| marcosw | after you connect you may need to set passive mode, which apparently is non-trivial under windows . | 17:37.48 |
| henrys | ray_laptop:I did | 17:38.21 |
| ray_laptop | henrys: OK. I'm sending it now. | 17:39.17 |
| henrys | I guess norbert really needs casper access so he can do regressions | 17:39.47 |
| Robin_Watts | mvrhel_laptop: If you still need it, the archive can be found in my home dir on casper | 17:45.00 |
| | XXXX_Project_0822.zip | 17:45.08 |
| mvrhel_laptop | ok thanks Robin_Watts | 17:45.14 |
| | got it Robin_Watts thanks | 17:50.04 |
| ray_laptop | Robin_Watts: Do you think we want (or need) a way to set the mdev align_mod and pad directly (other than from the target dev's dsop ? | 18:01.55 |
| | I was thinking it might be handy | 18:02.11 |
| Robin_Watts | ray_laptop: Sorry, missed this. | 18:03.22 |
| | I can't think of a use case for that offhand, but I could easily be wrong. If it falls out without extra work, great. | 18:04.09 |
| marcosw | chrisl: did you abort your cluster job or did I screw something up? (I'm messing with the cluster code at the moment). | 18:05.13 |
| chrisl | marcosw: I aborted it, I just noticed a possibly better way to do what I was going to test...... | 18:05.50 |
| marcosw | chrisl: thx | 18:06.00 |
| ray_laptop | Robin_Watts: no, maybe we'll just add it later if we find a use case. It's trivial, but I don't like having functions around that nobody uses. | 18:06.01 |
| Robin_Watts | Woo Hoo. | 18:14.50 |
| | I have the first version of the SSE that goes to 4bits working. | 18:15.03 |
| ray_laptop | Robin_Watts: great! | 18:17.05 |
| mvrhel_laptop | Robin_Watts: ok so I have your code running although I did get a range check at the end for some weird reason. how is the output in the 8 bit case organized? | 18:20.03 |
| | I can look at code and figure out.... | 18:21.08 |
| ray_laptop | Robin_Watts: so, the 'size_buf_device' returns the 'raster'. Should this be changed to return the raster with pad+alignment ? | 18:21.17 |
| | Robin_Watts: so how is it working without the pad ? | 18:24.59 |
| Robin_Watts | ray_laptop: It's using the 'unaligned' methods, and presumably getting lucky in reading off the end of the buffer :) | 18:33.20 |
| | or maybe at the size I'm running it now, it doesn't have to read off the end. | 18:33.39 |
| mvrhel_laptop | for some reason my files have no marks on the page :( | 18:33.43 |
| Robin_Watts | mvrhel_laptop: sorry, I had stepped away. | 18:34.02 |
| mvrhel_laptop | going to figure out now why | 18:34.33 |
| Robin_Watts | mvrhel_laptop: So... I'm running: | 18:34.34 |
| | -o out. -sDEVICE=xxxx-aps -r600 gs/examples/tiger.eps | 18:34.50 |
| ray_laptop | Robin_Watts: there you go again :-( | 18:35.05 |
| Robin_Watts | sorry. | 18:35.17 |
| mvrhel_laptop | ok. well let me try that first and then do my test file with the ICC stuff | 18:35.18 |
| ray_laptop | we really need that filter | 18:35.19 |
| Robin_Watts | I'll edit the logs. | 18:35.25 |
| ray_laptop | Robin_Watts: That's OK. I'll do it | 18:35.34 |
| Robin_Watts | mvrhel_laptop: So, if you do "-o out -sDEVICE=xxxx-aps -r600 gs/examples/tiger.eps" | 18:36.00 |
| | you should get files outs0, outs1, outs2, outs3, outs4 | 18:36.23 |
| mvrhel_laptop | interesting | 18:36.45 |
| | so with the tiger.eps and no icc stuff I don't get the range check at the end | 18:36.57 |
| | I may have to change the way these files get named | 18:37.35 |
| | right. I can kinda see the tiger | 18:42.55 |
| | the diff between white and where there is color is tiny | 18:43.17 |
| Robin_Watts | mvrhel_laptop: I suspect your PGM reader is duff. | 18:43.39 |
| | It's ignoring the MAXVAL value. | 18:44.02 |
| mvrhel_laptop | ah | 18:44.15 |
| Robin_Watts | Each byte contains 0..7 not 0..255 | 18:44.20 |
| | use "convert" to get a .png and you'll see. | 18:44.33 |
| mvrhel_laptop | photoshop does not like that | 18:44.35 |
| Robin_Watts | photoshop is broken then. | 18:44.45 |
| mvrhel_laptop | I am not going to argue with you | 18:44.54 |
| Robin_Watts | but it can easily be fixed. | 18:45.01 |
| mvrhel_laptop | again I want to be able to take the 0 255 range values and see where things are | 18:45.27 |
| Robin_Watts | Search for the line in gdevxxx.c that contains "P5" | 18:45.44 |
| | and change the 15 to 255. | 18:45.53 |
| ray_laptop | Robin_Watts: There are several P?M viewers that don't like MAXVAL other than 255. I recommend making it 255 | 18:46.10 |
| | Robin_Watts: and you have to scale the data up, right ? | 18:46.33 |
| Robin_Watts | Then in "write_plane" change "fputc(" to "fputc(17*" | 18:46.45 |
| mvrhel_laptop | not sure why you would have the squashed range anyway | 18:46.50 |
| | is that what they have? | 18:46.57 |
| Robin_Watts | Yes. | 18:47.05 |
| mvrhel_laptop | is it a 4 bit device? | 18:47.06 |
| Robin_Watts | It's a 4 bit device. | 18:47.12 |
| mvrhel_laptop | ok | 18:47.14 |
| ray_laptop | it's actually a 4-bit device, but maxval is 7 | 18:47.26 |
| Robin_Watts | but currently they only use 0..7, but they want to use 0..15 eventually, apparently. | 18:47.28 |
| | actually, possibly you should use 36* rather than 17* | 18:48.12 |
| ray_laptop | Robin_Watts: I was just about to point that out ;-) | 18:48.26 |
| Robin_Watts | Hold on, give me a mo and I'll upload a new version of the file. | 18:48.42 |
| mvrhel_laptop | ok let me fix these things so I can see what is going on colorimetrically | 18:48.42 |
| | no | 18:48.45 |
| | I will do it | 18:48.47 |
| | I want to change how the file names are handled too | 18:49.01 |
| | at least locally here | 18:49.07 |
| Robin_Watts | ok. I'll fix it in the next version of the file with the SSE in though. | 18:49.09 |
| | mvrhel_laptop: You just want to add '.pgm' ? | 18:49.27 |
| mvrhel_laptop | yes | 18:49.38 |
| ray_laptop | mvrhel_laptop: note that 36*7 is only 252 so you won't ever see full saturation | 18:49.50 |
| mvrhel_laptop | but I don't want to mess up your flow | 18:49.51 |
| Robin_Watts | ray_laptop: My version here will do the scale properly. | 18:50.30 |
| ray_laptop | Robin_Watts: OK. | 18:53.08 |
| mvrhel_laptop | ok now I am getting something reasonable for tiger | 19:00.04 |
| | let me now go back to the ICC stuff and see what is going wrong | 19:00.16 |
| amonakov | can somebody recommend a test pdf for rendering quality evaluation? font rendering, to be precise | 19:01.55 |
| | I'd like to play with enabling freetype hinting a bit | 19:02.45 |
| | as I understand, mupdf avoids hinting because it distorts character shape | 19:03.28 |
| | I think "slight" hinting (snapping in vertical direction, but not horizontal) makes sense for mupdf's use | 19:04.21 |
| | any opinion on that? | 19:04.28 |
| Robin_Watts | amonakov: Depends on the target device. | 19:06.59 |
| | If you are rendering at high enough resolution, then hinting does not help. | 19:07.15 |
| amonakov | I'd also like to try my hand at lcd (rgb subpixel) antialiased rendering; as I understand the most viable way seems to be rendering everything at subpixel resolution and downscaling+filtering last | 19:07.55 |
| Robin_Watts | If you are rendering to a screen, then IMHO, antialiasing gives far nicer results than hinting does, especially when you take sub pixel antialiasing into account. | 19:07.55 |
| amonakov | Robin_Watts: I'm talking about ~100 dpi devices | 19:08.19 |
| Robin_Watts | amonakov: If you know the LCD layout in advance you can do the filtering as you render. This is what I did when I wrote code to do it when I worked for Picsel. | 19:08.57 |
| | These days however, it's not so easy as you have all sorts of odd layouts for the pixies, so rendering first and then filtering en masse makes sense. | 19:09.37 |
| | (several pixies make up a pixel) | 19:09.44 |
| | But even so, hinting never helps, IMAO. | 19:10.30 |
| amonakov | Robin_Watts: antialiasing and hinting are not either-or tradeoffs, I don't understand why you phrase it like that | 19:10.44 |
| | you can snap to pixel grid, and then you can still use antialiasing | 19:11.14 |
| | especially if you snapped in vertical direction only | 19:11.24 |
| Robin_Watts | Indeed, they are not either/or. You can use both. But it's still a mistake, IMHO. | 19:11.46 |
| | hinting distorts the shape of glyphs, in the hopes that it will remain more readable at small sizes. | 19:12.28 |
| | antialiasing allows you to use smaller glyphs while still preserving the shape. | 19:13.10 |
| | The need for hinting is vastly reduced by having antialiasing. | 19:13.24 |
| amonakov | yes. I'm of the opinion that those hopes are not futile, and at 100 dpi it really improves the legibility. even with antialiasing | 19:13.44 |
| Robin_Watts | And I've yet to see anyone convincingly use hinting to improve the appearance of antialiased text. | 19:14.05 |
| | but if you believe differently, go for it. | 19:14.33 |
| ray_laptop | Robin_Watts: but narrow stems that aren't aligned on the pixel with AA tend to not be full density, right ? | 19:15.15 |
| | eg. two 50% lines side by side | 19:16.00 |
| Robin_Watts | ray_laptop: Indeed not. | 19:16.03 |
| | I understand the principles involved. I've just never seen an implementation that convinced me it was an improvement. | 19:16.41 |
| lukasg | hey everyone - I want to use gsvg in a project of mine, and am trying to build ghostpdl from source with a custom prefix location. it all compiles nicely, and I get a functioning svg/obj/gsvg binary, but it doesn't get installed in the custom location upon 'make install' | 19:17.05 |
| Robin_Watts | lukasg: That sounds like a makefile bug, but it's not surprising as gsvg gets very little TLC these days. | 19:17.41 |
| lukasg | then I noticed this comment in ghostpdl-9.10/Makefile: # only pcl has an install target at this point | 19:17.56 |
| ray_laptop | I thought gsvg was mostly broken and deprecated | 19:18.11 |
| lukasg | oh? | 19:18.20 |
| mvrhel_laptop | ok so the range check occurs with my fancy file. | 19:18.48 |
| ray_laptop | I don't know, but I know that it gets almost no attention | 19:18.49 |
| lukasg | hmm⦠I'm looking to create .eps or .pdf from an .svg | 19:19.07 |
| | ok, that's definitely good to know | 19:19.21 |
| | so I suppose I could patch the Makefile pre-configure, and try if gsvg works for my purposes. If it does, I guess I'll still use it, I'm not too worried about long-term maintenance for this project | 19:21.29 |
| amonakov | Robin_Watts: this is the difference I'm talking about: http://i.imgur.com/tE0WHvu.png | 19:25.10 |
| Robin_Watts | amonakov: Right. The contrast is certainly better on the right. | 19:26.18 |
| | The overall shape of the letters is better on the left. | 19:26.39 |
| | I just personally really dislike hinting. | 19:27.03 |
| | I hate the way that when you zoom a hinted page the text density appears to change. | 19:27.30 |
| ray_laptop | Robin_Watts: just to make sure I don't muck the planar code up. Just to confirm the planar buffers all precede the line pointers, right ? (the line_ptrs are not interleaved) | 19:31.28 |
| Robin_Watts | ray_laptop: Such is my memory of it, yes. | 19:31.48 |
| ray_laptop | At least I can get rid of the funky method to calculate the actual 'raster' (it used the diff between line_ptrs) | 19:32.29 |
| Robin_Watts | yeah, I remember that :( | 19:36.36 |
| ray_laptop | well, now the mdev->raster is the actual line_stride for a single line | 19:37.15 |
| Robin_Watts | http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ | 19:52.49 |
| | Not sure where we fit on that :) | 19:52.55 |
| | gs is 4.26M lines apparently. | 19:53.56 |
| mvrhel_laptop | Robin_Watts: so something is amiss with the deviceN stuff. I have to eat and then run to an appt. I will figure out the issue later today/tonight and get a fix to you | 19:54.07 |
| Robin_Watts | mvrhel_laptop: Thanks. | 19:54.15 |
| | and sorry that you've ended up with this. | 19:54.23 |
| mvrhel_laptop | oh no worry | 19:54.29 |
| | it is good for me to work on this some | 19:54.42 |
| | so I am a bit in the loop when I visit | 19:54.52 |
| ray_laptop | mvrhel_laptop: well, you could always read the code on the plane ;-) | 19:57.22 |
| Robin_Watts | mvrhel_laptop: When is your visit? | 19:58.38 |
| mvrhel_laptop | it is 3rd week in november I think | 19:59.07 |
| ray_laptop | mvrhel_laptop: how many months are you going to be over there ? ;-) | 19:59.46 |
| mvrhel_laptop | :) | 20:00.05 |
| Robin_Watts | I've almost got the SSE code for downscaling/bluenoising/packing to 4 bits working. | 20:00.55 |
| ray_laptop | Robin_Watts: great. | 20:01.17 |
| Robin_Watts | I'm getting 1 output line per band wrong. | 20:01.25 |
| | Oh, might be a really stupid error. | 20:02.09 |
| ray_laptop | I'm thinking that to test this on the cluster, I'll force the mdev->align_mod to 16 and set the pad to 8. Anyplace that relies on it being 'bitmap_raster' in the buffer device will break | 20:02.49 |
| Robin_Watts | ray_laptop: nice. | 20:03.01 |
| | Fixed it. | 20:03.03 |
| ray_laptop | that was quick | 20:03.11 |
| Robin_Watts | as I say, stupid typo. | 20:04.50 |
| | ray_laptop: Your conversion to 4 bit algorithm worked well. | 20:05.09 |
| ray_laptop | Robin_Watts: can you take look at mem_get_bits_rectangle in gdevmem.c -- the part where calculates the copy.options | 20:05.13 |
| | Robin_Watts: good | 20:05.17 |
| Robin_Watts | I had to use SSE instructions rather than MMX ones, but they are basically the same, but bigger, so your trick solved it nicely. | 20:05.34 |
| ray_laptop | yeah, the more bits in the register, the better | 20:05.56 |
| Robin_Watts | copy_params.options = .... | 20:06.08 |
| | ? | 20:06.10 |
| | ray_laptop: What's the problem? | 20:07.02 |
| | if the mdev->raster == the expected raster, then use the "GB_RASTER_STANDARD" option, otherwise use "GB_RASTER_SPECIFIED" | 20:07.37 |
| ray_laptop | Robin_Watts: yes, In particular, it looks like if the mdev->raster is bigger than bitmap_raster, it won't have set the GB_RASTER_STANDARD | 20:07.43 |
| Robin_Watts | Right. | 20:08.47 |
| | but that's what we want, right? | 20:08.54 |
| ray_laptop | which I guess makes sense, but we *want* to return a pointer if at all possible, right ? | 20:09.21 |
| | gx_get_bits_return_pointer is a mess | 20:09.59 |
| Robin_Watts | So this function first tries to get a pointer, and only if that fails does it try to get a copy. | 20:10.39 |
| ray_laptop | Robin_Watts: right. | 20:10.48 |
| Robin_Watts | When we ask for a pointer, we are at pains to ask for the raster that it can manage. | 20:11.10 |
| | i.e. we never ask for STANDARD raster when we know that it can't give us a STANDARD raster. | 20:11.28 |
| ray_laptop | Robin_Watts: yeah, I guess. where 'STANDARD' is bitmap_raster(width * depth) padded only to comply with align_bitmap_mod | 20:12.35 |
| Robin_Watts | bitmap_raster(width * depth) contains the padding. | 20:12.58 |
| amonakov | does mupdf perform gamma-correct antialiasing? | 20:13.48 |
| Robin_Watts | amonakov: Almost certainly not. | 20:14.07 |
| | We assume linearity. | 20:14.25 |
| | If you want gamma correction, then post process the final bitmap. | 20:14.42 |
| amonakov | is that what -G option in mudraw does? | 20:15.14 |
| | and mupdf-x11 does not do, at the time? | 20:15.28 |
| Robin_Watts | amonakov: Yes, mudraw calls: fz_gamma_pixmap(ctx, pix, gamma_value); | 20:16.20 |
| | amonakov: Indeed, mupdf-x11 does not call that, at least partly because we don't have an easy way to input the gamma required ;) | 20:17.21 |
| amonakov | I wonder what would be a "correct" gamma value for me, then | 20:17.49 |
| Robin_Watts | amonakov: depends on your monitor etc. Something between 0.8 and 2 I would guess. but that's a REAL guess. | 20:19.19 |
| | hmm. With the updatepage stuff it's not trivial to add the gamma stuff into mupdf-x11 as you'd need to be able to gamma a pixmap rectangle. | 20:20.26 |
| | Not hard to do, but you'd need to add that. | 20:20.35 |
| amonakov | haha :) I think the "canonical" gamma is 2.2 actually? | 20:20.53 |
| Robin_Watts | could be. | 20:21.09 |
| ray_laptop | amonakov: when printing, yes, but not to displays | 20:21.23 |
| Robin_Watts | If you want to try this, look for the calls to pdfapp_runpage in pdfapp.c | 20:21.39 |
| | The 3rd call needs an fz_gamma_pixmap call after the fz_free_device on app->image | 20:22.07 |
| | The 1st call needs an fz_gamme_pixmap_with_rect after the fz_free_device, again on app->image | 20:22.39 |
| | and that's it. | 20:22.43 |
| amonakov | ray_laptop: are you sure? for example http://en.wikipedia.org/wiki/Gamma_correction indeed lists 2.2 as gamma pertaining to monitor output | 20:22.44 |
| ray_laptop | amonakov: possibly, but I've never seen that much used | 20:23.50 |
| amonakov | the pixmaps are 8bpp, right? I think gamma correcting by 2.2 would benefit from bigger source depth | 20:33.48 |
| | and I wonder if glyph bitmaps received from freetype are gamma-corrected or not (they shouldn't be, but...) | 20:34.51 |
| Robin_Watts | pixmaps are 8bpp, yes. | 20:35.37 |
| | I think you'll find that 8bpp is fine for what you need. | 20:35.55 |
| Robin_Watts | heads downstairs for a bit. Will check in later. | 20:36.08 |
| | I'll do the last bit of SSE tomorrow, ray. | 20:36.19 |
| ray_laptop | Robin_Watts: OK. Hopefully I'll have the alignment and pad stuff ready for you by your tomorrow AM | 20:54.52 |
| | mvrhel_laptop: are you available ? | 23:23.16 |
| | The AIX361DC_Save.pdf (cust 532) *does* grow in memory usage, and it might be ICC profile related. I see 3000+ allocations and it looks like the "max" is reached during parsing (887Mb) :-0 | 23:58.48 |
| | Forward 1 day (to 2013/10/30)>>> | |
IRC Logs
