| <<<Back 1 day (to 2011/07/20) | 2011/07/21 |
mvrhel2 | damn compile_inits = 0 doesnt seem to work | 00:14.56 |
| sign | 00:15.00 |
| I will try on windows | 00:17.41 |
| ok. so it is yet again my fix that breaks compile_inits = 0 . This really should be tested on the clusterpush and put at the top of the report along with the new warnings | 04:02.29 |
| I only happened to catch it to do some testing for ray's recent commit | 04:03.15 |
henrys | it seems like having the hardwired default of ROM0 causes problems I wonder if the search were the same in both configurations if you wouldn't catch the problems in the rom0 build. | 04:08.20 |
| but yes we should test it. | 04:08.50 |
| I'll work on the x11cmyk problem I just assigned to you I assume you won't object (unix and all) ;-) | 04:12.24 |
mvrhel2 | henrys: ok thanks. | 05:18.29 |
| ok got the inits issue fixed. now I am going to do a clusterpush of the gray to K fix | 05:20.35 |
ray_laptop | interesting. Some new guy at HP (presumably in india) doesn't realize that the gs-bugs mailing list isn't private and sent a user ID and password :-/ Maybe one of us should tell them ?? | 06:32.51 |
kens | chrisl I think I have an example fo the WMode problem you fixed yesterday, but in a PostScript file this time. | 07:49.47 |
chrisl | kens: It really shouldn't be the same problem. | 07:52.06 |
kens | Well, I think I'll let you decide :-) | 07:52.20 |
chrisl | Okay, punt it over....... | 07:52.47 |
kens | The file has text which is displayed in one direction, but when convrted to PDF with Distiller, the selection runs at 90 degrees, just like yesterdays PDF file. | 07:52.49 |
| When I look in the file it has a CMap with WMode 1 | 07:53.01 |
| Its the problem from Peter this morning, sent to support. | 07:53.15 |
chrisl | Okay, let me have a quick look | 07:54.03 |
kens | Ian sent me this link this morning: | 07:56.05 |
| http://uk.reuters.com/video/2011/07/20/no-parking-especially-when-a-manhole-eru?videoId=217290140&videoChannel=77 | 07:56.06 |
chrisl | That outs one of our burst water mains into perspective! | 08:08.32 |
| s/outs/puts | 08:08.39 |
kens | There's also an amusing 'dog bites shark' video on there | 08:08.55 |
chrisl | kens: I don't understand what's going on with the file from Peter - we're *not* losing the WMode value from the Postscript, it is correctly set in the PDF, but the character spacing isn't correct. | 08:11.07 |
kens | You don't need to go to pdfwrite, you can see the sme result when rendering | 08:11.31 |
chrisl | I am. I've also just discovered that if I set the WModes in the PS files all to "0", the file renders "correctly". | 08:12.39 |
kens | That's bizarre. | 08:12.52 |
| I didn't try that, I just assumed that it was the same problem | 08:13.06 |
| When I saw the WMode 1 | 08:13.13 |
chrisl | I'm just about to check what Distiller makes of the file with WMode all zeros | 08:14.05 |
kens | Good idea! | 08:14.17 |
chrisl | But I'm having to reboot my VM..... | 08:14.25 |
kens | Hmm, the file isn't *that* comlicated.... ;-) | 08:14.41 |
chrisl | No, but Vista in a VM is *that* dumb! | 08:16.22 |
| Strange, changing the WMode in the file makes *no* discernible difference rendering with Jaws | 08:17.52 |
kens | Now that is indeed interesting. Suggest that I'm barking up the wrong tree with the WMode | 08:18.18 |
chrisl | Hmm, I think we are using the *wrong* CMap - I think we end up using the "-V" CMap, instead of the "-H" one | 08:20.00 |
kens | Hmm, can't think how that happens. | 08:22.49 |
chrisl | No, I can't either | 08:23.45 |
| Hmmm, Windows didn't reboot, it shutdown..... | 08:24.29 |
kens | I think I'm going to get cross with Rahul Sabnis soon. | 08:27.11 |
chrisl | Who be he, then? | 08:27.47 |
kens | The idiot complaining that they get a broken PDF file after they mail it, and so it must be a Ghostscript bug. | 08:28.08 |
| #692363 | 08:28.23 |
| Actually, since he's said it publicly, he's from HP, probably in India. | 08:28.45 |
| The Daziel buffoons I expect | 08:28.56 |
| Assuming they are even a commercial customer at all | 08:29.12 |
chrisl | Ah, yes, not being too bright! | 08:29.36 |
| kens: that document(s)PS.ps: changing the WModes makes no apparent difference in either Jaws or Distiller, but one way GS works, and the other it doesn't - colour me confused! | 08:36.26 |
kens | That's weird. Not least that changing the WMode makes no difference to other interpreters | 08:37.03 |
| That suggests its not being used by Jaws/Distiller, but is (apparently incorrectly) by GS. | 08:37.24 |
chrisl | yeh, but that doesn't make much sense either :-( | 08:38.32 |
kens | No it certainly doesn't | 08:38.41 |
| I'll open a bug report for it and get back to the customer | 08:45.08 |
| OK chrisl #692365, I've assigned it to you. For somre reason I still seem tobe getting 'text' bugs. | 09:16.50 |
chrisl | Oh, gee thanks! Cutting that file down is going to be a pain :-( | 09:18.06 |
kens | I know, sorry about that, but I think it si your area. | 09:18.23 |
chrisl | I think I'm going to stay away from customer contact whenever possible........ | 09:24.30 |
kens | I'd advise it I have to say. | 09:24.43 |
| Curisouly the HP people haven't come back since I asked if they were a commercial customer. | 09:25.15 |
chrisl | I'm sure they will come back, and even more indignant than before! | 09:26.01 |
| And, to make the day complete, my parents' car won't start, so I have to go over in a while and help get it running. | 09:26.14 |
kens | Oh joy :-( | 09:26.22 |
chrisl | I'm glad I bought that batter booster! | 09:26.48 |
| s/batter/battery | 09:26.54 |
kens | "Mmm, batter booster" says Homer. | 09:27.15 |
chrisl | It must be that Scottish heritage coming to the surface....... :-) | 09:27.48 |
| Right, I'm off to try to get an MX-5 to run - not sure when I'll be back....... | 10:18.57 |
nitin | Hi, i tried to compile the mupdf source but it is giving me this error.... LINK build/debug/mupdf build/debug/x11_main.o: In function `winopen': /cygdrive/d/mupdf/apps/x11_main.c:123: undefined reference to `_XOpenDisplay' /cygdrive/d/mupdf/apps/x11_main.c:127: undefined reference to `_XInternAtom' | 10:25.40 |
| please help | 10:25.54 |
kens | Looks like you don't have X11 installed. | 10:26.20 |
nitin | oh... i am using cygwin | 10:26.52 |
kens | Does cygwin support X11 ? | 10:27.10 |
nitin | so in my case, do i need to install x11 for cygwin | 10:27.18 |
kens | I don't use cygwin so I can't really be sure. | 10:27.40 |
| But the error is in X11_main, and is an undefined reference to _XInternAtoim so I would say it needs something to support X11 | 10:28.11 |
nitin | ok..thanks for the clue | 10:28.49 |
| i try to get x11 support in cygwin then will get back to this channel | 10:29.16 |
kens | tor or Robin might be able to help better than me | 10:29.29 |
nitin | since tor is not available right now... i am waiting... thanks for ur suggestion Kens | 10:30.21 |
Robin_Watts | nitin: Hi. | 10:48.22 |
| This is presumably so you can get the generated directory? | 10:48.43 |
nitin | Hi Robin | 10:50.46 |
| i do get the genarated directory but when i am running ndk-build them it is giving me some error...part of it was pasted above | 10:53.01 |
Robin_Watts | I can't see any errors pasted above that would have come from the ndk-build. | 10:53.41 |
nitin | i closed the window... i'll repost it | 10:54.26 |
| $ make -f makefile LINK build/debug/mupdf build/debug/x11_main.o: In function `winopen': /cygdrive/d/mupdf/apps/x11_main.c:123: undefined reference to `_XOpenDisplay' | 11:16.08 |
| when i am trying to compile the mupdf source, above error (it is just a part of the whole) comes... | 11:16.56 |
Robin_Watts | I don't see how that can be part of the ndk-build errors. | 11:19.51 |
| Are you following the steps in ReadMe.txt in the android directory ? | 11:20.28 |
nitin | yes... | 11:29.37 |
| it is the step 9, where i am getting this error | 11:30.35 |
| i tried to compile the mupdf source using cygwin | 11:30.59 |
Robin_Watts | 9) Change into the android directory, and edit local.properties into your | 11:32.28 |
| favourite editor. Change the sdk path there as appropriate. This should be | 11:32.30 |
| the only bit of localisation you need to do. | 11:32.32 |
| ? | 11:32.35 |
nitin | i am trying to compile and then that error came up...though now, i have these headers availabe in generated directory - cmap_cns.h, cmap_gb.h, cmap_japan.h, cmap_korea.h, font_base14.h, font_cjk.h, font_droid.h | 11:34.04 |
Robin_Watts | nitin: I am concerned that your step 9 may not be the same as mine. | 11:34.30 |
| And as such therefore you may be using an old version. | 11:34.40 |
nitin | it is same | 11:34.44 |
Robin_Watts | So how can you be getting that error in step 9? Do you mean step 8 or step 10 ? | 11:35.10 |
nitin | but as what tor8 suggested me to compile the mupdf source in order to get the generated directory files since it is not available for download | 11:35.50 |
| this error came up only when i tried to compile the source | 11:36.20 |
Robin_Watts | Right. That should be step 8. | 11:36.39 |
nitin | yes... | 11:36.46 |
Robin_Watts | If you've got the generated directory (and it sounds like you have) then ignore the errors and move on to step 9. | 11:36.58 |
nitin | $ make -f makefile LINK build/debug/mupdf build/debug/x11_main.o: In function `winopen': /cygdrive/d/mupdf/apps/x11_main.c:123: undefined reference to `_XOpenDisplay' /cygdrive/d/mupdf/apps/x11_main.c:127: undefined reference to `_XInternAtom' /cygdrive/d/mupdf/apps/x11_main.c:128: undefined reference to `_XInternAtom' /cygdrive/d/mupdf/apps/x11_main.c:129: undefined reference to `_XInternAtom' /cygdrive/d/mupdf/apps/x11_main. | 11:37.16 |
| am i doing anything wrong here????? | 11:37.45 |
Robin_Watts | 9) Change into the android directory, and edit local.properties into your | 11:38.03 |
| favourite editor. Change the sdk path there as appropriate. This should be | 11:38.05 |
| the only bit of localisation you need to do. | 11:38.07 |
| ok, no possibility for errors there. | 11:38.19 |
| 10) Change into the android directory (note, the android directory, NOT | 11:38.31 |
| the android/jni directory!), and execute (in a Cygwin window on Windows!): | 11:38.34 |
| ndk-build | 11:38.35 |
nitin | ok.... so i don't need to worry about these errors..right | 11:38.36 |
| ok... | 11:38.43 |
| thanks | 11:38.46 |
| ok.. i am moving on to step 9 now then....wish i donn find enough errors | 11:39.59 |
| Compile thumb : mupdfthirdparty <= jbig2.c | 11:46.48 |
| In file included from D:/mupdf/android/jni/../../thirdparty/jbig2dec/os_types.h:53, | 11:46.56 |
| from D:/mupdf/android/jni/../../thirdparty/jbig2dec/jbig2.c:22: | 11:47.08 |
| D:/android-ndk/platforms/android-8/arch-arm/usr/include/stdint.h:48: error: redefinition of typedef 'int8_t' | 11:47.23 |
| D:/mupdf/android/jni/../../thirdparty/jbig2dec/os_types.h:47: note: previous declaration of 'int8_t' was here | 11:47.39 |
| now when i am performing step 9... i am getting those errors | 11:49.16 |
Robin_Watts | step 10, but never mind :/ | 11:49.37 |
| Let me look. | 11:49.43 |
nitin | yes step 10... | 11:50.21 |
Robin_Watts | What version of the ndk are you using ? | 11:52.09 |
nitin | Android NDK, Revision 5c (June 2011) | 11:53.46 |
Robin_Watts | ok, that's the same version I have here. | 11:53.59 |
nitin | good for me | 11:54.54 |
Robin_Watts | trying a clean build now. | 11:55.12 |
| ok, that worked. | 12:00.00 |
| I wonder if I have uncommitted changes in thirdparty. | 12:00.11 |
nitin | if it has worked for you....then what i need to do here to get it right???? | 12:01.45 |
Robin_Watts | right. Load thirdparty/jbig2dec/os_types.h into an editor | 12:03.11 |
| Then change line 43 from: #else to #elif !defined(HAVE_STDINT_H) | 12:03.51 |
nitin | great... | 12:05.53 |
| i made the change | 12:06.03 |
Robin_Watts | That should solve it. I'll try and get that pushed back into the original repo. Sorry about that. | 12:06.06 |
nitin | no sorry... you helped me here... | 12:06.34 |
Robin_Watts | chrisl: We should look into photoshop group licenses. | 12:07.59 |
nitin | Robin_Watts: It worked for me.... THANKS A LOT | 12:10.37 |
Robin_Watts | nitin: Fab. | 12:10.46 |
| actually, has anyone used photoshop elements? Is that going to be too crippled for what we want ? | 12:11.43 |
| 53 quid seems a much saner price to pay. | 12:12.05 |
kens | Hmm, SaGS has a bug report with the ICC profiles 'fix'. | 13:11.32 |
| ray_laptop : ? | 13:27.43 |
Robin_Watts | Right. Unicode crap... | 13:51.42 |
| ray made the interesting observation that the title bar on the Ghostscript Image window is OK. I might have a quick look at that... | 13:53.20 |
kens | Odd | 13:53.37 |
henrys | kens:I don't think we give customers the number - I might be mistaken but we always just ask if they are customers. | 14:32.35 |
kens | Oh, OK, do you know i they are ? | 14:32.49 |
henrys | no I do not | 14:33.02 |
kens | I was guessing they were the same Indian bunch as usual ;-) | 14:33.14 |
| But maybe not.... | 14:33.20 |
| In which case, maybe we should check how htey are using GS >:-) | 14:33.45 |
henrys | I know there was a recent "cloud" customer that sounds like a possibility didn't seem like the Indian bunch. | 14:33.46 |
kens | I looked up the product, its a document converter thing. | 14:34.05 |
| But that odesn't really narrow it down any. | 14:34.27 |
| Its been a busy day on support :-( | 14:34.41 |
| I think we have two new blockers for release. | 14:34.49 |
henrys | regressions? | 14:35.00 |
kens | Yes. | 14:35.05 |
| SaGS's patch for the icc profiles fix. | 14:35.16 |
| And 128-bit AES seems to have stopped working (decryption) | 14:35.29 |
| reports from 2 different customers (but both referencing the file from one of our bug reports) | 14:35.54 |
henrys | haven't finished my mail yet just got through the knuckleheads' message | 14:36.14 |
kens | :-) | 14:36.26 |
henrys | kens those two customers work together. | 14:40.37 |
kens | Ah! | 14:40.44 |
flemic | hello | 14:51.54 |
| somebody there? | 14:52.16 |
kens | Yes, severl somebodys | 14:52.30 |
flemic | hi, a have a problem. is it possible to read box informations of a pdf file with ghostscript? | 14:53.36 |
| just dump the informations...!? | 14:53.52 |
kens | Yes. | 14:54.16 |
flemic | trimbox, mediabox etc | 14:54.20 |
kens | I thnk pdf_info.ps does htis | 14:54.23 |
flemic | ok, thank! I will check that | 14:55.55 |
kens | Seems it dumps MEdiaBox and CropBox, I have no doubt it can be extended to do the tohers. | 14:56.37 |
| others | 14:56.47 |
henrys | besides aes what is the other blocker? | 14:57.40 |
kens | The crash that SaGS has. | 14:57.50 |
| I'll find the number | 14:57.55 |
| #692367 | 14:58.09 |
| I htink a customer also has found this but reported it differntly | 14:58.21 |
| Yes, Jasper. He says he gets a crash when repeatedly zooming in GSView. I expect its the same problem. | 14:59.30 |
| It certainly sounds the same. | 15:00.08 |
henrys | I wonder is the memory pointed to should be in local vm. | 15:00.27 |
kens | Ummm, pass..... | 15:00.38 |
| I haven't actuallu examined hte problems | 15:00.47 |
| I di dlook at Peter's text problem because it was reported against pdfwrite | 15:02.04 |
| Then wished it off to chris | 15:02.26 |
henrys | I can't imagine the customer is using gsview in a commercial capacity. | 15:10.01 |
kens | No I guess not :-) | 15:10.12 |
| I did see another repot with an intermittent crash which might be related. | 15:10.23 |
| Was from Thomas, cc'ed to Jasper. | 15:11.32 |
| Got bounced the first tiem and they retried the mail to support without the images attached. | 15:11.50 |
| No, that's a red herring, sorry. | 15:12.10 |
| But if I understand SaGS correctly, and use of GS which doesn't cloe the app and restart between jobs oculd have the same problem. | 15:12.48 |
henrys | I thought Robin_Watts cleared lib_ctx | 15:18.17 |
kens | No idea. | 15:18.48 |
Robin_Watts | ? | 15:19.30 |
kens | SaGS's bug report and proposed patch | 15:19.53 |
| #692367 I think | 15:20.21 |
tkamppeter | Robin_Watts, hi | 15:43.50 |
Robin_Watts | tkamppeter: Ah, hi. | 15:43.57 |
| I was hoping to talk to you. | 15:44.02 |
| I committed changes that should make stars.pdf a bit more bearable. | 15:44.23 |
tkamppeter | Robin_Watts, how important is interpolation for printing, as printing is always a rendering with high resolutions, at least 300 dpi. | 15:44.42 |
Robin_Watts | The cluster reported differences in various test files on the cups device, but when I run them locally, I get identical results before and after my change. | 15:45.19 |
tkamppeter | Can I use always -dNOINTERPOLATE or do I get a visibly lower print quality then? | 15:45.40 |
Robin_Watts | If you look at the stars.pdf file, the 'shadings' you see behind each of the stars (the shadows) are given by a bitmap. | 15:46.02 |
| If you render the file twice, once with and once without interpolation, and compare them, you'll see a noticable stepping in the shading. | 15:46.35 |
| For stars.pdf there is a visible degradation in quality. | 15:47.01 |
tkamppeter | Robin_Watts, so I will leave interpolation in place. | 15:47.21 |
henrys | tkamppeter:can you tell us how does the quality compare to poppler? | 15:47.47 |
Robin_Watts | I *may* be able to find a bit more speed by tweaking the pattern bboxes used when tiling, but I don't want to promise that a) there is an improvement still be to found, or b) that I will find it in time for release. | 15:48.17 |
| Anyone around with access to a Windows 7 box ? | 15:50.34 |
henrys | if ray_laptop isn't around I'll start up my vm. | 15:51.40 |
tkamppeter | henrys, I will try. | 15:51.52 |
Robin_Watts | http://ghostscript.com/~robin/0001-Fix-Bug-692355.patch | 15:52.09 |
| That should, I hope, fix the windows title bar problems. | 15:52.21 |
| I've tested it out on windows XP Pro 32bit here, and I can enter unicode chars, copy/paste them, and it all seems to do the right thing (and the titles on the windows are right, including when you close the window and it changes the title to include " - closing" momentarily) | 15:53.17 |
henrys | w6bullfrogs | 16:00.32 |
| well there's a password I won't use again. | 16:00.54 |
mvrhel2 | oh looks like it is going to be a busy day | 16:10.17 |
| I wonder what broke with respect to writing out to CIELAB color space. | 16:10.42 |
kens | Time for me to go, goodnight everyone, I may be back later. | 16:13.36 |
henrys | Robin_Watts:works for me but wasn't broken before the patch. | 16:25.49 |
Robin_Watts | henrys: You have a windows 7 machine and it worked ? | 16:26.09 |
| I mean it used to work ? | 16:26.24 |
henrys | correct | 16:26.26 |
Robin_Watts | then that's very strange. | 16:26.34 |
henrys | both work | 16:26.37 |
Robin_Watts | I guess I'll wait for ray. | 16:27.02 |
henrys | is ray_laptop the onyl 7 machine to produce this? | 16:27.04 |
Robin_Watts | I thought it was ray + at least one other person. | 16:27.22 |
marcosw_ | henrys: do we need a support meeting this week? | 16:35.48 |
henrys | if you can just scrub support and your list I think that will be fine but I'm available. | 16:36.56 |
marcosw_ | I'll go through my bugs and the support list later today. | 16:37.43 |
henrys | marcosw_:I would like to ask folks to leave support to you and focus on projects and bugs - but I'm not sure how you would feel about that. Do you think there is too much for one person? | 16:38.17 |
mvrhel2 | ok I see what the issue is with 692364. This is not a new issue but has existed for some time | 16:38.48 |
| the problem is that the graphic state is initialized with DeviceGray. Then we initialize the icc manager. And then we start drawing. Unfortunately, the color spaces in the graphic state are still DeviceGray and not ICC due to the fact that no other color spaces were set (and hence installed and converted over to ICC). So when we try to go to CIELAB as the target, gray maps to something weird | 16:40.19 |
Robin_Watts | mvrhel2: I've never understood why we don't initialise the icc manager before anything else. | 16:41.08 |
| (I'm sure there is a good reason) | 16:41.15 |
mvrhel2 | If I had control of the interpreter I would | 16:41.18 |
| It would be the first thing I would do after getting the icc_dir set up | 16:41.37 |
Robin_Watts | What causes the icc manager to be setup ? | 16:41.44 |
| is it a call in the PS initialisation files or something ? | 16:41.58 |
marcosw_ | henrys: The support load varies widely over time but usually I have no trouble keeping up. I'd rather folks left support to me, unless I find myself falling behind and ask for help. | 16:42.03 |
mvrhel2 | set user params usually triggers it | 16:42.11 |
henrys | marcosw_:okay thanks | 16:42.25 |
Robin_Watts | Is there a reason it has to be done then? Can't we just hardwire a call in earlier? | 16:42.36 |
mvrhel2 | since the values that it needs can be set as a user param | 16:42.41 |
Robin_Watts | Ah! ok. | 16:42.49 |
mvrhel2 | unfortunately, I am at the mercy of order in which things are done in the interpreter. What I should do is this. | 16:43.24 |
Robin_Watts | Is it possible to start the icc manager up without those user params ? | 16:43.38 |
mvrhel2 | When the ICC manager IS set up, I should inspect the graphic state and fix the existing color spaces in it if they are DeviceGray | 16:43.55 |
Robin_Watts | shuts up and waits for mvrhel2 to talk | 16:43.55 |
| mvrhel2: That sounds a bit nasty to me. | 16:44.14 |
mvrhel2 | I think that makes the most sense | 16:44.14 |
Robin_Watts | Because it relies on you being able to check all the extant color spaces. | 16:44.44 |
mvrhel2 | it is relatively minor. Simply populating a member variable int the colorspace | 16:44.45 |
| ? | 16:44.54 |
Robin_Watts | Could I suggest an alternative? | 16:45.00 |
mvrhel2 | why is it nasty? the initialization occurs once | 16:45.12 |
| part of the initialization is to make sure that the pgs start up color spaces are also set properly | 16:45.33 |
| the DeviceGray color spaces in there are basically place holders | 16:45.50 |
Robin_Watts | Right, but when the initialisation happens you have to look at the graphics state and check to see if the color spaces are correctly set up, and if not, retrospectively fix them. | 16:46.01 |
| What if there are other color spaces around that you can't get to through the state? | 16:46.23 |
| (like say it's a nested state) | 16:46.31 |
| (That may not be possible now, but who knows what will happen in future). | 16:46.54 |
mvrhel2 | ok. I suppose. I don't see how else to do this though | 16:47.27 |
Robin_Watts | Would it be possible to do something where the 'default' states are REALLY just placeholders? | 16:47.31 |
| s/states/colorspaces/ | 16:47.44 |
mvrhel2 | I suppose we could initialize to something different | 16:48.08 |
Robin_Watts | and when we meet them during execution fetch the defaults from the icc_manager? | 16:48.15 |
mvrhel2 | and then if we end up in the remap of that thing, install the proper object | 16:48.19 |
| but I don't see really much difference | 16:48.54 |
Robin_Watts | What you just described sounds nicer than what I had in mind actually. | 16:49.23 |
| So you initialise with a colorspace that when remapped replaces itself with the current default ? | 16:49.53 |
| The difference in subtle, but it's there. | 16:51.01 |
mvrhel2 | This of course would involve the breaking of a const but since when has that stopped me | 16:51.05 |
Robin_Watts | s/in/is/ | 16:51.08 |
| Currently we intialise with something that's wrong, and rely on being able to "fix it up" later. | 16:51.40 |
| (and if we ever fail to fix something up, we'll have problems). | 16:51.52 |
mvrhel2 | well technically here is the deal. DeviceGray is supposed to be the colorspace if nothing else is explicitly set in the document | 16:52.20 |
Robin_Watts | With the new scheme, we initialise with something that says "fix me", and whenever we hit such a thing, we fix it automatically using the same mechanisms that have been in gs for donkeys years. | 16:52.33 |
mvrhel2 | the issue is that we have not gotten our DeviceGray color space in the graphic state completely set up as we want it since we dont have everything available when we intialize | 16:53.01 |
| this is why I was thinking of just doing it when we do have everything | 16:53.11 |
| which occurs when we initialize the icc manager | 16:53.25 |
Robin_Watts | Right, but do you see the difference I'm trying to highlight ? | 16:53.40 |
mvrhel2 | yes. I see the difference. | 16:54.12 |
| The nice way is a bit more work since I need to introduce a new color space but that is not the end of the world | 16:54.55 |
| I do like it in that it is clean and clear | 16:55.30 |
| I do feel like the clock is ticking on this though | 16:55.55 |
Robin_Watts | Yes. I'd hope it would be easier for future generations of ghostscript coders to understand :) | 16:56.13 |
mvrhel2 | anyone else have an opinion before I embark on this? henrys? | 16:56.51 |
Robin_Watts | I've made my case, so I'll leave it to you, as you have a much better idea of how much work it is. | 16:56.55 |
| mvrhel2: If the 'quick and nasty' fix is indeed quick, then maybe do that first? | 16:57.13 |
mvrhel2 | that is what I am thinking | 16:57.21 |
| especially since it is a customer issue and they may want a patch for 9.03 | 16:57.36 |
| giving them a patch that adds in a new color space may be tricky | 16:57.49 |
henrys | well the graphics state is gray because the nulldevice is installed right? | 16:58.24 |
mvrhel2 | well gray is fine. but when we start doing fill page etc, it should be ICC based | 16:58.54 |
| so that we can, as in this case of going to CIELAB as an output device color, map the fill page to CIELAB = [100,0 0] | 16:59.21 |
Robin_Watts | mvrhel2: I committed the dirty bbox changes. | 16:59.46 |
mvrhel2 | great | 16:59.51 |
| DeviceGray is the default color space if nothing else has been set in the document. | 17:00.16 |
| this is true for all devices | 17:00.21 |
| default source color space | 17:00.35 |
Robin_Watts | And I have (I think) a fix for the unicode windows stuff. So until tkamppeter finds that I broke a load of stuff, I have nothing on the critical path for the release. | 17:00.45 |
| Let me know if there is anything you'd like to offload to me. | 17:00.55 |
henrys | or right I'm thinking of the color model sorry | 17:00.58 |
mvrhel2 | np. so what happens now, is that we map the DeviceGray of the fill page to RGB using the old procs | 17:01.24 |
| so it goes to 255, 255 255 | 17:01.33 |
| which is a very saturated RED in CIELAB | 17:01.42 |
henrys | okay so you need the device icc profile set? | 17:02.24 |
mvrhel2 | well it is set in when we do the fill page | 17:02.41 |
| and the manager is all set too | 17:02.48 |
| the issue is that the graphic state has DeviceGray color spaces set | 17:03.01 |
| not ICC color spaces | 17:03.05 |
| they are left over from the init of the graphic state | 17:03.27 |
| For a quick fix, I was going to "fix" the color spaces in the graphic state, when the ICC manager is initialized | 17:03.53 |
| this assumes that we don't do any fills and drawings before the manager is initialized. | 17:04.13 |
| I hope that never happens (I am wondering if it can happen) | 17:04.25 |
| this is where the interpreter start up code becomes involved | 17:04.54 |
| as there would be nothing that I could do in the C code to fix that one | 17:05.25 |
| let me try that fix real quick | 17:06.35 |
henrys | I think the output icc profile has to be set in gs_init.ps under /setdevice - for the same reason the halftone has to be set there. | 17:09.07 |
| I guess I should be testing this stuff in the other languages. | 17:10.35 |
mvrhel2 | As I mentioned once, I would like to make a stress test for testing all these ICC options | 17:13.06 |
| it could be done on just a handful of files | 17:13.19 |
| and run during the clusterpush | 17:13.32 |
henrys | mvrhel2:see the erasepage in /setdevice - I think that is where the problem is - probably later it would be okay. | 17:14.01 |
mvrhel2 | well it wont be ok if the DeviceGray colorspace in the pgs stays the same | 17:14.46 |
| if we never encountered another color space in the document, then those color spaces would remain | 17:15.10 |
| and we would use the old procs, and basically ignore the ICC settings | 17:15.25 |
henrys | from what you are saying DeviceGray should never be put in in the first place if you want ICC to be the default. | 17:17.15 |
tkamppeter | Robin_Watts, I have built the current GS now and for me stars.pdf needs 15 minutes in standard mode. | 17:19.25 |
Robin_Watts | tkamppeter: And gives the right result at the end? | 17:19.48 |
| That sounds like progress to me. | 17:19.57 |
| How does that compare to poppler etc ? | 17:20.09 |
| henrys: Right. That was my argument. Michael suggested a scheme whereby we install a "placeholder" colorspace (call it "DefaultGray" or something?). When that actually gets used, its remap function will be called, and it can replace itself with the current default from the icc manager. | 17:21.57 |
tkamppeter | Robin_Watts, 1:15 min with -dNOINTERPOLATE | 17:22.00 |
mvrhel2 | henrys: well yes. the problem is that when we initialize the graphic state, we have to put something in for the color spaces so we start out with DeviceGray, since that is the Default if nothing else is set in the document | 17:22.24 |
| we can't put in an ICC color space yet, as we dont even have an ICC manager at this time | 17:22.44 |
| that comes after, and then we still need to set it up, which relies upon the user parameters since it is configurable from the user params | 17:23.13 |
henrys | what does the manager depend on for initialization? | 17:24.00 |
mvrhel2 | it needs the default icc profiles to use for the source colors | 17:24.17 |
henrys | well it must need the memory manager | 17:25.14 |
mvrhel2 | someone on the command line could set a -sDefaultGrayProfile="my_gray_source_profile.icc" | 17:25.31 |
henrys | set it up in gs_lib_init1 | 17:25.33 |
mvrhel2 | it does need the memory manager | 17:25.44 |
tkamppeter | Robin_Watts, the output is correct (6 stars) and quality-wise (seeing the files highly magnified "pixel-peeping") I do not see a difference, which would make me tend more to introduce -dNOINTERPOLATE by default. | 17:26.26 |
mvrhel2 | but it is a member variable of the graphic state | 17:26.35 |
| it has to be set up though through the user parameter settings | 17:26.58 |
Robin_Watts | tkampeter: seeing the output files 1:1 at 720dpi, I could clearly see the difference. | 17:27.14 |
mvrhel2 | that I hope is done before we actually do any fill pages etc | 17:27.20 |
Robin_Watts | tkamppeter: But this isn't a typical file. I could probably find you much smaller simpler files that would look much worse without interpolation. | 17:28.26 |
henrys | mvrhel2:well then gs_initgraphics right? | 17:29.03 |
| oh there is an NB above about that. | 17:29.46 |
mvrhel2 | so normally in gs_setcolorspace_only we install the color space | 17:31.03 |
| if there is a change in the color space id | 17:31.11 |
| this is when we do the conversion of the DeviceRGB, DeviceGray DeviceCMYK to an ICC color space | 17:31.41 |
| the thing that occurs is that we never really "install" the DeviceGray color space that we stuck in the graphic state | 17:32.17 |
| of course we can't really do that until the icc manager is set up | 17:32.35 |
| and that can't occur until we have the user parameters all set | 17:32.43 |
henrys | tell me again why you can't install icc gray on gsstate.c:256? | 17:33.10 |
mvrhel2 | ok. so in gs_imager_state_initialize the icc manager is allocate | 17:33.48 |
| line 234 | 17:33.56 |
| but we dont have the user parameters yet to fill it in | 17:34.10 |
tkamppeter | Robin_Watts, can you give me a good example file to test this? | 17:34.19 |
mvrhel2 | all the member variables are NULL | 17:34.27 |
Robin_Watts | tkamppeter: I'll try and create one. | 17:34.39 |
mvrhel2 | so we can't assign an ICC profile to the Gray color space at line 256 | 17:34.52 |
| so, in this sense, DeviceGray is a placeholder | 17:35.17 |
| I could actually take care of this problem when we go to the remap proc for DeviceGray | 17:35.42 |
| Robin_Watts; that would not really be any different than adding a new color space | 17:36.06 |
Robin_Watts | mvrhel2: That sounds nice. | 17:36.21 |
henrys | mvrhel2:are we getting the erasepage before user settings? | 17:36.39 |
| that in itself doesn't make sense for other reasons. | 17:36.56 |
mvrhel2 | henrys: that is a concern. | 17:37.22 |
henrys | I wonder if all this goes away if we just put off that erasepage in setdevice until after user settings. | 17:38.01 |
mvrhel2 | well we still need to fix the DeviceGray color spaces in the graphic state | 17:38.18 |
| those will still be wrong | 17:38.23 |
| let me fix that in the remap of the DeviceGray | 17:38.41 |
henrys | I thought the user settiings would fix that? | 17:38.44 |
mvrhel2 | no. we still will have the issue that the graphic state was initialized by DeviceGray | 17:39.07 |
| and we can't set it to ICC at that time | 17:39.14 |
henrys | the code just execute the default setting implicitly. | 17:39.15 |
mvrhel2 | yes. | 17:39.20 |
| unless it encounters a setrgb | 17:39.29 |
| or something | 17:39.31 |
henrys | we need alexcher here. | 17:39.57 |
mvrhel2 | there is the open question of are there any erase pages etc that occur before we set the user parameters | 17:40.27 |
| in this particular file from the customer, the user parameters have all been set before the fillpage occurs | 17:42.33 |
tkamppeter | henrys, Robin_Watts, the output quality of Poppler and Ghostscript are more or less the same. Poppler is somewhat faster on stars.pdf than GS with -dNOINTERPOLATE. Poppler: 48 sec, GS: 1:15 min. | 17:42.42 |
henrys | so you are saying in the languages we should never see Device* color space in the graphics state when rendering is that correct? | 17:42.49 |
mvrhel2 | so it is possible for me to fix the problem in gs_remap_DeviceGray | 17:42.50 |
| that is correct | 17:42.56 |
Robin_Watts | If the ICC manager isn't setup when you try to remap, then don't swap out and live with the gray ? | 17:43.10 |
mvrhel2 | can't do that | 17:43.22 |
| if the destination is CIELAB | 17:43.33 |
| you get the nice red background as output | 17:43.44 |
Robin_Watts | That way if we never initialise the icc manager we get the old standard way of working? oh. | 17:43.45 |
mvrhel2 | if I was going to an RGB output color we would be OK with that approach | 17:44.12 |
| let me fix this in gs_remap_DeviceGray | 17:44.57 |
| gx_remap_DeviceGray I mean | 17:45.11 |
alexcher | here | 17:45.14 |
mvrhel2 | alexcher, is it possible that an erasepage can occur in the intitialization before the user parameters are set | 17:45.43 |
| I am hoping the answer is no | 17:46.03 |
alexcher | mvrhel2: Yes, it occures quite early in the initialization process. | 17:46.26 |
mvrhel2 | how can you do a drawing operation before you know what color space you are drawing? | 17:46.55 |
Robin_Watts | tkamppeter: http://ghostscript.com/~robin/blob3.pdf | 17:47.05 |
mvrhel2 | There must be another one that occurs after the user parameters are set then | 17:47.12 |
Robin_Watts | render that with and without interpolation, and you'll see why interpolation is important. | 17:47.50 |
mvrhel2 | Robin_Watts: your link does not work | 17:48.13 |
Robin_Watts | ahem. Try again now. | 17:48.28 |
| sorry. | 17:48.30 |
alexcher | mvrhel2: gs creates a device, sets device parameters, makes it a current device, and does erasepage. | 17:48.31 |
| mvrhel2: user and system parameter change may happen at a wrong moment. | 17:49.47 |
mvrhel2 | and at that time the user parameters are not necessarily set? | 17:49.56 |
alexcher | mvrhel2: User and system parameters are Level 2 features but device is initialized on level 1. | 17:51.02 |
tkamppeter | Robin_Watts, get yourself a new camera 16 pixel is a little bit old-fashioned. Mine has 18MPixel. | 17:51.43 |
henrys | mvrhel2:why can't you simply simulate the ops second command line parameter in the code so it happens whenever ghostscript is run? At least for now. | 17:52.21 |
alexcher | mvrhel2: We, probably, have a dotted version. In need to check the code. | 17:52.21 |
tkamppeter | Robin_Watts, I think a 16-pixel-picture is a little unrealistic. Its output is too much dependent on the PDF viewer/print filter. | 17:52.43 |
Robin_Watts | Random thought, and please feel free to tell me to go away, but... wouldn't all this be sidestepped by NOT passing the icc profile dir in as a userparameter, but having it handled as a special case by the executable ? | 17:53.41 |
| tkamppeter: Yes, it's an extreme example. | 17:54.07 |
mvrhel2 | henrys and alexcher: I don't quite understand what you last said | 17:54.09 |
henrys | well the bug reporter set the default profile and it works correct? | 17:54.46 |
tkamppeter | Robin_Watts, if you have a PDF file generated by an application and meant to be a print job, its bitmap parts are expected to have enough resolution, and if not it is probably intended to see the pixels. | 17:54.51 |
Robin_Watts | tkamppeter: not true.up | 17:55.02 |
mvrhel2 | henrys: oh yes | 17:55.04 |
| I wonder why that worked. | 17:55.17 |
alexcher | mvrhel2: gs may have custom operators to achive the same effect on level 1. | 17:55.20 |
mvrhel2 | oh alexcher. now I understand | 17:55.35 |
tkamppeter | Robin_Watts, do you have an example? | 17:55.39 |
henrys | so I'd assume you could put that somewhere in our the vast abyss and get the same effect. | 17:55.45 |
Robin_Watts | tkamppeter: I can't believe you can't see the difference between stars.pdf with and without interpolation at 720dpi. | 17:55.55 |
henrys | preferrably in the C language. | 17:56.13 |
mvrhel2 | alexcher: so you have some PS code in gs_lev2.ps | 17:56.16 |
| that sets up the icc manager | 17:56.22 |
Robin_Watts | Render to png16 and then view the resultant images at 1:1. | 17:56.25 |
mvrhel2 | is it not possible to have the occur earlier? | 17:56.33 |
| s/the/that | 17:56.39 |
henrys | alexcher:when can we stop supporting level 1 I thought we agreed we could stop. | 17:56.49 |
| ? | 17:56.51 |
mvrhel2 | alexcher line 633 | 17:57.34 |
| to line 724 | 17:57.59 |
alexcher | henrys: yes, we should, but this requires significant changes in many places. | 17:58.20 |
mvrhel2 | or do an erase page following this | 17:58.44 |
alexcher | mvrhel2: Thank you, I'll check this. | 17:58.52 |
tkamppeter | Robin_Watts, I stepped through several magnifications and they looked equal for me all the time. | 17:59.51 |
| Robin_Watts, how did you the test? What output format did you create and how did you view the result? | 18:00.20 |
mvrhel2 | alexcher: my line numbers might be off a bit as I have a few things in my version for support of Gray to K | 18:00.20 |
Robin_Watts | tkampeter: I ran: gs -sDEVICE=png16m -o out.png -r720 stars.pdf | 18:00.53 |
| and then the same with -dNOINTERPOLATE | 18:01.01 |
| Then I loaded the pngs into windows bitmap viewer and sent them to 1:1. | 18:01.33 |
tkamppeter | Trying this now ... | 18:02.23 |
| Can I use -dNOINTERPOLATE with all input formats and all output devices? Or does it belong to special formats? | 18:07.47 |
Robin_Watts | It's to do with the internal graphics library, not the output device. | 18:08.09 |
tkamppeter | So I can use it always? | 18:08.26 |
Robin_Watts | yes. | 18:08.32 |
tkamppeter | Robin_Watts, on the PNG tests the computing times are of the same order and the generated images look also of equal quality for me. | 18:19.58 |
Robin_Watts | tkamppeter: what exact command lines did you use please? | 18:20.31 |
tkamppeter | Robin_Watts, the PNG files are even exactly identical (diff). | 18:20.59 |
| Command lines: | 18:21.10 |
Robin_Watts | Right. Did you put -dNOINTERPOLATE before the filename ? | 18:21.20 |
mvrhel2 | oh there are 2 fill pages that occur in this file | 18:21.30 |
tkamppeter | time gs -sDEVICE=png16m -o stars-gs-standard.png -r720 stars.pdf | 18:21.33 |
mvrhel2 | oh 3 | 18:21.38 |
| actually 10 | 18:21.53 |
tkamppeter | real15m15.741s user15m8.510s sys0m2.690s | 18:21.57 |
| time gs -sDEVICE=png16m -dNOINTERPOLATE -o stars-gs-nointerpolate.png -r720 stars.pdf | 18:22.10 |
| real1m23.835s user1m19.260s sys0m1.430s | 18:22.34 |
mvrhel2 | henrys and Robin_Watts: so a few lines in gx_remap_DeviceGray fix the issue | 18:22.45 |
Robin_Watts | mvrhel2: Nice! | 18:23.01 |
henrys | great what if users want to use the device color spaces? | 18:23.25 |
tkamppeter | The times show that the second actually ran without interpolation, and only the second. | 18:23.38 |
mvrhel2 | henrys: that is handled with the SMALL_PROFILES option | 18:24.03 |
| as those will do the simple mappings | 18:24.17 |
henrys | 10/4 | 18:24.25 |
Robin_Watts | tkamppeter: So -dNOINTERPOLATE clearly had an effect, but didn't change the output. | 18:24.31 |
| I'm now confused, because I'm seeing the same files produced here, and I can't say why. | 18:24.50 |
tkamppeter | Robin_Watts, yes this is also how I see it. | 18:24.50 |
Robin_Watts | tkamppeter: OK, I'm going to have to eat humble pie here. | 18:25.40 |
tkamppeter | Robin_Watts, also the two CUPS raster files are identical, coming from command lines which differ only by -dNOINTERPOLATE. | 18:26.02 |
Robin_Watts | I've just looked at the two produced files, and the artifacts I could see without interpolation enabled are in fact visible in the non-interpolated ones too. | 18:26.18 |
| s/non-/ | 18:26.28 |
mvrhel2 | ok. so now, the question is do I make this part of the whole gray to K commit | 18:26.29 |
Robin_Watts | so I apologise for that red herring. | 18:26.42 |
chrisl | Robin_Watts: what's the memory use like now with stars.pdf? | 18:26.51 |
mvrhel2 | henrys: if I just commit this fix, it is going to end up mapping some gray spaces to composite CMY which is what we dont want | 18:27.01 |
Robin_Watts | Now I want to understand why we are using interpolation anyway... | 18:27.11 |
mvrhel2 | so, I am going to make this part of the whole fix | 18:27.23 |
tkamppeter | Robin_Watts, so looks like that I will insert -dNOINTERPOLATE in the default GS options in gstoraster, at first at least in the Ubuntu package, and if no one complains later upstream. | 18:27.34 |
Robin_Watts | mvrhel2: Can you not do that fix first ? | 18:27.41 |
| tkamppeter: Sure. If I turn up anything to change that decision,I'll let you know. | 18:28.14 |
mvrhel2 | if is going to generate thousands of regressions which the other commit is going to undo | 18:28.21 |
tkamppeter | Robin_Watts, seems that now we get all complaints of Linux users about too slow printing fixed with a little patch ... | 18:28.28 |
mvrhel2 | If that seems confusing I can explain more | 18:28.54 |
Robin_Watts | mvrhel2: no, I mean you have 2 commits, right, A and B. | 18:29.06 |
mvrhel2 | yes | 18:29.16 |
Robin_Watts | With git you can commit them as A and B, and then rebase -i to change the order of them. | 18:29.23 |
mvrhel2 | well I have not commited anything yet | 18:29.29 |
| they are both uncommitted works | 18:29.37 |
| in two different checkouts | 18:29.43 |
Robin_Watts | would that not let you keep them separate and yet cause no revertable diffs ? | 18:29.45 |
| ah, ok. so either order would cause differences that the other would revert. | 18:30.12 |
mvrhel2 | well no. | 18:30.34 |
| actually, If I did the gray to K first | 18:30.43 |
| then the fix that I have here | 18:30.48 |
| that should not have double regressions | 18:30.56 |
| hmmm | 18:31.29 |
| just trying to reduce the number of files to look at | 18:31.39 |
| and these fixes are somewhat related | 18:31.49 |
| I had run into this issue in the gray to K but had not figured out quite what to do about it until now | 18:32.13 |
| I guess a sep. commit is better for a patch though | 18:32.36 |
| for the customer | 18:32.39 |
| I will do that | 18:32.41 |
| so they can fix 9,03 easily | 18:32.54 |
chrisl | mvrhel2: I don't know how the graphics library works, in this context, but I assume that all the languages have implicit or explicit "core" color spaces which must be supported? | 18:44.27 |
mvrhel2 | well Gray, RGB, CMYK | 18:44.45 |
| PS has its pile of CIE ones | 18:44.55 |
| PDF has its oddball Cal ones plus ICC | 18:45.09 |
| then there are Sep and DeviceN | 18:45.16 |
| of course XPS has ICC up to 8 colors | 18:45.26 |
| everything is ICC in XPS | 18:45.34 |
| that is about it I think | 18:45.47 |
chrisl | Okay, so is there an argument for including profiles for those "core" spaces (gray, rgb and cmyk) in the executable as static data? So they are always ready for use? | 18:45.55 |
mvrhel2 | chrisl: yes ray_laptop is going to bake in the ps_cmyk, ps_gray, ps_rgb icc profiles for us | 18:46.24 |
| so that we always have these ones that do the simple conversions | 18:46.37 |
chrisl | Oh, okay, I misunderstood what Ray was doing then - ignore me :-) | 18:47.03 |
mvrhel2 | no problem. I think it is a great idea. Two people thought of it... | 18:47.27 |
chrisl | It makes sense for the colour spaces we'll *always* need to be there implicitly, I think | 18:48.01 |
mvrhel2 | chrisl: so on the CIELAB TIFF stuff, when the user specifies a CIELAB output profile there is a special setting in the TIFF output that indicates the data is CIELAB ICC data | 18:48.26 |
| and photoshop then interprets it correctly | 18:48.34 |
henrys | in pcl's first erase page *pgs->color->color_space->type == gs_color_space_index_DeviceGray | 18:49.08 |
mvrhel2 | I had fixed that for them quite some time ago. but this file had a special issue with respect to things getting initialized for the ICC work flow | 18:49.13 |
chrisl | mvrhel2: yep, as I just replied, my suggestion about trying our profile was just as a diagnostic thing, not that I thought it was actually the problem. | 18:49.42 |
mvrhel2 | henrys: ok. well, if you try to set the -sOutputICCProfile to lab.icc then you should see a nice red background when you open it with photoshop | 18:50.37 |
| (and go out to tiff24nc) | 18:50.44 |
| henrys: is the pgs->icc_manager->defaultgray set? | 18:51.24 |
Robin_Watts | walks dogs. | 18:51.30 |
mvrhel2 | I need to go get the kids from track camp. | 18:51.40 |
| brb | 18:51.42 |
Robin_Watts | mvrhel2 is training Auden to be a bounty hunter. | 18:52.12 |
henrys | yes the defaultgray is set. | 18:54.33 |
tkamppeter | Robin_Watts, another Ubuntu package, with patched CUPS filters to use -dNOINTERPOLATE, is on its way ... | 18:59.29 |
Robin_Watts | No ray today ? | 19:41.10 |
kens | Haven't seen him today | 19:41.27 |
tkamppeter | Robin_Watts, with my results the decision is made, Ghostscript will return to be the ...toraster filter to generate the CUPS Raster format in Ubuntu Oneiric. Thank you for your great work! | 19:48.18 |
Robin_Watts | tkamppeter: Excellent stuff. | 19:48.35 |
| Though I should say that the work wasn't all mine; I merely finished off stuff that both mvrhel2 and ray did before me. | 19:49.02 |
tkamppeter | so also thanks to mvrhel2 and ray_laptop. | 19:50.57 |
Robin_Watts | mvrhel2: I've put a patch on bug 692235. That bug belongs to you officially, but I've done some digging on it before. | 19:54.02 |
| I'm hoping that Russell and Martin (the two commenters on the bug) will test it and if they are both happy, we can commit and close it. | 19:54.34 |
kens | Night alll. | 19:58.58 |
Robin_Watts | night. | 19:59.05 |
| Aha, ray. | 20:00.59 |
| Any chance you could try out my patch from bug 692355 to see if it solves it for you please? | 20:02.11 |
chrisl | Robin_Watts: is it just a Windows 7 setup that we know showed the problem that you need? I can do it, if you like? | 20:03.15 |
Robin_Watts | chrisl: Windows 7 works for henrys. | 20:03.36 |
| but it fails for ray_laptop. | 20:03.50 |
| and for someone else I thought. | 20:03.55 |
chrisl | Yeh, me!] | 20:04.02 |
| I pointed it out to Ray] | 20:04.10 |
Robin_Watts | basically, I'd like someone for whom it failed before to tell me it now works. | 20:04.14 |
| Ah, then you'd be perfect! :) | 20:04.22 |
chrisl | I also can't seem to hit the return key reliably | 20:04.27 |
Robin_Watts | dinner. bbiab. | 20:05.43 |
mvrhel2 | ok. back from indian buffet for lunch... | 20:19.57 |
chrisl | henrys: is your Win7 VM a 32 bit setup? | 20:27.50 |
Robin_Watts | henrys: Just to be clear here, were you testing gswin32c.exe or gswin32.exe ? | 20:37.24 |
| because the "Ghostscript Image" window works in both. | 20:37.43 |
| it's the text window in the gswin32.exe that doesn't work. | 20:38.01 |
chrisl | Robin_Watts: the Window title shows perfectly with your patch, both 32 and 64 bit exes | 20:38.18 |
Robin_Watts | Fab. | 20:38.25 |
chrisl | Both Ray and I were testing on 64 bit, so I wondered if the source of the problem was the 32 bit to 64 bit ABI - we'll probably never know...... | 20:39.06 |
Robin_Watts | now, how can I push just one of my git commits... | 20:39.52 |
| bingo. | 20:41.47 |
| mvrhel2: I burbled above about bug 692235 | 20:42.31 |
| chrisl: Thanks for testing. | 20:42.57 |
mvrhel2 | hi Robin_Watts: ok thanks. I will try to take a look at this this afternoon | 20:43.11 |
chrisl | Robin_Watts: np | 20:43.19 |
Robin_Watts | mvrhel2: It's a low priority bug, so don't feel you have to spend time on it. If you don't have any objections to the approach, feel free to assign it to me. | 20:43.58 |
mvrhel2 | ok | 20:44.13 |
| brb | 20:44.16 |
chrisl | I've had enough - good night all! | 21:10.14 |
henrys | sorry I was away - windows 7 32 - I ran gswin32.exe | 21:17.42 |
| I did run it from a cygwin prompt. | 21:18.15 |
| running it from an explorer window gets the same result. | 21:20.40 |
| language location - english and US FWIW | 21:23.06 |
ray_laptop | henrys: saw your comment -- you said you ran on Win7 32 but didn't say whether or not it worked. I commented on the bug that Win7 64 works for me. I didn't mention that BOTH gswin32.exe and gswin64.exe are OK. | 21:51.25 |
henrys | I said it worked earlier and Robin_Watts's question accounted for that context. | 21:52.42 |
ray_laptop | henrys: thx | 21:53.01 |
henrys | very odd | 21:53.12 |
| ray_laptop:is there anything other than region and language that might be at play here? | 21:53.51 |
| anything other conf setting that should affect the title. | 21:54.21 |
ray_laptop | henrys: not that | 21:57.05 |
| henrys: not that I know of. So I think it is OK now | 21:57.21 |
henrys | mvrhel2:so defaulting the language to the simple profiles is going to change all the files too - do you want to pool that in with the other changes? | 22:18.06 |
mvrhel2 | henrys: good question. | 23:27.21 |
| xps should default to what we currently have | 23:27.37 |
| I think pcl is the odd man out here | 23:27.47 |
| henrys: I think we should just wait until we get the SMALL_PROFILES build option put in place | 23:28.25 |
| but first I need to figure out why my very simple fix seg faults everything during the clusterpush | 23:39.01 |
| :( | 23:39.04 |
tkamppeter | ray_laptop, I also want to thank you for your parts of the work on the performance problem bug 691755. This fix was really important. | 23:39.53 |
| Forward 1 day (to 2011/07/22)>>> | |