| | <<<Back 1 day (to 2013/10/29) | 2013/10/30 |
| Robin_Watts | ray_laptop: Could this be related to the fact that we see "leaking" profiles with NumRenderingThreads? | 00:02.17 |
| ray_laptop | mvrhel_laptop: I see the following pattern (looking at the large 550Kb chunks): | 00:19.18 |
| | [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3aa0058: OK, used=18849477, max=19434641 | 00:19.20 |
| | [a+]gs_malloc(lcms)(557168) = 0x3b30058: OK, used=19410025, max=19434641 | 00:19.22 |
| | [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3bc0058: OK, used=19987681, max=19987681 | 00:19.23 |
| | [a+]gs_malloc(lcms)(557168) = 0x3c50058: OK, used=20548229, max=20548229 | 00:19.25 |
| | [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3ce0058: OK, used=21125885, max=21125885 | 00:19.26 |
| | [a+]gs_malloc(lcms)(557168) = 0x3d70058: OK, used=21686433, max=21686433 | 00:19.28 |
| | [a-]gs_free(rc_free_icc_profile) 0x3ce0058(557168) | 00:19.29 |
| | [a-]gs_free(lcms) 0x3d70058(557168) | 00:19.31 |
| | [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3ce0058: OK, used=21125885, max=21711049 | 00:19.32 |
| | [a+]gs_malloc(lcms)(557168) = 0x3d70058: OK, used=21686433, max=21711049 | 00:19.34 |
| | [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3e00058: OK, used=22243945, max=22243945 | 00:19.35 |
| | [a+]gs_malloc(lcms)(557168) = 0x3e90058: OK, used=22804493, max=22804493 | 00:19.37 |
| | [a-]gs_free(rc_free_icc_profile) 0x3e00058(557168) | 00:19.38 |
| | [a-]gs_free(lcms) 0x3e90058(557168) | 00:19.40 |
| | In this snippet 0x3750058 gets allocated, then 0x3b30058 followed by 0x3bc0058, 0x3c50058, 0x3ce0058 and 0x3d70058. The onliest one I see getting freed in the sequence is 0x3ce0058. Since each of these is 550Kb, no wonder there's a problem. I _do_ see a lot of these getting freed by a GC later, so it seems we aren't managing these properly | 00:19.41 |
| ray_laptop | floods IRC :-) | 00:19.44 |
| | after the GC, it seems that the usage goes from 323,948,769 down to 26,744,325.! The garbage truck must have been really full :-) | 00:21.56 |
| | Robin_Watts: sorry. I was putting together that flood for mvrhel_laptop. Maybe email might have been better. :-/ | 00:22.52 |
| | Robin_Watts: Do we see a lot of leaked profiles during rendering. I thought it was only one or two ? | 00:23.27 |
| Robin_Watts | ray_laptop: For tiger it's 3 blocks per band. | 00:26.07 |
| | but tiger hardly stresses the color system. | 00:26.19 |
| ray_laptop | Robin_Watts: OK, but after each band, those get freed. | 00:26.36 |
| Robin_Watts | ray_laptop: Right, but what if in a more complex file than tiger, we're leaking more blocks. | 00:28.44 |
| ray_laptop | Robin_Watts: please try tests_private/pdf/PDF_1.7_ATS/tests_private/pdf/AIX361DC_Save.pdf if you want, but all of the problems I see are during *writing* the clist | 00:28.45 |
| Robin_Watts | oh, ok. I was just mentioning it as an idea. | 00:29.02 |
| | That does sound different. | 00:29.15 |
| ray_laptop | The "used" at Outputpage start is 616,549,476 and at Outputpage end it is 618,125,584 and there are no GC's during print_page | 00:31.19 |
| | Robin_Watts: and I don't mind questions. Mostly this is for mvrhel_laptop when he consults the logs | 00:32.05 |
| | and me answering you helps keep him from some dead-ends | 00:32.30 |
| | maybe | 00:32.39 |
| | mvrhel_laptop: I am running HEAD debug build on Windows with: debugbin/gswin32c -r600 -dBandHeigt=128 -sDEVICE=ppmraw -o x.ppm -dPDFDEBUG -Z:a c:/Artifex/tests_private/pdf/PDF_1.7_ATS/AIX361DC_Save.pdf | 00:34.17 |
| | the -Za is noisy, but tracks the large allocations well | 00:34.42 |
| | I have the -Z: so I can separate parsing and rendering in the log. I capture the output with: > log 2>&1 | 00:35.48 |
| Robin_Watts | ray_laptop: You know you misspelt BandHeight there, right? | 00:36.35 |
| ray_laptop | mvrhel_laptop: I am going to see if there are other things I can see leaking. | 00:36.39 |
| | Robin_Watts: oops. | 00:36.45 |
| Robin_Watts | just in case that is significant | 00:36.55 |
| ray_laptop | but it shouldn't make a difference during clist writing. | 00:37.09 |
| | I'll re-run it | 00:37.19 |
| Robin_Watts | Bah. No SSE3 support in VS2005 :( | 00:37.27 |
| ray_laptop | that's why it had so many bands (729) | 00:38.07 |
| | Robin_Watts: so what? Is anybody running anything older than 2008 ? | 00:38.36 |
| Robin_Watts | I run 2005 routinely. | 00:38.45 |
| ray_laptop | (although I still have MSVC 6) | 00:38.53 |
| Robin_Watts | It's important that releases are done with VS2005. | 00:39.01 |
| | cos VS2008 binaries don't run on anything older than XP SP1, if memory serves. | 00:39.25 |
| ray_laptop | Robin_Watts: so why do you want (need) SSE3 ? | 00:39.25 |
| Robin_Watts | With SSE3 I can save a few cycles. | 00:39.38 |
| | so I have some #ifdefs in there. | 00:39.50 |
| ray_laptop | might be. I have an old machine I can check. Are you concerned about Windows 95 ?? | 00:40.13 |
| Robin_Watts | ray_laptop: Frankly I don't care. But 801 might not have SSE3 available in their targets. | 00:40.45 |
| | so I'll leave the ifdef stuff in there for now. | 00:40.54 |
| ray_laptop | Robin_Watts: true. | 00:40.55 |
| | Robin_Watts: can't that be a runtime check ? | 00:41.06 |
| | iirc, there's a call to check SSE level | 00:41.26 |
| Robin_Watts | ray_laptop: It could be a runtime check, but unless we really need them, runtime checks are bad. | 00:42.10 |
| ray_laptop | Robin_Watts: BTW, the max_used with -dBandHeight=128 (52 bands) is 894,485,169 (slightly worse) and at Outputpage start it is the same, so the problem is totally during parsing | 00:44.12 |
| Robin_Watts | cool. | 00:44.43 |
| ray_laptop | well, maybe :-/ | 00:44.54 |
| Robin_Watts | So with a single band, same issue? | 00:45.01 |
| | Does it need to be 600dpi? | 00:45.41 |
| ray_laptop | I haven't tried, but I will -- the allocation for the buffer will be larger, of course | 00:45.44 |
| | Robin_Watts: that's there params | 00:45.54 |
| | s/there/their/ | 00:46.02 |
| Robin_Watts | If it was my problem I'd try to whittle everything down as small as possible, cos smaller things fit in my small brain more easily :) | 00:46.40 |
| ray_laptop | Robin_Watts: as expected. max_used at Outputpage start time is: 1,398,485,170 | 00:47.55 |
| | !!!! :-0 | 00:48.13 |
| Robin_Watts | That's with 1 band at 600dpi? | 00:48.33 |
| ray_laptop | yep | 00:48.57 |
| | testing page mode now. Should be similar | 00:49.10 |
| Robin_Watts | oh, the problem shows up in page mode too? | 00:49.47 |
| ray_laptop | if it's during clist writing, why not (don't know yet) | 00:50.11 |
| | of course, it could be a *lot* worse since the PDF 14 transparency will be in page mode. This is a pretty awful file. | 00:51.40 |
| | and it is taking a LOT longer. | 00:51.50 |
| | OK. in page mode max is: 889,346,965 | 00:53.36 |
| | and that happens before "Outputpage start time" as expected | 00:54.49 |
| | although the larger max for a single band is somewhat inconguous | 00:55.31 |
| Robin_Watts | So it's not a clist problem. I'd find that a relief personally :) | 00:58.16 |
| ray_laptop | I don't think I spelled incongruous correctly | 00:58.47 |
| Robin_Watts | Is the size of the leak resolution independent ? | 00:58.48 |
| ray_laptop | I'll check... still collecting logs for BandHeight=128 | 01:01.34 |
| | OK, running -r72 page mode... | 01:01.45 |
| | wow! page mode 72 dpi, max = 1,820,165,519 | 01:03.15 |
| | although, bear in mind that page mode allocates whatever size transparency buffers are needed, not constrained to a band | 01:04.07 |
| Robin_Watts | how can 72dpi be larger than 600dpi? | 01:04.28 |
| | 889Meg vs 1.8Gig ? | 01:04.38 |
| ray_laptop | -r72 -dBandHeight=128 has a max at Outputpage start of 833,667,051 | 01:05.51 |
| Robin_Watts | oh, I see. page mode > clist. gotcha. | 01:06.41 |
| ray_laptop | retesting page mode 600 | 01:06.56 |
| Robin_Watts | rats. Just thought of a better way to do this last SSE case. | 01:07.41 |
| | will look at it tomorrow. I should go to bed. Have a good night ray. | 01:07.54 |
| ray_laptop | you, too, Robin_Watts | 01:08.17 |
| | the supposed page mode 600 was really 729 bands. I had used -dMaxBitmap=500m, but with transparency that used clist mode, and I didn't use -dBufferSpace=500m which would have given me 6 bands. | 01:15.18 |
| | but the page mode 72 dpi is conclusive that it _is_ a parsing time problems | 01:15.40 |
| | back to the pad+alignment debug... | 01:16.00 |
| | hmm... it appears that ghostbot might be down | 04:40.08 |
| | restarting it... | 04:40.18 |
| | OK, seeing if that fixes it. | 04:41.58 |
| | I suspect that doing edits on the logs messes up infobot | 04:42.26 |
| | If it's OK, I should see this is a few | 04:42.48 |
| | ghostbot appears OK. | 04:45.46 |
| | OK. Step 1 "cure everything my changes broke" :-) | 04:52.28 |
| | At least it tigers :-) | 04:52.39 |
| | regression running with the "normal" defaults. | 05:02.02 |
| | Next I try forcing a pad and alignment locally.Alignment of 8 (default is 4) and pad of 5 | 05:02.48 |
| mvrhel_laptop | ray_laptop: you around? | 05:30.33 |
| ray_laptop | mvrhel_laptop: yes, for a bit | 05:36.48 |
| mvrhel_laptop | ok. | 05:36.58 |
| | So I was just sending a file to Robin for him to check with customer 801's device | 05:37.20 |
| ray_laptop | I got around 17K segfaults from my alignment changes, so I would like an excuse to set it aside for the night | 05:37.44 |
| mvrhel_laptop | the interpreter is doing a range check error late in the running of the file and I can't quite figure out why | 05:37.47 |
| | ray_laptop: wow that sounds like something I would do | 05:38.06 |
| ray_laptop | naw, it's just that the planar device probably has some hidden assumptions | 05:38.34 |
| mvrhel_laptop | anyway, I can't get very far with my color testing until I figure out what is going wrong here. I will cc you in the email if you want to take a look in the morning | 05:39.20 |
| ray_laptop | sort of "I know how memory is arranged -- don't bother me with accessing it the right way" ;-) | 05:39.22 |
| mvrhel_laptop | I was not aware that there were ICC profiles leaking by the way | 05:39.33 |
| ray_laptop | mvrhel_laptop: I can look now. | 05:39.36 |
| mvrhel_laptop | or is it links | 05:39.38 |
| | ray_laptop | 05:39.48 |
| | ok let me email you the file | 05:39.53 |
| ray_laptop | mvrhel_laptop: do we generate links during the parsing stage when it's going to the clst ? | 05:40.07 |
| | but it is suspicious that the profiles are all exactly the same size as the one (just one) in the PDF -- obj 24 | 05:41.05 |
| | so, in the email, do you describe the problem ? or do you want to tell me here ? | 05:41.59 |
| mvrhel_laptop | ray_laptop: we will for graphic fills | 05:42.12 |
| | ray_laptop: I just sent the email and described the issue | 05:42.38 |
| ray_laptop | mvrhel_laptop: OK. Checking ... | 05:42.48 |
| mvrhel_laptop | basically if you run it with the 8 bit customer device | 05:42.49 |
| | no need to worry about a profile | 05:42.56 |
| ray_laptop | got it | 05:42.59 |
| mvrhel_laptop | when an error like this happens in the interpreter it gets hard for me to debug | 05:43.46 |
| | ray_laptop: so with the icc stuff, if we are doing a graphic fill, we will go ahead and render to the device value | 05:45.14 |
| | no icc profile stored. | 05:45.17 |
| | only in the case of images, and tranparency do profiles get put in the clist | 05:45.34 |
| ray_laptop | well, you know that rangecheck is not as common as something line undefined | 05:45.39 |
| | mvrhel_laptop: private tab, please | 05:47.34 |
| mvrhel_laptop | ok | 05:47.40 |
| ray_laptop | mvrhel_laptop: do you see the tab ? | 05:49.03 |
| | mvrhel_laptop: I'll have to pull in and build Robin's stuff. I get a segfault down in their device | 05:59.02 |
| mvrhel_laptop | oh wow | 05:59.16 |
| ray_laptop | width600 == 0 when trying to divide | 05:59.23 |
| mvrhel_laptop | well Robin's stuff is an improvement over that.... | 05:59.39 |
| ray_laptop | in their print_page | 05:59.51 |
| | OK. well, I guess I'll have a look in the AM. | 06:00.08 |
| mvrhel_laptop | ray_laptop: ok sounds good | 06:00.17 |
| | I am fading fast | 06:00.19 |
| | since my son's as gotten into middle school late nights are harder for me | 06:00.41 |
| ray_laptop | if you want to work on it in the meantime, set a brakpoint with a big count in gs_log_error | 06:00.42 |
| mvrhel_laptop | ray_laptop: yes I did that | 06:00.55 |
| | the problem is that the error is printed by the interpreter | 06:01.05 |
| ray_laptop | conditional on err == -15 | 06:01.15 |
| mvrhel_laptop | hmm ok let me do that | 06:01.49 |
| ray_laptop | gs_log_error will (should) show you the C code that sets it. | 06:01.55 |
| mvrhel_laptop | I would have thought though -Z# would have shown it | 06:02.03 |
| | and it does not | 06:02.05 |
| ray_laptop | unless it is done with PS and signalerror | 06:02.10 |
| mvrhel_laptop | that is what it seems to me, as I never got the -15 at the gs_log_error. | 06:02.50 |
| | when Errror: range_check is printed | 06:03.06 |
| | and it is bookended by some standard errors in indict.c | 06:04.03 |
| | right before the rangecheck from the interpreter there is a idict.c error -2 but that occurs about a zillion times | 06:04.51 |
| | also a -20 in gsparam, also a common one | 06:05.07 |
| | no -15 | 06:05.12 |
| | just Error: /rangecheck | 06:05.32 |
| | anyway. maybe Robin will figure it out while we sleep | 06:05.55 |
| | have a good night ray_laptop | 06:06.02 |
| ray_laptop | mvrhel_laptop: there are rangecheck signalled from the PS interp. | 06:06.13 |
| | finding them is a bitch | 06:06.22 |
| mvrhel_laptop | ray_laptop: yes that is why I called you in :) | 06:06.33 |
| ray_laptop | -dESTACKPRINT can help if you can get that printout. | 06:06.42 |
| mvrhel_laptop | oh I can stick on in where the error occurs | 06:07.15 |
| ray_laptop | toward the bottom it shows you the "tail" of what you were executing (what remains in a proc) | 06:07.16 |
| mvrhel_laptop | in the ps code | 06:07.17 |
| ray_laptop | mvrhel_laptop: I will pull in Robin's code and build and have a look in the AM | 06:07.51 |
| | I am also fading. | 06:07.57 |
| mvrhel_laptop | ok. sounds good | 06:08.03 |
| ray_laptop | g'nite | 06:08.08 |
| mvrhel_laptop | good night | 06:08.38 |
| shmoon | hi | 09:15.18 |
| | are there any differences between what poppler and ghostscript does | 09:15.33 |
| kens | Yes, many | 09:15.39 |
| shmoon | or fundaentally both are meant to solve the dame purpose | 09:15.39 |
| | same* | 09:15.49 |
| | i am trying to understand what each are for | 09:16.27 |
| | from what i read, i understand that ghostscript is used to render pdf or PS documents | 09:16.40 |
| | poppler does the same (rendering of pdf) | 09:16.47 |
| kens | Its a PostScript and PDF interpreter (there are also PCL and XPS interpreters) | 09:17.01 |
| shmoon | whether it is display (monitor) or printer | 09:17.01 |
| kens | AFAIK poppler does not handle PostScript | 09:17.12 |
| shmoon | so fundamentally both are meant for same purposes, kens ? | 09:18.37 |
| kens | depends what exactly you mean. From your point of view, possibly yes. | 09:18.54 |
| shmoon | hm ok | 09:19.19 |
| kens | I am not an expert on Poppler | 09:19.21 |
| shmoon | in poppler i can do pdf2text to get text out of pdf, can i do same with ghostscript? | 09:20.11 |
| kens | There's the txtwrite device | 09:20.20 |
| shmoon | hm, will read up a bit on it, thanks | 09:21.00 |
| kens | If you have a goal in mind, explaining it might allow us to answer better. Generral questions tend to get general answers | 09:21.42 |
| shmoon | yeah i completely agree | 09:24.07 |
| kens | forgot to read the IRC logs :-( | 09:25.00 |
| chrisl | kens: that "new" warning is down to change I did a while back - it's benign, but I have a change to stop the warning which I'll commit later | 09:26.02 |
| kens | Oh, OK, I'm surprised you triggered a warning | 09:26.16 |
| tor7 | Robin_Watts: (re yesterdays discussion with amonakov) I had an experimental patch to do gamma correct anti-aliasing (linearise colors, blend, convert back to srgb) for text | 09:26.54 |
| kens | I got one of my colour problems fixed already this morning, going to try for another before I go out | 09:26.57 |
| chrisl | kens: It wasn't something I considered - why would we warn when an optional entry is missing? I suspect it's for the benefit of Type 3 fonts...... | 09:27.24 |
| kens | That's possible. I don't suppose Alex's Git log had any kind of explanation ? | 09:27.47 |
| chrisl | Not of use, that I remember - I'll check again..... | 09:28.36 |
| kens | I wouldn't be surprised to find it wasn't helpful | 09:28.50 |
| tor7 | Robin_Watts: the problem with do fz_gamma_pixmap is that all non-b&w colors are already in sRGB color space, so they'll get all messed up. | 09:30.07 |
| | amonakov: there's a patch sitting in my personal repo to do gamma correct antialiasing (on the "gamma" branch) | 09:31.36 |
| chrisl | kens: the commit message doesn't explain the warning(s) - it's about encodings and symbolic fonts...... | 09:31.54 |
| kens | Well, taht's definitely unhelpful :( | 09:32.10 |
| tor7 | http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commit;h=14693ddb7980c9754aa5a641c4b1dd1e9e620ecd | 09:32.15 |
| kens | sybolic fonts aren't supposed to have encodings | 09:32.20 |
| chrisl | Yes, true, but they often do..... anyway, it was basically that I missed that it's up to the caller of the proc to check if the font object has an encoding, when the encoding is optional | 09:38.11 |
| | Off to squash..... | 09:43.43 |
| kens | bye folks, back in a bit | 10:25.17 |
| Steve___ | hello | 10:51.24 |
| | I was wondering if anyone here could help with me some problems ive been having with Ghostscript? | 10:52.52 |
| tor7 | Steve___: no one can help you if you first don't explain your problems. | 11:00.22 |
| Steve___ | hi tor7 - we use ghostscript with another program called PDF2TIFF - its basically a front end that sorts files into various folders depending on their extension | 11:01.33 |
| | the problem we are having is that ghostscript seems to be converting 40kB PDFs into 8MB TIFFs - is there any way we can make the output smaller? | 11:02.02 |
| tor7 | Steve___: TIFF generally doesn't compress very well. if you're looking for small file sizes and can live with RGB colors, I'd recommend using PNG instead. | 11:03.49 |
| | also, PDF is a vector format, so files that only contain text or line art can be very small. render them to a bitmap and they'll be big no matter what. | 11:04.21 |
| | if your TIFF are black&white (no grayscale) then you could try the tiffg4 device | 11:05.57 |
| Steve___ | right ok | 11:07.56 |
| | how would I use the tiffg4 device? | 11:09.16 |
| | we dont actually run ghostscript ourselves, we use another program as a front end that basically runs it for us | 11:10.02 |
| tor7 | Steve___: I have no idea, you'd have to look at the front end program and see if you can tweak the options it calls gs with | 11:11.37 |
| Steve___ | ah ok, I was worried you might say that haha | 11:11.59 |
| | ive had a look and there are no options for that, all it does is sort files in a folder before running the PDFs through ghostscript | 11:12.34 |
| | im in contact with the guys who made the front end to see if they can recommend anything, but thanks for your help anyway | 11:13.05 |
| sebblonline | Hi, does anyone know or can say, when there will be the next official release of mupdf downloadable on mupdf.com? Does that depend on the number of fixes or commits? I'm asking, because I made a report a month ago and wanted to know, when the fix will be available in the release. | 11:18.39 |
| Steve___ | hello again | 11:28.10 |
| | what commands would I need in the command line to get it to output in smaller resolutions? | 11:31.50 |
| | I found where our front end software runs the executable for ghostscript, and I was wondering if I could just add some specific options to the end of the filepath to change the output resolution, similar to this: "c:\path\to\exe\program.exe" -option1 - would that work with ghost script? | 11:35.46 |
| | so something like "c:\program files\gs\gs9.10\bin\gswin64c.exe" -gs -sDEVICE=tiffg4 -r600x600 ? | 11:57.09 |
| tor7 | Steve___: yes, something like that should work | 12:18.24 |
| | sebblonline: we normally aim for two releases a year | 12:18.44 |
| | I believe we're aiming at march for the next mupdf release | 12:19.36 |
| sebblonline | Ok, thanks for the info! | 12:21.06 |
| Robin_Watts | sebblonline: Has a fix gone in for your bug? | 12:36.15 |
| | ok, SSE code all working. | 12:55.09 |
| | Morning mvrhel_laptop | 13:57.13 |
| mvrhel_laptop | good morning Robin_Watts | 14:08.18 |
| | did you get a chance to look at the error? | 14:08.28 |
| | it had me puzzled | 14:08.41 |
| henrys | kind of a pain in the ass recompiling everything when I switch git branches - guess I could change the GENDIR makefile variable for each branch. Does this only bother me? | 14:26.21 |
| kens | I don't often switch branches | 14:27.00 |
| chrisl | henrys: In theory, if all the dependencies are good, it should only rebuild what's changed, but...... well, hmmm :-( | 14:29.06 |
| henrys | once you have a project off on the side for a while something important will change like a makefile than your hosed. | 14:31.01 |
| kens | I guess I just don't work like that | 14:31.36 |
| chrisl | Well, when makefiles change, all bets are off - deal with it! | 14:31.43 |
| | henrys: I don't find a minute or so to rebuild especially onerous, personally | 14:32.26 |
| kens | takes longer on Windows... | 14:32.45 |
| chrisl | True, but I assume henrys is on Mac most of the time | 14:33.15 |
| henrys | oh no parallel compile on windows? | 14:37.49 |
| kens | nope | 14:37.58 |
| chrisl | Not with nmake, no | 14:38.08 |
| | Interesting: qt has an nmake clone that supports parallel builds....... | 14:42.55 |
| henrys | chrisl: wow | 14:46.10 |
| chrisl | henrys: I think it might balls up our detection of the VS version, though :-( | 14:46.49 |
| Robin_Watts | mvrhel_laptop: No, no luck at all. | 14:47.19 |
| | mvrhel_laptop: I found myself pondering whether we actually need DeviceN stuff at all... | 14:47.38 |
| | We only need to deal with 5 colorants; do we need to resort to DeviceN as soon as we do anything other than gray/rgb or cmyk ? | 14:49.04 |
| | mvrhel_laptop: Aha. The rangecheck thing is my fault. It's in the put_params stuff. Let me try and figure out where/why | 14:56.56 |
| | henrys: Did you read Marti's proposal about lcms2? | 15:05.22 |
| henrys | not carefully yet I will get to it shortly | 15:06.06 |
| Robin_Watts | ok, np. | 15:06.57 |
| | mvrhel_laptop: ping me when you return. | 15:13.48 |
| mvrhel_laptop | Robin_Watts: I am back | 15:20.00 |
| | so you have a fix for the rangecheck | 15:20.16 |
| Robin_Watts | I have found the rangecheck mistake. that was me, sorry. | 15:20.19 |
| | I get reasonable CMYB output, but the K output is broken for your file. | 15:20.42 |
| | trying to figure out why now. | 15:20.46 |
| | Do you want a new copy of the device? | 15:20.55 |
| mvrhel_laptop | yes that would be great | 15:21.15 |
| | then I will look at the deviceN handling | 15:21.24 |
| Robin_Watts | gdevXXXX.c in my home dir. | 15:21.45 |
| mvrhel_laptop | ok thanks | 15:21.53 |
| Robin_Watts | I've got a hack in there at the moment. | 15:21.56 |
| | The current code lists both "Blue" and "XXXXBlue" as colorants. | 15:22.21 |
| mvrhel_laptop | that is one odd thing that I don't believe is right | 15:22.46 |
| Robin_Watts | I've hacked the 'get_comp_index' function to treat "Blue" and "XXXXBlue" and "XxxxBlue" as being the same. | 15:23.05 |
| mvrhel_laptop | oh | 15:23.11 |
| Robin_Watts | in the new version on casper. | 15:23.19 |
| mvrhel_laptop | ok | 15:23.30 |
| Robin_Watts | You may decide that's a bad thing. | 15:23.31 |
| | I did that just to see if that was the cause of the rangecheck (It wasn't) | 15:23.43 |
| mvrhel_laptop | right | 15:23.47 |
| | I had done a similar thing | 15:23.54 |
| | what was the source of the issue? | 15:24.12 |
| tor7 | Robin_Watts: oh, bollocks. did you turn fz_stroke_state into a shared reference counted struct? | 15:24.17 |
| mvrhel_laptop | out of curiosity | 15:24.17 |
| Robin_Watts | mvrhel_laptop: put_params tests the values for being out of range. | 15:25.16 |
| | and throws a range check if they are bad. | 15:25.27 |
| | I had cocked up some of those tests :( | 15:25.34 |
| | tor7: It is reference counted, and shared, yes. That may even have been me. | 15:25.53 |
| tor7 | Robin_Watts: I'm scared. sharing a struct that just bundles some state... so I basically have to malloc a new stroke_state struct for each path I draw? | 15:26.56 |
| Robin_Watts | tor7: not sure offhand. Let me look. | 15:27.38 |
| tor7 | I wonder why you did that though... before we just copied the data into the display list when needed | 15:27.39 |
| | which is kind of what I still assumed, but now I've got pointers in the display list into my (stale and overwritten) stack-stored fz_stroke_state... :( | 15:28.31 |
| Robin_Watts | Currently I think you should always be using fz_new_stroke_state. | 15:29.18 |
| | which will malloc. | 15:29.22 |
| tor7 | Robin_Watts: I am making good progress on having the svg-device tigering | 15:29.31 |
| | Robin_Watts: bah. I don't like it... it's a lot of keeping track of stroke states when I didn't use to have to, so as not to clobber any stowed away states by accident :( please tell me you had a good reason. | 15:30.45 |
| Robin_Watts | We *could* allow the use of stack based stroke_states by having them use a negative ref count, and when we 'keep' them, we could clone it automatically? | 15:30.55 |
| tor7 | svg-input, not device | 15:31.03 |
| Robin_Watts | tor7: I'm sure I had a very good reason. | 15:31.07 |
| | tor7: Right. | 15:31.11 |
| | and I'm sure I discussed it with you at the time. Though I cannot remember why or when :) | 15:31.51 |
| tor7 | Robin_Watts: me neither... though I do have a vague recollection of having discussed it! :) | 15:32.11 |
| | my main worry is if we make the eventual "canvas" api, everyone and his mother is going to screw up and clobber stroke states that have been put into display lists | 15:33.05 |
| Robin_Watts | tor7: We have an 'unshare' mechanism in there. | 15:33.26 |
| tor7 | Robin_Watts: if you'd done it to add dynamically allocated dash-stroke-lists I would have understood, but the dash list is still capped to 32 entries | 15:34.02 |
| Robin_Watts | tor7: No, it's not. | 15:34.14 |
| | fz_new_stroke_state_with_len | 15:34.20 |
| tor7 | ah, so that's why! | 15:34.36 |
| | that ought to be ...with_dash_len | 15:34.49 |
| Robin_Watts | feel free to rename. | 15:35.24 |
| tor7 | will do. | 15:35.36 |
| | Robin_Watts: how do you feel about not reference counting, still mallocing, but cloning when inserting into the display list? | 15:36.02 |
| | or maybe we should make it opaque, and use some sort of copy-on-write mechanism | 15:36.31 |
| Robin_Watts | The 'unshare' is supposed to be copy on write. | 15:36.47 |
| tor7 | anyway, I can proceed now that I know what's going on but this could be a sore spot in the api | 15:36.51 |
| Robin_Watts | I like the idea of having stack based ones with a negative ref count. | 15:37.13 |
| | so we'd do: fz_stroke_state ss = fz_default_stroke_state; | 15:37.38 |
| | Then ss.blah = ...; to set it up. | 15:37.46 |
| | Then do the call with &ss | 15:37.56 |
| | Then when the called thing does fz_keep_stroke_state, we have that spot refs = -1 and do a malloc/copy. | 15:38.20 |
| tor7 | Robin_Watts: yeah, I think that's a reasonable approach | 15:44.10 |
| | or just refs = 0? | 15:44.23 |
| | seeing as we use refs = -1 for const stuff | 15:44.38 |
| Robin_Watts | refs = -1 generally denotes constant... | 15:44.42 |
| | yes. | 15:44.44 |
| | I worry that 0 might work under debug builds and fail under release ones? | 15:45.02 |
| | if people forget to init them. | 15:45.10 |
| chrisl | Use MAX_INT for stack based? | 15:46.08 |
| tor7 | Robin_Watts: yeah, that is a worry | 15:47.05 |
| Robin_Watts | chrisl: yeah, -2, MAX_INT, any value like that would be fine. | 15:47.07 |
| tor7 | I'm not opposed to -1 (if we think of it as 'magic' rather than 'const') | 15:47.25 |
| | Robin_Watts: did you take a look at the commits on tor/master yet? | 15:47.42 |
| Robin_Watts | tor7: I suspect -2 would be better, as we get the option of having both 'const' and 'magic'. | 15:47.54 |
| | tor7: sorry, no. Busy with 801 currently. | 15:48.17 |
| | but I will try to as soon as I fix what I've broken here. | 15:48.26 |
| tor7 | right. no rush. | 15:48.28 |
| mvrhel_laptop | Robin_Watts: I see that yes, there is an issue with black | 15:50.56 |
| | do you want me to figure it for you? | 15:51.07 |
| Robin_Watts | mvrhel_laptop: I'm working on it now. | 15:51.17 |
| mvrhel_laptop | ok | 15:51.43 |
| | let me know when you have it fixed then I will take another look at things | 15:51.58 |
| Robin_Watts | I'm very confused, cos this was working earlier. | 15:52.30 |
| | Oh, it works for tiger, but not for your file! | 15:52.56 |
| mvrhel_laptop | Robin_Watts: I get black output with my file. but it is def wrong | 15:53.41 |
| Robin_Watts | I get diagonal noise for black on your file. | 15:54.30 |
| mvrhel_laptop | oh not me | 15:55.08 |
| | I get nice rectangles in the black plane | 15:55.18 |
| Robin_Watts | actually, I don't even get the other planes out readably. This is going to be something really stupid... | 15:55.25 |
| mvrhel_laptop | but I am using the icc profile and defining the colorants | 15:55.28 |
| | too | 15:55.31 |
| | i.e. using the customer command line | 15:55.41 |
| henrys | Robin_Watts: so the docx of October 14 is complete and latest. | 15:56.03 |
| mvrhel_laptop | Robin_Watts: I am going to create the psdcmyk output for this case as we should match that | 15:56.32 |
| | plane for plane with their profile | 15:56.42 |
| Robin_Watts | henrys: If it has his time estimates at the bottom, yes. | 15:56.48 |
| | mvrhel_laptop: Well, no. | 15:56.59 |
| | Their device gets the noise offsets wrong per band. | 15:57.27 |
| mvrhel_laptop | color wise yes if I use the same profile | 15:57.28 |
| Robin_Watts | unless you set the bandheight to 256 or something. | 15:57.52 |
| henrys | Robin_Watts: no I don't see time estimates are you certain I was copied in? | 15:58.06 |
| mvrhel_laptop | Robin_Watts: I guess I am not following you | 15:58.13 |
| | what noise offsets? I are you talking about halftoning? | 15:58.27 |
| | s/I are/Are/ | 15:58.41 |
| Robin_Watts | henrys: On Sunday, Marti copied to tech | 15:58.52 |
| | mvrhel_laptop: Yes, the halftoning. | 15:59.06 |
| chrisl | Robin_Watts: only Artifex people can send to tech...... | 15:59.26 |
| Robin_Watts | The output from their device is 4bpp, with halftoning. | 15:59.34 |
| mvrhel_laptop | ok well the avg. of the squares should match | 15:59.35 |
| Robin_Watts | ok. | 15:59.45 |
| mvrhel_laptop | I did not mean pixel for pixel | 15:59.52 |
| Robin_Watts | Oh, let me forward to tech then. | 15:59.54 |
| | mvrhel_laptop: Sorry. | 15:59.57 |
| | chrisl: That's... a shame. | 16:00.45 |
| | I've copied his message to tech now. | 16:00.59 |
| chrisl | Robin_Watts: it's been that way since I joined | 16:01.29 |
| mvrhel_laptop | Robin_Watts: thanks for adding the pgm suffix and getting the range to 255. much better. | 16:01.29 |
| ray_laptop | morning, all. | 16:03.36 |
| Robin_Watts | morning ray | 16:03.41 |
| mvrhel_laptop | Robin_Watts: oh that is interesting | 16:03.45 |
| ray_laptop | Robin_Watts: I'm going to look into my psdcmyk segfaults now | 16:03.51 |
| mvrhel_laptop | the psd device with their profile has the blacks wrong | 16:04.08 |
| | I need to look at their profile | 16:04.14 |
| | I suspect that we have an ordering issue here | 16:04.53 |
| henrys | Robin_Watts: looks good just need dollar estimate - does he want to send that privately, is that why it was not included in the document? | 16:06.47 |
| Robin_Watts | henrys: I figured that the rate he decides to charge artifex is nothing to do with me, and could be handled by you and Miles etc :) | 16:07.30 |
| henrys | okay I'll send him email | 16:07.55 |
| mvrhel_laptop | and the profile is fine | 16:09.28 |
| henrys | Robin_Watts: I'm surprised he got away with globals in a shared library without other complaints. | 16:09.58 |
| mvrhel_laptop | oh due | 16:10.02 |
| | duh | 16:10.04 |
| | I had copied their command line as it was in their readme | 16:10.46 |
| | it will not work the way that they have it for that profile | 16:10.56 |
| Robin_Watts | EH?! band_height = 132, so how can I be being called with 133 lines of data each time? | 16:14.06 |
| mvrhel_laptop | interesting. colors are still wrong :( | 16:14.06 |
| | oh. no actually they are correct | 16:14.25 |
| | Robin_Watts: so the colors from the customer device look correct | 16:20.06 |
| | when I use their profile and the proper name ordering | 16:20.19 |
| | in the command line | 16:20.25 |
| | However, I just left one spot name in the list of colorants | 16:22.51 |
| | it makes no sense to have Blue and XXXXBlue | 16:23.02 |
| | Since the profile only has XXXXBlue according to their command line | 16:23.27 |
| Robin_Watts | mvrhel_laptop: I agree that we should just leave 1 spotname in the colorants. | 16:23.38 |
| | But I worry that they might have PDF files set to have a "Blue" separation. | 16:23.57 |
| | so mapping "Blue" to "XXXXBlue" might be smart? | 16:24.07 |
| mvrhel_laptop | Robin_Watts: The spot color "Blue" will end up using a lot of XXXXBlue when going through the profile | 16:25.29 |
| | And is a common name | 16:25.58 |
| Robin_Watts | ok. I didn't realise that. | 16:26.23 |
| mvrhel_laptop | that may have different meanings not associated with their ink | 16:26.27 |
| | I will plan to ask them about this | 16:26.38 |
| Robin_Watts | Then I wonder why they listed it in their device? | 16:26.39 |
| | OK. | 16:26.41 |
| mvrhel_laptop | I would for now, just keep XXXXBlue | 16:26.53 |
| Robin_Watts | Seems sensible. I will make that change here. | 16:27.37 |
| | clist_dev_spec_op is not forwarding in the way I would have hoped it would. | 16:28.12 |
| | It forwards to gdev_prn_dev_spec_op. | 16:28.33 |
| | Not to the dev_spec_op of the clist target device. | 16:28.51 |
| | oh... clist has stolen the dev_spec_op by that point... | 16:31.39 |
| | I need to discuss this with ray... | 16:31.47 |
| | ray_laptop: You here? | 16:31.51 |
| ray_laptop | Robin_Watts: I understand why you are able to run without the pad. Each line "wraps" to the next line (maybe in the next plane) and then on the last line of the last plane, you pick up line_ptrs as the garbage. At least you aren't in danger of segfault as long as you have enough line ptrs | 16:32.02 |
| mvrhel_laptop | Robin_Watts: I am going over the DeviceN stuff now. num_std_colorant_names is set incorrectly for some reason | 16:32.04 |
| Robin_Watts | It's set to 5, right? | 16:32.30 |
| | ray_laptop: So, I'm having trouble with the bandheight adjustment stuff. | 16:33.20 |
| mvrhel_laptop | right. | 16:33.24 |
| ray_laptop | hmm.. I see. So clist should call the device's proc and rely on it calling the gdev_prn_spec_op proc ? | 16:33.35 |
| Robin_Watts | C M Y K B = 5 ? | 16:33.39 |
| mvrhel_laptop | looks like an issue in the graphics lib | 16:33.39 |
| | right. but XXXXBlue is not a std colorant | 16:33.51 |
| | kinda special | 16:34.00 |
| Robin_Watts | But it's 'standard' for this device maybe? I was guessing when I did this. | 16:34.14 |
| | Why would we need to list "CMYK" as standard colorants? If it really means "standard" colorants, then why is that a device thing. | 16:34.39 |
| | I assumed it meant "standard for this device". | 16:34.46 |
| | i.e. "spot colors that we cope with without having to make new entries". | 16:35.01 |
| mvrhel_laptop | CMYK are standard. there is a test in the code to see if the device has the std CMYK colorants. and it does it by checking the number of std colorants == 4 | 16:35.01 |
| | not the best test | 16:35.13 |
| | I feel | 16:35.17 |
| | I need to look a bit closer | 16:35.25 |
| Robin_Watts | mvrhel_laptop: I'm going to leave this to you :) | 16:35.31 |
| mvrhel_laptop | like I said, this may be an issue in the graphics lib | 16:35.33 |
| Robin_Watts | ray_laptop: So, the problem I have here is that with mvrhel_laptop's file, it wants to use a band_height of 133. | 16:35.57 |
| | and the band_height calculations are done several times, and each time the gxdso knocks it down to 132. | 16:36.19 |
| ray_laptop | Robin_Watts: OK. And you want a multiple of 2, right ? | 16:36.37 |
| Robin_Watts | Then finally it has one last go with 133 only to find that it ends up in clist_dev_spec_op. | 16:36.52 |
| | And that forwards to gdev_prn_dev_spec_op, which doesn't know anything about bandheights, so it returns 133. | 16:37.15 |
| ray_laptop | Robin_Watts: this is all during device setup (prior to clist writing), right ? | 16:37.34 |
| Robin_Watts | clist_dev_spec_op *can't* forward to the target devices dev_spec_op, because the targets dev_spec_op is clist_dev_spec_op at this point. | 16:38.08 |
| | ray_laptop: I assume so, yes. | 16:38.14 |
| | In fact, yes, I'm sure it is. | 16:38.26 |
| ray_laptop | Robin_Watts: clist has the target device and it's procs | 16:38.31 |
| Robin_Watts | cdev->target->procs.dev_spec_op == clist_dev_spec_op | 16:38.50 |
| ray_laptop | and this dosen't work with the get_space_params, or didn't you try that ? | 16:39.42 |
| | and that's what's being called (the target->procs.dev_spec_op) ? | 16:40.30 |
| Robin_Watts | I'm in clist_init_data | 16:40.52 |
| | in gxclist.c at line 463 | 16:41.04 |
| mvrhel_laptop | Robin_Watts: so yes you should set Number colorants for CMYK to 4 on line 389 | 16:47.29 |
| | When they use their 5 color profile this has no effect | 16:47.40 |
| | but with a CMYK profile it will | 16:47.46 |
| | having it at 5 prevents proper color management of the CMYK to CMYK values | 16:48.07 |
| ray_laptop | Robin_Watts: OK, so it's gdev_prn_allocate that does the dirty. It overwrites the procs with the clist procs right after (?) is does the setup as command list | 16:48.48 |
| | it has tucked away the device's orig_procs | 16:49.03 |
| Robin_Watts | Can it forward to the orig_proc ? | 16:49.18 |
| ray_laptop | forward to who ? | 16:49.43 |
| Robin_Watts | Could clist_dev_spec_op forward to the original dev_spec_op somehow? Where is the original one saved? | 16:50.40 |
| ray_laptop | Robin_Watts: do you mean make the orig_procs part of the gx_device_clist instead of in gx_device_printer ? | 16:50.53 |
| Robin_Watts | oh. | 16:51.14 |
| ray_laptop | the original one is in gx_device_printer "orig_procs.dev_spec_op" | 16:51.26 |
| Robin_Watts | gdev_prn_dev_spec_op could maybe call the original one if there was one? | 16:52.06 |
| ray_laptop | Are you sure this can't be done with the get_space_params | 16:52.27 |
| Robin_Watts | I'm not sure of anything anymore! | 16:53.01 |
| ray_laptop | Robin_Watts: OK, that's an approach. It has the orig_procs | 16:53.03 |
| Robin_Watts | But when we discussed this before, we decided on the dev_spec_op. | 16:53.18 |
| ray_laptop | Robin_Watts: yeah, I didn't fight you on it, and it's your favorite hammer ;-) | 16:53.45 |
| | but we need to define the chaining process for dev_spec_op to make sure we don't end up with loops | 16:54.18 |
| | generally a forwarding device calls its target procs | 16:54.59 |
| Robin_Watts | I can unlink the orig_proc before calling it, so it can't loop? | 16:56.06 |
| ray_laptop | and (if I understand it) the actual devices are expected to call gx_default_spec_op ? | 16:56.07 |
| Robin_Watts | yes. | 16:56.24 |
| | Might we ever have the same device having its dev_spec_op being called from more than 1 thread at a time? | 16:57.32 |
| ray_laptop | Robin_Watts: maybe, why ? remember, each thread is a standalone device struct, so even if the spec_op sets something for the device, we are OK | 16:58.47 |
| | I think | 16:58.55 |
| Robin_Watts | ray_laptop: To avoid loops, I could read orig_procs.dev_spec_op, then set that to NULL, then call it, then on return, reset it. | 16:59.21 |
| ray_laptop | but the clist playback in threads can't call the spec_op, can it ? | 16:59.24 |
| Robin_Watts | ray_laptop: Maybe not now, maybe not tomorrow, but one day... | 16:59.54 |
| ray_laptop | Robin_Watts: right, that's done several places, or set it to the default which we know never calls out | 17:00.00 |
| mvrhel_laptop | Robin_Watts: other than that one change, it all looks good to me color-wise | 17:00.25 |
| | nice job | 17:00.34 |
| Robin_Watts | ray_laptop: Right. The only time this would go wrong is if people had a device with a dev_spec_op and made it call gdev_prn_dev_spec_op at the end. | 17:01.00 |
| ray_laptop | Robin_Watts: OK, so I like having the gdev_prn_spec_op call the orig_procs.dev_spec_op with the method you describe | 17:01.07 |
| Robin_Watts | The 'unlinking' trick fails if we have multiple threads calling this. | 17:01.30 |
| ray_laptop | all a device is ever supposed to call is gx_default_spec_op | 17:01.35 |
| mvrhel_laptop | Robin_Watts: and line 433 can go away | 17:01.43 |
| amonakov | hello. what is the recommended way to submit mupdf (fitz) patches? | 17:02.25 |
| Robin_Watts | ray_laptop: In that case, I am tempted not to bother unlinking. | 17:02.59 |
| mvrhel_laptop | impressive looking work in the SSE2 area by the way | 17:03.08 |
| Robin_Watts | mvrhel_laptop: DevCMYKBBComponents is still needed, right? | 17:03.25 |
| mvrhel_laptop | oh yes | 17:03.56 |
| Robin_Watts | but the "number of standard colorants" should be 4, not 5? | 17:04.13 |
| mvrhel_laptop | but just the 5 of them | 17:04.13 |
| | yes | 17:04.19 |
| Robin_Watts | I'm looking at the device definition now... | 17:04.56 |
| | There is the XXXX_DEVICE(...) line | 17:05.14 |
| | and that has a 5 in it. | 17:05.18 |
| | Can you give me specific instructions for what to change please? It'll be safer than me trying to muddle it. | 17:06.04 |
| mvrhel_laptop | line 389 right after DevCMYKBBComponents | 17:06.25 |
| | with the comment /* @@@ Number colorants for CMYK */ | 17:06.34 |
| | should be 4 not 5 | 17:06.40 |
| ray_laptop | Robin_Watts: let me look at something in the clist processing before we decide on a method. | 17:07.13 |
| Robin_Watts | But the MaxSeparations should be 5? | 17:07.27 |
| mvrhel_laptop | yes | 17:07.32 |
| Robin_Watts | mvrhel_laptop: Do we need the update_spot_equivalent_colors stuff? | 17:08.03 |
| | and the ret_devn_params ? | 17:08.08 |
| | and the get_color_mapping_procs? | 17:08.22 |
| | and the get_color_comp_index | 17:08.33 |
| mvrhel_laptop | Robin_Watts: so update spot equivalent is not *really* needed for this device. Since it gives the device information that it can use. However, I don't know what happens if you have it null. ret_devn_params is needed | 17:10.03 |
| | get_color_mapping_procs is needed | 17:10.13 |
| Robin_Watts | mvrhel_laptop: Am I right in thinking that your file should give a completely clear black plane ? | 17:10.21 |
| mvrhel_laptop | no | 17:10.29 |
| | oh let me check in the case where we have no profile | 17:10.46 |
| | or rather when the profile is CMYK | 17:11.49 |
| | as no profile means this to be the case | 17:11.59 |
| | Robin_Watts: ok so yes | 17:12.45 |
| Robin_Watts | Phew. | 17:12.51 |
| mvrhel_laptop | with out using the customer profile the black plane is blank | 17:12.58 |
| | :) | 17:13.25 |
| Robin_Watts | OK, updated gdevXXXX.c in my home dir | 17:13.31 |
| ray_laptop | Robin_Watts: since you and mvrhel_laptop have been going back and forth, where's the 'latest and greatest' code you guys are discussing. I wanted to look at it, too, in a bit | 17:13.55 |
| Robin_Watts | ray_laptop: I will do a zip of all my changes in a mo. | 17:14.15 |
| ray_laptop | Robin_Watts: You don't have a tree in your home dir on casper ? | 17:15.19 |
| Robin_Watts | not with all my changes. | 17:15.32 |
| ray_laptop | oh, I see the gdevXXXX.c file that has a time stamp of just a few minutes ago | 17:16.08 |
| | ls -lt | head is your friend :-) | 17:16.25 |
| Robin_Watts | 801.tar.gz in my home dir is refreshed with everything, including the gdev_prn_dev_spec_op we were just talking about. | 17:17.26 |
| ray_laptop | Robin_Watts: I see two .zip's should I first grab the big one (XXXX_Project_0822.zip) ? | 17:17.43 |
| | if it's the same as was on the FTP site, then I already have it | 17:18.02 |
| Robin_Watts | ray_laptop: The big one is their original device within 9.06 or something like that. | 17:18.11 |
| | that's the one from the ftp site, yes. | 17:18.17 |
| mvrhel_laptop | Robin_Watts: so you can ditch update_spot_equivalent_colors | 17:18.22 |
| Robin_Watts | mvrhel_laptop: Great, thanks. | 17:18.32 |
| ray_laptop | OK. So I just tar -x the 801.zip ? | 17:18.37 |
| mvrhel_laptop | let me double check on the others to see what the defaults do | 17:18.46 |
| ray_laptop | on top of the code base I have ? | 17:18.51 |
| Robin_Watts | mvrhel_laptop: Does that mean I no longer need equivalent_cmyk_color_params equiv_cmyk_colors; in the device definitions? | 17:20.06 |
| | ray_laptop: On top of a current ghostpdl, yes. | 17:20.20 |
| mvrhel_laptop | Robin_Watts: that is true | 17:20.26 |
| | you would use those to construct the simulated composited view | 17:20.43 |
| | and we are not doing that | 17:20.52 |
| Robin_Watts | Great. I blindly copied some of this stuff from psdcmyk, I think. | 17:21.04 |
| | Hmm. | 17:21.25 |
| | the get_color_comp_index function makes reference to the equiv_cmyk_colors | 17:21.45 |
| mvrhel_laptop | hold on let me look this over more | 17:22.45 |
| | Robin_Watts: it can be NULL | 17:25.55 |
| | so just remove | 17:26.13 |
| | and do the call with NULL | 17:26.32 |
| Robin_Watts | cool, thanks. | 17:27.06 |
| ray_laptop | mvrhel_laptop: Len just called. I don't suppose you've gone back to looking at the massive allocation problem, have you ? I think we may need to jump on that soon. They are also P1. | 17:27.20 |
| Robin_Watts | Do we need the thing with the warnings about the number of separations? | 17:27.21 |
| mvrhel_laptop | no that can be removed | 17:27.50 |
| ray_laptop | mvrhel_laptop: we need to get on this before he continues with some hacky solution (that's what he wanted to talk about) | 17:27.53 |
| mvrhel_laptop | ray_laptop: gone back to looking at? I really have not really looked at it as I thought we decided it was not an ICC problem, but now I guess it is | 17:28.58 |
| | ray_laptop: I am about finished up here I think with helping Robin | 17:29.22 |
| Robin_Watts | mvrhel_laptop: Yes. MUCH appreciated. Thanks. | 17:29.35 |
| mvrhel_laptop | then I will help Len | 17:29.44 |
| | Robin_Watts: I really did not do much | 17:29.52 |
| | let me just check a couple other things | 17:30.05 |
| | Robin_Watts: so you can remove warning_given from the device definition | 17:30.50 |
| Robin_Watts | just doing that. | 17:31.00 |
| | So, new 801.tar.gz uploaded. | 17:34.29 |
| mvrhel_laptop | Robin_Watts: ok I think that is all I have for now | 17:38.05 |
| Robin_Watts | mvrhel_laptop: Thanks. | 17:38.16 |
| mvrhel_laptop | Robin_Watts: glad to help out the bit that I could | 17:38.33 |
| Robin_Watts | ray_laptop: Where did the alignment stuff land? Is that on hold while you fight fires for Len ? | 17:38.52 |
| mvrhel_laptop | ray_laptop: ok. let me run and do one thing (3 minutes) and then lets have fun with icc leaks | 17:38.53 |
| Robin_Watts | mvrhel_laptop, ray_laptop: Let me know if I can help with this leaky thing. I can try a memento run if that will help. | 17:39.21 |
| amonakov | excuse me, I have a few questions, is this a good time? | 17:44.28 |
| | I was wondering about the recommended way to submit patches, but there's a couple of other things I'd like to clarify as well | 17:44.57 |
| Robin_Watts | amonakov: Open a bug on bugs.ghostscript.com, mark it as an enhancement, describe exactly what it solves etc, and attach the patch. | 17:45.47 |
| amonakov | ok, thanks | 17:46.37 |
| | the other two questions were about how to add opt-in font hinting (fitz_enable_device_hints?), and assumed colorspace in fitz re: tor7's patch above | 17:47.37 |
| Robin_Watts | Either you'd add a hint to the device, or you'd put something in the context, similar to the antialiasing levels that are there now. | 17:48.36 |
| ray_laptop | mvrhel_laptop: sorry. Took a while to get Len to let me go back to work :-/ | 17:50.01 |
| | Robin_Watts: They aren't *real* leaks in that they just aren't being GC'd. | 17:50.40 |
| | and the profile is getting loaded over and over again even though we already have it laying around. We just "misplaced it" (i.e., forgot about it and left it for the GC to find later) | 17:51.51 |
| mvrhel_laptop | ray_laptop: ok. what do I need to do see this happening | 17:52.18 |
| ray_laptop | Robin_Watts: I don't memento will help with that | 17:52.20 |
| Robin_Watts | ray_laptop: possibly not. | 17:52.51 |
| | tor7: ping | 17:53.02 |
| mvrhel_laptop | ray_laptop: likely a tranparency group issue | 17:53.08 |
| | just a guess anyway | 17:53.32 |
| amonakov | alas, tor7 does not seem to be here; I was hoping to talk to him | 17:53.39 |
| mvrhel_laptop | ray_laptop: let me get set up with the file | 17:53.51 |
| ray_laptop | mvrhel_laptop: I ran the file, with HEAD using: debugbin/gswin32c -r72 -sDEVICE=ppmraw -o x.ppm -dMaxBitmap=1g -d PDFDEBUG -Z:a AIX361DC_Save.pdf > log 2>&1 | 17:54.17 |
| Robin_Watts | tor7: For the logs: Your reviews all look good. The only thing I have questions about is the first one... | 17:55.04 |
| ray_laptop | Then in the log you can look for the *magic* size of the blocks being alloc'ed and freed (557168) | 17:55.19 |
| Robin_Watts | 1) Does our PWG support really do CMYK already? | 17:56.13 |
| mvrhel_laptop | henrys: might end up doing a mt. bike trip in the Yukon this next summer | 17:56.14 |
| henrys | mvrhel_laptop: summer is a good time ;-) Sounds like quite an adventure. | 17:57.04 |
| Robin_Watts | tor7: actually, 1) was my only question in the end :) | 17:57.04 |
| ray_laptop | mvrhel_laptop: the "forget" part may be that we are in a save / restore, but the profile(s) that we forgot were put in stable memory. stable memory is still subject to GC | 17:57.16 |
| | mvrhel_laptop: but that's guessing. | 18:00.44 |
| | Robin_Watts: to answer your question, I am going to budget the rest of the morning to the alignment code, then when I do a push, work on the other part of Len's issue -- getting an error page to print after a VMerror, with expected consultations with mvrhel_laptop if he needs it | 18:02.18 |
| | so, back to alignment for a bit. | 18:02.36 |
| Robin_Watts | ray_laptop: I was going to say that if you want to throw it over to me, and concentrate on Len, feel free. | 18:02.49 |
| | 801 also did a 'bent' tiff device in their sourcetree. | 18:03.31 |
| | I've ignored that for now, but possibly I should be looking at converting that over too ? | 18:03.45 |
| | henrys: ^ | 18:03.55 |
| ray_laptop | Robin_Watts: does it also get the same 4-bit munged stuff from their gxclthrd.c | 18:09.33 |
| Robin_Watts | yes. | 18:09.39 |
| ray_laptop | Robin_Watts: but, I think they mentioned they need TIFF (not clear why). I thought it was just for monochrome | 18:10.01 |
| Robin_Watts | ray_laptop: So, the question is, do I push forwards with a new version of their tiff device, or do we just wait for the padding/alignment stuff, fix the SSE to make use of that, and then send them that as a starting shot? | 18:11.23 |
| ray_laptop | Robin_Watts: well, it seems like the 'process_page' changes are common, so I'd say go ahead and start the tiff changes. We don't have to send it to them (we can send the color part sooner) | 18:14.05 |
| Robin_Watts | Damn. My dev_spec_op clist fix causes mass timeouts on the cluster | 18:21.46 |
| henrys | Robin_Watts: let's not worry about the tiff stuff | 18:29.54 |
| Robin_Watts | good answer :) | 18:30.13 |
| henrys | anybody have opinions about the best tablet out there these days. My son is looking for one. | 18:32.39 |
| Robin_Watts | At what size? The new Nexus 7 is pretty damn good. | 18:33.52 |
| mvrhel_laptop | Robin_Watts: any chance you could add a mention of --debug into the documentation in Use.htm Debug switches | 18:36.59 |
| | seems like something that should be there | 18:37.09 |
| Robin_Watts | sure. | 18:37.18 |
| mvrhel_laptop | and I think you did that extension yes? | 18:37.19 |
| | thanks | 18:37.20 |
| | for what ever reason I always forget the notation | 18:37.36 |
| | and then have to go back and look at the commit | 18:37.43 |
| | after looking at our great documentation :) | 18:38.03 |
| Robin_Watts | mvrhel_laptop: I did the extension, yes. | 18:38.58 |
| henrys | Robin_Watts: he wants a 10 he's looking at nexus 10 vs. iPad air | 18:43.58 |
| Robin_Watts | well, does he want shiny, but expensive, unexpandable, and walled garden, or does he want android? :) | 18:45.02 |
| henrys | Robin_Watts: he'll probably get an iPad so he can talk to the girls at the apple store ;-) | 18:49.43 |
| Robin_Watts | and this is why apple is the most successful company in the world today :) | 18:51.51 |
| mvrhel_laptop | ray_laptop: so I am seeing some funny stuff go on in the transparency ICC code that may be the source of our problems | 18:52.42 |
| | digging a little more to track down | 18:53.07 |
| Robin_Watts | henrys: Did you read about the peachy printer in the end? | 18:53.48 |
| | I just gave in and pledged for castAR. | 18:54.07 |
| | I feel that my geek status needed reinforcement :) | 18:54.37 |
| henrys | Robin_Watts: no I never got around to it. Thanks for reminding me. | 18:55.23 |
| | Robin_Watts: the nexus 10 release is imminent and I'm sure the goal will be to outdo the air. The current 2012 model doesn't compete really. | 19:01.23 |
| mvrhel_laptop | ok. with this debug set up I should be able to figure out the issue | 19:02.20 |
| | need to eat now though | 19:02.24 |
| ray_laptop | mvrhel_laptop: thanks | 19:02.32 |
| | darn. I rushed out to deliver lunches and my regression didn't start :-( running it now | 19:03.44 |
| | that *should* fix the planar mode alignment+pad change issue | 19:04.14 |
| Robin_Watts | ray_laptop: Excellent. If there are remaining problems, feel free to mail me, and I can look tomorrow. | 19:04.38 |
| | I'm going out to see Enders Game in a bit. | 19:04.49 |
| ray_laptop | Robin_Watts: this one actually has the pad forced to 5 and the alignment forced to 8 | 19:05.13 |
| | so it's the 'stress test' | 19:05.29 |
| | If you want I can run a pad of 64 and alignment of 16 later, as well | 19:05.55 |
| | Enjoy the movie! My 14yr old *really* wants to see it. He read the series this summer | 19:08.15 |
| pipitas | Hi. I'm trying to convert a PDF page with some color to pure grayscale: "gs -o gray.pdf -sDEVICE=pdfwrite -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray color.pdf". However, it does not work (I *KNOW* it used to work on former occasions). | 19:12.16 |
| | I used a current debug build from Git, and added "-Zc" to get debugging output about color.- | 19:12.22 |
| | The only (to me) meaningful output line I can spot is this: | 19:12.22 |
| | "Unable to convert color space to Gray, reverting strategy to LeaveColorUnchanged." | 19:12.22 |
| mvrhel_laptop | now I am suspecting that there is some funny stuff going on with the color space setting | 19:12.24 |
| henrys | Robin_Watts: Orson has really ruffled some feathers here ... | 19:12.49 |
| pipitas | What could be wrong with my command (or with the input PDF)? | 19:13.02 |
| Robin_Watts | pipitas: You probably need ken. Try again in about 15 hours time. | 19:13.55 |
| pipitas | Hmm⦠I need to print my train ticket for a departure 14 hours from now â on a printer which complains about low level inks for CMY, but which still has K ink enough :) | 19:15.45 |
| Robin_Watts | pipitas: Print to a greyscale bitmap. Print the bitmap. | 19:17.10 |
| ray_laptop | pipitas: hopefullly your printer will allow that. I had a KM laser printer that refused to print a black page when out of yellow. | 19:18.48 |
| | pipitas: my newer Epson *does* allow black only printing when out of color, in fact, it will even automatically print gray from a color page. Very high user friendly marks | 19:19.47 |
| | and when I ran out of black, it let me print in CMY. Both required pressing "OK" on the panel | 19:20.43 |
| | that's the way to do it, IMHO | 19:21.05 |
| Robin_Watts | Damn. Still SEGVs with my new patch. Will have to look why tomorrow. | 19:21.35 |
| mvrhel_laptop | ray_laptop: so it is interesting that the icc color space has no compareproc. | 19:21.56 |
| ray_laptop | plus Epson has individual C, M, Y and K cartridges so you don't have to waste the C and M when you run out of Y (which always goes fastest) | 19:22.28 |
| mvrhel_laptop | The net effect is that I am seeing a free and a new allocation where we don't need to be doing that | 19:23.31 |
| | this is a performance hit at the least | 19:23.50 |
| | of course it is not the source of our growing pile of profiles | 19:24.01 |
| ray_laptop | mvrhel_laptop: yeah, that might help (as long as we haven't lost track of the profile we've already loaded). A 'q' /ICCBased ... cs 'Q' could revert to something like DeviceRGB or DeviceGray and lose the profile | 19:24.04 |
| pipitas | is going to remove the ink cartridges and shake them a bit in order to try and fool the printer in his host's home office⦠| 19:24.08 |
| ray_laptop | pipitas: good luck. That often works with laser toner, but some inkjets have "smart" cartridges so you can't even refill them. They count drops and mark it as empty | 19:25.21 |
| | my previous company did that nefarious deed since they planned on making lots of money on ink. They went out of business before the $$$ started rolling in | 19:26.27 |
| amonakov | would it be kosher to add new field `int hint_all_glyphs' into struct fz_context_s? | 19:27.22 |
| | hm, fz_font_context_s might be a better fit actually | 19:28.55 |
| JakeSays | hello.. i have a mupdf question. i'm implementing this method in a custom device: fill_image_mask(fz_device *dev, fz_image *img, fz_matrix ctm, fz_colorspace * colorspace, float *color, float alpha) | 19:40.24 |
| | my question is, how can i determine the actual bounds of the image as it will be displayed? the images are much larger than the space they consume in the rendered pdf | 19:41.12 |
| Robin_Watts | JakeSays: The image is scaled to fit within a square from (0,0) to (1,1). And that square is then transformed by the ctm. | 20:10.43 |
| | So if the ctm is (100, 0, 0, 200, 30, 40) then the image will end up being 100 wide by 200 tall, with its corner at (30,40) | 20:11.22 |
| | And if you can't instantly see how I got those figures, you should read up on transformation matrices before doing anything else. | 20:12.16 |
| JakeSays | Robin_Watts: ah ok. yeah i understand the transformation. part i was missing was the scaling. | 20:15.48 |
| | Robin_Watts: would i need to convert the image dimensions from pixels to points before scaling/transforming, or does the normalizing to the unit square eliminate that need? | 20:33.13 |
| pipitas1 | mvrhel_laptop: Are you around? | 20:39.05 |
| mvrhel_laptop | yes | 20:39.20 |
| | pipitas1^^ | 20:39.49 |
| pipitas1 | Did you see my question from about 1hr 20min ago? | 20:40.09 |
| mvrhel_laptop | no | 20:40.13 |
| pipitas1 | I tried to convert a 1page color PDF to grayscale, but got again a color PDF with message: Â Â "Unable to convert color space to Gray, reverting strategy to LeaveColorUnchanged." | 20:41.07 |
| | Command was: "gs -o gray.pdf -sDEVICE=pdfwrite -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray color.pdf" | 20:41.30 |
| | This *USED* to work. | 20:41.48 |
| | Either I don't remember the correct command, or the input PDF is somehow weird, or GS has a bug⦠| 20:42.12 |
| | mvrhel_laptop: I tried GS 9.10 as well as current Git. Both with same result. | 20:42.44 |
| mvrhel_laptop_ | sorry connection dropped | 20:42.54 |
| | did you see my comment about pdfwrite color? | 20:43.02 |
| | kens is in charge of this | 20:43.10 |
| | and in the middle of a big change | 20:43.17 |
| | pdfwrite did not make sure of the icc color settings | 20:43.26 |
| pipitas1 | mvrhel_laptop: But it SHOULD work with the 9.10 release, no? | 20:43.41 |
| mvrhel_laptop_ | but you are not doing that I see | 20:43.43 |
| | pipitas1: I would expect to see no real diff with the 9.10 release but you should check with kens | 20:44.14 |
| | he will be around UK time | 20:44.22 |
| pipitas1 | mvrhel_laptop: I know KenS in charge of pdfwrite, but I thought *you* can spot my mistake (if I made one). | 20:44.37 |
| mvrhel_laptop | pipitas1: I don't see any issue with your command line | 20:46.16 |
| | unfortunately I can't test it out now | 20:46.32 |
| | in middle of something | 20:46.35 |
| pipitas1 | mvrhel_laptop: I understand | 20:55.26 |
| mvrhel_laptop | ray_laptop: cluster testing the icc comparison test. | 21:23.09 |
| | now I will see what else is going on | 21:23.17 |
| ray_laptop | mvrhel_laptop: Ha! I beat you. My test is running first ;-) | 21:24.50 |
| mvrhel_laptop | hmm where is that reset button | 21:25.11 |
| ray_laptop | mvrhel_laptop: if you had sudo access on a server, you could su to 'ray' and submit a "git abort" (not that I've ever abused my access that way ;-) ) | 21:26.41 |
| mvrhel_laptop | well this fix has cut way down on the icc allocation noise | 21:27.13 |
| ray_laptop | not git abort, I mean toolbin/localcluster/gitpush.sh abort | 21:27.27 |
| | mvrhel_laptop: Great! so the performance AND allocation should be a *lot* better | 21:27.57 |
| mvrhel_laptop | in fact it is looking like this was the issue | 21:28.16 |
| ray_laptop | mvrhel_laptop except we still don't know why the old things were left around for the GC to clean up. | 21:29.12 |
| mvrhel_laptop | right. let me push on for a bit | 21:29.23 |
| ray_laptop | mvrhel_laptop: I have to pick up kids today. My wife is on a shopping trip to help our niece decorate with balloons and stuff. | 21:30.41 |
| mvrhel_laptop | ok | 21:30.51 |
| ray_laptop | oh. one of our fastest cluster machines, "i7", is --DOWN-- :-( | 21:31.29 |
| | marcosw: are you doing maintenance on it, or did it finally overheat due to that extreme overclocking (or water cooling failure) ? | 21:32.28 |
| JakeSays | Robin_Watts: hey that worked. thanks! | 21:33.59 |
| ray_laptop | I've (finally) got my phone (mostly free) wi-fi hotspot working. I can now heartily recommend PDAnet for an android based phone ! | 21:34.14 |
| | it's a commercial product, but a one-time purchase is better than $15/mo my phone provider (Verizon) wants *on top of unlimited internet* | 21:35.44 |
| | mvrhel_laptop: my cluster run is almost finished. Thanks for waiting ;-) | 21:37.03 |
| mvrhel_laptop | np | 21:37.13 |
| ray_laptop | I'll see if I got less than 30K segfaults this time :-) | 21:37.42 |
| | I fixed planar mode and broken non-planar mode :-( | 21:38.15 |
| | so maybe now both will work | 21:38.34 |
| mvrhel_laptop | ray_laptop: so were you seeing the issue during writing or reading (clist) | 21:51.55 |
| | I don't see any issues now with writing | 21:52.07 |
| | all the profiles see to be getting freed with reference counting | 21:52.23 |
| | s/see/seem/ | 21:52.27 |
| | when my cluster run is finished (assuming all is ok with it). would you mind checking if you still see the issue | 21:53.12 |
| | ray_laptop; for the logs when you get back. I am seing about a 5percent speed improvement with the fix on that file | 22:42.40 |
| | not huge, but at least in the right direction | 22:42.56 |
| marcosw2 | rayjj or mvrhel_laptop: I'm trying to figure out which version of Visual Studio I want to install on the Win7 regression machine. Is Visual Studio Express 2013 for Windows Desktop a reasonable choice? Or do I want Visual Studio Team Foundation Server Express 2013? | 22:43.30 |
| JakeSays | marcosw2: team foundation server express isnt an ide | 22:57.22 |
| mvrhel_laptop | The express should be fine marcosw2 | 23:02.43 |
| Robin_Watts | mvrhel_laptop: Why do we want anything newer than VS2005 installed? | 23:50.19 |
| | All our projects build with VS2005. | 23:50.32 |
| mvrhel_laptop | Robin_Watts: VS2005 would be fine | 23:55.06 |
| JakeSays | dang. thats old. | 23:55.20 |
| mvrhel_laptop | tell me about it | 23:55.26 |
| Robin_Watts | JakeSays: Anything newer than VS2005 loses compatability with old machines for no good reason. | 23:55.43 |
| JakeSays | i built mupdf earlier today with vs2012. worked fine. | 23:55.58 |
| | Robin_Watts: well, the good reason is more $$ for ms. lol | 23:56.24 |
| marcosw | I figured I should install the latest visual studio since the first thing we do when a ghostscript user complains about something being broken is to tell them to upgrade to the latest release. | 23:59.39 |
| | Forward 1 day (to 2013/10/31)>>> | |
IRC Logs