| | <<<Back 1 day (to 2012/05/17) | 2012/05/18 |
| sebras | Robin_Watts: time to go to bed. nn. | 00:15.30 |
| Robin_Watts | night | 00:26.02 |
| | Morning tor8. | 11:04.56 |
| tor8 | morning | 11:05.00 |
| Robin_Watts | In the patch that you are resurrecting, is there anything about writing to streams ? | 11:05.21 |
| paulgardiner | morning | 11:05.38 |
| Robin_Watts | I need to construct the hints stream (probably as an fz_buffer, right?) | 11:05.55 |
| | And to do that I need to write values to the buffer, but a few bits at a time (here is a 15 bit value, here is a 7 bit value, etc...) | 11:06.31 |
| | I know that our stream stuff has code to read n bits - do we (or did we) have code to write n bits at a time? | 11:06.54 |
| tor8 | Robin_Watts: paulgardiner: I meant to ask about that, the pdf_update_stream buffer contents | 11:07.13 |
| | we used to have both read/write fz_streams, but I don't see much value in having all the encryption filters other than zlib really | 11:07.47 |
| Robin_Watts | Certainly, we need zlib. | 11:08.08 |
| tor8 | Robin_Watts: no, not for writing bits. each of the filters I think implemented their own bit writing. | 11:08.10 |
| Robin_Watts | Maybe only as a "fz_deflate_buffer" call? | 11:08.54 |
| tor8 | so my question was how do we set up the buffer to pdf_update_stream? do we leave the buffer as raw and let pdf_write_document apply the flate filter, or do we create it already compressed? | 11:08.57 |
| Robin_Watts | How about fz_copy_buffer_deflated ? | 11:09.27 |
| tor8 | Robin_Watts: it's only relatively recently that I split out the bit reading into fz_stream | 11:09.30 |
| Robin_Watts | normal buffer in, spits out a copy of the data in a new buffer, but deflated. | 11:09.51 |
| tor8 | Robin_Watts: yes, something like that. | 11:10.05 |
| | question is, do we call that before pdf_update_stream, or during the pdf_write_document? | 11:10.35 |
| | I think later is probably better, for the appearance stream stuff | 11:10.51 |
| Robin_Watts | With that call, I think we have the freedom to choose. | 11:11.06 |
| paulgardiner | tor8: Yes, the latter makes more sense for appearance streams | 11:11.23 |
| tor8 | Robin_Watts: we also need to encrypt the buffers for writing. | 11:11.32 |
| Robin_Watts | The only problem I can see is that for linearised stuff I write the file twice. | 11:11.51 |
| | That might turn into compressing twice. | 11:11.57 |
| tor8 | Robin_Watts: right. I think we can do both actually. | 11:12.27 |
| Robin_Watts | And yes, I was about to say we should support writing encrypted files. | 11:12.31 |
| tor8 | just make sure the /Filter parameter is set correctly | 11:12.38 |
| paulgardiner | Robin_Watts: could the first write also update the stream? | 11:13.02 |
| | Or is that an added complication? | 11:13.13 |
| Robin_Watts | paulgardiner: It could (that would be quite natural) | 11:13.24 |
| tor8 | at the moment the WIP patch hooks in the streams at the 'raw stream' layer, so expects it to be both encrypted and compressed according to /Filter but that ought to change I think | 11:13.32 |
| | paulgardiner: I think we could make the pdf_write_document take one option whether to flate compress uncompressed streams | 11:14.02 |
| Robin_Watts | BUT... it would mean that writing a file out suddenly changed an object to being compressed when it wasn't before, and that might confuse code? | 11:14.06 |
| paulgardiner | Presumably a separate stream-compression pass is also a possible | 11:14.25 |
| | ity | 11:14.35 |
| tor8 | but that ties back to another question I had ... when calling pdf_write_document, do we think of that as a "save" or "save as" operation? | 11:14.43 |
| | i.e. do we switch the xref to the new document or not | 11:14.52 |
| | I'd think not, by default of staying sane | 11:15.02 |
| Robin_Watts | tor8: When I started this (by taking the code from mupdfclean) it was a destructive process. | 11:15.28 |
| tor8 | but all the object renumbering etc, maybe we completely break the xref doing that stuff? | 11:15.30 |
| Robin_Watts | (i.e. things change in the document). | 11:15.39 |
| | I believe that it is now a non-destructive thing. | 11:16.01 |
| tor8 | Robin_Watts: yeah, that's why I think maybe we should switch over, or make very clear that it's a destructive process, or do the stuff on a copy of the document so the original isn't destroyed | 11:16.12 |
| | I also worry about what happens to streams when you renumber | 11:16.37 |
| Robin_Watts | (though actually the xref table does change) | 11:16.43 |
| | (and objects are renumbered) | 11:16.55 |
| | tor8: In what way "happens to streams when you renumber" ? | 11:18.57 |
| | Possibly we should move the 'original_num' and 'original_gen' information into the indirect object. | 11:19.42 |
| | So encryption will still work transparently after renumbering. | 11:20.16 |
| tor8 | your renumberobj() function, it copies the objects around, oh nevermind I'm completely misunderstanding | 11:20.30 |
| Robin_Watts | And that would be *your* function. Don't you go blaming me :) | 11:21.00 |
| tor8 | I thought you copied the objects, but I'm just being dense, you're just fiddling with the indirect references :) (or well, this is sebras old code) | 11:21.03 |
| | (so I should be blaming him ;) ) | 11:21.12 |
| Robin_Watts | Ah :) | 11:21.19 |
| | From a "pure" standpoint, it would be nicest if a "pdf_write" didn't alter the xref at all. | 11:22.33 |
| tor8 | http://git.ghostscript.com/?p=mupdf.git;a=blob;f=mupdf/pdf_doctor.c;h=be683592c4e487155ff53945241bc13cc56c700f;hb=326f45d1621b2b64a07867c7048ec05124cc3d6f has an old but maybe interesting function | 11:22.57 |
| | pdf_transplant -- copy objects from one document to another and renumber on the fly | 11:23.16 |
| | I used it to merge pdf documents | 11:23.25 |
| | Robin_Watts: I agree. I think pdf_write_document should not affect the original. | 11:23.46 |
| Robin_Watts | (so given the write process makes changes to the xref (probably unavoidably) we should maybe have pdf_write copy/write/destroy the copy | 11:23.56 |
| tor8 | another approach would be to separate out some of the passes in pdf_write into pdf_optimize_foo calls | 11:24.07 |
| | so garbage collection, renumbering, etc can be done as separate steps destructively | 11:24.19 |
| Robin_Watts | Yes. | 11:24.36 |
| paulgardiner | I'd imagine that would lead to cleaner looking code. | 11:24.50 |
| tor8 | I think I'd prefer that approach, it lets us add more tweaks like this without making the pdf_write code even more complicated | 11:25.01 |
| | how would linearization work with that though? | 11:25.14 |
| Robin_Watts | That would require a rework of the code, as currently the steps are intertwined. | 11:25.17 |
| | and share local state (i.e. later steps depend on state gathered in earlier ones) | 11:25.47 |
| | At the moment pdf_write takes various flags to tell it what to do. | 11:26.23 |
| | actually writing the file could be another flag. | 11:26.34 |
| | then pdf_write would become 'pdf_transform' ? | 11:26.50 |
| | and it could copy the xref, operate on it, and return it. | 11:27.03 |
| | So pdf_write would then be pdf_close_document(pdf_transform(xref, PDF_FLAG_WRITE | PDF_FLAG_LINEARISE | PDF_FLAG_ASCII )); etc. | 11:27.41 |
| | BUT... The idea of copying an xref scares me a bit. | 11:28.08 |
| | Because of the way we hold pdf objects in memory; when we copy an xref we will end up with objects in both trees; update them in one xref, and the contents of the other may change. | 11:29.13 |
| | For instance, suppose we have an xref for a file that has a load of uncompressed appearance streams in it. | 11:31.51 |
| | When we write that, pdf_write might choose to compress the streams. | 11:32.05 |
| | When it does that it'll have to add (or amend) '/Filter' entries. | 11:32.26 |
| tor8 | Robin_Watts: hm, yeah. copy-on-write semantics? | 11:33.51 |
| Robin_Watts | I changed some of the writing code to copy before altering, I think. Let me check. | 11:34.20 |
| | Right. When we write streams, I now copy the object before fiddling with it. | 11:35.15 |
| | but probably that ought to be a 'deep' copy (i.e. recurse through resolving indirections too) | 11:35.50 |
| tor8 | I don't think that should be necessary | 11:36.56 |
| | (at least not following indirections) | 11:37.07 |
| Robin_Watts | Suppose I say "Write stream X" | 11:37.55 |
| | and X is an indirect reference to << /Filter 23 0 R /Length 24 0 R >> stream ..... endstream | 11:38.30 |
| | If I choose to ascii expand that file on writing, I need to change the filter list. | 11:39.44 |
| | and if object 23 was cached in memory by the original xref, it'll be cached by the new xref too - both will contain pointers to the same memory object. | 11:41.10 |
| | When I change one, the other changes too. | 11:41.17 |
| | Or were you thinking we'd copy all cached objects when cloning the xref ? | 11:41.31 |
| tor8 | Robin_Watts: yes, but you'd replace the /Filter in the stream dictionary | 11:43.06 |
| | so you'd replace the indirect reference with an array | 11:43.17 |
| paulgardiner | Use 1023, rather than altering 23? | 11:43.54 |
| tor8 | write stream X << /Filter 23 0 R ... >> -> copy -> change to << /Filter [/Flate] ... >> | 11:44.53 |
| Robin_Watts | paulgardiner: Renumbering would be bad. | 11:50.29 |
| | tor8: That's what I mean by a "deep copy" - resolve the indirects so that they are safe to change. | 11:51.10 |
| tor8 | Robin_Watts: you can't do that if it points to a stream or a cycle | 11:53.24 |
| Robin_Watts | mmm. | 11:53.36 |
| tor8 | Robin_Watts: actually I don't think you need to either | 11:54.21 |
| | since pdf_update_object will only update the object in the xref copy | 11:54.37 |
| Robin_Watts | but the same object will be in both xrefs. | 11:55.00 |
| tor8 | and if we make a copy (deep copy dict/array but without following indirects) when we modify | 11:55.03 |
| | we should be okay | 11:55.05 |
| | yes, but if we copy when we want to change an object, the update_object call will only update the new xref | 11:55.47 |
| | so we always replace an object in the xref with a new object (copied and changed, or brand new) | 11:56.30 |
| Robin_Watts | oh, of course. | 11:59.13 |
| | I think I still like the idea of putting the orig_num/orig_gen fields in the xref entry, so that renumbers don't affect the readability of streams. | 12:05.09 |
| paulgardiner | tor8: I found some weirdness in pdf_set_color from pdf_interpret.c | 12:11.02 |
| tor8 | Robin_Watts: yeah, we can do that (orig_num/gen) | 12:11.55 |
| Robin_Watts | tor8: Just been pondering this over lunch. | 12:48.20 |
| | copy on write couldn't be something we enforce at the object level. | 12:48.54 |
| | we'd have to do it at the pdf_write level. | 12:49.01 |
| | tor8: So are we proposing to reintroduce stream writing capability? (As opposed to buffer writing capability) | 13:02.17 |
| tor8 | Robin_Watts: no, I think that's overkill | 13:02.39 |
| Robin_Watts | Cool. I agree. | 13:02.46 |
| | So I shall do some simple 'write bits into buffer' functions. | 13:03.03 |
| tor8 | writing to a buffer and compressing a buffer in one batch should be enough | 13:03.16 |
| | fz_write, fz_write_byte, fz_write_bits ? | 13:03.33 |
| Robin_Watts | tor8: Yeah, something like that. | 13:03.53 |
| tor8 | fz_deflate_buffer (return a new copy, I guess) | 13:03.59 |
| Robin_Watts | Oh, and while I remember... | 13:04.01 |
| | Any objection to me wrapping the #define inline stuff in fitz.h with #ifndef CPLUSPLUS etc ? | 13:04.29 |
| | That would solve the problem neatly I think. | 13:04.41 |
| tor8 | Robin_Watts: sure. | 13:04.58 |
| paulgardiner | Robin_Watts: Is it __cplusplus? | 13:05.00 |
| tor8 | but no FZ_INLINE please | 13:05.06 |
| Robin_Watts | paulgardiner: I was going to google for it. | 13:05.23 |
| | tor8: sure. The ifdef removes the need for that. | 13:05.34 |
| paulgardiner | Robin_Watts: And it seems we need to #define restrict to nothing too. | 13:06.06 |
| Robin_Watts | That's in the same block. | 13:06.42 |
| paulgardiner | Robin_Watts: I have your change on my forms branch, which is maybe the only place we need it for now. | 13:07.10 |
| Robin_Watts | it's worth having it globally, I think, as other people may also be trying to drive mupdf from C++. | 13:07.34 |
| paulgardiner | Ah, of course | 13:07.56 |
| | I stuck an extra #elif defined after the C99 #if | 13:08.49 |
| | tor8: I found some weirdness in pdf_set_color from pdf_interpret.c | 13:09.07 |
| Robin_Watts | paulgardiner: I'm just wrapping that whole block in #ifndef __cplusplus as I think that's neatest. | 13:09.37 |
| paulgardiner | but we need restrict redefined to nothing | 13:10.01 |
| | Or I seemed to when I tried it. | 13:10.16 |
| | Presumably restrict isn't a C++ thing? | 13:10.42 |
| Robin_Watts | When do we need restrict defined to nothing? | 13:10.43 |
| | Is it not? | 13:10.50 |
| | The restrict keyword is not standard in C++. ass. | 13:11.30 |
| paulgardiner | Hmmm. It seems not... although now thinking about it, you'd expect it to be | 13:11.36 |
| | Oh ok. That makes sense then | 13:11.57 |
| Robin_Watts | restrict is C99. And is found in later versions of C++. Joy. | 13:12.00 |
| paulgardiner | tor8: ping | 13:13.08 |
| Robin_Watts | paulgardiner: Tell me about the wierdness. | 13:13.46 |
| paulgardiner | The if falls through to the for loop which then overwrites what the if may have done. Looking at the commit that introduced this. I think there should be a break at the end of the if (inside the braces. | 13:15.26 |
| | Commit a8a47bb37 | 13:15.43 |
| | Also to match the previous code the if should be above case PDF_MAT_COLOR, but still allowing fall through if the if block isn't taken. | 13:16.34 |
| | On the other hand a8a47bb37 may have been fixing a bug. | 13:16.56 |
| Robin_Watts | looking now. | 13:17.42 |
| tor8 | paulgardiner: right you are, that looks like a bug | 13:18.11 |
| | should have an else on the for loop I think | 13:18.22 |
| paulgardiner | else is another possibility, but not if the 'if' applies only to the PDF_MAT_PATTERN, as it did before a8a47bb37 - if I'm reading it correctly | 13:19.10 |
| | the PDF_MAT_PATTERN case, that is | 13:19.36 |
| tor8 | mat->v should be set to a proper color for both the pattern and color case | 13:20.38 |
| | (for uncolored patterns, that pick up the current color) | 13:20.47 |
| Robin_Watts | Where was pdf_set_color originally? | 13:20.53 |
| paulgardiner | Ok, I thought probably so. Yes 'else' is good then | 13:21.02 |
| tor8 | Robin_Watts: it was a twisted incomprehensible mess :) | 13:21.11 |
| paulgardiner | pdf_build.c | 13:21.13 |
| tor8 | and it probably still is :( | 13:21.29 |
| Robin_Watts | paulgardiner: Obviously! :) | 13:21.40 |
| paulgardiner | git kindly directed me there. | 13:22.02 |
| | Of course, this was nothing to do with the problem I was tracing at the time, so another problem: | 13:22.51 |
| Robin_Watts | And before that? | 13:22.54 |
| | oh, it was pdf_setcolor | 13:23.12 |
| | Either a break or an else would do the right thing I reckon. | 13:23.45 |
| paulgardiner | I have a file with something like "0.74 -0.25 -0.25 rg" in it. We somehow make that grey, but Acrobat seems to clamp. | 13:24.01 |
| | I wondered whether we were going float -> signed int -> int before clamping, but that's a wild guess. | 13:26.04 |
| Robin_Watts | I suspect that the mat->v values should be clamped to being between 0 and 1 at the end of pdf_set_color | 13:26.38 |
| paulgardiner | I did that in setColor and it worked, but I wondered if that was the correct place. | 13:27.29 |
| | There seems to be other clamping going on elsewhere. | 13:27.39 |
| Robin_Watts | setColor ? | 13:27.46 |
| paulgardiner | pdf_set_color, sorry | 13:27.58 |
| Robin_Watts | right. | 13:28.08 |
| | I suspect the drawing code all just assumes that the color values are reasonable. | 13:28.37 |
| paulgardiner | Might the v[i] values legitimately hold neg values for some colour spaces? | 13:29.44 |
| Robin_Watts | No (said Robin confidently with his fingers crossed) | 13:30.01 |
| paulgardiner | :-) | 13:31.23 |
| tkamppeter | chrisl, hi | 14:07.51 |
| chrisl | tkamppeter: hi | 14:09.43 |
| tkamppeter | chrisl, I have a user report that simply removing page comprtession from GS's PS output makes the output printing on his Toshiba: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/978120. | 14:17.16 |
| | chrisl, perhaps you ask the propkle at first to send uncompressed PostScript, as I describe in comment #20 of mentioned bug before going deeper into the problem. | 14:18.15 |
| chrisl | tkamppeter: yes, I'll do that, thanks. I've been decompressing the files myself, so far. | 14:19.09 |
| Robin_Watts | tor8: I already have an fz_write. | 14:49.36 |
| | (I know you are unsure about offering a 'write' thing in the fz_document interface at the moment and would rather leave it as a pdf_write thing, and that's fair enough, but I'm loathe to close off the possibility) | 14:50.54 |
| chrisl | tkamppeter: it might be worth double checking with the guy on 998087 that, when tried all those "lpadmin" lines, he actually replaced '<printer>' with the name of his printer...... | 14:58.53 |
| Robin_Watts | Morning mvrhel | 15:03.33 |
| | It seems I've been allocated bug 693048 on the grounds that the name on the commit that caused it was mine. | 15:11.47 |
| | I knew I'd regret that :) | 15:11.57 |
| | but it's quite possible that it really is a graphics lib problem, so I'll look into it anyway, unless you have a burning desire for it mvrhel ? | 15:12.42 |
| | I am going to mark all my contentious commits as being by Michael in future though. | 15:13.15 |
| mvrhel | Robin_Watts: ok that is fine with me if you take that bug | 15:14.00 |
| Robin_Watts | mvrhel: Hmm. | 15:34.45 |
| | I have a dead simple file here that strokes a diagonal line. | 15:35.02 |
| | and I'm stepping through that. | 15:35.14 |
| | The stroke code reads the number of alpha bits correctly. | 15:35.27 |
| | Then it does: if (!color_is_pure(...)) abits=0; | 15:35.41 |
| | Because the color is now a devn one, it's not pure. | 15:36.05 |
| | hence devn colors mean no antialiasing. | 15:36.29 |
| | Essentially, I think it's trying to test for it not being a halftone (because antialiasing a halftone would be bad). | 15:40.02 |
| | So this may predate devn colors ? | 15:40.12 |
| | Can you get halftones with devn colors ? | 15:40.18 |
| henrys | mvrhel:so 693036? Should that go to you. or is this something that goes away with ps2write. Does this customer need to be told to move to ps2write? | 15:45.48 |
| | sorry I haven't kept up. | 15:46.03 |
| Robin_Watts | I thought that mvrhel had mailed them, and they came back saying that ps2write was slower than pswrite for them. | 15:50.48 |
| | mvrhel said that that did not match his experience. | 15:51.00 |
| kens | so did ray | 15:51.23 |
| henrys | okay right. but this likely shouldn't be assigned to alexcher | 15:55.01 |
| | sigh - a difficult customer | 16:00.24 |
| Robin_Watts | So the devn stuff uses fill_rectangle_hl_color - which the alpha device doesn't support. | 16:07.21 |
| | Hence we can never use antialiasing with devn colors (tiffsep, any planar devices etc) | 16:07.59 |
| kens | time to go for a pizza, night all.... | 16:18.22 |
| henrys | Robin_Watts:but I thought that was a regression - tiffsep was using something else before? | 16:25.28 |
| tor8 | Robin_Watts: rename the current fz_write to fz_write_document and I'll be happier | 16:25.54 |
| Robin_Watts | tiffsep was using a chunky device before. | 16:25.59 |
| | tor8: OK. | 16:26.04 |
| tor8 | or fz_save_document :) | 16:26.08 |
| Robin_Watts | I prefer write to save as it can be "write with options" | 16:26.31 |
| | Actually, it's not a planar vs chunky thing. It's a 'devn' vs 'pure' thing. | 16:27.40 |
| tor8 | I was thinking more of load/save, read/write symmetry | 16:27.49 |
| Robin_Watts | previously colors were packed into the color index with compressed color encoding; so the number of colorants could grow over time. | 16:28.34 |
| | Now they are pegged at 14 when we start, and devn colors are used throughout. | 16:28.54 |
| henrys | ah and we can't aa a devn color... | 16:29.52 |
| Robin_Watts | right. | 16:30.00 |
| | (I'm trusting that mvrhel will correct my understanding here if I'm wrong) | 16:30.27 |
| henrys | I like that I can do bugs.ghosts <TAB> <bug number> at a crome url prompt and it will take me to the bug. I guess google understands bugzilla | 16:36.22 |
| Robin_Watts | I mention "bug 12345" on here, and then click on it :) | 16:37.10 |
| | but I will use the chrome trick too from now on, thanks. | 16:37.40 |
| henrys | Robin_Watts:it seems like you've happened upon another weakness in our testing. we should have caught the aa problem. | 17:00.36 |
| Robin_Watts | So the gs antialiasing works by spotting that it's drawing a 'pure' color, drawing to a 1bpp memory device (scaled up) then scaling that down (to get coverage at the real scale), and then filling that with the pure color using copy_alpha | 17:02.59 |
| | I can do the same trick (with some minor tweaks to the memory device) for devn colors too. | 17:03.31 |
| | BUT... how do I copy_alpha with a devn color ? | 17:03.46 |
| | Presumably there should be a high level color equivalent of copy_alpha. Or how has mvrhel done this stuff? | 17:09.49 |
| henrys | I don't see a high level copy alpha. | 17:13.16 |
| Robin_Watts | I have a bad feeling about this. | 17:13.52 |
| rayjj__ | mvrhel: I assume you saw that I managed to do timings for Avadhut (in between laptop crashes). | 17:19.35 |
| sebras | Robin_Watts: Yeah, I think you're right. Full reverse! Chewie, lock in the auxiliary power! | 17:20.16 |
| henrys | rayjj__:buy another laptop, it's not worth it. | 17:25.07 |
| Robin_Watts | rayjj__: Estimate the cost in lost ray time in waiting to reboot, picking up the pieces etc... it really won't take long to justify a new lappy, I expect. | 17:30.06 |
| | Then get it fixed under warranty, and I'm sure someone will give it a home. | 17:30.32 |
| | Earth calling mvrhel, come in mvrhel... | 17:55.32 |
| rayjj__ | Robin_Watts: yes, that's my plan. Just have to find a time to go pick up a new one and move stuff over. At least it's still under warranty. | 18:00.21 |
| marcosw | morning henrys | 18:12.06 |
| henrys | hello marcosw, early? | 18:21.14 |
| | did you want to start now? | 18:22.09 |
| mvrhel | rayjj: you still there? | 18:26.51 |
| | Robin_Watts: I am back | 18:26.55 |
| | wife is away and kid duty is making me overextended | 18:27.18 |
| henrys | mvrhel:you're in demand. | 18:27.35 |
| mvrhel | and my son has a baseball game tonight and one tomorrow morning.... | 18:28.17 |
| marcosw | henrys: yes, we can start now. how far back would you like to go/ | 18:28.35 |
| | ? | 18:28.36 |
| henrys | sorry you did say 11:00 I am late. | 18:28.50 |
| mvrhel | argh: solicitors at the door now. ah luckily they saw the sign | 18:29.08 |
| | Robin_Watts: you there? | 18:29.26 |
| henrys | marcosw:first I wanted to get bugs from cert problems so we can get shelly to work. | 18:29.37 |
| rayjj__ | mvrhel: I am here (sort of). | 18:30.04 |
| mvrhel | rayjj_: thanks for running the test. yes I had only done the pdf to ps case, since that seemed to be the only slow one in his table on the bug | 18:30.36 |
| rayjj__ | mvrhel: my highlighting isn't working so I didn't 'hear' your query | 18:30.42 |
| mvrhel | rayjj_: ok. I don't know what more I can do on this issue | 18:31.06 |
| | maybe you should fly to new dehli to help them out | 18:31.25 |
| marcosw | henrys: sorry about not entering that issue earlier, I'll do it now and then we can discuss (or was there something to discuss before I enter a bug?). | 18:31.26 |
| henrys | not that I know of. | 18:31.54 |
| | do you know the last report we did? | 18:32.32 |
| rayjj__ | mvrhel: I will run pswrite and ps2write in server mode and push them that direction | 18:33.14 |
| | mvrhel: I agree that there isn't anything more for you to do. We just need to push back on server mode processign | 18:34.28 |
| mvrhel | rayjj_: OK. Sounds good. That is really the solution. Do those devices work properly in server mode? It is just pdfwrite yes? | 18:34.32 |
| | that has an issue, and ken is fixing that | 18:34.50 |
| rayjj__ | mvrhel: now (as of earlier this week) pswrite, ps2write and pdfwrite (as far as we know) all work fine in server mode. | 18:35.39 |
| marcosw | henrys: we went through the bugs at the staff meeting, that was three weeks ago. | 18:36.01 |
| mvrhel | rayjj_: oh great! so I think we tell them to do that, and we close the bug. Do you want to handle that? | 18:36.11 |
| | marcosw: thanks for the timings file. I need to double check this as it seems backwards to me. | 18:37.01 |
| henrys | marcosw:lets start with 693007 may 4 | 18:37.10 |
| mvrhel | I will test first and then get back with you | 18:37.16 |
| marcosw | mvrhel: backwards is a possibility, as I said I didn't spot check the results. | 18:37.30 |
| | henrys: 693007 appears to be missing the promised attachments (unless they were emailed, the comment is unclear. | 18:39.11 |
| mvrhel | Robin_Watts: so it sounds like you have a handle on the aa bug | 18:39.55 |
| henrys | marcosw:possible sails lead with that email address. | 18:39.55 |
| | sales | 18:40.13 |
| | are you driving? | 18:40.36 |
| Robin_Watts | mvrhel: No. | 18:40.41 |
| marcosw | yes, I'll forward it to scott and add a comment to the bug asking for the files. | 18:40.42 |
| Robin_Watts | mvrhel: I've hit a dead end with the bug. I can't see how to go on from here. I would like to discuss it. | 18:41.38 |
| | (Sorry, was occupied elsewhere) | 18:41.46 |
| henrys | marcosw:up to 011 which is a bit sparse. | 18:42.36 |
| mvrhel | Robin_Watts: I can try to answer questions but it may be better if I spent a little time looking at it first too | 18:43.01 |
| Robin_Watts | mvrhel: I can run through a description of what I've done and what I've discovered if that will help. | 18:43.27 |
| mvrhel | sure | 18:43.51 |
| Robin_Watts | OK, so the test file on the bug is knackered, so I made my own/ | 18:44.27 |
| | Very simple postscript file that strokes an almost horizontal line, so I can easily see if there are AA pixels. And there aren't when using tiffsep. | 18:45.03 |
| | (that's with GraphicsAlphaBits rather than TextAlphaBits obviously, but it's the same issue) | 18:45.17 |
| henrys | rayjj__:693013 should be an enhancement yes? | 18:45.21 |
| marcosw | henrys: I thought the reference is 011 to 692459 made is clear enough :-) | 18:45.28 |
| henrys | marcosw:okay | 18:45.50 |
| mvrhel | Robin_Watts: yes. and likely some devn HL color proc is missing | 18:46.11 |
| Robin_Watts | If you look in gspaint.c in do_stroke | 18:46.25 |
| | line 402ish. | 18:46.35 |
| | If the color isn't pure, we won't do aa. | 18:46.47 |
| marcosw | 013 says enhancement in the description, so it probably should be categorized as such. | 18:46.50 |
| Robin_Watts | I've updated that so that it's "if the color isn't pure or devn don't do aa" | 18:47.01 |
| henrys | 015 is properly P2 that needs to go forward. | 18:47.09 |
| mvrhel | Robin_Watts: good first step :) | 18:47.19 |
| henrys | marcosw:yes go ahead and change 013 | 18:47.33 |
| Robin_Watts | and the code makes it all the way through rendering down to a call to a fill_rectangle_hl_color call to the alpha bits device. | 18:47.39 |
| marcosw | done | 18:47.40 |
| henrys | and 015 P2 | 18:47.55 |
| marcosw | 014 might be another sales lead | 18:47.57 |
| mvrhel | ok that is probably needed in alph_bits device | 18:48.03 |
| Robin_Watts | But there is no fill_rectangle_hl_color proc in the alpha device, so we return with a crash. | 18:48.09 |
| | I have implemented such a proc. | 18:48.23 |
| | Are you familiar with the way the aa device works? | 18:48.36 |
| mvrhel | yes | 18:48.40 |
| marcosw | it references a comment in 691152 that was entered by jfmachines.co.uk | 18:48.46 |
| | never mind, I already sent an email to scott. | 18:49.18 |
| Robin_Watts | OK, so you know the normal code stores a 'saved_color' color index and then fills the downscaled thing with that using copy_alpha at the end. | 18:49.18 |
| marcosw | moving on to 0134 | 18:49.20 |
| | 013 | 18:49.22 |
| | 015 | 18:49.30 |
| Robin_Watts | I've had to update the device to also keep a stored device color. | 18:49.37 |
| mvrhel | right | 18:49.47 |
| | this had to be done in the clist also | 18:49.53 |
| | as there was a similar process | 18:49.59 |
| marcosw | henrys: why should 015 be P2? | 18:50.05 |
| henrys | right | 18:50.19 |
| Robin_Watts | but the problem is that when the alpha device is flushed, the old code does a copy_alpha and passes in the saved_color. | 18:50.20 |
| | There is no way to do a copy_alpha with the saved_hl_color. | 18:50.42 |
| henrys | yes it looks like jfmachines has not been reported will you tell scott? | 18:50.58 |
| | oh no it has - you did on may 1 | 18:51.20 |
| mvrhel | what type is saved_color? | 18:51.49 |
| | a color index? | 18:51.57 |
| Robin_Watts | yes. | 18:52.16 |
| mvrhel | what a pain | 18:52.39 |
| | I hate to say it, but we may need to add in a new proc then | 18:52.59 |
| Robin_Watts | So we'd have a copy_alpha_hl ? | 18:53.18 |
| mvrhel | yes | 18:53.22 |
| rayjj__ | sounds like that's what we need | 18:53.30 |
| Robin_Watts | OK. Am I right in thinking that there are no default implementations for _hl procs ? | 18:53.46 |
| mvrhel | Robin_Watts: right. they are generally for the clist, the mem planar and for the various filtering devices | 18:54.30 |
| Robin_Watts | We have to do this for the clist? | 18:55.18 |
| mvrhel | as only psdcmyk and tiffsep (devices that support this color type) are the only ones that make use of them | 18:55.21 |
| | there will need to be a copy_alpha_hl for the clist | 18:55.30 |
| | I think | 18:55.35 |
| henrys | ah a bug from gigs 018 | 18:55.38 |
| Robin_Watts | I was hoping that this would be post clist only. | 18:55.39 |
| mvrhel | there is a clist_copy_alpha | 18:55.53 |
| marcosw | I'll take 018 to test. | 18:56.11 |
| mvrhel | Robin_Watts: this is not going to be a one day process to fix | 18:56.25 |
| henrys | okay great. | 18:56.25 |
| Robin_Watts | What filtering devices? | 18:56.33 |
| mvrhel | pdf14 | 18:56.38 |
| | for example | 18:56.43 |
| | that needs to maintain the alpha plane | 18:56.53 |
| Robin_Watts | has running screaming from the building. | 18:56.56 |
| mvrhel | not sure about the pattern accumlator device | 18:57.09 |
| Robin_Watts | gah. I can't type. | 18:57.11 |
| marcosw | I'm up to 026 | 18:57.12 |
| henrys | marcosw phone bbiab | 18:57.26 |
| mvrhel | Robin_Watts: it was your commit that broke this ;) | 18:57.27 |
| Robin_Watts | mmm. | 18:57.41 |
| mvrhel | Robin_Watts: if you want to pass this mess off to me that is fine | 18:57.50 |
| | I had a pile of these things that I had to fix to get us to where we are | 18:58.05 |
| Robin_Watts | yeah. | 18:58.16 |
| mvrhel | When I saw the bug reported, recall that I said I thought it was AA | 18:58.22 |
| henrys | yes, my eclipse glasses are in ... | 18:58.32 |
| mvrhel | in the back of my head I was thking uhoh | 18:58.35 |
| | supposed to be cloudy here Sunday | 18:58.51 |
| | not sure we will be able to see anything | 18:59.05 |
| Robin_Watts | I am tempted to pass it to you, as the pdf14 device is a huge unknown area of code for me. | 18:59.11 |
| henrys | wow marcosw you've sped ahead. | 18:59.45 |
| Gigs- | henrys: hi | 18:59.56 |
| marcosw | Just looking at 033 :-) | 19:00.04 |
| Gigs- | I have not had a change to benchmark mvrhel's planar yet | 19:00.37 |
| | Maybe this afternoon | 19:00.40 |
| henrys | marcosw:hold on 26 is a sales lead - spammer's make lot of $$ | 19:00.43 |
| mvrhel | Gigs: ok. if you find anything tell me in about 2 weeks... | 19:00.57 |
| Gigs- | you mean sooner than 2 weeks? | 19:01.06 |
| mvrhel | I might be able to do something by then | 19:01.08 |
| | just kidding | 19:01.15 |
| henrys | hi Gigs how are you? | 19:01.19 |
| ghostbot | just great, henrys | 19:01.19 |
| Gigs- | henrys: fine, thanks | 19:01.31 |
| mvrhel | ha | 19:01.32 |
| marcosw | would be a support only contract, but I'll send it to scott | 19:01.56 |
| Gigs- | I don't think spammers really make that much. There was a talk at defcon about that sort of thing. Apparently it kind of relies on a steady stream of suckers willing to invest. | 19:02.46 |
| Robin_Watts | mvrhel: Let me make a patch for what I've got here, and attach it to the bug. | 19:02.57 |
| mvrhel | ok. Robin_Watts thanks | 19:03.13 |
| Robin_Watts | mvrhel: No, thank you! :) | 19:03.23 |
| marcosw | henrys: emailed scott with the 026 info. | 19:03.46 |
| henrys | 033 seems fine. | 19:04.01 |
| | 034 should go ray | 19:04.30 |
| marcosw | I'll check if 033 occurs with master. | 19:04.32 |
| mvrhel | Gigs: just so you know, as a tiffsep user, anti-aliasing is broken for this device. not sure if you even used that option though | 19:05.06 |
| marcosw | I'm thinking 036 should go to mvrhel, but I wish Alex would have reassigned it. | 19:06.06 |
| henrys | it should yes, I wish alexcher would have moved it along. | 19:06.41 |
| mvrhel | oh my favorite customer | 19:06.54 |
| rayjj__ | Frankly, I don't understand why cust 393 needs AA at 400 dpi | 19:06.59 |
| mvrhel | rayjj_: I was wonder the same thing | 19:07.12 |
| Robin_Watts | Does tiffsep have the downscaler hooked up I wonder... | 19:07.31 |
| | Probably not. | 19:08.26 |
| rayjj__ | mvrhel: I wonder if we should render at 4x and down sample when emitting the TIFF planes | 19:08.28 |
| henrys | marcosw:actually rayjj_ was handling that customer (036) | 19:08.32 |
| Robin_Watts | But I could hook it up. | 19:08.35 |
| rayjj__ | Robin_Watts: we had the idea at about the same time. | 19:08.56 |
| Robin_Watts | rayjj__: That's exactly what we'd get from hooking the downscaler - yeah. | 19:09.02 |
| mvrhel | that would be nice | 19:09.10 |
| Robin_Watts | I'll have a look at that. | 19:09.32 |
| marcosw | I've reassigned 036 (and made it P1, since it's a top 10 customer). | 19:09.38 |
| rayjj__ | that sounds like easier than adding *_hl_color_alpha functions | 19:09.40 |
| mvrhel | definitely | 19:10.35 |
| henrys | marcosw:042? | 19:11.56 |
| rayjj__ | marcosw: why is the problem with UseFastColor (bug 692036) assigned to me ? | 19:12.21 |
| marcosw | it was a simple bisect problem, there were several changes that decreased performance | 19:12.42 |
| | rayjj__: henry said "actually rayjj_ was handling that customer (036)" ^^ | 19:13.05 |
| henrys | rayjj__: I just thought you could make it all part of a great wontfix statement. | 19:13.16 |
| marcosw | that should read "wasn't a simple bisect problem" | 19:13.30 |
| rayjj__ | mvrhel: do you have any idea what the issue is (why the UseFastColor output is wrong ? | 19:13.34 |
| marcosw | I'll update 042 later today. | 19:13.39 |
| | I think that's it for the bugs. The rest all seem correctly assigned (most are internal). | 19:14.20 |
| rayjj__ | marcosw: I was going to push cust 130 toward using server mode, but that doesn't address 693036 which is incorrect output with -dUseFastColor | 19:14.54 |
| henrys | okay looks like I need to send out an email to everyone to change status to "assigned" as we agreed at the meeting, I'll do that now. | 19:14.54 |
| | rayjj__:seems to me like they shouldn't be using that option - presumably with server mode they won't need it right? But yes reassign to michael. | 19:15.57 |
| rayjj__ | henrys: that option can result in a big performance gain (not using ICC color) | 19:17.20 |
| henrys | rayjj__:what seems to be lacking in the communication to the customer is that ps2write produces better output - pswrite output is unacceptable so it really isn't sensible to compare the device except in their particular workflow. | 19:17.27 |
| Robin_Watts | mvrhel: patch attached. | 19:18.17 |
| | I'll look at the downscaler later (maybe not til monday) | 19:18.29 |
| henrys | rayjj__:well if you think their workflow should have the option fine. I was trying to avoid loading mvrhel with another customer bug. | 19:18.30 |
| rayjj__ | henrys: we have told them that pswrite is deprecated. After I do the server mode performance with ps2write we can just push them that way for performance. | 19:19.20 |
| henrys | right okay. | 19:20.12 |
| rayjj__ | henrys: of course the 'gotcha' is that ps2write (and pdfwrite) server mode only work with HEAD and there are quite a few patches (from ken) to get 9.05 to work | 19:20.14 |
| henrys | and server mode is immature. | 19:21.31 |
| mvrhel | rayjj_ and henrys : I agree that if they run in server mode, they should not need to use -dUseFastColor | 19:24.02 |
| rayjj__ | henrys: server mode working for ps2write and pdfwrite is immature. It worked all along for pswrite (but we won't emphasize that going forward) | 19:24.35 |
| mvrhel | so the solution to that customer is to go with server mode and not use -dUseFastColor and all their issues should go away | 19:25.41 |
| rayjj__ | mvrhel: I'll verify that. I don't want to assume that without testing | 19:25.50 |
| mvrhel | rayjj_: yes that would be a wise idea | 19:26.02 |
| | need to run to the store bbiab | 19:26.08 |
| rayjj__ | mvrhel: because ICC color is somewhat slower than FastColor mode if there are lots of color conversions | 19:26.38 |
| | as with image files and possibly with gradients | 19:26.54 |
| | mvrhel: but I'll test with their files with and without UseFastColor in server mode | 19:27.29 |
| mvrhel | henrys: did miles decide on the next staff meeting date? | 20:13.52 |
| | and am I working on 036 or is rayjj_ ? | 20:15.11 |
| henrys | I think 034 should be a P4 bug on your list right? | 20:54.21 |
| | mvrhel:perhaps there should be a new bug - marcos should do a quick scan for egregious problems with FastColor? | 20:55.19 |
| | miles did not say more about the meeting, no. | 20:55.53 |
| | mvrhel:so 036 stays with rayjj_ unless he finds performance unacceptable, but I do think we should look for severe breakage with fastcolor, do you agree or do you feel it will be an option seldom used? | 21:21.15 |
| mvrhel | henrys: I think we should look for severe breakage | 22:31.27 |
| henrys | okay I'll ask marcosw about it. | 22:56.02 |
| | marcosw:just talking about you. | 22:58.57 |
| marcosw | it's not true! | 22:59.06 |
| henrys | Would it be possible to do a random sampling of test files fast_color vs no fast color? | 22:59.44 |
| marcosw | comparing output or just times? Either is relatively easy. | 23:00.40 |
| henrys | I think our immediate concern is severe quality degradation. | 23:01.33 |
| marcosw | so 72dpi would be sufficient? | 23:01.51 |
| henrys | I think so, yes. | 23:02.07 |
| marcosw | and what output device(s)? | 23:05.45 |
| henrys | mvrhel:wouldn't a cmyk dithering device catch problems in most devices except high level stuff? | 23:09.00 |
| | I guess we should check banding too but that can be automated by using fast color with and without banding. | 23:09.43 |
| | unless mvrhel thinks otherwise I would say 1 bit cmyk and pdfwrite. maybe 100 randomly selected files? | 23:10.27 |
| | be back later this evening. | 23:13.26 |
| mvrhel | henrys: yes, this makes sense. I am surprised that -dUseFastColor is an issue in a high level device | 23:26.09 |
| | bb later. off to baseball | 23:26.32 |
| | Forward 1 day (to 2012/05/19)>>> | |
IRC Logs