| | <<<Back 1 day (to 2011/07/28) | 2011/07/29 |
| chrisl | mvrhel2, henrys: are we blocking on the RGBW problem tkamppeter raised, or do we go for a release candidate and try to fix the problem for the actual release? | 05:57.08 |
| mvrhel2 | gawd that should not be a blocker | 06:19.57 |
| | any fixes for it should occur in gdevcups.c | 06:20.11 |
| | chrisl ^^ | 06:20.21 |
| | I just ran the output and viewed it with rasterview and it is not strange looking | 06:20.56 |
| chrisl | mvrhel2: okay, thanks. Phew, that's a bit of a relief! | 06:20.57 |
| | So is it just that the W plane isn't coming out right? | 06:21.28 |
| mvrhel2 | that is not to say that there may not be issues. it is a bit unclear exactly what they want with respect to the output | 06:21.34 |
| | the W plane supposedly is supposed to be a binary plane that indicates regions that are text | 06:21.57 |
| | the output has never been correct with ghostscript | 06:22.04 |
| | with our recent work in getting the tagging stuff working and object dependent color management it is now possible to make it work | 06:22.33 |
| chrisl | Beat me to it, I was about to ask that...... | 06:23.03 |
| mvrhel2 | but I don't think we can hold up this release to get it working. there may be a small patch for the cups device code and/or for tkamppeter to have a special profile case when that color space is used | 06:23.25 |
| | I suspect that with the fix that we did for the gray to K only, that we actually are getting the output that we used to get with 8.71 (or very close to it). | 06:24.51 |
| chrisl | Well, have a week or so between the RC and the real release, and from past experience, if a half dozen people actually build the RC we'll be lucky, and if half that number run even a smoke test, I'd be surprised! | 06:25.15 |
| | mvrhel2: it must be getting late for you - that's all I need to know, so I don't want to keep you unnecessarily. | 06:26.19 |
| mvrhel2 | ok. chrisl, I sent you an email about adding some stuff to the news | 06:26.43 |
| tkamppeter | mvrhel2, theis gray-to-K-only fix, when did it go into GS (my snapshot is of July 15)? Or has it still to go in? | 06:27.04 |
| mvrhel2 | I think that is all that I have. Nothing more is coming from me | 06:27.07 |
| chrisl | mvrhel2: Yep, I saw your mail, I'll get to that after I've had some breakfast....... | 06:27.38 |
| mvrhel2 | tkamppeter let me see when it went into 9.04 | 06:27.43 |
| tkamppeter | mvrhel2, and my 07/15 snapshot was trunk and not 9.04. | 06:28.51 |
| mvrhel2 | tkamppeter: ok hold on | 06:29.06 |
| | tkamppeter: so one fix for this (for gray scale images at higher resolutions) was done less than 2 days ago. Let me see when the main fix went in | 06:30.18 |
| chrisl | tkamppeter, mvrhel2: it looks like it was about 5 days ago, I think | 06:30.34 |
| mvrhel2 | yes 5 days ago | 06:30.49 |
| | tkamppeter: it would be good to test with that | 06:31.01 |
| | what this does is force DeviceGray colors to map to K only | 06:31.19 |
| | actually let me test another file | 06:31.42 |
| | this may be an issue with the RGBW color space... | 06:31.50 |
| | but it should be what 8.71 did | 06:32.01 |
| | looks good with rasterview | 06:33.47 |
| | it was a DeviceGray input image | 06:33.59 |
| | in a PDF file | 06:34.04 |
| | tkamppeter: so chrisl is about to create a release candidate soon. you can either try the head or wait for his "official" release | 06:34.54 |
| | ok. I am calling it a night | 06:37.41 |
| | tkamppeter: let me know how things look | 06:38.01 |
| tkamppeter | mvrhel2, thanks, I will test, good night. | 06:38.15 |
| mvrhel2 | thanks. good night | 06:38.21 |
| chrisl | good morning kens | 06:57.28 |
| kens | Hichrisl | 06:57.40 |
| chrisl | kens: that black images problem is weird, I didn't see anything strange about the image, except for the *awful* way the data source is defined....... yet more evidence the cairo developers should be shot :-( | 08:27.52 |
| kens | That much I can agree with. | 08:40.26 |
| | Defining the input dat to an image operation as bunches of strings in an arry. ANd then putting that into a type 3 font. Just mad. | 08:40.58 |
| | Not to mention the stupid n-op settransfer | 08:41.10 |
| | I suspect that the Cairo people don't have anyone who understands the otuput formats (at least for PostScript and PDF) very well. Or possibly at all. | 08:41.39 |
| | THis looks to me like it was cobbled together from various examples, probably those available from a Google search. | 08:42.06 |
| | Hmm, this is good. | 08:44.41 |
| | If I run the file through ps2write, tehn the resultign output (remember this is basically the same as pdfwrite) works fine. | 08:45.01 |
| chrisl | That is very odd! | 08:46.24 |
| kens | The image is LZW encoded instead of DCT. I'm going to set up pdfwrite to do LZW encoding instead of DCT. | 08:46.47 |
| | If I can remember how..... | 08:47.23 |
| kens | resorts to the documentation | 08:48.28 |
| | Oh, that's interesting. | 08:55.33 |
| | Ghostscript reads the 'black iomages' PDF file just fine. | 08:55.44 |
| chrisl | kens: even if they are DCT? | 08:57.48 |
| kens | Yes. | 08:57.54 |
| | Jaws also is happy with teh PDF file. | 08:58.00 |
| | This is starting to look like an Acrobat bug :-) | 08:58.10 |
| | Goign to try MuPDF now. | 08:58.18 |
| chrisl | Did you get to try the LZW compression in the PDF? | 08:58.39 |
| kens | Actually I tried flate and it made no difference. | 08:58.54 |
| | But I had tested the ps2write output in Ghostscript! | 08:59.10 |
| | Obviously I can test that in Acrobat directly | 08:59.24 |
| chrisl | What about using one of the options that forces some kind of colour space manipulation like UseCIEColor? | 09:00.26 |
| kens | I may try that in a minute. | 09:00.37 |
| | OK MuPDF also showws black boxes. | 09:01.09 |
| | Interesting. | 09:01.13 |
| chrisl | Well, at least you can debug MuPDF to work out why...... | 09:01.44 |
| kens | I might ask to to do that for me. He's much more familiar with MuPDF. | 09:03.55 |
| | Of course the first thing is to throw away 4 of the 5 pages of input, and all the rest of the detritus. | 09:04.18 |
| | Well, I've reduced the file to a single image, and stripped out the Cairo Prolog. This results in a black image in Acrobat. Pulling the DCTEncoded binary, and saving as a JPEG file, the JPEG opens correctyl. | 10:45.20 |
| | So its not the image data that's wrong. | 10:45.41 |
| | I wonder if the text matrix is not being applied to the CTM for the image or something similar. | 10:48.46 |
| | tor8 could you do me a big favour ? | 10:59.27 |
| tor8 | kens: I can try, what do you need? | 10:59.51 |
| | and please don't ask me to rewrite cairo's pdfwrite back end ;) | 11:00.13 |
| kens | I have a PDF file created by pdfwrite, which displays an image black in MuPDF and Acrobat and OK in GS and Jaws. Coudl you tell me *why* Its black in MuPDF ? | 11:00.38 |
| tor8 | is this the one that's hidden in a type3 font? | 11:00.53 |
| kens | Yes :-( | 11:00.59 |
| tor8 | mupdf doesn't support colored type3 fonts | 11:01.07 |
| kens | OH! | 11:01.14 |
| tor8 | so it gets rendered as b&w and used as a mask | 11:01.23 |
| kens | EEk. | 11:01.30 |
| | So a coloured image is just not going to work as a glyph ? | 11:01.42 |
| | In MuPDF that is. | 11:01.59 |
| tor8 | nope. no going to work at all. in mupdf that is. | 11:02.08 |
| kens | Hmm I wonder if this is also why Acrobat is throwing it out. | 11:02.30 |
| tor8 | it's been a *very* low priority problem for oh, over 8 years since I first found out about them :) | 11:02.50 |
| kens | If I Distill the file instead then I don't get a type 3 font, I get a straight image. | 11:02.52 |
| | I'm thinking this is an Acrobat bug. | 11:03.07 |
| | At least I'm not going mad. | 11:03.49 |
| tor8 | all fonts in mupdf go through the font cache, which is b&w masks only. supporting colored type3 fonts would need hacking workarounds in the interpreter to draw the glyphs as xobjects rather than fonts I think. | 11:04.44 |
| kens | is inclined to send this to Marcos for submission to Adobe's bug program :-) | 11:04.45 |
| | OK, well at least that explains my experience. I wonder if Acrobat does the same :-) | 11:05.19 |
| tor8 | possibly :) | 11:05.41 |
| | after all, how common are colored type 3 fonts, to mess up the text pipeline completely? | 11:06.07 |
| kens | Sommon enough in old PostScript. It used to be how company logos were done | 11:06.26 |
| | Hmm, in fact the Adobe logo in the Adobe flyer PDF file is a type 3 font. But I bet its done as a mask and coloured separately. | 11:07.34 |
| | That works OK if (like Adobe) your logo only has a single colour. | 11:07.58 |
| | I guess I can replace the image in this PDF file with a coloured rectangular fill. That should prove something. | 11:08.44 |
| | Well, a coloured rectangle works, so its not as simple as that :-( | 11:14.07 |
| | Well it seems Acrobat is happy with simple fills in colour in a type 3 CharProc. | 11:19.43 |
| chrisl_droid | kens:? | 11:27.10 |
| kens | yes | 11:27.37 |
| | ? | 11:27.42 |
| chrisl_droid | My cable is down - perfect timing! | 11:28.04 |
| kens | Oh good, that explains why you're on the phone.... | 11:28.25 |
| | I guess no release candidate today then... | 11:28.44 |
| chrisl_droid | indeed! | 11:28.45 |
| Robin_Watts | tor8: Ah. I was looking at the type3 stuff the other day, and something was niggling me about it :) | 11:29.12 |
| chrisl_droid | well, I'm going out for a while, if the cable isn't back after that I can probably borrow neighbour's connection to get the rc done | 11:30.37 |
| kens | OK | 11:30.53 |
| chrisl_droid | I just wanted someone to know I hadn't just disappeared | 11:31.31 |
| kens | :-) | 11:31.38 |
| chrisl_droid | so back in a couple hours - one way or another! | 11:32.13 |
| | my typing is even worse on the phone :-( | 11:32.53 |
| Robin_Watts | tor8: For type 3 fonts, mupdf first draws to a bbox device, then draws again with a 1 component mask. | 11:50.26 |
| | When we draw to the bbox, can we have d0 and d1 put a bit in the dev->hints to say whether it's a mask or a coloured glyph? | 11:51.08 |
| | Then we can draw again with the appropriate pixmap ? | 11:51.26 |
| tor8 | Robin_Watts: there's another problem in mupdf, that we could solve at the same time, I think | 12:06.04 |
| | oh wait, nevermind | 12:07.00 |
| | I'm reading the code, it looks like it wouldn't be too difficult to allow fz_render_t3_glyph to return a color pixmap | 12:09.02 |
| | and add special cases for colored glyphs in draw_device.c: draw_glyph | 12:09.54 |
| kens | Does either of you have a Mac running right now ? I'd be interested to know what it makes of this file. | 12:10.31 |
| tor8 | kens: link? | 12:11.03 |
| kens | I could put it on Casper, or jutst emila, its only 18Kb | 12:11.17 |
| tor8 | casper's fine | 12:11.27 |
| kens | Just a moment then. | 12:11.35 |
| tor8 | Robin_Watts: I'd rather scan the charproc string buffer for "d0" or "d1" than overload meaning to the hints flag | 12:13.29 |
| kens | OK in /home/ken as gs-reduced.pdf | 12:13.35 |
| Robin_Watts | tor8: That sounds nasty. | 12:13.48 |
| tor8 | kens: image comes out readable | 12:14.29 |
| kens | AhA! | 12:14.36 |
| | I think Acrobat bug :-) | 12:14.59 |
| Robin_Watts | Given that we have to run the stuff through a bbox device anyway, we just need some way for that device to return us a bit more information. | 12:15.26 |
| tor8 | Robin_Watts: how about a second argument to the bbox device? | 12:15.30 |
| Robin_Watts | We don't have a device specific way of handling d0 and d1. | 12:15.46 |
| tor8 | fz_new_bbox_device(&bbox, &is_color_t3_proc) | 12:15.48 |
| | oh right | 12:16.00 |
| Robin_Watts | tor8: That's why I suggested using a bit in dev->hints, because it's there in every device. | 12:16.19 |
| tor8 | hm, fine, let's add another "is_color_t3_proc" flag to the fz_device struct | 12:16.29 |
| Robin_Watts | tor8: Can we add a 'flags' word ? | 12:16.43 |
| tor8 | or a generic flag argument for output-flags | 12:16.56 |
| Robin_Watts | and have 1 bit in that be IS_COLOR_T3_PROC | 12:16.58 |
| tor8 | hints is for input to the device | 12:17.01 |
| Robin_Watts | fair enough. | 12:17.05 |
| tor8 | yeah | 12:17.06 |
| | what you said :) | 12:17.10 |
| Robin_Watts | tor8: Are we doing a mupdf release now too ? | 13:07.53 |
| | tor8: We should put some encrypted docs into the sanity test for mupdf. | 13:21.14 |
| tor8 | Robin_Watts: we probably ought to, we're up to 180 patches since last release | 13:23.12 |
| | but there's a few things I had hoped to include for the next release that are not done yet | 13:23.26 |
| Robin_Watts | tor8: I thought the plan was to release mupdf in lockstep with gs ? | 13:23.34 |
| tor8 | like the new text extraction, I'll want another week or two to bang on it | 13:23.39 |
| | yeah, but that wasn't my idea (lockstep releases) so I don't have to like it ;) | 13:24.16 |
| Robin_Watts | New patch on casper for you. | 13:24.44 |
| | actually. Ignore that. | 13:25.09 |
| | OK. New version there now :) | 13:25.37 |
| tor8 | the is_dict? the idiom for null tests in mupdf is if (!nullable_expression) | 13:25.47 |
| Robin_Watts | tor8: Yes. That's the idiom I just swapped to. | 13:26.04 |
| tor8 | right you are too! :) | 13:26.23 |
| Robin_Watts | Using ! for NULL is a REALLY bad idea, IMHO. | 13:26.29 |
| | but using it for ints is fine, and this is an int return. | 13:26.43 |
| | if (x == NULL) is MUCH clearer, to my mind than if (!x). Especially as I tend to read if (!x) as if (x != NULL) | 13:27.24 |
| tor8 | using null as a truthy value has a long tradition in c. i read if (!x) as "if no x" but I guess it's what you're used to that counts, as usual. | 13:28.17 |
| Robin_Watts | Yes, C has a long tradition of allowing such abuse. | 13:29.53 |
| | and it's got a clear meaning. | 13:30.36 |
| | but it's 'unfriendly' style, IMHO. | 13:30.47 |
| | Same reason I put brackets around things. | 13:31.04 |
| | You might know that something is alright because you have intimate knowledge of C's precedences etc, but if you can save a future reader of the code even a second or two in reading it, it's worth it for clarity. | 13:32.03 |
| | From clarity comes correctness etc. | 13:32.10 |
| | Every now and then I try and convince myself to write if (NULL == x) rather than if (x == NULL), but that's just too heavily ingrained in me :( | 13:32.56 |
| | (because if you slip up and use = rather than ==, the compiler gives an error). | 13:33.20 |
| tor8 | convoluted code is still convoluted, even in the presence of brackets. | 13:33.31 |
| | any sane compiler gives you a warning on if (x = NULL). that's one of the few places I use unneccessary brackets. if ((x = NULL)) will tell the compiler to shut up about assigning in a boolean-evaluated expression | 13:34.32 |
| Robin_Watts | That's a gccism. | 13:34.43 |
| tor8 | and clang-ism | 13:34.57 |
| Robin_Watts | and sadly, relying on compilers for such warnings is a poor strategy. MSVC don't surf. | 13:35.22 |
| tor8 | writing code backwards and cluttering perfectly legible expressions with needless brackets for the benefit of j random developer who's still wet behind the ears, well, not my style :) I expect at least a basic knowledge of the language you're reading, or I'd be writing in python or java. | 13:36.34 |
| Robin_Watts | Did Chrisl pull my mkromfs changes into 9.04 ? | 13:36.42 |
| | tor8: It's a well known fact (well to me at least), that we get less and less smart as we get older. | 13:37.30 |
| | How many times have you ever looked back at code, and gone "Wow, I was SOO much cleverer back then!" ? | 13:37.51 |
| | I figure that "j random developer" might be me in the future :) | 13:38.10 |
| tor8 | Robin_Watts: I'm as dense as they come, I never try to be clever with my code. not that I always succeed. | 13:38.15 |
| | at least you seem to be able to grok my code in mupdf, despite the lack of brackets :) | 13:39.08 |
| Robin_Watts | Yes, mupdf is easy enough to parse, thankfully. | 13:39.49 |
| | ok, so I've broken the UFST build, apparently. | 13:43.04 |
| kens | Ah, so that was you :-) | 13:43.24 |
| Robin_Watts | where the hell is the UFST crap in the makefiles... | 13:43.28 |
| | kens: supposedly with my mkromfs changes. | 13:43.39 |
| kens | Its built separately and linked as a library I think | 13:43.46 |
| | Yes I see chrisl did incoporate you r changes to mkromfs | 13:44.01 |
| Robin_Watts | kens: but stuff goes into rom, right ? | 13:44.02 |
| kens | It used to, yes, what it does now I'm less sure about. | 13:44.21 |
| Robin_Watts | I thought I did the mkromfs stuff *after* the branch, deliberately. | 13:44.26 |
| kens | I haven't looked at it for ages | 13:44.27 |
| | Actually I think that was a fals positive. | 13:44.51 |
| | I don't think chrisl put the mkromfs changes in | 13:45.00 |
| Robin_Watts | indeed. | 13:45.14 |
| kens | I did a grep for mkromfs and it picked up something that hadn't actually changed. | 13:45.34 |
| | So the release is safe from teh UFST breakage, which is a good thing. | 13:45.58 |
| Robin_Watts | marcosw: Ping ? | 13:46.20 |
| | tor8: Random other thought... | 13:48.21 |
| kens | Hmm this suggests one of the support files doesn't like being compressed with your stuff. The FCOs are loaded from disk | 13:48.29 |
| Robin_Watts | kens: Right. But I can't see where the ufst stuff gets into my stuff. | 13:48.58 |
| | I turn compaction on and off with -C and -B on the command line. | 13:49.16 |
| | So if it's not turned on, we'll never compact anything. | 13:49.31 |
| kens | I think chrisl simplified the build requirements so that you only have to set up some minimal stuff for the build. My old (*very*) old build sets up a shed load of stuff for the build. | 13:49.31 |
| Robin_Watts | Right, but there is only one call to mkromfs during the build, right? And that's the one from psromfs.mak | 13:50.03 |
| kens | As far as I know, yes | 13:50.12 |
| | I assume dyou would want to build the UFST variant for testing though | 13:50.26 |
| Robin_Watts | and nowhere can I see how anything UFSTy can get into that build line. | 13:50.37 |
| kens | The FAPI stuff does UFST and FreeType both I think. | 13:50.56 |
| | I could be wrong. | 13:51.08 |
| | Certainly all the UFST-specific stuff (FCO's and so on) are being loaded from disk in Marcos' example | 13:51.30 |
| Robin_Watts | The FAPI files are postscript format, right ? | 13:51.34 |
| kens | They are PostScript programs, yes | 13:51.44 |
| Robin_Watts | Right, so compaction applied to them shouldn't be a problem. | 13:52.05 |
| kens | Also there are some only vaguely PS files, like cidfmap | 13:52.11 |
| Robin_Watts | Ah, cidfmap isn't really postscript ? | 13:52.31 |
| kens | It is, but it may not look like it much | 13:52.42 |
| | FCOfontmap-PCLPS2 Is a candidate | 13:53.45 |
| | In gs/Resource/Init | 13:53.52 |
| Robin_Watts | How do I do a UFST build then ? | 13:54.04 |
| kens | I'm no longer sure :-( | 13:54.13 |
| | I'm trying to figure it out | 13:54.18 |
| | I think all you need these days is a build parameter but I don't know what it is. | 13:54.38 |
| | chrisl simplified all this (which is good, obviously) but I havem't built it since then. | 13:55.03 |
| Robin_Watts | UFST_ROOT=C:\... I guess. | 13:55.24 |
| kens | Sounds promising. | 13:55.40 |
| | You'll need the UFST library in a directory off that. | 13:55.58 |
| | You may need to ahev built it (there is a VS solution IIRC) already | 13:56.12 |
| | It used to require UFST_BRIDGE=1 as well. | 13:56.43 |
| | Well, what do you know, I still have a copy of the UFST source. | 13:57.21 |
| | I guess I can try this. | 13:57.26 |
| Robin_Watts | Looks like lib.mak also calls mkromfs. | 13:57.45 |
| | But I haven't changed that at all. | 13:57.53 |
| kens | UFST_ROOT=c:\ufst | 13:59.17 |
| | Sadly this throws a build error. | 13:59.38 |
| | In c. | 13:59.43 |
| Robin_Watts | I think you need UFST_BRIDGE=1 as you said. | 14:00.06 |
| kens | I have that too | 14:00.13 |
| | thros a compile error on fapiufst.c )1668) | 14:00.34 |
| | Odd, the line numbers don't match my source. Time for a clean. | 14:01.45 |
| kens | wonders if chrisl unplugged his cable modem in order to get the releas done on the quiet :-) | 14:02.35 |
| Robin_Watts | I'm sure I had ufst built on my machine at some point in the past. | 14:04.20 |
| kens | I definitely have. | 14:04.29 |
| Robin_Watts | Can't find it now though :( | 14:04.30 |
| | Are the visual studio projects the ones in demo ? | 14:05.53 |
| kens | For me they get built when you build GS in Visual Studio | 14:06.24 |
| | No wait. | 14:06.39 |
| | Perhaps they don't. | 14:06.44 |
| Robin_Watts | Not with my VS project :) | 14:06.44 |
| kens | I htink those are the ones you want to build. | 14:08.09 |
| | I wonder if mine are out of date. | 14:08.16 |
| | I hope UFST is still under Subversion | 14:09.35 |
| Robin_Watts | it is. | 14:10.50 |
| kens | OK well I just updated. Lets see if a reuibl helps | 14:11.10 |
| Robin_Watts | I've just updated it and all the libs build except for the "demo" project, which I suspect is OK. | 14:11.11 |
| kens | demo never worked without modifications. Mine is midified | 14:11.25 |
| | Or even modified | 14:11.36 |
| Robin_Watts | but then my gs build fails with not being able to find ufst/rts/inc/cgconfig.h | 14:11.38 |
| kens | Really ? let me look | 14:11.50 |
| Robin_Watts | No, wait. that's me being a fool. | 14:12.25 |
| kens | I've got one and it claims to be under Suversion control | 14:12.26 |
| Robin_Watts | Right fapiufst.c falls in a heap for me | 14:12.57 |
| kens | Mee to | 14:13.08 |
| | Me too. But the errors don't seem to make sense | 14:13.20 |
| Robin_Watts | For me, UFSTFONTDIR doesn't appear to be defined. | 14:13.41 |
| kens | 'formal parameter 2 different from declaration' | 14:13.49 |
| | That's a compile time definiition ? | 14:14.09 |
| | Well, that's weasy to fix. | 14:14.25 |
| Robin_Watts | well, it sounds like something that the build system should set up to me. | 14:15.30 |
| | The build system sets up UFSTROMFONTDIR and UFSRDISCFONTDIR | 14:15.51 |
| kens | It depends on whether you are building in custom FCOs | 14:16.00 |
| Robin_Watts | and gs.psi/int.mak should setup UFSTFONTDIR | 14:16.28 |
| kens | I defined one manually, makes no difference | 14:16.58 |
| Robin_Watts | Right. | 14:17.22 |
| | The problem is that the cl invocation uses: -DUFSTFONTDIR= | 14:17.43 |
| | so for whatever reason the gs/psi/msvc.mak stuff that's supposed to set UFSTROMFONTDIR or UFSTDISCFONTDIR= ain't being called. | 14:18.21 |
| kens | suspects it works on Linux | 14:18.38 |
| | But why does this lead to compilation errors ? | 14:18.47 |
| Robin_Watts | memcpy(x, UFSTFONTDIR, 10); doesn't compile too well if UFSTFONTDIR is defined to nothing. | 14:19.57 |
| kens | THat's not the errors I'm getting I don't think. | 14:20.25 |
| | Which line is that | 14:20.32 |
| Robin_Watts | .\psi\fapiufst.c(1627) : warning C4028: formal parameter 2 different from declaration | 14:20.48 |
| kens | Ah, a chrisl :-) | 14:20.49 |
| Robin_Watts | 1>.\psi\fapiufst.c(1668) : error C2059: syntax error : ',' | 14:20.50 |
| | 1>.\psi\fapiufst.c(1674) : error C2059: syntax error : ',' | 14:20.52 |
| kens | OK, same error | 14:20.56 |
| Robin_Watts | Hey chrisl_web. Got your cablemodem back ? | 14:21.02 |
| kens | suispects not | 14:21.11 |
| Robin_Watts | or wireless hotspotting through your phone ? | 14:21.15 |
| chrisl_web | No connected over a tether to my phone :-( | 14:21.15 |
| kens | chrisl UFST build problem | 14:21.31 |
| Robin_Watts | marcosw has given me a bug saying that I've broken ufst. | 14:21.32 |
| | but the revision he blames (my mkromfs hackery) isn't in the 904 branch. | 14:21.50 |
| | but I'm looking into it anyway, and I can't even get the ufst to build on windows. | 14:22.03 |
| | I've added: UFST_BRIDGE=1 UFST_ROOT=c:\cvs\artifex\ghostpcl\ufst to my nmake call. | 14:22.27 |
| kens | : Robin_Watts if UFSTFONTDIR is undefined, then it gets defined as "" | 14:22.51 |
| Robin_Watts | and I've used the demo.sln project to make the ufst libs. | 14:22.55 |
| chrisl_web | Oh, it probably is, you want to not do any fiddilng when the FCOs are built into romfs | 14:22.56 |
| Robin_Watts | kens: No, it's defined. It's just not defiend to anything. | 14:23.10 |
| kens | : OK | 14:23.16 |
| | chrisl this is a compile time problem using VS | 14:23.26 |
| | UFSTFONTDIR is defined but has no content | 14:23.35 |
| Robin_Watts | When I then come to build, I get the following invocation: | 14:23.36 |
| | cl /c /DWINDOWS_NO_UNICODE /DGX_COLOR_INDEX_TYPE="unsigned __int64" /DHAVE_SSE2 /FR.\debugobj\ @.\debugobj\ccf32.tr /Za /Zm1100 -I.\psi -I.\debugobj -I.\debugobj -I.\base -DMSVC -DUFSTFONTDIR= -Ic:\cvs\artifex\ghostpcl\ufst\sys\inc -Ic:\cvs\artifex\ghostpcl\ufst\rts\inc -Ic:\cvs\artifex\ghostpcl\ufst\rts\psi -Ic:\cvs\artifex\ghostpcl\ufst\rts\fco -Ic:\cvs\artifex\ghostpcl\ufst\rts\gray - | 14:23.49 |
| | Ic:\cvs\artifex\ghostpcl\ufst\rts\tt -Fo.\debugobj\fapiufst.obj /c .\psi\fapiufst.c | 14:23.51 |
| | Note the "-DUFSTFONTDIR=" | 14:24.08 |
| | That means that the following line (and others like it) don't compile: | 14:24.22 |
| | strncpy(tmppath, UFSTFONTDIR, sizeof(tmppath)); | 14:24.47 |
| chrisl_web | Hmm, we had a lot of trouble getting that to work, let me have a lot at the makefile | 14:25.09 |
| Robin_Watts | Now it looks to me like the gs/psi/int.mak either chooses an invocation of: | 14:25.20 |
| | $(PSCC) $(UFST_CFLAGS) -DUFSTFONTDIR=$(UFSTROMFONTDIR) $(UFST_I... | 14:25.30 |
| | or $(PSCC) $(UFST_CFLAGS) -DUFSTFONTDIR=$(UFSTDISCFONTDIR) $(UFST_... | 14:25.38 |
| | and UFSTROMFONTDIR and UFSTDISCFONTDIR are supposed to be set in gs/psi/msvc.mak | 14:26.06 |
| kens | Defining UFSTROMFONTDIR gets past that error | 14:26.22 |
| Robin_Watts | but clearly they are not getting set (or are not getting set until too late) | 14:26.31 |
| kens | But it doesn't like the backslashes I used. | 14:26.41 |
| chrisl_web | Well, I can see: UFSTROMFONTDIR=\\\"%%%%%rom%%%%%fontdata/\\\" is in msvc.mak | 14:27.17 |
| Robin_Watts | Ah, I should probably be calling ufst-debug, not debug. | 14:27.56 |
| chrisl_web | Oh, I thought it did that for you - it's a while since I built it with UFST on Windows, and even longer since I did so at the command line. | 14:29.04 |
| Robin_Watts | chrisl_web: Anyway, I'll keep bashing at looking at this, but I can't see how my change can be responsible for it being broken in 9.04 | 14:29.48 |
| chrisl_web | I don't think any of your mkromfs changes are in 9.04. I haven't tested it since you sorted out the dependencies, though. | 14:31.25 |
| | Robin_Watts: if it really is 9.04, then it can't be your mkromfs changes, they're not in there. | 14:34.18 |
| | Robin_Watts: as I will be working on the UFST soon anyway, why don't you just assign the bug to me, other than the dependecies, I can't see anything you've done could be a problem on 9.04 | 14:37.18 |
| Robin_Watts | ok. My mkromfs changes *have* broken the ufst build on non-9.04 | 14:38.07 |
| | I'll fix that, and then assign the bug to you. | 14:38.14 |
| chrisl_web | Robin_Watts: it should just be a case of making sure that the FCOs are treated as binary files (so not compaction/compression gets done on them) and that should be fine - I thought they were marked that way already, though. | 14:39.24 |
| Robin_Watts | The problem is with one of the MISC_INIT_FILES | 14:39.48 |
| | Specifically, one of: FCOfontmap-PCLPS2 cidfmap FAPIcidfmap FAPIconfig FAPIfontmap Fontmap Fontmap.GS xlatmap | 14:40.22 |
| chrisl_web | Oh, I'd hhuess the FCOFontmap one? It has a slightly strange format, which I hate | 14:40.56 |
| | s/hhuess/guess | 14:41.08 |
| Robin_Watts | I might just leave all of them uncompressed. It's a tiny amount in the grand scheme of things. | 14:41.29 |
| | It is indeed that file. | 14:42.24 |
| chrisl_web | Yeh, it's crap, isn't it? Well, leave it uncompressed for now. | 14:43.18 |
| Robin_Watts | Done, and I've passed you the bug. | 14:48.02 |
| | Let me know if there is anything else I can help/interfere with. | 14:48.18 |
| chrisl_web | Okay, thanks. | 14:49.10 |
| tkamppeter_ | Robin_Watts, chrisl_web, mvrhel2, I tried the current snapshot of Ghostscript, RC1, it is even worse for CUPS Raster. CityMap comes out black-ink-only now. launch-leaflet did not change though. It looks as before. | 14:52.20 |
| Robin_Watts | tkamppeter_: Is it *just* cups that's a problem, or non cups devices too ? | 14:53.55 |
| | tkamppeter_: If you can give me details, I can have a quick look. | 14:58.53 |
| tkamppeter | Robin_Watts, I have tested only CUPS now, the same tests I did yesterday with mvrhel. | 15:00.41 |
| | Robin_Watts, they are all RGBW CUPS. If we do not get this right I will go with Poppler to generate CUPS Raster in Oneiric and leave us with another 6 months to work on the CUPS Raster output device. | 15:01.58 |
| Robin_Watts | tkamppeter: Right. From what I skimmed in the logs last night, mvrhel2 thought that the cups rasters were looking OK. | 15:02.41 |
| | Ah, speak of the devil. | 15:02.54 |
| mvrhel2 | tkamppeter: so I am guessing that you did not like what rasterview had to show? | 15:03.20 |
| Robin_Watts | malc_: Bug fixed :) | 15:04.09 |
| tkamppeter | Robin_Watts, if I switch to standard RGB (and not use RGBW) I get correct output. The problem is RGBW and this is what HP's driver needs. | 15:04.14 |
| malc_ | Robin_Watts: congratulations :) | 15:04.18 |
| mvrhel2 | tkamppeter: so with the head is it giving you the correct output? | 15:04.50 |
| ray_laptop | darn! hope chris comes back | 15:05.04 |
| tkamppeter | mvrhel2, You will get another e-mail with four scans, all printed with todays snapshots and HPLIP, same conditions as yesterday, all on Oneiric GS 9.04 RC1. | 15:05.12 |
| mvrhel2 | what does it look like on rasterview | 15:05.30 |
| | that is the only thing I can look at | 15:05.36 |
| Robin_Watts | ray_laptop: He's got no cable modem today, so is reliant on tethering to his phone. | 15:05.40 |
| mvrhel2 | I can't print them tkamppeter | 15:05.46 |
| ray_laptop | chrisl_web: Hi. I assume that you updated (or will update) the script so the it keeps the luratech stuff under the luratech directories. | 15:06.04 |
| mvrhel2 | tkamppeter: can I give you a minor patch to test? | 15:06.38 |
| chrisl_web | ray_laptop: yes, I did it - it was looking at the script that reminded me we'd discussed doing that. | 15:06.55 |
| ray_laptop | chrisl_web: and you can change the gs/LICENSE stuff in the script to just say 'luratech' instead of 'ldf_jb2, lwf_jp2' | 15:07.04 |
| Robin_Watts | will leave this to mvrhel2 and tkamppeter then. Let me know if I can help. | 15:07.08 |
| mvrhel2 | one where we end up using a RGB ICC profile with RGBW but have 32 bits for the color depth | 15:07.14 |
| | that gave an incorrect view with rasterview | 15:07.26 |
| | but perhaps that will give you a correct print | 15:07.34 |
| chrisl_web | ray_laptop: let me just check..... | 15:07.42 |
| ray_laptop | chrisl_web: I didn't feel that it was critical for 904, but I do like it under the luratech directory (much clearer what it is compared to ldf_jb2 and lwf_jp2) | 15:08.15 |
| chrisl_web | ray_laptop: I just felt it was good to get done, it was a pretty trivial change. | 15:08.57 |
| malc_ | tor8: hi, around? | 15:09.19 |
| tkamppeter | mvrhel2, scan in your mailbox, please send me the patch. | 15:09.53 |
| mvrhel2 | with the patch, the view in rasterview is seriously off | 15:10.19 |
| | so I have no idea what you are going to get when you print tkamppeter | 15:10.37 |
| kens | chrisl modem back up ? | 15:13.23 |
| tkamppeter | mvrhel2, the view and the printout often do not correspond well with RGBW. Perhaps rasterview does not support well RGBW. So should I send you screenshots of my rasterview? | 15:13.31 |
| chrisl | yes, just now - hallelujah! | 15:13.45 |
| kens | :-) | 15:14.05 |
| chrisl | Question is, will it stay that way | 15:14.45 |
| mvrhel2 | tkamppeter: it would be nice to see a screen shot of what it should look like with rasterview vs what it does look like in rasterview since I have nothing else to judge if it is correct unless you want to send me a printer | 15:14.47 |
| tkamppeter | mvrhel2, so I will send you screenshots of the 4 files, done with the RC1. | 15:17.55 |
| mvrhel2 | Til, no email from you yet, but I sent you a patch to try | 15:18.04 |
| tkamppeter | mvrhel2, you have offered me a small patch to test. Can you send it to me? | 15:18.22 |
| mvrhel2 | tkamppeter: it should be in your inbox | 15:19.33 |
| tkamppeter | mvrhel2, arrived now. I will try ... | 15:20.41 |
| mvrhel2 | ok. the output with rasterview is so wrong with this one that I can't imagine it working but who knows | 15:21.14 |
| | I really don't like working on something that has no reference and for which the definition has not really been well defined | 15:21.50 |
| mvrhel2 | mumbles something about monkeys typing shakespeare | 15:22.55 |
| tor8 | malc_: pong. | 15:26.40 |
| malc_ | tor8: http://phk.freebsd.dk/pubs/malloc.pdf there's something funny there, try searching for "fi nd" yes with space, with adob reader searching for "find" works.. some ligature madness? | 15:28.43 |
| | s;adob;adobe.. | 15:28.53 |
| tkamppeter | mvrhel2, I am testing now. The patch is very promising. The rasterview tests showed correct colors on all 4 files now. | 15:29.05 |
| mvrhel2 | huh | 15:29.17 |
| | how come my rasterview shows a cyan background | 15:29.29 |
| tkamppeter | mvrhel2, now I also try on the printer. | 15:29.40 |
| mvrhel2 | ok | 15:29.44 |
| mvrhel2 | keeps his fingers crossed | 15:29.51 |
| Robin_Watts | mvrhel2: Are you on a 32bit box, and tkamppeter on a 64 ? | 15:30.50 |
| mvrhel2 | yes | 15:30.57 |
| | well I am on 32 bit | 15:31.03 |
| tkamppeter | mvrhel2, sorry, as usual, such a psositive result is wrong. I stepped back in history and took the wrong command lines, of normal RGB. The printer gave me a cyan background on the first CityMap and I replied that with power-cycling the printer. | 15:31.25 |
| mvrhel2 | ok | 15:31.38 |
| | so, what is expected in RGBW | 15:31.55 |
| tor8 | malc_: it's the extra spacing that makes mupdf (and me, when I read it) add an extra space between the two words "fi" and "nd" ;) | 15:32.20 |
| tkamppeter | The printer even painted the back side of the CityMap cyan. Fortunately, it has separate cartridges and HP pays for them. | 15:32.21 |
| ray_laptop | mvrhel2: if you want to clarify to Freek -- they will be able to use the same threshold data for different resolutions, but will create different PS 8-bit threshold arrays from it since the linearization will change with resolution. | 15:32.49 |
| tor8 | malc_: and I'm sure adobe is more flexible when matching strings | 15:33.06 |
| mvrhel2 | ray_laptop: ah yes. I just sent an email to him | 15:33.29 |
| tkamppeter | mvrhel2, ^^ | 15:33.30 |
| ray_laptop | running 'genpat' is what takes a while at large sizes, but linearization is fast | 15:33.31 |
| Robin_Watts | tor8: I need a test file with 'd0' in it. | 15:33.48 |
| malc_ | tor8: let me try to select the text with spawn of evil which takes 486MB of disk space to see if it gives back find or fi nd | 15:33.50 |
| tkamppeter | mvrhel2, I am repeating the rasterview test now. | 15:33.50 |
| mvrhel2 | tkamppeter: I understand. I wonder if this is a transparency thing. citymap has transparency if I recall | 15:34.01 |
| tor8 | Robin_Watts: casper:/home/ken/gs-reduced.pdf | 15:34.40 |
| mvrhel2 | let me run a transparency case with head and look at what I see with rasterview | 15:34.42 |
| Robin_Watts | tor8: Ah! | 15:34.51 |
| tkamppeter | mvrhel2, I get a cyan CityMap in rasterview, too. So HPLIP seems to be doing well. | 15:34.56 |
| malc_ | tor8: adobe gives back 'find', the viewer that comes with chrome (foxit?) gives back "find" with fi being one symbol.. | 15:35.58 |
| mvrhel2 | tkamppeter: hold on let me run a simple transparency file. | 15:36.25 |
| tor8 | malc_: yeah, I'm sure it all depends on the heuristics used by each viewer to extract the text | 15:36.29 |
| mvrhel2 | tkamppeter: can you run ./examples/text_graphic_image.pdf and tell me if that looks ok | 15:36.54 |
| tor8 | the general case needs to be able to insert missing spaces, since a lot of files simply don't emit space characters at all | 15:36.56 |
| mvrhel2 | with head? | 15:36.57 |
| | and RGBW | 15:37.00 |
| | as it looks ok with rasterview to me | 15:37.10 |
| malc_ | tor8: okay.. just idle curiosity got better of me | 15:37.24 |
| tkamppeter | mvrhel2, seems that your change of cups->color_info.num_components does not only chabge ICC profile selection but also changes some offset of the pixels. | 15:37.25 |
| mvrhel2 | tkamppeter: perhaps. I have no idea what the expected encoding is for RGBW | 15:38.01 |
| | see the comment about Monkeys above | 15:38.23 |
| tkamppeter | mvrhel2, ./examples/text_graphic_image.pdf has cyan background, too. | 15:38.32 |
| mvrhel2 | tkamppeter: without the patch | 15:38.41 |
| tkamppeter | mvrhel2, colors look OK now. | 15:41.14 |
| mvrhel2 | ok. so on that we agree | 15:41.32 |
| | so I am looking to see if this is a transparency issue no | 15:41.49 |
| | now | 15:41.51 |
| | tkamppeter: try running the bad files with -dNOTRANSPARENCY | 15:42.43 |
| | and see if you get the correct print | 15:42.52 |
| tkamppeter | mvrhel2, the colors look even the same as with 9.01. | 15:43.00 |
| Robin_Watts | tkamppeter: Is there any way that mvrhel2 can view an RGBW cups file in the absence of having a printer ? | 15:43.47 |
| | Is there a flag to rasterview or something to show the w plane separately ? | 15:44.07 |
| mvrhel2 | ok so I do have something to go on | 15:44.37 |
| | a simple transparency file run through RGBW and view with rasteview is giving me garbage | 15:45.00 |
| | somehow the pdf14 device is getting things mucked up | 15:45.28 |
| | for this color space | 15:45.35 |
| | tkamppeter: if you prints with -dNOTRANSPARENCY come out "reasonable" then that also points to the culprit | 15:46.19 |
| | s/you/your/ | 15:46.23 |
| tkamppeter | mvrhel2, with -dNOTRANSPARENCY they look correct, with only slight deviations, like the border of the map. | 15:46.27 |
| mvrhel2 | ok | 15:46.31 |
| | well thats some progress | 15:46.48 |
| | I need to eat some breakfast before I start digging further into this | 15:47.01 |
| tkamppeter | Robin_Watts, he uses rasterview, but rasterview cannot show the W plane separately. | 15:47.27 |
| Robin_Watts | tkamppeter: Right. So that's a failing in rasterview? Is it something that could easily be fixed? | 15:48.02 |
| mvrhel2 | tkamppeter: so really ghostscript could create RGBW with RGB and W containing real text tag information | 15:48.34 |
| tkamppeter | Robin_Watts, I never looked into the source code of rasterview ... | 15:48.36 |
| mvrhel2 | but it would be good to have a soft view like rasterview show us what we need to have | 15:49.22 |
| | breakfast time. bbbiab | 15:49.29 |
| tkamppeter | mvrhel2, if I do "lpr -P <printer> <CUPS raster file>" I get a printout of the map in correct colors but with solid blue border. | 15:51.57 |
| | mvrhel2, unfortunately, the print is rotated by 90 degrees and so it shows only the map and not the legend. | 15:53.04 |
| | mvrhel2, Robin_Watts, problem is probably that it is neither a 3-byte nor a 4-byte pixel, but a 3-byte-plus-a-boolean pixel (25 bit per pixel) ... | 15:54.50 |
| Robin_Watts | tkamppeter: But that'll be packed into 32 bits, right? | 15:55.32 |
| | mvrhel2: Are you using rasterview under windows ? | 15:56.13 |
| ray_laptop | mvrhel2: gmail eats emails with .zip files that have .exe in them. I uploaded it to casper and sent the email with the URL | 15:56.46 |
| | coffee time for me... | 15:57.14 |
| tkamppeter | Robin_Watts, yes, I know. So a problem can be that this color space is considered 4-component but needs 3-component color management. | 15:58.10 |
| Robin_Watts | tkamppeter: Interestingly, rasterview treats R,G,B and W as all having the same widths. | 16:06.30 |
| henrys | alexcher are you around? | 16:07.30 |
| tkamppeter | Robin_Watts, this I have seen now in the source of rasterview, too. For me it seems that Mike is not consistent with what RGBW means. According to docs and what HP needs RGBW is RGB + boolean black-or-not-black. | 16:07.59 |
| Robin_Watts | tor8: kens: I get an economist logo with that file now under mupdf. | 16:09.43 |
| kens | Coo! Another piece of evidence for me :-) | 16:10.07 |
| Robin_Watts | but horizontally flipped ? | 16:10.14 |
| kens | Hmm, not what I get with GS | 16:10.35 |
| | I think htere may be an odd matrix in there though | 16:11.03 |
| Robin_Watts | kens: That could easily be me. | 16:11.07 |
| | Anyone know of any nice simple files that use d0 ? | 16:11.20 |
| | There must be one of the test suites or something. | 16:11.44 |
| kens | We have 'some' in the test suite. | 16:11.51 |
| | I think one even has d0 in the name | 16:12.00 |
| Robin_Watts | There is a 'd1_with_color_ops' | 16:12.48 |
| kens | No, I was wrong | 16:13.10 |
| tkamppeter | Robin_Watts, , mvrhel2, in gdevcups.c RGBW is origin or destination of conversions at three places: Near line 1185, in cups_map_cmyk(), thereit looks like 4-component inverse of CMYK, near line 2037, in cups_map_color_rgb(), there it also looks like inverse CMYK, and near line 2270 in function cups_map_rgb_color() and there it looks correct, like RGB + boolean. | 16:13.10 |
| chrisl_web | tkamppeter: has the W component ever worked in the Ghostscript output? | 16:22.50 |
| tkamppeter | chrisl_web, perhaps during 8.x. In Ubuntu Natty I used Poppler and older Ubuntus have GS 8.x | 16:28.00 |
| alexcher | henrys; here | 16:30.11 |
| henrys | you said shading was not getting gc'd? What did you mean? | 16:31.42 |
| | I did look at your patch with the regular memory debugging stuff and I get the usual "not found in chunk" with -ZA you can see the ref array allocated just after the save. | 16:33.24 |
| | basically what Robin_Watts found. | 16:33.33 |
| alexcher | henrys: when the return vakues of buildshading operator are discarded, the memory is still consumed. | 16:34.55 |
| tkamppeter | Robin_Watts, chrisl_web, mvrhel2: I also wonder about the many different cups_map_...() functions in gdevcups.c. Are they all actually used? Is RGBW a CUPS-Raster-only color encoding (perhaps even only used by the HPLIP driver)? Or are there PDFs with elements encoded in RGBW? Is Mike Sweets definition of RGBW correct? | 16:35.41 |
| henrys | but if gc is broken for shading we don't want to fix that with save/restore right? that just masks the underlying issue | 16:35.45 |
| chrisl_web | henrys: I've got a pair of 9.04rc1 (GS and GhostPDL) archives up on casper - how do you feel about making them public? | 16:36.35 |
| henrys | alexcher:so we should be able to create a very simple shading example, call vmreclaim and see it doesn't work right? | 16:36.44 |
| | chrisl_web:fine by me. | 16:37.12 |
| Robin_Watts | save/restore is NOT masking the problem. | 16:37.22 |
| | If anything it's making it more obvious. | 16:37.31 |
| chrisl_web | henrys: great, I will mail out a notification before I finish (real soon!). | 16:37.50 |
| henrys | Robin_Watts:basically there is a memory leak which alex's fix masks with save/restore - what am I missing? | 16:39.03 |
| alexcher | henrys: there are several issues there: (1) we should not cache every shading. (2) there are memory management problems. | 16:39.07 |
| Robin_Watts | henrys: That's not how I'd describe the situation. | 16:39.26 |
| henrys | alexcher: the save/restore masks (2) is that right? | 16:40.17 |
| alexcher | henrys: I'd say that current caching masks memory problems. | 16:41.22 |
| Robin_Watts | There are memory management problems that ordinarily we get away with because gc gets us the memory back eventually. By adding save/restore we force the memory to come back to us sooner, but this exposes the memory management problems by making SEGVs apparent. | 16:42.06 |
| | Regardless of anything else, we should fix the memory management problems. | 16:42.27 |
| | Once we do that, we may find that the save/restore is unnecessary. | 16:42.44 |
| henrys | we've reached agreement. | 16:43.07 |
| Robin_Watts | but at the moment the save/restore serves a hugely useful purpose of a) making it much easier to catch the problems, and b) making most files complete much faster. | 16:43.27 |
| | I may have a go at shrinking the example file over the weekend to try and find the smallest file I can that triggers the problems. | 16:44.09 |
| henrys | alexcher:is the caching easily disable so we can see the effect of that? | 16:47.22 |
| chrisl_web | henrys: mail sent out (to tech and gs-devel) about the rc1 archives. | 16:47.33 |
| | I'm going to finish now, before my phone goes into meltdown! | 16:47.55 |
| | Enjoy your weekends....... | 16:48.04 |
| Robin_Watts | chrisl_web: Night. | 16:48.06 |
| henrys | bye | 16:48.10 |
| | that's what I'd do - release the code and get the hell out of here! | 16:48.32 |
| Robin_Watts | Gah. Having no luck finding Type3 fonts that use d1. | 16:48.55 |
| alexcher | henrys: yes, just disable the ps code that adds /.shading to the dictionary.. | 16:49.10 |
| mvrhel2 | ok I am back | 16:49.35 |
| Robin_Watts | alexcher: Is that the bit you tested and said wasn't causing the problem ? | 16:49.36 |
| henrys | kens:I thought you had a pcl->pdf example type3 and d1? | 16:49.46 |
| Robin_Watts | I have kens example. | 16:50.03 |
| alexcher | henrys: yes, I did this nut it doesn't help. | 16:50.06 |
| Robin_Watts | and that seems to work. | 16:50.09 |
| | but I can't compare/contrast it with acrobat. | 16:50.28 |
| | I'd like a more 'ordinary' test file. | 16:50.39 |
| alexcher | henrys: yes, I did this but it doesn't help. | 16:51.49 |
| ray_laptop | Robin_Watts: if you can spot an address which is getting 'traced', you can see what structure referenced it, and which 'index' (pointer #) in the struct it was. | 16:52.32 |
| Robin_Watts | ray_laptop: how ? | 16:52.52 |
| alexcher | henrys: reusable streams used by shading don't cause problems either. | 16:53.07 |
| ray_laptop | if you can breakpoint on the 'trace', then go 'up' the call stack and look at the 'pre' | 16:53.44 |
| tkamppeter | mvrhel2, can you scroll back to see my messages? | 16:54.19 |
| ray_laptop | you can step into the enum function manually | 16:54.20 |
| Robin_Watts | ray_laptop: Urm... It's the ref marking phase that goes wrong. | 16:54.29 |
| ray_laptop | (I use 'Set Next Statement') | 16:54.40 |
| Robin_Watts | but I can have a go at that now, if you can bear with me. | 16:55.05 |
| ray_laptop | Robin_Watts: it marks by using the 'enum' function of the structure to enumerate pointers | 16:55.20 |
| Robin_Watts | OK, I've found 2 'd1' files to play with in the FTS test suite. | 16:57.07 |
| | ray_laptop: Rebuilding now. | 16:57.15 |
| mvrhel2 | tkamppeter: so this RGBW color space is the only place that we have encountered something named like this in ghostscript. I believe the name should be changed to RGBT where T is a tag information, but if HP calls it RGBW then I suppose it should stay. Real RGBW color spaces are used in digital projectors | 16:57.17 |
| | one thing I see in gdevcups.c that is wrong with respect to RGBW is that it lists White as a colorant for the device | 16:57.44 |
| | which is very confusing | 16:57.51 |
| | since I thought this was going to be a text bit location | 16:58.18 |
| tkamppeter | mvrhel2, I can send you a patch to gdevcups.c showing how it should be, but the patch does not solve the problem. Again I get correctly-looking colors only with -dNOTRANSPARENCY. | 17:00.18 |
| Robin_Watts | Hehe. Acrobat dies on one of the Type3 font examples, and my crap hacked together code gets it right :) | 17:01.11 |
| mvrhel2 | tkamppeter: so I will look into why things are going crazy when we have transparency and we are going out to the RGBW color space. I have no idea what the encoding should be for RGBW nor how the W plane should be generated. If it was a text plane, then I would think this device should be set up as a RGB tags device similar to our bitrgbtag device | 17:02.07 |
| | tkamppeter: then you would have a true RGB + tag plane where you could encode text portions as 1 and non-text as 0 | 17:02.47 |
| | brb | 17:03.56 |
| tkamppeter | mvrhel2, patch sent. | 17:04.13 |
| Robin_Watts | ray_laptop: OK, built and running. Let me try and navigate to the problem... | 17:07.49 |
| | Damn. Stuff has moved around in memory since I last got this to fail. It'll take me a few minutes to get the new values. | 17:11.15 |
| ray_laptop | Robin_Watts: not surprising things move | 17:13.04 |
| Robin_Watts | indeed. I forgot that I'd pulled stuff in today is all. | 17:13.21 |
| ray_laptop | Robin_Watts: the -Z@$? _should_ be giving you an 'object not in any chunk' from ilocate.c:534 or 'Reference to free object' ilocate.c:540 | 17:16.38 |
| Robin_Watts | ray_laptop: Not using that. | 17:17.05 |
| | Gah. I had the fast thresholding enabled, which seems to slow this file to a crawl for some reason. | 17:19.15 |
| henrys | ray_laptop:yes a refs array not in any chunk. | 17:22.45 |
| | Robin_Watts:FWIW the problem with not using the gs debug stuff is you don't see global v. local - LIFO v. freelists etc. | 17:24.32 |
| | although in this case that info isn't shedding much light. | 17:24.57 |
| Robin_Watts | I'm not not using it for any particular religious reason. I just didn't know about it. | 17:25.42 |
| | Something has changed though; this file used to fall over repeatably in a nice way. Now it's taking ages. | 17:26.31 |
| | Possibly my mkromfs fix has moved stuff in memory so it doesn't fail or something :( | 17:26.52 |
| | But it shouldn't take this long to run... | 17:27.24 |
| henrys | you do have alexcher's patch in? | 17:31.38 |
| | it did take a long time for me but I was doing all the logging. | 17:31.59 |
| | and memory checking | 17:32.16 |
| Robin_Watts | yes. | 17:32.39 |
| | It's going way beyond the point it was crashing for me before. | 17:34.35 |
| tkamppeter | mvrhel2, Robin_Watts: I have looked into the source code of the HPLIP driver now to see how RGBW is handled: | 17:36.21 |
| Robin_Watts | Let me try some git magic to get me back to here I was before. | 17:37.10 |
| henrys | Robin_Watts:this is really out of your domain - should probably be alex or ay I feel like we are dumping on you. | 17:38.08 |
| | s/or ay/or ray/ | 17:38.37 |
| Robin_Watts | henrys: If I had it back to the state it was yesterday, then it would have been easy for me to run tests and get information out, that might point ray or alex to a simple fix. | 17:38.53 |
| henrys | okay | 17:39.27 |
| Robin_Watts | if I can't get back to a state in which I can reproduce the crash fairly soon, then I'll bale on it. | 17:39.30 |
| ray_laptop | Robin_Watts: sorry -- I'm on the phone with cust 532, but I'll watch for my name here. | 17:40.02 |
| Robin_Watts | ray_laptop: No worries. I'm not blocked on you at the moment :) | 17:40.20 |
| mvrhel2 | tkamppeter: and? | 17:40.21 |
| tkamppeter | mvrhel2, Robin_Watts: If the W byte is 0, the pixel is marked as black pixel in a separate list and the content of the RGB bytes gets unchanged into the RGB bitmap (but probably does not get used when printing as this pixel is marked black). If the W byte is FF then the RGB byte gets unchanged into the RGB bitmap and the pixel is NOT marked black. This means the RGB pixel gets printed as it is. If the W bit has another value, 01..FE, the | 17:41.03 |
| | n it is considered like some luminance thingy: The following formulas are applied: | 17:41.03 |
| | mvrhel2, Robin_Watts: R := R - (255 - W); G := G - (255 - W); B := B - (255 - W) | 17:42.40 |
| Robin_Watts | (255-W) = Black | 17:43.02 |
| | So R -= Black, G -= Black, B -= Black. Makes sense. | 17:43.24 |
| tkamppeter | mvrhel2, Robin_Watts: If results get negative they are set to 0. Then the resulting RGB triple gets into the bitmap to be printed. | 17:43.29 |
| | mvrhel2, Robin_Watts: So HPLIP takes two definitions or RGBW: | 17:44.05 |
| mvrhel2 | so that is not at all a text plane | 17:44.19 |
| Robin_Watts | IF W = 0, then Black = 255, then those would give R,G,B = 0. | 17:44.31 |
| mvrhel2 | but some weird UCR thing | 17:44.33 |
| tkamppeter | mvrhel2, Robin_Watts: 1. Mike Sweet's definition of RGB + boolean black=0 not black=FF | 17:44.45 |
| Robin_Watts | IF W = 255, then RGB would go unchanged. | 17:44.52 |
| | So it would be nicer if the code was changed so that W = 0 meant R,G,B = 0. That way it would at least be consistent with itself. | 17:45.23 |
| tkamppeter | mvrhel2, Robin_Watts: 2. Projector RGBW (am I right?) RGB + one byte to dim the RGB value | 17:45.39 |
| Robin_Watts | RGBW is really just CMYK but inverted. | 17:45.47 |
| mvrhel2 | tkamppeter: actually the above description would be like projector RGBW | 17:47.04 |
| tkamppeter | If the input is mode 2, in addition to the above conversion W=0 pixels are marked black, but pixels with R = B = G = 0 after conversion but W != 0 are not marked black. | 17:47.35 |
| | I will put two code pieces into a pastebin now. | 17:48.07 |
| henrys | alexcher:looking at the -ZA output I see allocations for the shading object a save and then this dictionary is created I assume related to the shadings, and I assume the shading objects should hold a reference to the dictionary so now I don't see how this would work. | 17:48.43 |
| tkamppeter | mvrhel2, Robin_Watts: This is the code snippet in the HPLIP driver: http://paste.ubuntu.com/654644/ | 17:50.34 |
| | mvrhel2, Robin_Watts: This is the patch for gdevcups.c to fix its mixing of CUPS RGBW and projector RGBW: http://paste.ubuntu.com/654646/ | 17:52.35 |
| | mvrhel2, Robin_Watts: Canm you look some messages back from here, I have two messages not marked with your names. | 17:53.37 |
| Robin_Watts | Right. So for each row, the hp driver copies rgb unchanged, then modifies it for non full/empty pixels to account for blackness. | 17:53.50 |
| | And for every 8 pixels, it collects a 'black' value. | 17:55.37 |
| | That black value is dependent on the W value being 0, and a pixel_value array, which appears to be an 8 entry lookup table. | 17:56.19 |
| norbertj | hello all | 17:57.18 |
| Robin_Watts | ah, is pixel_value[k] = 1<<k or something ? | 17:57.20 |
| tkamppeter | Robin_Watts, The "if (b != 0 && b != 0xFF) {" bracketing the calculation is not actually needed. The calculation applied to b = ff gives the same result as not doing the calculation and for b = 0 the pixel is marked black so RGB values are not used for this pixel. So the bracket is only an accelerator for CUPS RGBW. | 17:57.50 |
| norbertj | I found following snippet on | 17:58.04 |
| | http://www.cups.org/documentation.php/spec-raster.html | 17:58.05 |
| | CUPS_CSPACE_RGBW | 17:58.07 |
| | This color space provides a dedicated black text channel and uses the sRGB color space definition and whitepoint for the RGB color channels. The white channel is 0 for text (or "true") black, otherwise it must contain the maximum color value: 1 for 1-bit, 3 for 2-bit, 15 for 4-bit, 255 for 8-bit, or 65535 for 16-bit. | 17:58.08 |
| tkamppeter | Robin_Watts, It calculates for each pixel whether it is black, but the array to mark this is one BIT per pixel and not one BYTE per pixel. | 17:58.58 |
| Robin_Watts | tkamppeter: Right. I just don't understand what pixel_value[k] is. | 17:59.28 |
| henrys | tkamppeter:sorry if this was already answered: did this ever work properly? | 17:59.35 |
| tkamppeter | norbertj, this is the CUPS RGBW (1) which I talked about earlier ... | 17:59.46 |
| Robin_Watts | henrys: tkamppeter answered that earlier, saying he wasn't sure. It might have worked back in v8, but he can't be sure. | 18:00.20 |
| tkamppeter | Robin_Watts, forgot to include the definition: | 18:00.31 |
| | static BYTE pixel_value[8] = { | 18:00.34 |
| | 0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01 | 18:00.34 |
| | }; | 18:00.34 |
| Robin_Watts | Right, that makes sense then, thanks. | 18:00.43 |
| tkamppeter | It is only to access the bits in a byte. | 18:00.45 |
| mvrhel2 | tkamppeter: So I would like to fix this by making changes in gdevcups.c. When I run with the RGB profile and tranparency I get the same cyan output, but at least it is discernible. We really should be able to do the encoding based upon RGB. | 18:02.41 |
| Robin_Watts | tkamppeter: The second patch... I don't see anything in there to cope with (say) c+k being > 255 | 18:03.12 |
| tkamppeter | mvrhel2, Robin_Watts: HPLIP understands both CUPS RGBW and projector RGBW when it gets CUPS Raster marked RGBW, but we as Ghostscript developers and issuers of the CUPS Raster output device should follow the CUPS documentation (which norbertj cited) to not confuse other manufacturers (making CUPS work as it is documented). | 18:03.41 |
| Robin_Watts | tkamppeter: So the problem is that gs is producing RGBW with W values other than 0 and 255 ? | 18:04.29 |
| tkamppeter | mvrhel2, Robin_Watts, HPLIP understands both probably due to the badly programmed gdevcups.c (I did not touch that part) which confused them. | 18:05.02 |
| | Robin_Watts, mvrhel2: I am not absolutely sure what GS emits, also due to the badly programmed gdevcups.c | 18:06.00 |
| Robin_Watts | henrys: ray_laptop: alexcher: I can't reproduce the problem any more, so I'm baling on it. | 18:06.07 |
| | tkamppeter: Well, a 'quick test' might be to nobble gdevcups to ensure that we only produce 0 and 255 there and to see if that fixes it. | 18:06.30 |
| tkamppeter | Robin_Watts, mvrhel2: I could open the Raster file with a hex editor and look ... | 18:07.51 |
| Robin_Watts | tkamppeter: Smart. | 18:08.00 |
| henrys | alexcher:did you look at the -ZA output do you see what I mean? | 18:08.52 |
| tkamppeter | Robin_Watts, nothing, no 3-byte+00|FF patterns | 18:10.15 |
| Robin_Watts | ? | 18:10.47 |
| | tkamppeter: Can you put the file somewhere for me to look at in a hexeditor here please? | 18:11.11 |
| tkamppeter | Robin_Watts, by email. I hope you can gunzip a gz file. | 18:13.48 |
| Robin_Watts | tkamppeter: Can we avoid email ? | 18:14.06 |
| tkamppeter | Robin_Watts, why | 18:14.15 |
| Robin_Watts | email is slow/unreliable for sending files | 18:14.19 |
| | Can't you stick it on casper or somewhere? | 18:14.29 |
| | Also, I get email on a different machine :) | 18:14.35 |
| tkamppeter | Robin_Watts, do I have access to casper | 18:14.46 |
| Robin_Watts | I believe so. | 18:14.53 |
| | You have git commit capabilities, right? | 18:15.35 |
| tkamppeter | Yes I can | 18:15.44 |
| Robin_Watts | so you can ssh to casper using the same key. | 18:15.46 |
| tkamppeter | Robin_Watts, in my home dir on casper | 18:16.38 |
| Robin_Watts | tkamppeter: Thanks. | 18:16.47 |
| tkamppeter | Robin_Watts, This is of 9.01 | 18:17.23 |
| Robin_Watts | tor8: New patch in the repo on casper for your consideration. | 18:17.52 |
| | I need to test it out on sane, but I can't see it causing any problems. | 18:18.04 |
| | I see lots of 0F 59 E2 FD in that file. | 18:22.22 |
| | which is cyan, if I'm not mistaken. | 18:22.47 |
| | well, bluish, at least. | 18:25.11 |
| tkamppeter | Robin_Watts, it is CityMap | 18:25.52 |
| Robin_Watts | As a quick hack, you could try changing the driver to clamp W values < 128 to 0 and > 128 to 255. | 18:26.29 |
| tkamppeter | Robin_Watts, with -dNOTRANSPARENCY | 18:26.58 |
| Robin_Watts | I thought -dNOTRANSPARENCY worked? | 18:27.18 |
| tkamppeter | Robin_Watts, so this is a Raster file with which HPLIP works. | 18:27.48 |
| Robin_Watts | That file was produced by ghostscript with -dNOTRANSPARENCY, and HPLIP works with it ? | 18:28.21 |
| mvrhel2 | Robin_Watts: this is why I am looking at something in the transparency code that is getting mixed up | 18:29.16 |
| Robin_Watts | tkamppeter: Before I go any further, I'd like to be clear on that. | 18:29.52 |
| | The file you gave me was produced by ghostscrip with -dNOTRANSPARENCY, and HPLIP works PERFECTLY with it ? | 18:30.13 |
| tkamppeter | Yes. Only the border is solid blue, but this is due to NOTRANSPARENCY. | 18:30.56 |
| | Robin_Watts, now I have added one from 9.04 with NOTRANSPARENCY, also CityMap, works as well | 18:31.34 |
| Robin_Watts | OK. | 18:31.39 |
| | So it seems that "non 0 or 255" values for W aren't upsetting it. | 18:32.03 |
| | Though to follow the letter of the spec we should only be outputting 0 or 255. | 18:32.23 |
| tkamppeter | Robin_Watts, that's it | 18:32.52 |
| | Robin_Watts, now I have uploaded one without NOTRANSPARENCY, which is broken in rasterview and with HPLIP. | 18:34.13 |
| | Also CityMap. | 18:34.29 |
| | Note that the two with 9.04 I did with the patch http://paste.ubuntu.com/654646/ which should (I hope) produce real CUPS RGBW. | 18:35.31 |
| | Robin_Watts, ^^ | 18:36.06 |
| Robin_Watts | tkamppeter: Right. I asked about that before... I can't see in the patch how it can cope with c+k being > 255 | 18:36.13 |
| tkamppeter | Robin_Watts, which place? | 18:36.32 |
| Robin_Watts | in the first chunk of the patch. | 18:36.57 |
| | It's probably just out of range, that's all. | 18:37.06 |
| tkamppeter | Robin_Watts, gdevcups.c follows the CUPS RGBW at one point, where I patched in "XXX Correct". | 18:37.13 |
| mvrhel2 | hmm I see that the pdf14 device is pushing an RGB device | 18:37.27 |
| | It should be pushing a CMYK device | 18:37.43 |
| Robin_Watts | mvrhel2: Are you rendering to CMYK internally, and then converting to RGBW at the end? | 18:38.36 |
| | That would sound correct if we were producing 'real' RGBW. | 18:39.06 |
| mvrhel2 | Robin_Watts: The pdf14 device does no conversions to RGBW. There is no RGBW blend space | 18:39.19 |
| | It simply does a put image at the end | 18:39.24 |
| Robin_Watts | but if we are supposed to only be producing RGB + binary W, then surely we should be rendering to RGB internally, and fudging the W from the tag plane ? | 18:39.40 |
| mvrhel2 | Robin_Watts: you are talking about fixing a bigger problem that will take some time. | 18:39.55 |
| Robin_Watts | Right. | 18:40.05 |
| | So you're just trying to make it work producing 'true' RGBW for now ? | 18:40.15 |
| mvrhel2 | I am hoping to just get this thing working so that transparency files render like non transparency files | 18:40.17 |
| Robin_Watts | tkamppeter: Will that be acceptable for this release ? | 18:40.31 |
| mvrhel2 | the proper way to do this device is to do it as a RGB device that has tags | 18:41.07 |
| | like our bitrgbtag device | 18:41.13 |
| | that all works even with transparency | 18:41.25 |
| ray_laptop | mvrhel2: I know you are on more critical stuff -- just wanted to make sure you got the emails about the 'genpat' stuff | 18:41.34 |
| | mvrhel2: one sent just a few minutes ago. | 18:41.46 |
| mvrhel2 | but it will require some significant rework in gdevcups.c | 18:41.51 |
| Robin_Watts | mvrhel2: Right. Just wanted to check that what you're producing will be OK for tkamppeter. | 18:42.16 |
| mvrhel2 | ray_laptop: I got the one with the link. thanks | 18:42.30 |
| | I haven't had a chance to do anything with it yet though :( | 18:42.39 |
| | ray_laptop: nothing from you in the last few minutes though | 18:43.29 |
| Robin_Watts | is being called for dinner, and may call it a day after that. Have a good weekend everyone. | 18:44.09 |
| mvrhel2 | oh the polarity of RGBW is the thing that is screwing us up | 18:44.25 |
| henrys | bye Robin_Watts | 18:44.47 |
| Robin_Watts | tkamppeter: I'll be around over the weekend in case you find any more critical problems, but it sounds like mvrhel2 is well on the way to sorting this one for you. | 18:44.58 |
| mvrhel2 | two ways to fix this. | 18:44.59 |
| tkamppeter | Robin_Watts, OK, thanks, I will continue with mvrhel2 now, have a great weekend. | 18:45.41 |
| mvrhel2 | thanks Robin_Watts | 18:45.48 |
| | have a great weekend | 18:45.59 |
| Robin_Watts | mvrhel2: Not sure I really did anything but OK :) | 18:46.05 |
| mvrhel2 | you poked and prodded things along | 18:46.17 |
| henrys | alexcher that bug is in your court if you aren't going to work on it please reassign it to me, ray or support, thanks | 18:46.37 |
| mvrhel2 | asked lots of questions, which is what I like about you | 18:46.41 |
| tkamppeter | mvrhel2, what are the two ways to fix? And should I commit my CUPS-RGBW-only patch (only after testing together with one of your solutions)? | 18:46.52 |
| mvrhel2 | tkamppeter: the approach I prefer is to set the cups device to be subtractive in polarity in gdevcups.c for RGBW. the other approach is to change how pdf14 determines how it will do its install of the pdf14 device | 18:48.11 |
| | which may break other things | 18:48.18 |
| | so let me first try the first approach | 18:48.41 |
| tkamppeter | mvrhel2, OK. | 18:50.50 |
| mvrhel2 | tkamppeter: I would REALLY like to do away with #define cups((gx_device_cups *)pdev) in gdevcups.c | 18:51.44 |
| | as it makes debugging a pain | 18:51.49 |
| | perhaps I can send you a patch for this if you would consider it | 18:53.12 |
| alexcher | henrys: I have a week-end ahead, the most productive time, to solve the bug. | 18:59.55 |
| henrys | okay I also see you have a pspcl6 bug assigned to you that can be given to me. | 19:01.49 |
| tkamppeter | mvrhel2, for me it is no problem. I would try the patch. I always only did the necessary on Mike's code. I never tried a general improvement. As Mike stopped working on it it was full of segfaults and CUPS got new functionality which did not get implemented in gdevcups.c, so I had to fix all that to make the drivers and printers working correctly. | 19:02.26 |
| mvrhel2 | ok | 19:02.49 |
| henrys | lunch time for me. | 19:02.55 |
| mvrhel2 | tkamppeter: so I believe I have a solution but it is a little odd but it is due to the weird way that RGBW behaves, which is like a mixed up CMYK space | 19:08.17 |
| | let me clean it up a bit | 19:08.39 |
| tkamppeter | mvrhel2, OK. | 19:09.22 |
| mvrhel2 | tkamppeter: I am going to send you a patch to try. | 19:13.00 |
| | what we should look at doing for the next release is to find out what exactly is optimally needed for RGBW and try to get that working. GS now has extreme capabilities in doing color management and tag reporting for object types | 19:13.47 |
| | and we need to look at some of these other color spaces. | 19:14.47 |
| | I suspect RGBA will have some issues too | 19:14.57 |
| | tkamppeter: ok I just sent you the patch | 19:19.03 |
| | please let me know soon if it works | 19:19.12 |
| | I am out this afternoon again | 19:19.17 |
| tkamppeter | mvrhel2, downloade it and testing it nnow ... | 19:22.54 |
| | mvrhel2, rasterview looks OK ... | 19:24.31 |
| | ...printer lloks also OK. | 19:26.35 |
| | mvrhel2, so nothing is totally scrambled any more, but colors are somewhat different now. | 19:27.13 |
| | mvrhel2, so thanks for fixing the transparency issue. | 19:28.11 |
| mvrhel2 | tkamppeter: OK. Do you want me to commit this then or do you want to do it? | 19:28.31 |
| | tkamppeter: do in the long term (for next release in 6 months) we should look at cleaning up these color spaces and get a better understanding of what is needed for them | 19:29.37 |
| tkamppeter | mvrhel2, please commit it. | 19:29.41 |
| mvrhel2 | s/do/so | 19:29.43 |
| | ok | 19:29.46 |
| | tkamppeter: and do you want it in the 9,04 release? | 19:30.05 |
| tkamppeter | mvrhel2, yes. | 19:30.29 |
| mvrhel2 | ok, I will let chrisl know to merge it in | 19:30.48 |
| tkamppeter | mvrhel2, the colors off problem is independent of this. | 19:30.59 |
| mvrhel2 | tkamppeter: so at this stage for RGBW you basically have CMYK | 19:31.47 |
| tkamppeter | mvrhel2, I tried launch_leaflet now, and the skin colors on right photo on the second page are really pink. | 19:31.57 |
| mvrhel2 | tkamppeter: we should probably try using a different ICC profile for when RGBW is invoked | 19:36.21 |
| | tkamppeter: try the following | 19:37.24 |
| tkamppeter | mvrhel2, "try the following"? What? | 19:40.19 |
| mvrhel2 | hold on | 19:40.23 |
| | sorry | 19:40.25 |
| | -sDefaultRGBProfile=ps_rgb.icc -sDefaultCMYKProfile=ps_cmyk.icc -sOutputICCProfile=ps_cmyk.icc | 19:41.47 |
| tkamppeter | mvrhel2, I tried it now, no change colors are exactly the same as before, skin is as pink. | 19:45.44 |
| mvrhel2 | tkamppeter: hmm. ok | 19:47.21 |
| | is this file attached to the bug? | 19:47.35 |
| tkamppeter | mvrhel2, also the colors of CityMap did not change. | 19:48.32 |
| mvrhel2 | is this the brunel 200 file | 19:48.34 |
| tkamppeter | mvrhel2, yes. And there see especially the rightmost photo on the second page. | 19:49.10 |
| | mvrhel2, you mean the "RGBW colors off" bug? | 19:50.01 |
| | mvrhel2, there is also a tool to investigate RGBW bitmaps. | 19:50.52 |
| mvrhel2 | tkamppeter: ok. I am taking a quick look at the leafelet file to see what rasterview shows | 19:56.27 |
| | tkamppeter: do the color print pink also? | 19:57.37 |
| | colors | 19:57.41 |
| | I need to grab some lunch | 19:58.25 |
| tkamppeter | mvrhel2, it prints even more pink than it looks on the screen. | 20:02.33 |
| mvrhel2 | tkamppeter: ok. sounds like a job for an icc profile | 20:04.44 |
| | or, we need to actually fake this thing out to do RGB + BYTE | 20:05.10 |
| | tkamppeter: I may be able to spend a little time tonight on that approach | 20:05.37 |
| | that was what my original plan was | 20:05.52 |
| | when I went to 3 components earlier | 20:05.59 |
| kens | Night all | 20:06.00 |
| mvrhel2 | and we got the pretty Cyan output | 20:06.07 |
| tkamppeter | mvrhel2, yes this is actually a three-component format and could probably be color-managed like a pure RGB.\ | 20:08.35 |
| mvrhel2 | tkamppeter: ok I am looking at the approach now | 20:34.28 |
| tkamppeter | mvrhel2, OK. | 20:36.33 |
| mvrhel2 | tkamppeter: OK I think I have it! | 20:38.27 |
| | at least on rasterview my one file looks quite good | 20:38.48 |
| | I will send you another patch to test | 20:38.56 |
| tkamppeter | mvrhel2, OK, I will try it. | 20:39.10 |
| mvrhel2 | and you will want to add in -sOutputICCProfile=ps_rgb.icc on the command line | 20:39.23 |
| | tkamppeter: let me create a release build to check the leaflet file real quick | 20:40.00 |
| | hold on | 20:40.02 |
| henrys | so I guess we missed getting in the small profiles for this release. | 20:55.31 |
| mvrhel2 | henrys: yes | 20:56.54 |
| | tkamppeter: I have to go now. there seems to be an issue when I ran this out to multiple pages and tried to open anything either than the first page with rasterview | 20:57.31 |
| | I am not sure what that is all about | 20:57.40 |
| | if it is my fix or if it always existed | 20:57.49 |
| | but it will have to wait until tonight for me to look at | 20:57.59 |
| | doing the single page fixes the pink skin | 21:00.19 |
| | and also the transparency works | 21:00.24 |
| | tkamppeter: I am going to send you the patch | 21:01.47 |
| | be sure to run with -sOutputICCProfile=ps_rgb.icc | 21:01.52 |
| tkamppeter | mvrhel2, OK, I will try. | 21:02.05 |
| mvrhel2 | sent. | 21:02.40 |
| | got to go | 21:02.42 |
| | I will check IRC and email while out. | 21:02.49 |
| | please let me know if it works later | 21:02.54 |
| | bye | 21:02.56 |
| henrys | alexcher:do you know about this one 692349? Wasn't that fixed? | 21:08.22 |
| alexcher | henrys: I don't know but it's easy to check. | 21:11.53 |
| | henrys: Current version compiles fine on VS 2003. | 21:12.54 |
| henrys | with the unicode stuff enabled? | 21:14.06 |
| alexcher | henrys: I have VS 2003 ready and can check what SaGS says in the comment #3. | 21:14.45 |
| | henrys: I was using default build. | 21:15.26 |
| | henrys: I'm going away to the Windows box. | 21:17.04 |
| | marcosw: Does the bug 692375 happen in debug or release build? | 22:56.50 |
| | Forward 1 day (to 2011/07/30)>>> | |
IRC Logs