| | <<<Back 1 day (to 2013/09/15) | 2013/09/16 |
| kens | Oh Oh, looks like Robin_Watts has gone recursive :-) | 07:01.16 |
| | Hmm did someone get Robin_Watts wet ? I hope nobody fed him after midnight..... | 07:09.21 |
| robin_watts_mac | It's my phone line that has the gremlins :) | 11:17.26 |
| kens | shouldn't feed it after midnight either then :-) | 11:17.51 |
| robin_watts_mac | Tor and sebras have clearly stolen my bandwidth - net hasn't worked right since they left. | 11:18.45 |
| | Eclipse are testing the line now. | 11:18.55 |
| kens | Well, somethign definitely is wrong.... | 11:19.13 |
| robin_watts_mac | Right now, I might be connected via a USB mobile broadband dongle thing. | 11:19.18 |
| | changing router | 11:22.36 |
| sebras | robin_watts_mac: I told you broadband was better in .se, I just nudged a cable in your office to prove my point... >;) | 11:26.25 |
| kens | Robin_Watts : ping | 12:08.03 |
| Robin_Watts | pong | 12:08.09 |
| | if I fall off the net, I apologise. | 12:08.18 |
| kens | Do you know about search in MuPDF ? | 12:08.19 |
| Robin_Watts | a bit. | 12:08.24 |
| kens | Stack Overflow question: | 12:08.34 |
| | http://stackoverflow.com/questions/18811081/does-mupdf-reads-ascii-and-if-not-i-would-like-to-know-how-does-he-handle-the | 12:08.34 |
| | I suspect one problem is that Arabic is a right -to-left language | 12:08.52 |
| Robin_Watts | Right to left is a question for tor. | 12:09.03 |
| kens | :-) | 12:09.10 |
| Robin_Watts | I believe we do a right to left pass now. | 12:09.11 |
| kens | Fair enough | 12:09.22 |
| | tor7 ping ? | 12:09.26 |
| Robin_Watts | I have a BT engineer booked for wednesday afternoon, and a new router arriving tomorrow (in case both of mine are broken and are what is causing the problem) | 12:17.57 |
| kens | Seems unlikely *both* would be broken | 12:18.16 |
| | But that is howI endedup with 2, making sure it wasn't the router.... | 12:18.33 |
| Robin_Watts | kens: Well, it's possible that my backup router (which I have been using just for it's wifi capabilities) was previously retired from being my main router because of a problem. | 12:18.58 |
| kens | Its always possible, unless you can remember why you retired it, | 12:19.36 |
| Robin_Watts | It's cheaper to buy a new router than to have BT turn up and charge me for the callout. | 12:19.41 |
| kens | True | 12:19.46 |
| | I seem to recall that'S WHY i HAVE 2 NOW | 12:20.01 |
| | I swear I'm going to rip the caps lock key off this keyboard | 12:21.08 |
| sebras | Robin_Watts: doesn't arabic letters change when they are in a word and when they're on their own..? maybe we don't handle that using ucdn for search text? | 12:21.34 |
| kens | sebras that depends if its Naskh or Nastaliq | 12:21.55 |
| Robin_Watts | kens: http://www.howtogeek.com/howto/windows-vista/disable-caps-lock-key-in-windows-vista/ | 12:21.56 |
| kens | Robin_Watts : I'm using Windows 7, but I'll look at that | 12:22.11 |
| Robin_Watts | http://www.techrepublic.com/blog/windows-and-office/how-do-i-turn-off-the-caps-lock-key-in-windows-7/ | 12:22.22 |
| kens | :-) | 12:22.29 |
| | sebras the fact the the SO poster says they can find single characters makes me doubt its an initial/medial/terminal glyph change | 12:24.14 |
| | Although use of kashidas might confue the search (they are broadly equivalent to 'space' in Latin) | 12:24.43 |
| sebras | kens: I don't know at what stage these changes happen, if they are done by mupdf or if they are encoded in the text-file itself. and the same for the search text. | 12:25.56 |
| Robin_Watts | kens: I suspect tne android app converts Unicode into UTF8. | 12:26.10 |
| tor7 | kens: mupdf uses unicode internally, and so does the search. we also do an rtl pass so it ought to be able to search arabic text, but it's not extensively tested. | 12:26.14 |
| sebras | but both must be handled similarly of course. and I remember my arabic friend having problems with searching in arabic texts in pdfs. | 12:26.30 |
| kens | I suspect someone needs to look at an example file | 12:26.31 |
| sebras | though this was pre tor[0-9] adding ucdn. | 12:26.56 |
| kens | If there's no ToUnicode CMap then its not going to work | 12:27.05 |
| tor7 | kens: Robin_Watts: http://johnhaller.com/jh/useful_stuff/disable_caps_lock/ | 12:27.29 |
| | handy .reg registry files for disabling caps lock | 12:27.44 |
| kens | I downloaded the server toools :-) | 12:28.04 |
| tor7 | just install and log out your windows and back in | 12:28.07 |
| | My caps lock has been a control key ever since I owned a Happy Hacking keyboard over a decade ago :) | 12:28.39 |
| kens | I've never found it a problem in the past but for some reason this keyboard drives me nuts with the caps lock | 12:29.05 |
| tor7 | kens: what keyboard do you have? | 12:31.43 |
| kens | A Logitech K260 | 12:31.56 |
| tor7 | http://www.keyboardco.com/keyboard/usa-topre-realforce-87uw-variable-mini-black-on-beige-keyboard.asp get a keyboard with decent switches instead :) | 12:32.44 |
| kens | £180 :-O | 12:33.38 |
| tor7 | kens: I paid more than that for mine, when I had to direct import it from japan... :/ | 12:33.54 |
| kens | Mine doesn't bother me enough to pay that | 12:34.08 |
| sebras | kens: tor7 tricked me into buying a similar one. it's expensive to be his friend... ;) | 12:34.36 |
| tor7 | kens: I have a spare I could lend you if you want to give it a tryout | 12:34.39 |
| kens | Tor, Really its only the caps lock which annoys me, and now I have a solution for that :-) | 12:35.08 |
| sebras | kens: though I have to say that the topre keyboards are really nice to type on. | 12:35.10 |
| henrys | mvrhel_laptop: I thought the mupdf viewer was on the windows app store? | 14:21.42 |
| | ah nvm I found it. Microsoft search site is confusing. | 14:24.34 |
| Robin_Watts | So, ages ago, when I last had this problem, I bought a USB 3G dongle thing, that I could use on pay as you go to get me mobile internet for when the ADSL breaks. | 14:43.09 |
| | And today is the first day I need to use it. | 14:43.17 |
| | Guess which day their systems crash? | 14:43.26 |
| paulgardiner | Oh, oh, I think I know that one! | 14:44.25 |
| Robin_Watts | touch wood seems to be working now. | 14:44.37 |
| | 4 quid for 3 days seems a reasonable price to pay as a backup plan. | 14:44.48 |
| henrys | Robin_Watts: in writing the newsletter and your progressive downloading feature I got to thinking why progressive http wouldn't solve the problem nicely, and read the pdf as you would locally? | 15:21.46 |
| Robin_Watts | henrys: We operate in *many* different ways :) | 15:22.27 |
| | Some servers do not tell you how long a file is. | 15:23.08 |
| | Some servers let you do byte range fetches, some don't. | 15:23.19 |
| henrys | okay so it's a feature we don't do that ;-) | 15:23.28 |
| Robin_Watts | We will make the best of whatever we can. | 15:23.50 |
| | In the best possible worlds, we'd get a linearised file, on a server that supports byte ranges. | 15:24.14 |
| | with unbroken hint streams :) | 15:24.33 |
| | and we can get any page from the document very quickly. | 15:24.49 |
| | If we don't have a linearised file, but we do have byte range fetches, we'll read the file 'as normal' and we can get to any page 'fairly quickly'. | 15:25.21 |
| | (But non-linearised files require us to read the page tree, and that can be 30-50% of the size of a file :( ) | 15:25.56 |
| | If we have a linearised file, but no byte range fetches, we can get the pages out in order as fast as possible. | 15:26.25 |
| | If we have a non-linearised file, on a non-byte range capable fetch... we have to wait for it all to download. | 15:26.55 |
| | Essentially, our code is smart enough to do the best it can with what it is given. | 15:27.12 |
| mvrhel_laptop | bbiab | 15:45.30 |
| Robin_Watts | tor7, paulgardiner: ping | 15:53.33 |
| paulgardiner | hi | 15:53.42 |
| Robin_Watts | So, I'm doing the JNI bindings for mupdf on android. | 15:53.52 |
| | and I'm at the draw device. | 15:53.58 |
| | The naive way to go would be to do: blah = new DrawDevice(Bitmap bm); | 15:54.18 |
| | to be the equivalent to fz_new_draw_device(ctx, pixmap); | 15:54.50 |
| | The way the current native stuff works is that it calls AndroidBitmap_lockPixels to get the address of the samples. | 15:55.23 |
| | and then unlocks them at the end of the call. | 15:55.34 |
| paulgardiner | On each render? | 15:56.16 |
| Robin_Watts | Yes. | 15:56.27 |
| | Now, either I need to do that when the device is created, and then release when the device is finished with (i.e. spanning all the drawing operations), or I need to lock/unlock on every call. | 15:57.07 |
| | I'm thinking that I need to lock/unlock on every calls. | 15:57.23 |
| | as keeping the bitmap locked across that long might cause the java heap problems. | 15:57.43 |
| | I was going to say that it'd be hard to replace the bitmap on every device call, but it's not the bitmap I need to replace, it's the bitmap->samples value, and that's doable. | 15:58.53 |
| | OK, I have a plan then. Thanks. | 15:59.04 |
| paulgardiner | Sounds good to me | 16:01.19 |
| tor7 | Robin_Watts: lock/unlock on the begin/end page device calls? | 16:20.41 |
| Robin_Watts | tor7: No, that's still not often enough. | 16:20.58 |
| | The idea of this is to let people render for themselves by making device calls. | 16:21.20 |
| tor7 | so on every draw device call? that means you're making a jni-draw-device that does lock/forward/unlock? | 16:21.24 |
| Robin_Watts | The standard Device.java has a set of call that just call deviceXXXXNative(); for each XXXX entrypoint. | 16:22.25 |
| | The DrawDevice.java will override those with calls that call drawDeviceXXXXXNative(); | 16:22.50 |
| tor7 | Robin_Watts: keep in mind, the fz_pixmap with sample pointer gets stowed away in the draw device stack (like when drawing to clip masks or transparency groups, the "dest" pixmap is different) | 16:22.55 |
| Robin_Watts | and that will do: lock/deviceXXX/unlock | 16:23.13 |
| | tor7: The bitmap pointer gets stored away. | 16:23.23 |
| | The bitmap->samples pointer doesn't. | 16:23.32 |
| | hence I can make a bitmap on creation, and fill in the samples pointer every time I lock. | 16:23.56 |
| | so even if it gets moved around by java, it'll always be locked and in the right place whenever the C looks. | 16:24.23 |
| tor7 | right. makes sense. | 16:24.32 |
| | as long as locking isn't too slow... | 16:24.45 |
| Robin_Watts | This is JNI. "Too slow" has a whole new definition here :) | 16:25.08 |
| paulgardiner | tor7: Hi, I've found out what's causing the iOS app lock warnings. The implementation of CGDataProviderCreateWithData must have been updated and that's changed the timing/thread use of the releasePixmap call. | 16:25.39 |
| tor7 | Robin_Watts: you might want the DrawDevice JNI code to peek at the 'dest' stack to skip doing lock/unlock on "safe" calls | 16:25.40 |
| | paulgardiner: sounds plausible, and annoying | 16:26.07 |
| | I remember having to do a dance with the objc destructors and refcounting to make the free calls end up on the correct thread | 16:26.42 |
| paulgardiner | tor7: I could stick the fz_drop_pixmap call on the background thread, but then I'm worried about releasePixmap being called after we've destroyed the ctx or queue | 16:26.52 |
| tor7 | *all* fz_ calls should happen on the background thread | 16:27.19 |
| | if they don't, you've spotted another bug :) | 16:27.31 |
| Robin_Watts | tor7: I'll worry about that optimisation later :) | 16:27.36 |
| paulgardiner | Yeah, maybe CGDataProviderCreateWithData used to call the callback on the thread with which it was called. | 16:28.19 |
| tor7 | paulgardiner: so it may well be that something in the GUI thread holds on to the pixmap and the call to free it doesn't happen where I expect it | 16:28.39 |
| | paulgardiner: you could try wrapping the fz_drop_pixmap call in releasePixmap as a dispatch to the background thread | 16:29.18 |
| paulgardiner | At the moment it looks to be getting called on the UI thread which is causing the warnings | 16:29.22 |
| | tor7: Yeah | 16:29.43 |
| | I suppose, were the callback to be delayed long enough that we'd blow the queue away, then we'd have problems as it is now with the ctx having been destroyed. | 16:30.43 |
| tor7 | the CG* stuff isn't reference counted so you won't have the same problems as with the MuPageView -dealloc function | 16:30.43 |
| | paulgardiner: we never destroy the fz_context in the ios app, so that ought not to be a problem | 16:31.36 |
| | but yeah, if the dispatch queue is freed and the callback comes in later we'll have a problem | 16:32.34 |
| paulgardiner | Ah right, so we may have a problem with the change we have just been discussing: what if we destrou queue before the callback, or is that also impossible? | 16:32.35 |
| | :-( | 16:32.42 |
| tor7 | the queue is only destroyed on program exit though | 16:32.49 |
| | in MuAppDelegate -dealloc | 16:33.07 |
| paulgardiner | if (queue) {destroy on background thead} else {destroy now} ? | 16:33.34 |
| tor7 | if (queue) destroy(); else leak(); | 16:33.55 |
| paulgardiner | destroy now should be safe though if the queue is null. | 16:34.19 |
| mvrhel_laptop | henrys: ping | 16:38.39 |
| paulgardiner | That does look to have shut it up. :-) | 16:38.40 |
| henrys | mvrhel_laptop: yup | 16:38.45 |
| mvrhel_laptop | so did you see my comment over the weekend regarding the monobit device creation | 16:38.58 |
| | so I am thinking that the device creator should really not set the profile | 16:39.32 |
| | nor should it set it to forward | 16:39.49 |
| | if someone is fooling around with this device for some special case (e.g. like font caching) | 16:40.22 |
| | then they should deal with this issue like they are dealing with avoiding the remap now | 16:40.37 |
| | so what I need to do, is remove the forwarding proc from the one creation and see what breaks and figure out how best to deal with that | 16:42.00 |
| henrys | yes I did read it. It looks like a pandora's box to me though. | 16:43.14 |
| | mvrhel_laptop: ^^^ | 16:43.22 |
| mvrhel_laptop | perhaps. the alternative is to set the one that is currently causing a segv to forward at this time, and open a bug to revisit this | 16:43.53 |
| | henrys ^^ | 16:43.58 |
| henrys | and I'm still curious why it is only becoming an issue in such an isolated situation, mvrhel_laptop | 16:44.03 |
| mvrhel_laptop | henrys: because, again this only breaks with ttf bold with non-FAPI | 16:44.28 |
| | in pcl | 16:44.35 |
| | that was the only case that the one device gets created | 16:44.54 |
| henrys | I like punting it to a future enhancement bug unless it pops up elsewhere. | 16:45.15 |
| mvrhel_laptop | that would be the odd case that I would set to forward, which will fix the issue | 16:45.18 |
| | ok, I will do that and open the note to self in bugzilla | 16:45.33 |
| henrys | okay have an errand to do bbia few | 16:45.52 |
| mvrhel_laptop | ok. I hope things are ok in CO for you | 16:46.10 |
| Robin_Watts | henrys: has the water subsided at all? | 16:50.13 |
| henrys | yes it has come down quite a bit. I have to think we are near a katrina-like disaster. the entire front range is affected. | 17:12.59 |
| ray_laptop | (for the logs): marcosw: I have my Dell poweredge now, and am running memtest (from the ubuntu cd-rom boot). The main (16G) memory speed concerns me a bit. It is only 3.5 Gb/s which seems a bit slow. Does this look similar to what you have. | 17:25.04 |
| | marcosw: I am waiting for the drive caddies that were back ordered, so I can't actually install ubuntu yet. The other thing that is odd is that the screen reports DDR2 667MHz, but the FSB speed is 332 MHz) | 17:27.15 |
| henrys | ray_laptop: is that the noisy one. | 17:28.55 |
| | ? | 17:28.56 |
| Robin_Watts | DDR = Double Data Rate, right? So 332*2 is approx 667 which sounds about right ? | 17:29.57 |
| henrys | mvrhel_laptop: the footage here says the flood affects an area the size of connecticut http://www.today.com/video/today/53021614#53021614 , but the video doesn't do it justice. Our local creek is just raging, wow! | 17:33.13 |
| mvrhel_laptop | that is insane | 17:33.26 |
| | I read in the paper that 800 people were missing | 17:33.38 |
| ray_laptop | henrys: it's pretty noisy. It has 4 2" fans inside, but being inside doesn't quite the noise much | 17:35.31 |
| mvrhel_laptop | ok. on to bug 691182, which as I mentioned in the staff meeting may end up in Robin_Watts' lap | 17:35.33 |
| Robin_Watts | ok. | 17:35.59 |
| | mvrhel_laptop: Did you see marcosw's mail about tiger getting darker with -dUseCieColor? | 17:36.31 |
| mvrhel_laptop | I did not see anything in particular about tiger, but *every* color is going to change with -dUseCIEColor due to the fixes that I did | 17:37.03 |
| Robin_Watts | mvrhel_laptop: He sent a mail with 2 screenshots in. | 17:37.26 |
| ray_laptop | I popped the top, and am really impressed with the packaging. The fans are all "snap in" so if one fails, you just plug in a new one. It has 8 "hot swap" SAS/SATA drive bays that load from the front, and dual P/S | 17:37.32 |
| mvrhel_laptop | he sent it to who | 17:37.43 |
| ray_laptop | henrys: I'll just wear my noise cancelling headphones here in the office. | 17:38.40 |
| mvrhel_laptop | I got an email from him about differences | 17:38.41 |
| | but nothing about tiger | 17:38.44 |
| | I went through all the bmp diffs for all the files that had CIE color spaces in our regression suit | 17:39.07 |
| Robin_Watts | "Change in raster output with recent commit" | 17:39.15 |
| mvrhel_laptop | ah. I did not see the attachement Robin_Watts | 17:39.44 |
| Robin_Watts | mvrhel_laptop: To you and CC'd to tech | 17:39.46 |
| | ah, ok. I'll shut up then. | 17:39.52 |
| mvrhel_laptop | I read the email | 17:39.55 |
| | and replied to him | 17:39.57 |
| | I will need to construct a version of tiger with our default CIE color spaces and compare to distiller to see how we comper | 17:41.00 |
| | compare | 17:41.02 |
| | let me do that just to see | 17:41.13 |
| ray_laptop | oops. got some errors at about 15% through the first pass. (not ECC errors, either which is not what I expected). The data was all 0's instead of what it was supposed to be 0x69001478 (moving inversions, random pattern) | 17:41.15 |
| mvrhel_laptop | Robin_Watts: I am not going to do that with every PS file we have in the test suite though | 17:41.44 |
| ray_laptop | mvrhel_laptop: I've never been able to get Adobe colors to compare to ours. | 17:41.45 |
| mvrhel_laptop | ray_laptop: well we should be much closer now | 17:42.03 |
| Robin_Watts | ray_laptop: That's not good. Send it back. It'll be less grief than trying to figure out which one is wrong and getting replacement ram sent in the long run. | 17:42.11 |
| mvrhel_laptop | we had a 4% yellow cast in CMYK at white before | 17:42.20 |
| | as well as a bug in CIEA based spaces | 17:42.29 |
| | which is likely the background color in the tiger image | 17:42.35 |
| | but I will double check | 17:42.58 |
| ray_laptop | Robin_Watts: First I'll see if the supplier want to send me all new memory. It'll probably be cheaper than the shipping (70 lb, to and from TX) | 17:43.21 |
| mvrhel_laptop | I think Robin_Watts is just trying to delay me from reviewing bug 691182 and dropping it on him | 17:43.46 |
| | ;) | 17:43.54 |
| Robin_Watts | ray_laptop: And then it'll be the motherboard that's knackered, or a PSU problem or... :( | 17:44.01 |
| ray_laptop | Oh, I notice that even though the memory controller has ECC and ECC errors are reported, the test mode (whatever the default is) has ECC: off | 17:44.56 |
| | Robin_Watts: not likely to be the P/S since it has dual P/S | 17:45.20 |
| Robin_Watts | ray per hour * hours required to test > cost of shipping * large factor, I'm sure. | 17:45.24 |
| ray_laptop | Robin_Watts: I'm testing while waiting for the backordered parts anyway. Initially I hadn't even planned on running memtest | 17:46.23 |
| | but I'll let it run for a while. and see. It may have just been a comic ray | 17:46.57 |
| Robin_Watts | "I'll be here all week. Try the veal." | 17:47.35 |
| ray_laptop | I'll let it run for a couple of passes (22% done after 26 min), then try again with ECC mode. | 17:48.11 |
| mvrhel_laptop | ray_laptop: ps question for you | 17:48.36 |
| ray_laptop | mvrhel_laptop: sure. go ahead | 17:49.21 |
| ray_laptop | opens PLRM ... | 17:49.39 |
| mvrhel_laptop | so tiger does all its fills with things like 0.063 0.35 0.54 0 k and 0.8 g. I need to make sure that these use a particular CIEA and CIEDEFG color space that I have to define in the file (using what we have in Resources/Color) | 17:50.25 |
| ray_laptop | mvrhel_laptop: with -dUseCIEColor, right ? | 17:51.07 |
| mvrhel_laptop | is there an easy way in PS to make is so that fills like 0.063 0.35 0.54 0 k use the CIEDEFG color space. ray_laptop, distiller has no -dUseCIEColor | 17:51.32 |
| | the CIE color spaces have to be explicit in the file | 17:51.43 |
| | I can generate our output fine. | 17:51.59 |
| | need to compare to distiller. | 17:52.06 |
| | I did this with some constructed files. | 17:52.38 |
| | but if Robin_Watts want me to check tiger.eps I need a version that will use the proper CIE color spaces. Maybe ps2write would make me one if I use -dUseCIEColor | 17:53.25 |
| ray_laptop | mvrhel_laptop: distiller can take PS input (which is what tiger.eps is) so: << /UseCIEColor true >> setpagedevice in tiger will be the same as -dUseCIEColor on the gs command line | 17:53.29 |
| | mvrhel_laptop: is that what you are asking ? | 17:54.08 |
| mvrhel_laptop | ray_laptop: my copy of distiller claims it does not support < /UseCIEColor true >> setpagedevice | 17:54.13 |
| | I had that in a file from the regression tests | 17:54.22 |
| ray_laptop | (UseCIEColor is a standard pagedevice setting) | 17:54.23 |
| mvrhel_laptop | and it did not work | 17:54.26 |
| | let me find the file | 17:54.43 |
| | hold on | 17:54.44 |
| ray_laptop | mvrhel_laptop: well, I guess device parameters can be device specific | 17:55.08 |
| mvrhel_laptop | 477-03-fixed.ps | 17:55.15 |
| | for example | 17:55.18 |
| ray_laptop | but it doesn't really look optional according to pg. 237 of the PLRM | 17:56.20 |
| mvrhel_laptop | please look at the file 477-03-fixed.ps and try to run it through distiller | 17:56.43 |
| chrisl | Presumably, the simplest solution is to find the definition of "/k" and replace it with your own | 17:57.09 |
| mvrhel_laptop | ok. that makes sense | 17:57.24 |
| | well k is a standard ps definition | 17:57.40 |
| | can I replace it with my own? | 17:57.45 |
| chrisl | So, it looks like you'll need to replace k, K, g and G | 17:58.01 |
| ray_laptop | mvrhel_laptop: Note that Distiller may not have the ColorSpace resources for DeviceGray DeviceRGB and DeviceCMYK, so you may need to have those in the file as well and do the "defineresource" with them. | 17:58.19 |
| chrisl | Also note that the background is being set with an explicit "setgray" at line ~66 | 17:58.40 |
| mvrhel_laptop | maybe I should just check the background and that will make everyone happy | 17:58.57 |
| | otherwise this is going to burn up my whole day | 17:59.09 |
| ray_laptop | mvrhel_laptop: 'k' is NOT a standard PS definition. "setcmykcolor" is the standard. The procs in tiger define 'k' | 17:59.40 |
| mvrhel_laptop | ah ok | 17:59.46 |
| | alright. well is sounds like chrisl could do this in his sleep in 5 minutes... | 18:00.10 |
| | but I will give it a go | 18:00.21 |
| ray_laptop | (it's in the ProcSet:Adobe_Illustrator_1.2d1 part) | 18:00.36 |
| mvrhel_laptop | perhaps a good excercise for me | 18:00.38 |
| chrisl | Except I'm not good with CIE color spaces! If you mail me the color space definitions, I could certainly do it | 18:00.51 |
| mvrhel_laptop | ok I see it | 18:00.52 |
| | the are all in Resources/Color | 18:01.04 |
| | one for RGB, CMYK and Gray | 18:01.13 |
| | oh I see the .8 setgray too | 18:01.42 |
| ray_laptop | mvrhel_laptop: it looks like tiger is checking for a non-standard "setcmybcolor" operator, and reverting to setrgbcolor (strangely) | 18:04.03 |
| chrisl | Yeh, that looks, erm, bad...... | 18:04.24 |
| ray_laptop | chrisl: tiger predates Level 1.5 where setcmykcolor was created/added to Level 1 PS | 18:05.01 |
| Noldorin | ray_laptop, you mentioned a -c option to me the other day. it doesn't seem to exist, at least not documented... | 18:05.34 |
| chrisl | ray_laptop: sure, so why use CMYK at all? | 18:05.36 |
| ray_laptop | so that's probably Illustrator's hack for PS that is Level 1 compatible, but that Illustrator can use to retain CMYK in the file | 18:05.42 |
| | chrisl: For Illustrator to be able to use to adjust CMYK colors | 18:06.08 |
| mvrhel_laptop | ok. so I have the CIEA, CIEABC and CIEDEFG colorspaces added | 18:08.32 |
| | and defined | 18:08.39 |
| chrisl | mvrhel_laptop: so you probably want something like: /k {myDEFGcolorspace setcolorspace setcolor} bdef | 18:08.51 |
| mvrhel_laptop | ok. let me do that next. thanks | 18:09.06 |
| ray_laptop | Noldorin: -c *is* in doc/Use.htm#General_switches | 18:09.07 |
| chrisl | Where myDEFGcolorspace is the DEFG colorspace dict | 18:09.12 |
| mvrhel_laptop | right | 18:09.15 |
| Noldorin | ray_laptop, whre's that? i only know of the man page :) | 18:09.21 |
| mvrhel_laptop | right now, I have for example. | 18:09.30 |
| ray_laptop | Noldorin: in the gs/doc directory | 18:09.46 |
| chrisl | mvrhel_laptop: I suspect you only need the DEFG and A spaces | 18:09.50 |
| Noldorin | ah, cheers | 18:09.53 |
| mvrhel_laptop | chrisl. ok | 18:10.01 |
| ray_laptop | Noldorin: online you can get it from: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=tree;f=gs/doc;h=ff2e9cb783eed7b4b26938a3d3559fc132ee0388;hb=HEAD | 18:10.37 |
| | chrisl: do we even maintain man pages anymore ? | 18:11.13 |
| chrisl | ray_laptop: we've never maintained man pages, they were contributed - I apply patches when people supply them | 18:11.39 |
| ray_laptop | chrisl: sounds like we should change (at least the main man/gs.1) to refer people to doc/Readme.htm | 18:12.46 |
| | chrisl: that or deprecate them altogether. Unless thay can be automatically generated from the doc's | 18:13.58 |
| chrisl | ray_laptop: one problem is that different Linux distributions either don't necessarily include our HTML docs by default, or don't put them in consistent places, so we can't actually put a path in there | 18:14.12 |
| ray_laptop | chrisl: well, we can refer them to: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=tree;f=gs/doc;h=ff2e9cb783eed7b4b26938a3d3559fc132ee0388;hb=HEAD | 18:14.46 |
| mvrhel_laptop | hmm. I may have to throw this file to you to look at real quick chrisl | 18:15.02 |
| | hold on | 18:15.04 |
| chrisl | ray_laptop: Can't use the git version as the hyperlinks don't work | 18:15.24 |
| ray_laptop | chrisl: mvrhel_laptop really means "run away" | 18:15.33 |
| chrisl | :-) I already mentioned I'm not good with CIE color spaces! | 18:15.55 |
| mvrhel_laptop | hehe | 18:16.22 |
| ray_laptop | chrisl: you mean the hyperlinks from 'man' ? If so, so what. They can cut and paste in a browser | 18:16.25 |
| chrisl | ray_laptop: no the hyperlinks between the HTML files don't work | 18:16.48 |
| ray_laptop | oh, yuck. | 18:17.06 |
| chrisl | We could refer tohttp://www.ghostscript.com/doc/<version number>/Readme.htm | 18:17.31 |
| | like:http://www.ghostscript.com/doc/9.10/Readme.htm | 18:17.39 |
| mvrhel_laptop | http://www.ghostscript.com/~mvrhel/tiger_CIE.eps | 18:17.41 |
| ray_laptop | chrisl: we used to have the docs for the latest release on artifex.com. but ghostscript.com is just as good | 18:17.47 |
| mvrhel_laptop | chrisl: there is some dumb PS error in my feeble attempt to do this | 18:18.03 |
| | likely you will find it quickly | 18:18.10 |
| chrisl | Give me a moment | 18:18.37 |
| mvrhel_laptop | chrisl: the interiors of the CIE stuff is fine I believe. These I had done in other PS files | 18:19.13 |
| | I am likely screwing up the simple definitions | 18:19.28 |
| ray_laptop | OK. One hour without noise cancelling headphones is all I can take. Have to go someplace quiet and work :-) The sound is a lot like being on an airplane, but doesn't require a parachute to get away from :-) | 18:19.40 |
| mvrhel_laptop | oops I do see the whitepoint is wrong on the one, but that is not the issue. I will fix that later | 18:19.55 |
| ray_laptop | after 1 hour it's 45% through the first pass. | 18:20.29 |
| chrisl | mvrhel_laptop: well, it looks okay, but I get a strange undefined error..... let me have a play | 18:23.21 |
| mvrhel_laptop | ok. same as me | 18:23.30 |
| henrys | tor7:I feel like a 500.00 bounty for the 14 xps fixes from shelly, many dups and not difficult fixes, agreed? | 18:25.14 |
| mvrhel_laptop | chrisl | 18:27.46 |
| chrisl | Yep | 18:27.53 |
| mvrhel_laptop | the xdef /p commands | 18:28.13 |
| | in the /g /G /k /K defines | 18:28.28 |
| | are those missing now and causing the issue? | 18:28.35 |
| chrisl | Yeh, if you look for /f and /S and just delete the p and P calls | 18:28.58 |
| mvrhel_laptop | ok | 18:29.06 |
| chrisl | And that is drawing with your color spaces :-) | 18:30.02 |
| mvrhel_laptop | ok need to replace the setgray | 18:30.34 |
| | and fix white poing | 18:30.45 |
| | point | 18:30.47 |
| chrisl | Yeh, for this, just replace setgray with g | 18:30.54 |
| mvrhel_laptop | right. now, I need to figure out, distiller seems to convert to CMYK based color for. need to do a few adjustments | 18:34.00 |
| | hmm. the gray back ground may be a problem. tongue color certainly changed. | 18:35.53 |
| | warrants further investigation... | 18:36.33 |
| | :( | 18:36.42 |
| | thanks for helping chrisl | 18:37.34 |
| chrisl | No problem | 18:37.44 |
| mvrhel_laptop | hmm. I am not getting the dark colors with gs that marcosw is showing | 18:42.03 |
| | oh | 18:43.09 |
| | the after is correct | 18:43.17 |
| | whew | 18:43.24 |
| | the before was the dark one | 18:43.33 |
| | which is wrong | 18:43.35 |
| | we are dead on with the background now | 18:43.52 |
| | Robin_Watts: so all is well I believe | 18:44.09 |
| | I will reply to marcosw about the tiger image | 18:44.48 |
| tor7 | henrys: yes. | 18:47.13 |
| henrys | tor7:thanks | 18:48.49 |
| mvrhel_laptop | ok. now I can put CIE color behind me for at least a bit until I tackle ken's needs. | 18:48.50 |
| mllie | Hello | 18:50.45 |
| ghostbot | hey, mllie | 18:50.46 |
| mllie | How can I see if ghostscript is installed? | 18:51.01 |
| Noldorin | mllie, gs -v | 18:58.58 |
| | from thecommand lien | 18:59.00 |
| | command line* | 18:59.04 |
| mvrhel_laptop | Robin_Watts: you still around? | 20:41.36 |
| | I know it is a bit later there | 20:42.39 |
| | s/later/late/ | 20:42.45 |
| | Robin_Watts: for the logs, so based upon what I am seeing, 691182 may be good for you to look at | 21:01.27 |
| | essentially the type 3 image with interpolation is the problem. the mask is getting handled by the image_simple_expand renderer and the image is getting interpolated | 21:02.33 |
| | bbiaw | 21:02.42 |
| Noldorin | does ghostscript have the ability to loop over an array? | 21:14.24 |
| Robin_Watts | mvrhel_laptop: OK. Will look tomorrow. | 23:02.27 |
| | I may just disable interpolation in the case where there is a paired mask. | 23:03.04 |
| | Forward 1 day (to 2013/09/17)>>> | |
IRC Logs