| | <<<Back 1 day (to 2013/12/19) | 2013/12/20 |
| mvrhel_laptop | hi ray_laptop: I will attached my comments to the bug | 00:48.37 |
| | did you see what I had said in IRC? | 00:48.45 |
| marcosw1 | Robin_Watts: the robin.mhw directory was so that I could duplicate the clusterpush result email with no useful content. | 04:29.32 |
| Robin_Watts | marcosw1: Well, it's showing up on the web dashboard. Let me know when it's over and done with and I'll remove the traces so it doesn't. | 08:58.13 |
| | henrys: I mentioned ghostscript, but frankly, I don't think txtwrite gives enough power. | 14:51.20 |
| | If the idea is to extract the text and then do clever things with it, like tabulate data, try to reform structure etc, then txtwrite doesn't give nearly the power required. | 14:52.10 |
| | chrisl has pulled, it seems :) | 14:52.31 |
| kens | In what sense ? It gives the text and its location | 14:52.42 |
| | Not in the default ocnfiguration, its true | 14:52.53 |
| | THat just writes teh text in UTF | 14:53.03 |
| | But the XML output is braodly similar to mupdf | 14:53.14 |
| Robin_Watts | kens: Oh, I was showing my ignorance then. | 14:53.46 |
| | apologies. | 14:53.51 |
| kens | NO problem. | 14:54.00 |
| | Its not the same as the MuPDF output, but I tried to make it similar | 14:54.12 |
| | I'd be happy if people used it, it would be possible to improve it further I've no doubt | 14:54.49 |
| Robin_Watts | If we were to sponsor it, we could offer our $250 prize for the 'best use of Ghostscript or MuPDF' in a project ? | 14:54.56 |
| henrys | Robin_Watts: it's fine to sponsor, would it be easiest for you to pay and expense report it or do you want something directly from Artifex? | 15:00.40 |
| Robin_Watts | henrys: If we're up for sponsoring, then I'll contact him and see how he wants to do it. | 15:01.15 |
| | I would be happy to pay and expense it, but I suspect it would be easier done from someone with a US bank account. | 15:01.40 |
| | I doubt they take cards etc. | 15:01.46 |
| | But I can look into it, sure. | 15:01.55 |
| henrys | Robin_Watts: if you just send me the info I'll take care of it. | 15:02.33 |
| Robin_Watts | will do. | 15:02.41 |
| henrys | kens:who did the txtwrite web page attached to ghostscript.com where files can be submitted? | 15:08.19 |
| kens | I had no idea there was such a thing! :-) | 15:08.39 |
| henrys | Must have been Robin_Watts ⦠http://ghostscript.com/txtwrite.html | 15:09.33 |
| Robin_Watts | me I think, but it was your idea. | 15:09.50 |
| kens | Crikey, that's quite nice, I didn't know that was there. SHouldn't we have a MuPDF version too ? | 15:10.41 |
| henrys | kens:it does | 15:11.02 |
| kens | That one is juts GS thoughb, I assume the MuPDF one is elsewhere ? | 15:11.33 |
| henrys | Robin_Watts: I'm glad I looked for it otherwise I would have had that idea again ;-) | 15:13.01 |
| | Robin_Watts: how is it kept up to date with releases? | 15:15.28 |
| Robin_Watts | henrys: no idea :( | 15:15.39 |
| henrys | well I can just look | 15:15.39 |
| | 9.05 I don't know if kens has done a lot with it since then. | 15:18.35 |
| kens | I've fixed a few bugs, one or two were serious | 15:18.47 |
| | One could cause crashes | 15:18.58 |
| henrys | Robin_Watts: you are using gs4txtwrite on casper in cgi-bin right? not the other server? | 15:19.52 |
| Robin_Watts | what other server? | 15:20.13 |
| kens | peeves maybe ? | 15:20.37 |
| henrys | Robin_Watts: I thought we had moved ghostscript downloads? | 15:20.39 |
| Robin_Watts | henrys: oh, right, yes, but that's just for downloats. | 15:20.53 |
| henrys | Robin_Watts: that's what I thought. | 15:21.04 |
| | so to update we just copy a new gs to gs4txtwrte in cgi-bin on casper. | 15:21.55 |
| Robin_Watts | I think so. | 15:22.13 |
| henrys | kens, Robin_Watts ha the date on the file said Dec 20 and I'm thinking how the heck? But it's 2011 | 15:23.55 |
| kens | :-) | 15:24.04 |
| Robin_Watts | Clearly there is something about Xmas that makes henrys mind turn to text extraction :) | 15:24.30 |
| kens | Horrifying thought! | 15:25.15 |
| henrys | Robin_Watts: you started it with this hackathon business | 15:25.36 |
| | kens:I'll just copy in the latest for now but chris should probably make it part of the release. It's easily googled so it should be up to date. | 15:26.40 |
| kens | Did anyone else get a surp[rise $2.80 on their credit card from the Sheraton in Maui ? When I check out my bill was clear | 15:36.54 |
| henrys | kens: haven't looked yet | 15:38.02 |
| tor8 | kens: I got the full breakfast tab on my credit card. | 15:38.52 |
| Robin_Watts | kens: What was the $2.80 for? | 15:40.10 |
| kens | no idea | 15:40.21 |
| tor8 | $2.80 is an odd sum. the water bottles said they were like $4 or something. | 15:41.01 |
| kens | the credit card just says $2.80 tio the Sheraton | 15:42.56 |
| Robin_Watts | $2.80 is a plausible amount for a bottle of drink bought at the little shop? | 15:44.30 |
| kens | didn't buy anything | 15:45.01 |
| ray_laptop | mvrhel (for the logs): I don't see any new comments in the bug, but I do understand your comments from yesterday about pre->nbands w.r.t. band 17 | 15:49.46 |
| | morning, all. | 15:49.57 |
| Robin_Watts | Morning ray. How are you feeling? | 15:50.10 |
| ray_laptop | Am I really on ? I typed something in chatzilla a few minutes ago and it didn't make it to the logs, so I must have actually been offline | 15:50.34 |
| kens | You are here now | 15:50.44 |
| Robin_Watts | The first thing I saw from you was "mvrhel (for the logs)..." | 15:50.59 |
| ray_laptop | Robin_Watts: my eye is the biggest problem. Waiting for an opthamologist appt | 15:51.39 |
| Robin_Watts | ray_laptop: keeps drying out ? | 15:51.51 |
| ray_laptop | Robin_Watts: yes, that msg for mvrhal I just cut an paste from my previous session | 15:52.06 |
| | Robin_Watts: yep, and I can't find a patch that will keep it closed. At least it's OK at night | 15:52.40 |
| Robin_Watts | ray_laptop: It's not pretty, but presumably you've tried taping the eye shut? | 15:52.44 |
| ray_laptop | Robin_Watts: EVERYTHING. An eyelid is hard to stick to, and I don't want to resort to cyanoacylate :-) | 15:53.29 |
| Robin_Watts | :) | 15:54.30 |
| henrys | ray_laptop: I guess the ophthamologist will have some ideas. | 15:58.24 |
| ray_laptop | henrys: I hope so | 16:07.02 |
| | On the good side, the eyelid is starting to twitch when I blink (so my wife tells me) | 16:07.42 |
| Robin_Watts | eh? what? | 16:37.33 |
| | gdevp14.c lines 8065-> 8070 | 16:37.57 |
| | Is it just me, or does there seem to a flaw there :) | 16:38.21 |
| | s/to/to be/ | 16:38.30 |
| kens | if (pis->is_gstate) ? | 16:38.44 |
| Robin_Watts | result->profiles->smask_gray = pis->icc_manager->default_gray; | 16:39.00 |
| | result->profiles->smask_rgb = pis->icc_manager->default_rgb; | 16:39.02 |
| | result->profiles->smask_cmyk = pis->icc_manager->default_cmyk; | 16:39.04 |
| | pis->icc_manager->default_gray = smask_profiles->smask_gray; | 16:39.06 |
| | pis->icc_manager->default_rgb = smask_profiles->smask_rgb; | 16:39.08 |
| | pis->icc_manager->default_cmyk = smask_profiles->smask_cmyk; | 16:39.09 |
| | pis->icc_manager->smask_profiles->swapped = true; | 16:39.11 |
| | As a swap operation that would seem to be... suboptimal. | 16:39.16 |
| | Oh! Wait. It is just me. | 16:39.47 |
| kens | It doesn't seem to be a swap exactly | 16:39.51 |
| Robin_Watts | and I stared at that for ages before saying anything. My brain is shutting down. I blame the experience of sainsburys this morning :( | 16:40.41 |
| kens | Never mind, its nearly Xmas | 16:40.53 |
| henrys | Robin_Watts: what is the preferred way to have -Zi without -ZI being "implied"? (gs_debug_flag_implied_by) | 16:42.01 |
| Robin_Watts | henrys: It is a convention that lower case letters imply upper case ones. | 16:42.35 |
| | If you use letters, then there is no way to avoid that implication, IIRC. | 16:43.13 |
| | oh, right, actually it's easy. | 16:44.40 |
| | But it would be bad form. | 16:44.48 |
| | What are you trying to do ? | 16:44.59 |
| | actually, that's the wrong way around. | 16:45.51 |
| | Upper case letters imply lower case ones. | 16:46.11 |
| henrys | Robin_Watts: the way I read the docs you have it backward | 16:46.14 |
| | in the code | 16:46.17 |
| Robin_Watts | 'i' is implied by 'I'. | 16:46.28 |
| | 'I' = interp_detail | 16:46.44 |
| | 'i' = interp | 16:46.48 |
| | hence if you ask for 'I' you get 'i' for free. | 16:46.59 |
| | I implies i. | 16:47.02 |
| henrys | Robin_Watts: yes but I am asking for 'i' and getting 'I' which seems wrong | 16:47.36 |
| Robin_Watts | henrys: That does seem wrong. | 16:47.51 |
| henrys | indeed gs_debug_flag_implied_by['i'] == 'I' | 16:48.20 |
| Robin_Watts | That says "i' is implied by 'I'. | 16:48.41 |
| | no, sorry. | 16:48.55 |
| | Let me stop babbling and look at this. | 16:49.19 |
| henrys | Robin_Watts: maybe just the variable name has me fouled up - let me see if I actually have a problem. | 16:50.53 |
| | Robin_Watts: sorry fit of madness it does seem to work properly. | 17:02.13 |
| Robin_Watts | yeah, testing L and l shows it works the way we'd hope. | 17:03.02 |
| | Ah, right. When we check for a flag 'i', we first check the entry for 'i'. | 17:03.43 |
| | Then we move to the entry that 'implies' 'i' (i.e. 'I') and we check that too. | 17:04.08 |
| | so we want to know 'what implies x' for some x. | 17:04.24 |
| | Hence 'is_implied_by'. | 17:04.34 |
| | There is some sort of method in my madness. | 17:04.44 |
| kens | OK goodnight all | 17:18.11 |
| Robin_Watts | Morning tor8 | 18:12.05 |
| | Care to review this for me? http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=0d837b4a07681331648016cca7093402df68ca9f | 18:12.21 |
| | That solves the subpixel text thing. | 18:12.42 |
| | mvrhel_laptop: Morning. | 18:14.40 |
| mvrhel_laptop | good morning | 18:14.51 |
| Robin_Watts | I've run into something really really odd. | 18:15.02 |
| | How is the clist bug going ? | 18:15.12 |
| mvrhel_laptop | I had asked ray_laptop a bunch of questions but did not hear from him Robin_Watts | 18:15.44 |
| Robin_Watts | mvrhel_laptop: He was on here earlier. | 18:15.57 |
| mvrhel_laptop | I know what the issue is but it has to do with the clist banding | 18:16.24 |
| Robin_Watts | but he's gone (or is going at least) to see the opthalmologist today. | 18:16.26 |
| mvrhel_laptop | and patterns | 18:16.27 |
| Robin_Watts | Well, if you're stalled, can I distract you with something else for a moment ? | 18:17.02 |
| | (but if you want to ring him and try to make progress, then I completely understand) | 18:17.20 |
| mvrhel_laptop | I am not stalled just thinking that this is an issue for ray and not me | 18:17.26 |
| | I will probably try to give him a call | 18:17.42 |
| Robin_Watts | Go for it. | 18:17.59 |
| mvrhel_laptop | Robin_Watts: I can look at the error handling issue to though | 18:18.07 |
| Robin_Watts | I have a really massively reduced file that shows the error handling issue. | 18:18.31 |
| mvrhel_laptop | oh ok great. do you want to make a formal bug or just hand it to me? | 18:18.51 |
| Robin_Watts | I have opened a formal bug. | 18:19.01 |
| | but not put the file on there yet. | 18:19.09 |
| | I have a strange thing going on I don't understand. | 18:19.18 |
| | Changing whether we pass an error code on or not on 1 line makes it crash or not. | 18:19.36 |
| mvrhel_laptop | oh I see from the logs that ray did get my message | 18:19.40 |
| Robin_Watts | But it doesn't crash there. And as far as the debugger is concerned, that line is NEVER RUN?!? | 18:19.57 |
| | If you need someone to help with the clist bug, then I'm quite happy to be your gormless assistant. | 18:21.05 |
| mvrhel_laptop | Robin_Watts: ok let me bring you up to speed on it | 18:21.34 |
| | hold on | 18:21.42 |
| | Robin_Watts: adding my comments to the bug. hold on | 18:27.09 |
| Robin_Watts | Holding. | 18:27.27 |
| mvrhel_laptop | Robin_Watts: ok I added my comment | 18:34.12 |
| | it was best to put it there instead of on IRC | 18:34.21 |
| Robin_Watts | Sure. Just a tick. | 18:35.35 |
| | Just trying to digest your comments. | 18:38.39 |
| | Does the pattern have the same id both times? | 18:39.49 |
| | both when it's written to the 1 band and when it's written to all bands? | 18:40.05 |
| mvrhel_laptop | yes | 18:40.35 |
| | same id is used through out | 18:40.51 |
| Robin_Watts | Then when reading can we say "only read this in if we don't have it already?" | 18:40.53 |
| | That way it wouldn't be evicted and all would be well ? | 18:41.10 |
| mvrhel_laptop | we could do that | 18:41.12 |
| Robin_Watts | Alternatively, could we just say "for patterns, they are likely to be reused, so always write to all bands" | 18:41.33 |
| | That way the '1 band' followed by 'n band' case would not occur. | 18:42.12 |
| | I lack a large enough overview to see if either of those are completely stupid or not :( | 18:42.30 |
| mvrhel_laptop | that is a question for ray | 18:44.33 |
| Robin_Watts | Are transparency groups refcounted ? | 18:44.46 |
| mvrhel_laptop | no | 18:44.52 |
| Robin_Watts | Should they be? | 18:44.57 |
| mvrhel_laptop | I dont think so. there is a push and pop that should match up | 18:45.16 |
| | and it is then done | 18:46.04 |
| | and that all currently works just fine | 18:46.54 |
| Robin_Watts | push and a pop of what ? | 18:46.57 |
| mvrhel_laptop | the transparency group | 18:47.11 |
| Robin_Watts | Storing the transparency group pointer somewhere other than the pattern cache would be nice then, as you say. | 18:47.45 |
| mvrhel_laptop | it is not in the pattern cache. it is in the tile | 18:48.25 |
| | which was very convient | 18:48.32 |
| Robin_Watts | The pattern cache holds tiles, right? | 18:48.55 |
| mvrhel_laptop | bear with me for a sec | 18:49.18 |
| | imagine that you have a tile | 18:49.23 |
| | and now you have a fill with that tile | 18:49.31 |
| | at that time, a group is pushed and provided to the tile | 18:49.46 |
| | or the pointer is provided to the tile | 18:49.56 |
| | the fill occurs with the tile into that group | 18:50.05 |
| | when the fill is finished, we pop the group and null out the pointer | 18:50.26 |
| | the tile could still be used for another group | 18:50.31 |
| | or fill that is | 18:50.43 |
| | but it will be a new group | 18:50.51 |
| Robin_Watts | So a "tile" is a pattern | 18:51.09 |
| mvrhel_laptop | what is weird now, is that in the middle of reading the image data | 18:51.24 |
| | yes | 18:51.26 |
| | we end up getting a set color command | 18:51.43 |
| Robin_Watts | so the pattern cache is a cache of tiles. | 18:51.46 |
| mvrhel_laptop | yes | 18:51.58 |
| Robin_Watts | and the transparency group pointer is held by (one of) those tiles. | 18:52.09 |
| | OK, so I understand the problem, I think. | 18:52.34 |
| mvrhel_laptop | it is held by the current device color | 18:52.40 |
| | which is a pattern in the cache | 18:52.57 |
| | or tile in the cache | 18:53.01 |
| Robin_Watts | I guess it depends how we view this stuff. | 18:53.15 |
| | Do you have any idea how easy or hard it would be to skip reading a pattern if the pattern is already in the cache? | 18:54.03 |
| mvrhel_laptop | yes. let me show you where that is | 18:54.19 |
| Robin_Watts | i.e. read the id, check the id, if the id is there, skip. | 18:54.23 |
| | Cos that seems like a perfectly reasonable thing to do. | 18:54.32 |
| | Alternatively... this could be solved at the writer side. | 18:55.07 |
| | AIUI, the writer keeps track of what is in the pattern cache for each band. It could only write out a pattern to a band if that pattern is not already in the cache. | 18:55.40 |
| mvrhel_laptop | yes. I don't like what the writer is doing. | 18:55.42 |
| | but the decision of writing out to all bands is the culprit and that is weird | 18:56.16 |
| | let me show you that oo | 18:56.19 |
| | too | 18:56.21 |
| | first, gx_dc_pattern_read is where we read the pattern from the clist | 18:56.41 |
| | in gsptype1.c | 18:56.47 |
| | gx_pattern_cache_ensure_space((gs_imager_state *)pis, cache_space_needed); around line 2046 | 18:57.06 |
| | is where we check if there is room in the cache | 18:57.18 |
| | and it is there that we purge the cache to get enough room | 18:57.37 |
| | what I worry about is this | 18:57.46 |
| | we are in the middle of reading the pattern out of the clist | 18:58.04 |
| | we may have to read it anyway since that is the command that was packed in the clist | 18:58.19 |
| | to set the color | 18:58.21 |
| | adding a check here to use one that is the same id is a possiblity but I think we will run into clist reading issues | 18:59.03 |
| | so to me, it seems that fixing the writing side would make more sense. | 18:59.19 |
| | Robin_Watts: ^^ | 18:59.22 |
| | in gxclpath.c | 19:00.06 |
| | if (!all_bands && dc_size * pre->nbands > 1024*1024 /* arbitrary */) line 155 | 19:00.14 |
| Robin_Watts | just getting there. | 19:00.26 |
| mvrhel_laptop | this is where the decision is made to go out to all bands | 19:00.28 |
| | during the processing of the 4th image | 19:00.45 |
| | we first do band 17 | 19:00.49 |
| | and pre->nbands = 1 | 19:00.56 |
| | so we write out a single tile since band 17 does not yet have a tile | 19:01.14 |
| | then we do band 13 and write out the id | 19:01.28 |
| | then we do band 14 and pre->nbands = 5 | 19:01.44 |
| | which pushes us over the edge to write out the pattern to all the bands | 19:01.54 |
| | this is during the processing of the same image | 19:02.02 |
| Robin_Watts | So dc_size = expected size of the color data. | 19:02.06 |
| mvrhel_laptop | yes. to me it would seem that the decision to do 1 or all bands would be made with the first band that we do | 19:02.36 |
| Robin_Watts | I vote for: if (is_pattern) all_bands = true; | 19:02.37 |
| mvrhel_laptop | there is a cost (size of the clist) in doing that | 19:03.15 |
| ray_laptop | Robin_Watts: We know enough at the start of the image to know the full imagemaxk extent | 19:03.26 |
| Robin_Watts | Hi Ray. | 19:03.40 |
| ray_laptop | Robin_Watts: all_bands is quite a bit of overhead | 19:03.43 |
| | Robin_Watts: hi | 19:03.47 |
| mvrhel_laptop | ray_laptop: how hard would it be for you to fix the writing to avoid the single then all occurence? | 19:04.02 |
| ray_laptop | With any 'all bands' operator, it has to put an 'end' marker on all bands, then emit the info ffor all bands, then start collecting new sequences for individual bands | 19:04.59 |
| Robin_Watts | ray_laptop: mvrhel_laptop has just been explaining this problem to me. | 19:05.25 |
| | And we've discussed various different ways of solving it. | 19:05.35 |
| ray_laptop | mvrhel_laptop: that's what I'm looking into. making the decision to do all_bands or single based on the full imagemask extent | 19:06.01 |
| | mvrhel_laptop: during clist_begin_image. | 19:06.19 |
| mvrhel_laptop | oh great | 19:06.29 |
| | then I will get out of your way | 19:06.34 |
| | thanks ray_laptop | 19:06.39 |
| ray_laptop | If we emit the all_bands, then the individual bands won't do anything other than emit the id | 19:06.59 |
| Robin_Watts | ray_laptop: That sounds ideal. | 19:07.00 |
| | If the pattern is then reused later on, will we get into this same problem again? | 19:07.31 |
| mvrhel_laptop | yes | 19:07.32 |
| | no we dont have that problem now | 19:07.44 |
| Robin_Watts | Probably not, because the pattern won't be replaced mid image, right? | 19:07.55 |
| mvrhel_laptop | it is just having it do it in the middle of the image processing | 19:07.56 |
| | right | 19:08.00 |
| ray_laptop | and if we don't emit the pattern to all bands, then as bands are emitted, they will write the pattern IFF needed for that band (based on the id in that band) | 19:08.03 |
| Robin_Watts | OK. | 19:08.10 |
| | ray_laptop: Sounds great. | 19:08.14 |
| mvrhel_laptop | ok. now I will look at the pdf14 issue that you found Robin_Watts | 19:08.53 |
| | then back to mupdf... | 19:09.00 |
| ray_laptop | mvrhel_laptop: it'll still do it during clist_image_plane_data, for the case where it wasn't loaded by all_bands initially | 19:09.01 |
| Robin_Watts | mvrhel_laptop: OK. | 19:09.02 |
| mvrhel_laptop | Robin_Watts: I dont see the bug #? | 19:11.00 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=694858 | 19:11.35 |
| ray_laptop | The opthamologist had a better appoach that (so far) is working farily well. I use an ointment (that lasts longer than drops) and use "moisture goggles" (like cunglasses with goggle type foam gaskets) and the eye doesn't dry out) | 19:11.52 |
| | works well enough that the occassional volitional slow blink takes care of it | 19:12.16 |
| Robin_Watts | ray_laptop: So you can blink your eye if you conciously try? | 19:12.56 |
| ray_laptop | I might even try it with contacts in a day or two to see how that works | 19:13.09 |
| mvrhel_laptop | Robin_Watts: I will take this bug OK? | 19:13.10 |
| ray_laptop | Robin_Watts: yes | 19:13.13 |
| Robin_Watts | mvrhel_laptop: Sure. | 19:13.19 |
| ray_laptop | mvrhel_laptop: I thought Robin_Watts marked it as "color" so it'd be assigned to you ? | 19:13.42 |
| Robin_Watts | The file on there that fails, fails with a simple: gs/debugbin/gswin32c.exe -o out.pgm -sDEVICE=pgmraw -r300 ev3.pdf | 19:13.42 |
| mvrhel_laptop | ray_laptop: it was labeled Transparency problems but Component was Images | 19:22.38 |
| Robin_Watts | Do Images not go to you? | 19:23.21 |
| | no, evidently they go to me. Should have made it color. sorry. | 19:23.43 |
| | mvrhel_laptop: Can you reproduce the problem OK ? | 19:34.17 |
| mvrhel_laptop | Robin_Watts: snow day today. lots of distractions | 19:36.31 |
| Robin_Watts | no worries. I'm going to cook now. If you have trouble reproducing it, just let me know. | 19:39.00 |
| | tor8: Fancy reviewing: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=0d837b4a07681331648016cca7093402df68ca9f | 19:58.45 |
| tor8 | Robin_Watts: ohhh! yes. LGTM. | 20:54.42 |
| Robin_Watts | tor8: Ta. | 21:45.51 |
| | Forward 1 day (to 2013/12/21)>>> | |
IRC Logs