| | <<<Back 1 day (to 2013/10/20) | 2013/10/21 |
| ray_laptop | well, since ghostbot is here, I assume the empty logs are just because everyone is on holiday :-) (including me) | 02:08.11 |
| | waiting to see if my comment shows up in the logs. otherwise, I'll restart ghostbot | 02:09.33 |
| | Guess it's OK. Just saw my comments. | 02:10.42 |
| sebras-hotel | hi | 09:08.42 |
| ghostbot | hi, sebras-hotel | 09:08.42 |
| sebras-hotel | ghostbot: so... are we the only ones here today? seems awfully quiet... | 09:09.16 |
| ghostbot | sebras-hotel: okay | 09:09.16 |
| chrisl | sebras-hotel: there are others here - but, personally, I'd prefer to elsewhere right now....... | 09:11.56 |
| kens | is cloaked | 09:12.15 |
| sebras-hotel | it is quiet over at #gstreamer as well, everyone is on the gst-conference in edinburgh | 09:13.50 |
| kens | thinks; Not a good day to be in Edinburgh | 09:14.14 |
| sebras-hotel | no..? | 09:14.37 |
| kens | wet and windy | 09:14.42 |
| chrisl | That's true for ~6 months every year! | 09:15.20 |
| sebras-hotel | ah, but isn't it always..? | 09:15.22 |
| | chrisl: the other ~6 months it is cold and snowy..? | 09:15.40 |
| kens | chrisl is custom_tests.lst a new file in teh regression suite ? I don't recall seeing it before and my pdfwrite change cna't possibly have caused it to start fialing | 09:15.54 |
| chrisl | kens: never seen it before. Maybe it's part of doing the customised testing we discussed at several staff meetings? Or a mistake | 09:16.57 |
| | sebras-hotel: no, it can actually be quite nice in Edinburgh - I was there at the end of sept and it was blue sky/t-shirt weather...... | 09:17.33 |
| kens | Hmm, well maybe I'll tackle Marcos about it, I only changed pdfwrite and the original file is failing in *every* configuration, so I don't htink it cna be me. I'm not sure I see the point in adding a test file that fails everything | 09:17.43 |
| chrisl | kens: where is custom_tests.lst? | 09:18.37 |
| kens | in tests_private/comparefiles, according to the log I just got | 09:18.57 |
| chrisl | Well, looking at what it contains, it's not a surprise it fails! | 09:19.36 |
| kens | It has hte look of a parameter file, form the name | 09:20.15 |
| chrisl | I do think it's related to marcosw starting on the customised testing, as it contains: "tiger.pbmraw.1000.0-dMaxBitmap=10000 -sDEVICE=pbmraw -r1000 -dJOBSERVER ./tests_private/comparefiles/tiger.eps" | 09:20.41 |
| kens | Then I will ignore the problems :-) | 09:21.38 |
| chrisl | I should think that's a good idea..... | 09:21.53 |
| Micha` | Hallo Leute! | 09:23.52 |
| kens | Guten Morgen | 09:23.58 |
| Micha` | In my application, I want an XObject containing all the handwritten annotations the user makes. On first creating this XObject, I naturally use pdf_new_pdf_device to populate it. On resuming writing, in another session, I wanted to use the same function to *augment* the stream. This is not the present behavior, where the stream is overwritten. So I have written code to update the pdf_device created within pdf_ne | 09:30.02 |
| | w_pdf_device with the old data, hence setting num_L, max_L, and L for L = images, alphas, fonts, groups, gstates. | 09:30.03 |
| | Should I submit this code using the bug tracking system? | 09:30.28 |
| kens | Probably, or you could wait until Robin is online and ask (or let him read the logs of course) | 09:31.13 |
| Robin_Watts | I'm here | 09:31.21 |
| | Micha`: Yes, add the code to an enhancement bug request. | 09:31.58 |
| Micha` | It is unclear from the comment describing pdf_new_pdf_device that it *erases* the contents first. Maybe this is not the final intent of pdf_new_pdf_device? | 09:32.10 |
| Robin_Watts | It is the 'current' behaviour, and I think it's documented as a device that's still in flux. | 09:32.56 |
| | Micha`: Possibly we'll want a pdf_new_appending_pdf_device or something. | 09:33.22 |
| chrisl | Robin_Watts: I finished Wool over the weekend - that a very, um, compelling book! I could barely put it down. Thanks for the recommendation. | 09:36.58 |
| kens | also read it | 09:37.08 |
| | asving up next 2 for more trips | 09:37.24 |
| Robin_Watts | chrisl: Ah, fab. I haven't read 'Shift' yet. Supposedly it's good, but not as good. | 09:37.29 |
| Micha` | As an end user, I would have expected pdf_new_pdf_device to resume writing to the stream by default, and I'd have searched for a fz_reset_device if I needed to actually erase the contents of the stream. | 09:37.46 |
| | But well, this is independant of the code I can propose now. | 09:37.55 |
| Robin_Watts | chrisl: I recommend "Leviathan Wakes" too. | 09:38.35 |
| kens | Isn't that a Peter Hamilton book ? | 09:38.47 |
| Robin_Watts | SA Corey. | 09:38.55 |
| kens | Oh my mistake | 09:39.01 |
| Robin_Watts | James S A Corey, even. | 09:39.07 |
| | First of 3. All of which I enjoyed. | 09:39.25 |
| chrisl | Ah, good, I've gone off Hamilton since the last of the Void books..... | 09:39.36 |
| kens | Yes, couldn't agree more | 09:39.55 |
| Robin_Watts | I've also just finished "Empire of Light" the 3rd of a series by Gary Gibson. | 09:40.05 |
| | The last void book put me off hamilton :( | 09:40.16 |
| kens | ah yes, I've been tempted by Leviathan, Amazon keeps recommending it to me, but not got around to trying it yet | 09:40.22 |
| Robin_Watts | I have Manhattan in Reverse to read next. | 09:40.28 |
| chrisl | kens: I also read Rapture of the Nerds - that was rather disappointing | 09:44.08 |
| kens | Yeah, I wasn't impressed | 09:46.01 |
| chrisl | I thought similar ground was covered better in Accelerando | 09:46.41 |
| kens | Exactly | 09:46.48 |
| chrisl | And I was pleasantly surprised by Saturn's Children - I hadn't expected much it, and quite enjoyed it | 09:47.32 |
| Robin_Watts | http://kitty.9bis.net/ <- Improved version of putty. | 10:44.04 |
| | kens, chrisl (and indeed anyone else interested): Could I trouble you to proof read the new section of docs I've just written please? | 12:40.32 |
| | http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=blob_plain;f=gs/doc/Drivers.htm;hb=93665e3a5d8d8b4cc5d9b6efcb1bdb22c0a86743#Printer_drivers_mt | 12:40.33 |
| kens2 | Robin_Watts : the documentation looks good to me. Would it be possible to add a caveat in there somewhere to the effect that "high-level, non-rendering devices such as pdfwrite and ps2write do not benefit from any multi-threaded support as both interpretation and creaqtion of the high-level output are essentially inherently single-threaded". I know your doc is very careful to refer to rendering and compressed buffers of rasters, | 13:51.08 |
| | but it would be nice to have that explicitly somewhere | 13:51.08 |
| Robin_Watts | kens2: You're not printer devices. | 13:51.33 |
| kens2 | Robin_Watts : and you think people will undertand that distinction ? | 13:51.48 |
| Robin_Watts | OK. I have a plan. Let me try it... | 13:52.03 |
| kens2 | THe existing parameter is -dNumRenderingThreads and people don't understand that rendering means rendering.... | 13:52.10 |
| | I'd behappy to say 'non printer devices such as...' | 13:52.40 |
| | Of course, apps like PDF Creator which present the GS PDF output as a virtual printer rather blur that distinction too | 13:53.17 |
| Robin_Watts | <p>While the <tt>print_page</tt> entry point is specific to printer | 13:55.59 |
| | devices, the <tt>process_page</tt> device entry point is not. It will, | 13:56.01 |
| | however, only be useful for devices that involve rendering the page. | 13:56.03 |
| | As such, neither -dNumRenderingThreads or <tt>process_page</tt> will | 13:56.05 |
| | help accelerate devices such as <tt>pdfwrite</tt> or <tt>pswrite</tt>. | 13:56.07 |
| kens2 | THat's good | 13:56.20 |
| | Very happy with that | 13:56.25 |
| Robin_Watts | fab. | 13:56.30 |
| | Morning mvrhel_laptop | 14:49.22 |
| mvrhel_laptop | hi Robin_Watts | 14:49.29 |
| sebras-hotel | oh, tor(n) seems to be missing today..? | 14:51.45 |
| Robin_Watts | sebras-hotel: He's off from 21-24th | 14:52.43 |
| sebras-hotel | Robin_Watts: yes! he mentioned something like that yesterday or the day before, but I didn't anticipate it was so soon. | 14:53.30 |
| | ...and of course I had forgotten. | 14:54.07 |
| Robin_Watts | mw too. | 14:54.07 |
| | me too | 14:54.08 |
| chrisl | Robin_Watts: the doc seems okay to me - <sigh> even more in the device API...... | 14:55.38 |
| Robin_Watts | chrisl: Couldn't see any other way to do it nicely. | 14:56.15 |
| | And no one will ever need to implement this. | 14:56.40 |
| chrisl | Robin_Watts: I'm not criticising you - just venting my feelings on the leviathan | 14:56.56 |
| Robin_Watts | (i.e. the default or the clist ones are all we'll ever need) | 14:57.00 |
| | chrisl: The problem is not the amount in the device API - it's the amount of dead stuff there, IMHO. | 14:57.24 |
| chrisl | Yep | 14:58.07 |
| kens | marcosw ping | 15:52.33 |
| mvrhel_laptop | kens: so with your file and the command line you gave me I get a seg fault | 16:03.53 |
| kens | really ? I don't (or didn;'t) | 16:04.05 |
| mvrhel_laptop | if (pdev->PDFA < 0 || pdev->PDFA > 2){ | 16:04.32 |
| | ecode = gs_note_error(gs_error_rangecheck); | 16:04.34 |
| | param_signal_error(plist, "PDFA", ecode); | 16:04.35 |
| | goto fail; | 16:04.37 |
| | } | 16:04.38 |
| kens | pdev->PDFA should be 0 | 16:04.52 |
| mvrhel_laptop | it ends up in here in gdevpdfp.c | 16:04.52 |
| | it is -1 | 16:05.03 |
| kens | SOrry yes -1 | 16:05.08 |
| | Hmmm let me try this | 16:05.18 |
| mvrhel_laptop | and ref_param_read_signal_error ends up doing a segv | 16:06.05 |
| | not sure why though | 16:06.43 |
| kens | You did set -sOutputFile ? | 16:07.04 |
| mvrhel_laptop | -sDEVICE=ps2write -dPDFUseOldCMS=false -dCompressFonts=false -dCompressPages=false -o ./myoutputs/test.ps ./myinputs/ken_test.pdf | 16:07.27 |
| kens | Looks OK, just a second | 16:07.45 |
| | Nope, runs to completion for me# | 16:08.30 |
| mvrhel_laptop | let me do a clean rebuild | 16:08.40 |
| kens | THat's using absolutely up to dat e code and a 32-bit debug build | 16:08.51 |
| mvrhel_laptop | I am doing 32-bit debug | 16:09.04 |
| | I updated yesterday but will again | 16:09.11 |
| kens | Yesterday should be fine, the only reason I'm using totally up to date code is because I fixed a couple of unrelated problems recently | 16:09.34 |
| | For me pdev->PDFA is 0 when I hit that line | 16:10.37 |
| mvrhel_laptop | ok still building... | 16:10.49 |
| kens | As I remember PDFA=0 means 'not PDFA', 1 = 'PDF/A-1' and 2 means 'PDFA-2' | 16:11.31 |
| | -1 sounds wrong | 16:11.41 |
| mvrhel_laptop | we are going out to a ps file. not sure I would know what PDFA setting would do | 16:12.09 |
| | ok works now | 16:12.35 |
| | sorry to bother you with that kens | 16:12.42 |
| kens | Well, our PostScript file is a PDF wrapped up with PS code tro read it | 16:12.43 |
| mvrhel_laptop | I should have done the rebuild first | 16:12.47 |
| kens | NP mvrhel_laptop | 16:12.49 |
| mvrhel_laptop | ok so I am getting the gray square where it should be white | 16:14.14 |
| kens | Yes, that's the problem | 16:14.24 |
| | I followed through to where teh DeviceN remap takes place, and verified all the components were 0 | 16:14.39 |
| | Then it goes through the link, to convert to RGB, and the result is 0.5 gray (pdfwrite tests RGB results to see if R=G=B and sets them to gray) | 16:15.19 |
| mvrhel_laptop | ok. let me see what is going on | 16:15.35 |
| | actually let me check that going to a raster device works | 16:15.58 |
| kens | It does | 16:16.07 |
| mvrhel_laptop | oh ok | 16:16.12 |
| kens | Which is why I'm assuming I've done something dumb :-) | 16:16.28 |
| | OK I have to run off, will check the logs later | 16:19.50 |
| mvrhel_laptop | oh | 16:23.22 |
| | kens: you still here/ | 16:23.32 |
| | ? | 16:23.34 |
| kens | Back briefly mvrhel_laptop | 16:34.07 |
| mvrhel_laptop | kens: so the issue is that concretization will return fracs | 16:34.22 |
| kens | Right I wondered if that was the problem | 16:34.33 |
| | SO I need to frac2float the results | 16:34.42 |
| | I must have been lucky with the other cases | 16:34.59 |
| mvrhel_laptop | yes. around line 389 like | 16:35.00 |
| kens | I htink there are a few places I call concretize, I'll check them all | 16:35.18 |
| mvrhel_laptop | when you do the icc stuff your self you will not need to do this | 16:35.28 |
| | like around line 460 | 16:35.35 |
| | ok. so you should be good to go now | 16:36.13 |
| | and I will head back to mupdf | 16:36.28 |
| kens | Yes I'll try and get back to it later, failing that, tomorrow. Thanks Michael | 16:36.30 |
| mvrhel_laptop | your welcome | 16:36.36 |
| | have a good night kens | 16:37.23 |
| kens | ANd you have a good day Michael :-) | 16:37.33 |
| | Off again for a shower | 16:37.38 |
| henrys | chrisl: good luck with yuki, see your mail | 16:41.58 |
| | if I delegate things before you know about them you can't touch your nose. I pick up fast on these things. | 16:42.56 |
| chrisl | henrys: wtf? Intellifont? | 16:43.16 |
| henrys | yes see my comments about that. | 16:43.43 |
| | odd | 16:43.44 |
| chrisl | henrys: I'm not that encouraged getting these kinds of questions from such an (apparently) senior person..... | 16:44.57 |
| henrys | chrisl: well if he could do something they'd put him to work ;-) | 16:46.07 |
| chrisl | henrys: the worry is that we are actually missing a lot of glyphs compared to the MT fonts - *but* none of them seem relevant to PDF (Acrobat does not seem to support them). I feel an engineer is more likely to understand that. | 16:47.30 |
| henrys | chrisl: does postscript? | 16:48.52 |
| chrisl | No | 16:49.08 |
| henrys | can't we construct a comparison that compares what is "reachable" by PDF or Postscript | 16:51.00 |
| chrisl | We can in Postscript, not in PDF. | 16:51.28 |
| henrys | right hmmph | 16:51.53 |
| | of course the postscript program could be converted to pdf but that will only get a subset of PDF accessible fonts. | 16:52.40 |
| chrisl | Well, the list of PDF accessible fonts is essentially the same as PS on the two RIPS we're comparing | 16:53.40 |
| henrys | chrisl: as long as you detail the limitation I think that is fine. | 16:57.18 |
| chrisl | henrys: I'm writing a "holding" mail just now - he's got questions there I don't have an immediate answer for | 16:57.56 |
| henrys | bbiab | 17:00.17 |
| ray_laptop | morning, all. | 17:13.32 |
| | My son had a dentist appt this AM, so I got a late start | 17:13.47 |
| Robin_Watts | ray_laptop: Morning. | 17:14.27 |
| | Various patches up for your consideration. | 17:14.34 |
| | I'm working on a version of the downscaler to work with process_page now. | 17:14.59 |
| ray_laptop | Robin_Watts: on the gxdso_adjust_bandheight I see that it is only on the path without a fixed bandheight, which means that a command line can cause breakage of page processing. | 17:15.16 |
| Robin_Watts | Oh. I didn't realise the command line would set it like that. | 17:16.03 |
| | but I suppose it has to. | 17:16.10 |
| | so would you be happy with me moving out to the generic level ? | 17:16.26 |
| ray_laptop | so devices that have specific band height requirements need to check and fall back (or error out) if the constraint is not met, right ? | 17:16.27 |
| Robin_Watts | We could make devices error out, yes. | 17:17.00 |
| | falling back - not so much. | 17:17.13 |
| ray_laptop | some devices might be able to fall back to processing in the main thread. But mainly it should be noted in the doc that 'if the processing requires a specific band height, it *might* have the adjust_bandheight dso called, but it may not. the device should check before rendering and fall back or return an error code" | 17:19.48 |
| Robin_Watts | ray_laptop: Why don't we just make it *always* call the adjust_bandheight ? | 17:21.22 |
| ray_laptop | Robin_Watts: also, allowing the dso to adjust the bandheight upwards might cause problems. If allocation of the computed band height fails, the logic reduces the size and tries again. If the dso increases it, that might create a loop | 17:21.41 |
| Robin_Watts | ray_laptop: The documentation (a later commit that you haven't got to yet) says that it should only adjust downwards. | 17:22.13 |
| ray_laptop | Robin_Watts: I'm OK with having it always call the adjust | 17:22.13 |
| | Robin_Watts: yes, I'll review the docs also. | 17:24.03 |
| | I guess I'll reserve comments until I've gone over the whole bunch | 17:24.29 |
| Robin_Watts | I need to tweak the docs to say that we will always adjust the bandheight. | 17:24.38 |
| | so if you want me to do that before you go any further, just say. Save you going over it several times. | 17:24.58 |
| ray_laptop | Robin_Watts: What is the default_process_page for ? | 17:26.00 |
| Robin_Watts | ray_laptop: Non clist mode. | 17:26.12 |
| | So people who are writing printer devices don't need to cope differently for clist and non-clist modes. process_page will work for both. | 17:26.56 |
| | just there will be no benefit for the non-clist mode. | 17:27.09 |
| henrys | yikes can't believe I'm showing my house ⦠been here for 17 years. | 17:27.10 |
| ray_laptop | Robin_Watts: Rather than gx_default_process_page, then I suggest naming it something else eg. gx_page_mode_process_page ot gx_non_clist_process_page | 17:27.26 |
| Robin_Watts | ray_laptop: Why? It is a default implementation of process_page. | 17:27.45 |
| | It will work with any device. | 17:27.55 |
| ray_laptop | Robin_Watts: well, invoking it if the device is in clist mode will be a problem, won't it ? | 17:28.40 |
| Robin_Watts | It gets inserted into any device that puts NULL in the value as with all the other default functions. | 17:29.13 |
| | and that gets overriden by the clist one whenever the device is setup as as clist device. Exactly like all the other clist procs are. | 17:29.44 |
| ray_laptop | Robin_Watts: and I have a little bit of heartburn about using process_page code that expects to work in a band on the whole page -- in particular the buffer it creates might double the amount of memory used | 17:30.10 |
| Robin_Watts | ray_laptop: But that's exactly what a page device would be doing anyway. | 17:30.47 |
| ray_laptop | so if someone wants to limit memory usage to a certain amount (say with -dBufferSpace) and the page mode buffer is just below that limit, the default_process_page could greatly increase memory usage | 17:31.42 |
| Robin_Watts | ray_laptop: Right, but the existing solution is exactly as bad. | 17:32.30 |
| ray_laptop | Robin_Watts: no, because the existing solution doesn't need to process in a thread safe manner and can operate line by line | 17:33.59 |
| Robin_Watts | ray_laptop: yeah, the buffer could grow incrementally more safely. | 17:34.25 |
| ray_laptop | but if the process_page functions have to be constructed to run thread safe, the call from default_process_page won't let them operate in line by line mode, right ? | 17:35.32 |
| Robin_Watts | ray_laptop: Sorry? | 17:36.15 |
| ray_laptop | but I guess a process fn could recognize that it's getting the entire page in the init_buffer fn call | 17:37.22 |
| Robin_Watts | ray_laptop: yes. | 17:37.48 |
| | Good spot. | 17:37.51 |
| ray_laptop | Robin_Watts: what do you think about allowing a process fn return the number of lines it processed, so the caller can loop on a calling process and output until it is all consumed. | 17:38.48 |
| | That would let a process function use a smaller buffer | 17:39.03 |
| Robin_Watts | ray_laptop: I like that not at all. | 17:39.10 |
| ray_laptop | waits for the objection | 17:39.30 |
| Robin_Watts | Trying to formulate it now. | 17:40.09 |
| | We have threads running in the background filling buffers. | 17:41.41 |
| | And the output functions send those buffers out to file. | 17:41.53 |
| | At the moment, a background thread cannot run the next band until its current band has been output (as the buffer won't be free) | 17:43.16 |
| | Actually, this probably don't make the situation any worse than it currently is. | 17:44.38 |
| | but I suspect it makes it much harder to code. | 17:44.45 |
| | ray_laptop: As you say, the device can spot that it's being called in init_buffer_fn in a single threaded mode. | 17:47.00 |
| | And if it is called in single threaded mode, it is free to do the outputting wherever it wants. | 17:47.26 |
| | It is possible that in future we might want to consider having more buffers than threads, so we can run the next thread while the output is being done in the forground. | 17:48.22 |
| | And returning the number of lines used would complicate that. | 17:48.32 |
| ray_laptop | Robin_Watts: OK. I admit that while it makes sense for page mode, it would grossly complicate MT banded mode | 17:49.33 |
| | so for page mode, a device that recognizes that it's in page mode, (in the init_buffer call) might be able to NULL out its output_fn, and call the output_fn itself, using whatever (small) buffer it might need | 17:51.27 |
| Robin_Watts | ray_laptop: yeah. | 17:52.30 |
| ray_laptop | Robin_Watts: so for page mode, we _could_ examine num_rendering_threads_requested and spawn multiple threads for the processing, right ? | 17:53.10 |
| | each thread would get 1/n of the page mode buffer to process | 17:54.15 |
| Robin_Watts | ray_laptop: Urm... yes. | 17:54.21 |
| ray_laptop | too clever ?? | 17:54.34 |
| Robin_Watts | I think that's a clever idea to keep around for if we ever need it. | 17:54.49 |
| | And if we do, then we'd be really glad we'd called it gx_default_process_page :) | 17:55.06 |
| ray_laptop | jsut hates having cores sit around on their butts | 17:55.07 |
| | Robin_Watts: so, how about adding that idea as a comment in the default_process_page | 17:56.35 |
| Robin_Watts | Will do. | 17:58.05 |
| ray_laptop | Robin_Watts: plus noting either in the doc or the default code, (or both) the method to avoid needing another full page buffer when in page mode (mentioning how init_buffer determines that) | 17:58.16 |
| | Robin_Watts: and possibly add that to the "example" fpng code ??? | 17:59.04 |
| Robin_Watts | ray_laptop: Yeah. I have notes of those here. | 17:59.25 |
| | I will do that tomorrow. | 17:59.31 |
| ray_laptop | Robin_Watts: great! | 17:59.33 |
| kens | mvrhel_laptop : just to say I tried the fix on that code and it works perfectly. I'll sort out the other cases tomorrow. THanks again | 17:59.44 |
| mvrhel_laptop | kens: good news | 17:59.56 |
| ray_laptop | thanks for being so receptive to my screwball ideas :-) | 17:59.56 |
| kens | Now I'm heading off, night all | 18:00.15 |
| ray_laptop | Robin_Watts: I'll finish reviewing the docs shortly. | 18:00.39 |
| Robin_Watts | ray_laptop: ideas are no more screwball than all this work is :) | 18:01.01 |
| ray_laptop | Robin_Watts: OK, so I've looked at the docs and like it, so once you've added the tweaks we've discussed, I'm fine with you pushing it | 18:07.29 |
| | Robin_Watts: now all we have to do is convince cust 801 to use it :-/ | 18:07.55 |
| | back to cust 532 fun :-( | 18:11.27 |
| | wow. a 2TB laptop drive for $69 -- too bad it's only 5400 RPM | 18:16.16 |
| Robin_Watts | ray_laptop: I have a 4TB drive at 5400RPM. Couple it with an SSD, and it's ideal. | 18:19.41 |
| | oh, for a laptop drive. That's a good price. | 18:20.07 |
| ray_laptop | henrys and Robin_Watts: do you think we should modify cust 801's device to use the process_page mode. Since the code we have is 9.07 based, it would be sort of painful. | 18:20.22 |
| Robin_Watts | ray_laptop: I had an email in mind to send to them about this stuff. | 18:20.44 |
| ray_laptop | Robin_Watts: yeah, if that was a hybrid I'd probably jump on it | 18:20.53 |
| Robin_Watts | Say that we'd been looking over their code, and we'd spotted this non-standard thing they'd done. Compliment them on it being a cunning trick to get the extra performance. And then say that inspired by that we've extended the core of standard ghostscript to allow such benefits to be done entirely within the device. | 18:22.10 |
| | And offer to help them move over to the new scheme. | 18:22.30 |
| | ray_laptop: So you're happy with the fact that fpng etc all modify the contents of the buffer device ? | 18:22.57 |
| ray_laptop | Robin_Watts: sounds like a good approach. | 18:23.18 |
| Robin_Watts | I claim this is safe to do, because process_page sends each band once, strictly non overlapping etc. | 18:23.36 |
| ray_laptop | Robin_Watts: not excited about modifying the contents of the buffer, but I'm able to accept it without my gorge rising ;-) | 18:24.11 |
| Robin_Watts | I can live with that :) | 18:24.21 |
| mvrhel_laptop | bbiab | 18:32.20 |
| henrys | ray_laptop, Robin_Watts: I'm not up to speed on that, I do want to get 801's code regression testable. that's my goal with 801. | 19:19.59 |
| Robin_Watts | henrys: How do you propose we get 801s code regression testable? | 23:03.58 |
| | The easiest way would be to port it into our new scheme. | 23:04.05 |
| mvrhel_laptop | argh. the way I wanted to fix my issues in winRT are not going to work I think | 23:55.02 |
| | taking a break for a bit | 23:55.08 |
| | Forward 1 day (to 2013/10/22)>>> | |
IRC Logs