| | <<<Back 1 day (to 2013/10/15) | 2013/10/16 |
| Robin_Watts | got it. | 00:01.20 |
| | SpNg: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=4a51eec56e083d8b704394a478e03de86cd2643a | 00:03.51 |
| | Let me know how that works out for you. | 00:03.58 |
| ray_laptop | Robin_Watts: It looks like PNG supports IDAT chunks, each compressed individually | 00:04.17 |
| | Robin_Watts: " typically the chunk size will correspond to the encoder's buffer size." | 00:04.56 |
| Robin_Watts | ray_laptop: They are not compressed separately. | 00:06.58 |
| | Trust me, I ran into this last month in mupdf. | 00:07.07 |
| | when I added banding there. | 00:07.18 |
| ray_laptop | so, since IDAT chunks contain the compressed datastream is then the concatenation of the contents of all the IDAT chunks | 00:07.20 |
| | all that is needed is a "reset" for Flate, right ? | 00:07.38 |
| Robin_Watts | ray_laptop: Ah, I see where you'te going. Yes. | 00:07.58 |
| SpNg | Robin_Watts: trying it now ;-) | 00:13.31 |
| | ls | 00:13.51 |
| ray_laptop | Robin_Watts: looking at some sites, I see mention of a zlib "full flush", or a way of writing "a partial deflate stream" | 00:16.40 |
| | Robin_Watts: more tomorrow. My brain has to re-tune to the old 8.72 code for cust 532. At least I'm making progress. | 00:19.38 |
| SpNg | Robin_Watts: is this patch for 9.10? | 00:23.45 |
| | Robin_Watts: I can't get that compile. for some reason I keep running out of disk space when doing "make" I added a 50GB vdi to my virtual box and compiled it. used the whole drive up then terminated. any ideas? | 01:42.58 |
| Srinivasa | Hi all here! | 06:15.40 |
| | is there a way to compare text+formatting of two pdf files? | 06:15.58 |
| chrisl | Srinivasa: in general, looking at them is the only reliable method | 06:17.58 |
| Srinivasa | chrisl, need an automated way of doing... atleast text and its style... | 06:18.49 |
| chrisl | Srinivasa: you might be able to get the information to do the comparison out Ghostscript's txtwrite device - I'm not sure | 06:23.02 |
| | Srinivasa: of course, txtwrite (and the mupdf "equivalent" output) will only produce output for text that is actually "text"...... | 06:27.07 |
| Srinivasa | chrisl, great piece of info.... thanks! I will give it a try..... | 06:27.46 |
| chrisl | Srinivasa: it really depends on the level of detail you need. | 06:28.31 |
| Srinivasa | chrisl, I am actually trying to compare the extracted text out of pdf with the html converted back to pdf- ofcourse along with the style | 06:30.02 |
| | do you think there are better ways of doing so? | 06:30.19 |
| chrisl | Srinivasa: I think that's a process bound to fail regularly, unless the PDFs are *very* carefully tailored to the process | 06:31.35 |
| | Srinivasa: you should probably look at the txtwrite output options: http://ghostscript.com/doc/9.07/Devices.htm#TXT | 06:33.11 |
| Srinivasa | chrisl, I am going through the url .... | 06:34.42 |
| | Using somekind of test automation could resolve? | 06:35.13 |
| chrisl | Well, I would start with -dTextFormat=0, then parse the XML and compare the data | 06:36.07 |
| sebras-work | Srinivasa: so... if you already have a tool that extracts the text from the PDF and makes html for you, then why do you need to compare it? | 06:47.24 |
| Srinivasa | sebras-work, extraction can miss certain spaces.... and sometimes depending on the pdf might skip formatting also... | 06:48.16 |
| chrisl | Srinivasa: it might be missing "spaces" because aren't actually spaces, in which case, other text extraction systems wouldn't necessarily do any better | 06:50.01 |
| Robin_Watts | Morning to7. | 08:30.54 |
| | I think there are a couple of small fixes on robin/master for your enjoyment. | 08:31.08 |
| sebras-work | tor7: morning! | 08:34.39 |
| tor7 | Robin_Watts: backport which fix from where? I thought we were using openjpeg 2 | 08:34.57 |
| Robin_Watts | tor7: no. we're still on openjpeg 1.5+patches, I believe. | 08:35.19 |
| tor7 | ah. is openjpeg2 in a separate repo? | 08:35.40 |
| | or on a different branch that we don't track | 08:35.52 |
| | in our git-conversion repo | 08:35.59 |
| Robin_Watts | tor7: Honestly I can't remember. | 08:36.22 |
| tor7 | Robin_Watts: okay. they look fine, anyway. | 08:36.52 |
| Robin_Watts | Ta. | 08:36.59 |
| tor7 | now I just need to look over paul's commits | 08:37.01 |
| Robin_Watts | We probably should try to move to openjpeg 2. | 08:37.08 |
| | oh, wait... we are on 2.0. How come gs has changes that we don't? | 08:39.23 |
| kens | SHelly ? | 08:40.25 |
| tor7 | paulgardiner: (for the logs) I believe you've forgotten to check in MuDialogCreator.m (there's a .h but no .m) | 08:40.41 |
| Robin_Watts | kens: right, but I thought that the standalone openjpeg module was generated from the gs one. | 08:41.17 |
| kens | has no idea | 08:41.27 |
| tor7 | paulgardiner: and I see you're comfortable with Interface Builder, all those .xib's :) | 08:41.28 |
| | Robin_Watts: the standalone openjpeg module is taken from upstream | 08:41.47 |
| Robin_Watts | tor7: Ah! | 08:41.56 |
| tor7 | it's a git-svn cron job | 08:42.26 |
| Robin_Watts | Can we arrange to have a branch in that openjpeg module that is autogenerated from the gs one ? | 08:42.28 |
| tor7 | Robin_Watts: I can look into it | 08:42.43 |
| Robin_Watts | Otherwise we cannot get the gs fixes until they work their way upstream, and that might take a while. | 08:42.57 |
| | paulgardiner: tor7 just commented on your reviews. he thinks you missed a file? | 08:54.57 |
| paulgardiner | Yeah, just checking. I think it's okay. It's a protocol so has implementations only in other classes | 08:56.01 |
| | Yeah. Checked. It's a protocol. | 08:57.12 |
| | So I guess I'm okay to push. Nothing else flagged | 08:58.14 |
| tor7 | paulgardiner: yeah, go ahead. | 09:00.12 |
| paulgardiner | Thanks tor7 | 09:00.21 |
| kens | bbiab | 09:25.32 |
| Robin_Watts | I am tempted to replace my old HP Laserjet 5L. | 09:38.15 |
| | Looking at a samsung ML 2855ND as a possibility. | 09:38.28 |
| | Has duplex, network, PS Level 3 and PCL 6. | 09:38.40 |
| sebras-work | Robin_Watts: you should ask tor7 about his printer. it's a convenient Samsung, but I don't know about the feature-set... | 09:51.14 |
| Robin_Watts | All the printers I can see are significantly larger than my 5L. | 09:51.42 |
| tor7 | Robin_Watts: sebras-work: yeah, but mine doesn't have duplex | 09:52.12 |
| | Robin_Watts: my main printer is a samsung ML-1640 | 09:53.13 |
| sebras-work | tor7: oh, you're right. | 09:53.16 |
| tor7 | which has neither duplex nor postscript | 09:53.25 |
| | but it's small and convenient | 09:53.32 |
| sebras-work | tor7: I remember using it to printout a CLA some time ago and doing the duplexing manually. :) | 09:53.39 |
| Robin_Watts | I don't care about postscript really. I do care about duplex. I swore ages ago, that I'd never buy a laser printer without duplex as doing it manually drives me nuts. | 09:54.16 |
| tor7 | Robin_Watts: I agree. manual duplex is enough to drive anyone insane. | 09:54.34 |
| sebras-work | Robin_Watts: you have to print everything twice. :) | 09:54.40 |
| tor7 | sebras-work: sometimes more, if you also forget to flip them upside down (not just printing on the same side twice) | 09:55.06 |
| | or the wrong order | 09:55.09 |
| | way too many permutations to get wrong | 09:55.14 |
| | and where do you start if you have an odd number of pages... | 09:55.33 |
| | and have to print the second batch in reverse | 09:55.38 |
| Robin_Watts | or when the printer decides to feed 2 pages part way through. | 09:55.40 |
| sebras-work | I recently discovered that my inkjet could do duplex-printing when I did a cups upgrade. apparently I have once tried duplex-printing because I was astonished when it suddently did duplex when I didn't ask for it. It just sucked the paper right back in! | 09:55.55 |
| | I'd like to have a color laserprinter with scanner, but when I bought mine 4 years ago there were no laser multi-function devices on the market. | 09:56.55 |
| Robin_Watts | I have a scanner/fax/color inkjet thing. | 09:58.13 |
| sebras-work | Robin_Watts: mm, me to, but I hate inkjet-printers with a passion. :) | 10:16.39 |
| | Robin_Watts: and I don't really need the fax-part. it seems almost as ancient to me as pagers! | 10:17.22 |
| Robin_Watts | My bank will accept faxed instructions from me for foreign currency conversions. | 10:18.09 |
| | so the alternative would be post. | 10:18.17 |
| | Then again, maybe I should forgo a laser printer and get one of these instead: http://www.kickstarter.com/projects/117421627/the-peachy-printer-the-first-100-3d-printer-and-sc | 10:22.26 |
| tor7 | Robin_Watts: the small printrbot looks more useful, and a fun weekend project to assemble | 11:36.40 |
| Robin_Watts | Well, that has a smaller maximum build size, costs a lot more, has way more to go wrong with it, and is just 'less clever'. | 11:38.20 |
| | extrusion based things have all sorts of problems with the pressure of the extrusion. Photolithography seems much smarter, and the idea of floating the resin on salt water to get the 'Z' axis control is genius. | 11:39.55 |
| | Controlling the laser from the sound card, and measuring the drip speed by the microphone is just brilliant too. | 11:40.22 |
| tor7 | Robin_Watts: yeah, the biggest issue with the peachy printer is going to be the print speed. but true, there's a lot to be said for being able to print any structures without worrying about it collapsing while printing | 11:59.34 |
| Robin_Watts | tor7: AIUI the issue of support is the one that causes most failed prints, and this project solves that. | 12:00.15 |
| | Also, castAR looks really interesting. | 12:00.30 |
| tor7 | Robin_Watts: yeah. it's a do-it-yourself version of what shapeways is doing with their prints | 12:00.52 |
| | re castOR, it's kind of expensive, and how is the software going to customisable (to support your newest board game)? | 12:01.27 |
| | Robin_Watts: did I mention how much I like my new toy? | 12:02.01 |
| Micha` | Any reason why pdf_drop_obj allows its argument to be nil but not pdf_drop_xobject? | 12:03.04 |
| Robin_Watts | Micha`: pdf_drop_xobject should cope with it being NULL. if it doesn't, it 's a bug. | 12:03.39 |
| Micha` | Ah, well, there you go then :-) It refers to xobj->storable without checking if xobj is non-NULL. | 12:04.22 |
| | --- I see that pdf_keep_obj also allows for NULL object pointers, but not pdf_keep_xobject, but this seems less problematic. | 12:06.01 |
| Robin_Watts | Micha`: Urm... | 12:26.36 |
| | pdf_drop_xobject calls fz_drop_storable(ctx, &xobj->storable); | 12:26.56 |
| | &xobj->storable == xobj. | 12:27.12 |
| | hence NULL is perfectly fine. | 12:27.17 |
| | fz_drop_storable checks for NULL on entry. | 12:27.37 |
| | so pdf_drop_xobject does cope with a null xobject. | 12:27.50 |
| Micha` | Is it? The dereferencing of xobj is no problem here? | 12:27.57 |
| Robin_Watts | We take the address of the storable field within the structure. | 12:28.24 |
| | And the storable field is deliberately the first thing in the structure. | 12:28.37 |
| | no deferencing is actually done. | 12:28.44 |
| | Likewise pdf_keep_xobject can accept NULLs. | 12:29.00 |
| Micha` | Right! Boy, my C-foo is getting rotten by the years. | 12:29.10 |
| Robin_Watts | foods. bbs. | 12:29.57 |
| Micha` | Robin_Watts: Man, there is such an amount of rage in SO on a question about the validity of the &(obj->field) construct when obj is NULL! | 12:43.15 |
| tor7 | Robin_Watts: so, I've extracted the openjpeg ghostpdl directory as a git subtree | 12:54.19 |
| | there are a grand total of 13 patches | 12:54.30 |
| | and running the job took a good 10-15 minutes of churning through commits on casper :( | 12:55.01 |
| Micha` | A small typo: pdf-object.c:1119, in the message, pdf_dict_getp should read pdf_dict_putp. | 12:56.30 |
| Robin_Watts | tor7: cool. Are you going to update mupdf to the new head, or should I? | 13:21.00 |
| | tor7: Have you pushed those changes into thirdparty/openjpeg.git ? I can't see them. | 13:23.49 |
| OlegS | Can one fz_context be used for loading 2 different pdf files at the same time? | 13:31.48 |
| Robin_Watts | OlegS: No. See docs/overview.txt | 13:32.32 |
| | Look in the "Multithreaded" section, and you will see there are 3 rules. | 13:32.56 |
| | You can make an fz_context, then clone it to get another. | 13:33.15 |
| | Then you can read 2 different pdf files using each of those two contexts. | 13:33.30 |
| | so they'll share the same store/font cache etc. | 13:33.45 |
| tor7 | Robin_Watts: they're in ~tor/src/openjpeg-gs at the moment, I'll add that as a remote to thirdparty/openjpeg.git | 13:34.29 |
| Robin_Watts | tor7: Ok, that explains why I couldn't see them :) | 13:34.51 |
| | The more I look at this 'post-process' thing for gs clist stuff, the more I want to do it as a new device call. | 13:35.49 |
| | I really need to discuss this with ray, I think. | 13:36.01 |
| tor7 | Robin_Watts: but be careful, since the openjpeg-gs branch is not rooted in the upstream at all | 13:36.15 |
| | so you could cherry-pick but don't ever try merging or rebasing | 13:36.32 |
| Robin_Watts | tor7: oh, yeah, ick. | 13:36.44 |
| sebras-hotel | is intrigued to look at the irclogs because of tor7s comments about rebasing... | 13:36.59 |
| tor7 | Robin_Watts: oh, hm, actually, it might have found the root! | 13:37.03 |
| | or I may have messed up | 13:37.11 |
| | sebras-hotel: nothing interesting to see. move along! | 13:37.23 |
| | sebras-hotel: using git-subtree to extract the ghostpdl.git openjpeg changes | 13:37.38 |
| sebras-hotel | tor7: these are not the patches I'm interested in... | 13:37.45 |
| OlegS | Robin_Watts: I tried to clone the context but I discovered a conflict between objects of different documents in the store | 13:42.15 |
| Robin_Watts | OlegS: Can you give me an example, please ? | 13:42.34 |
| | actually, I think I can see why. | 13:45.17 |
| OlegS | Sorry but I cannot give you example of pdf documents because it contains some private data | 13:46.46 |
| Robin_Watts | OlegS: I meant, an example of an object that was being confused. | 13:47.21 |
| | but I think I can see why. | 13:47.25 |
| OlegS | It's a pdf_obj object of PDF_INDIRECT kind | 13:48.25 |
| Robin_Watts | I think it's a fairly simple fix. | 13:48.34 |
| | ok, yes, that's what I was thinking would be the problem. | 13:48.46 |
| tor7 | Robin_Watts: okay, I've set up a script and remotes to pull the ghostpdl/openjpeg subtree into /home/git/thirdparty/openjpeg.git | 13:49.23 |
| | Robin_Watts: you can see what's there now | 13:49.29 |
| | and I have no idea how it managed to hook it up to the right spot in the history... | 13:49.47 |
| Robin_Watts | OlegS: Can you try this fix out please? http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=70ad82df409db007ec08e66c3cb631f7e20595c6 | 13:53.06 |
| | tor7: looking now. | 13:53.11 |
| OlegS | Robin_Watts: Issuing the compile error in line 'hash->u.i.ptr = key->doc': error C2037: left of 'doc' specifies undefined struct/union 'pdf_obj_s' | 13:59.26 |
| Robin_Watts | OlegS: Damn, sorry. Will try for a new version. | 13:59.51 |
| | OlegS: Try this: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=366bb0e508d25d61ac7376ce0ea56c109456ddb5 | 14:06.51 |
| mvrhel_laptop | kens: gs_colorspace_set_icc_equivalent | 14:09.21 |
| kens | mvrhel_laptop : thanks, I'll get right on it | 14:09.33 |
| mvrhel_laptop | should do the job. and should work for your other case too | 14:09.34 |
| | I should have known that to begin with... | 14:09.45 |
| kens | Not to worry, I thought it was going to be an easy change until I tripped over the shfill | 14:10.06 |
| OlegS | Robin_Watts: It seems ok now | 14:14.39 |
| Robin_Watts | Does that solve the problem? | 14:14.59 |
| OlegS | Robin_Watts: I think so | 14:16.15 |
| Robin_Watts | paulgardiner_: Have a good holiday! | 14:18.01 |
| paulgardiner | Robin_Watts: thanks. Just trying to work out what I've forgotten to pack. | 14:19.09 |
| OlegS | Robin_Watts: Thanks | 14:19.41 |
| Robin_Watts | OlegS: Thanks for finding that problem. | 14:20.11 |
| Gigs- | xcfxmyk no longer exists? It's mentioned in the current docs | 14:25.59 |
| chrisl | Gigs-: I assume there's a typo in there somewhere | 14:29.13 |
| | Gigs-: I mean, in your question.... | 14:29.52 |
| Gigs- | cmyk yes | 14:30.15 |
| chrisl | In my current debug build there are x11cmyk, x11cmyk2, x11cmyk4 and x11cmyk8 | 14:31.18 |
| Gigs- | it's described as an xcf that puts the separations in as alpha channels, I'm not sure it's useful to me at all, just wondering what happened to it | 14:32.02 |
| | you are missing some other cmyks btw, you should have psdcmyk and pcxcmyk at least | 14:32.57 |
| chrisl | We do have psdcmyk, and almost no one cares about pcx now | 14:33.54 |
| Gigs- | no one cared about pcx when that device was made either :) | 14:34.07 |
| | pcxcmyk was a step in the development of tiffsep basically to debug | 14:34.21 |
| | still a useful device for dumping raw sep binary data | 14:34.36 |
| chrisl | It's possible that they are not considered "production quality" so don't get included in the default build | 14:35.41 |
| Gigs- | ok, np I was just wondering about that xcfcmyk, no pressing need for it | 14:36.25 |
| | chrisl do you know how to read functiontype 0 streams? | 14:36.46 |
| chrisl | Gigs-: not off the top of my head, I'd have to read up in the PLRM | 14:37.12 |
| Gigs- | The question was: FunctionType 0 /Size [ 2 ] /Range [ 0 1 0 1 0 1 0 1 ] /Domain [ 0 1 ] (stream) 00 00 00 00 00 80 FF 00> .. in my tint transform stream, how is it ordered, like C C M M Y Y K K? If that's the case, why is K inverted? | 14:37.21 |
| | it's just a basic mapping function, Domain is input 0 to 1, Range is output CMYK | 14:38.15 |
| | it's not entirely clear from the PDF spec how the stream itself is ordered though | 14:38.42 |
| Robin_Watts | hey ray_laptop | 14:48.20 |
| | The more I get into this, the more I think it would be neater to do this by adding a new device function. | 14:48.57 |
| | Do you have time to discuss it at some point ? | 14:49.11 |
| Gigs- | I just found a thread from 2002 with a comment from Peter Deutsch and someone with an erols email, blast from the past | 14:50.20 |
| chrisl | Gigs-: I assume that's not the entire dictionary you pasted above? | 14:51.48 |
| Gigs- | it is | 14:51.54 |
| chrisl | So, it's missing entries | 14:52.07 |
| Gigs- | it's a tint transform for a single separation to CMYK | 14:52.11 |
| | I can paste the original code in its entirety on a pastebin, one second | 14:52.37 |
| chrisl | Or, it's missing an entry | 14:52.40 |
| Gigs- | http://paste.ubuntu.com/6224223/ | 14:52.52 |
| | Yeah I did leave out a few things sorry | 14:53.29 |
| | tried to trim it down to just the relevant bits | 14:53.41 |
| chrisl | BitsPerSample was the one that worried me | 14:54.02 |
| Gigs- | yeah I don't know why length is done by reference there, but it seems correct | 14:54.44 |
| | the length object just contains an integer | 14:55.03 |
| chrisl | Because PDF creators are lazy, and like to slow things down for no apparent reason..... | 14:55.17 |
| Gigs- | heh yeah that's the truth | 14:55.23 |
| kens | Functions don't care what the ordering is. You have a 1->4 function there, so it takes 1 arguement and returns 4 results. Its up to you to get the order corfrect. However, the stream data i your case ia sample 1, result 1, sample 1, result 2, saample 1, result 3, sample 1, result 4, sample 2, result 1 etc | 14:55.38 |
| Gigs- | that's what I thought kens, so it's effectively inverting the K | 14:56.17 |
| kens | So if that's sep to CMYK then your two end points are C=M=Y=K=0 and C=0, M=128, y=255, k=0 | 14:56.33 |
| | Not so much invertingk as K plays no part,m its always 0 | 14:56.49 |
| | Looks like a hacky RGB type conversion | 14:57.08 |
| Gigs- | let me digest what you said a second | 14:57.23 |
| kens | resorts to gthe PDFRM | 14:57.50 |
| Gigs- | how is M=128 when it's 00 00 00 00 | 14:57.51 |
| kens | You r data is 00,00,00,00 then 00,80,FF,00 unless I miosread it | 14:58.26 |
| Gigs- | stared at the PDFRM but failed his pdf-fu saving throw | 14:58.38 |
| Micha` | Robin_Watts: When we made the change to set force a non NULL page->contents on pdf_page_write, we copied the code from pdf_create_page which defines the contents as a new dictionary. This may be why it triggers a warning (and an error in evince) on reading: a Contents should be either a stream or an array of streams, not a dict. Is it? | 14:59.49 |
| Gigs- | so the lookup stream is out1-low out2-low out3-low out4-low out1-high out2-high ... etc? | 14:59.53 |
| kens | I've been creating PDF functions to do linear interpolation of endpoints when I have to colour convert the tint transform of DeviceN and Separation values, so I ought to be up to spee don this | 15:00.01 |
| Micha` | s/set force/force/ | 15:00.02 |
| kens | Gigs- : No, outlow 1, outlow 2, outlow 3, outlow 4, outhigh1, outhigh 2, outhigh 3, outhigh 4 | 15:00.36 |
| | But let me find the relevant doc | 15:00.49 |
| Gigs- | yeah that's what I meant | 15:00.54 |
| | your help is much appreciated, it's a little hard to find where the details of all this are documented | 15:01.20 |
| Robin_Watts | Micha: It's entirely possible I screwed up. it serves me right for trying to drop what I'm doing and do quick fixes for people. | 15:01.34 |
| kens | Gigs I think this is it: | 15:02.23 |
| | "Sample data is represented as a stream of unsigned 8-bit bytes (integers in the range 0 to 255). The bytes constitute a continuous bit stream, with the high-order bit of each byte first. Each sample value is represented as a sequence of BitsPerSample bits. Successive values are adjacent in the bit stream; there is no padding at byte boundaries." | 15:02.23 |
| | Because you only have one input you don't need to worry about the multi-dimensional stuff | 15:03.07 |
| | "For a function with multidimensional output (more than one output value), the values are stored in the same order as Range." | 15:03.20 |
| Gigs- | yeah but that doesn't tell you what you just told me, that the ordering is all the low limits first and then the high limits, for some reason I kept trying to parse it in my head as Clow Chigh Mlow...e tc | 15:03.23 |
| kens | Is hte key point | 15:03.28 |
| Gigs- | because range is 01 01 01 01 and not 0 0 0 0 1 1 1 1 the way I'd expect from that line in the documentation | 15:03.52 |
| Micha` | Robin_Watts: Well, you went the safe way by copying existing code, though. But no stress on fixing this; I can make local changes. I guess it'd be better if I opened bug reports rather than randomly reporting them here. | 15:03.52 |
| kens | Right 0 1 is the range of the first sample, then 0 1 again for the 2nd and so on | 15:04.16 |
| Robin_Watts | Micha: Yeah, most of the time I can't test these quick fixes instantly. | 15:04.17 |
| | Hence if I make changes like this, it would be good if you could test them and let me know, that way I can avoid committing broken stuff to the golden repo. | 15:04.44 |
| Gigs- | kens: one more question, a little higher level, this file I have defines this tint transform twice for the same separation name | 15:04.53 |
| Micha` | Well it DID prevent segvs :-) | 15:05.05 |
| kens | Really ? that's odd, how does it do that ? | 15:05.10 |
| Gigs- | kens: single page file, etc. GS seems to ignore the first definition and use the second. | 15:05.14 |
| kens | Gigs- : can I look at the file ? | 15:05.26 |
| Gigs- | kens sure | 15:05.29 |
| Robin_Watts | Opening bugs is good. You can put suggested fixes on the bugs too if you have them. | 15:05.29 |
| Gigs- | one sec | 15:05.32 |
| Micha` | Ok, will do. | 15:05.45 |
| Gigs- | kens: http://www.gigstaggart.com/pics/13100241401.pdf | 15:06.46 |
| kens | one moment | 15:07.02 |
| Gigs- | object 6 and 56 for Dieltblue, renders as Cyan | 15:07.22 |
| | obj 9 and 71 for Varnish | 15:07.37 |
| kens | OK so where's the duplicate ? | 15:08.15 |
| | Oh 6 & 56 | 15:08.31 |
| Gigs- | referring objects are 7 and 57 | 15:08.59 |
| kens | Right so you have two colorspaces referencing the 2 functions | 15:09.15 |
| | Not too surprising | 15:09.21 |
| Gigs- | deviceN spaces? | 15:09.28 |
| kens | Separation spaces | 15:09.35 |
| | THey have the same name | 15:09.52 |
| Gigs- | Is it valid to have two separation color spaces with the same name? | 15:09.56 |
| kens | and teh same tint transform | 15:10.00 |
| | PDF defines objects by their object number, so you cna have as many definitions of a colour as you like | 15:10.24 |
| | You can in PostScript too, each new one overrides the previous | 15:10.37 |
| Gigs- | when it encounters data in that color space how does it know? | 15:10.39 |
| | oh so just the last one encountered then | 15:10.46 |
| kens | The colour will be set in the contents stream | 15:10.51 |
| Gigs- | When Varnish for example is defined as an element in a deviceN colorspace, the Separation tint transform is not used right? | 15:11.47 |
| kens | object 4 defiens page resoruces, and it hsa a ColroSpace dictionary which references object 7 as /Ap_sep_Dieltblue | 15:11.49 |
| Gigs- | in that case it would go through the deviceN's transform instead? | 15:12.33 |
| kens | Object 57 is used in the definition of the Colorspace named /DN_4 | 15:12.54 |
| | Gigs- : there are no DeviceN here, these are both separation | 15:13.06 |
| | object 16 is DeviceN | 15:13.19 |
| Gigs- | yeah but Varnish is also an element in several DN colorspaces | 15:13.23 |
| kens | Yes | 15:13.30 |
| Gigs- | this all seems so inefficient heh | 15:13.42 |
| kens | Like I said, you can have as many named color spaces as you like | 15:13.45 |
| | Inefficient is one word, certainly :-) | 15:13.54 |
| | Possibly its a collection of EPS files so there are multiple ink definitions | 15:14.31 |
| Gigs- | so if I wanted to alter every occurance of "Varnish" on this page, I need to go through all the separation color space definitions, and also change it in every device N colorspace it occurs in? | 15:14.37 |
| kens | I should say *was* EPS files | 15:14.38 |
| Gigs- | I should hope they are not internally still using EPS, but you never know. It's an artpro file originally | 15:15.07 |
| kens | I'm not sure what you are asking about the Varnish | 15:15.24 |
| | THe Varnish ink (separatin or DeviceN) might be used by any number of colour spaces | 15:15.42 |
| Gigs- | if I want to alter the tint transform for Varnish globally | 15:15.56 |
| kens | If you want to alter the use of Varnish, then you need to alter every colour space which uses that named ink | 15:15.59 |
| Gigs- | thanks that confirms what I thought | 15:16.12 |
| kens | Gigs its possible that each colour space using Varnish has a different tint transform :-) | 15:16.21 |
| Gigs- | possible technically, but would make no sense from a print standpoint | 15:16.50 |
| kens | The multipl eink definitions might also reflect some kind of internal layout choice of the app, like layers | 15:16.54 |
| Robin_Watts | tor7: OK, moving to openjpeg 2 produces 308 diffs. I've just checked all the bmpcmps, and they are all progressions or neutral. | 15:16.56 |
| Gigs- | not in separated litho world | 15:16.57 |
| Robin_Watts | some of them are really noticable improvements. | 15:17.03 |
| | so all the stuff on robin/master (except for the last 2) are ready to go. | 15:17.18 |
| kens | Gigs in separations, its moot, because of course the tint transfrom won't be used | 15:17.23 |
| tor7 | so which version were we using? | 15:17.24 |
| Robin_Watts | We were still on 1.5.0+patches I think. | 15:17.38 |
| kens | heads back to the colour salt mine | 15:17.40 |
| Gigs- | kens: yeah moot except for when I need a CMYK or RGB version and some artist put a 30% orange tint on the varnish so they could see it | 15:17.54 |
| | kens: hehe | 15:17.57 |
| Robin_Watts | or at least, we certainly didn't have all shellys fixes. | 15:18.00 |
| | regardless, this is a step forwards. | 15:18.08 |
| Gigs- | kens: so I'm looking at either using mupdf or a custom thing to alter all the tint transforms in a file in a minimally invasive way | 15:18.44 |
| kens | OK | 15:18.51 |
| tor7 | Robin_Watts: alright. I'm a bit worried about the state of our openjpeg thirdparty git though, which branches come from where etc | 15:19.21 |
| Gigs- | I'm going to hopefully not encounter creative colorspace definitions that include stuff like PS code | 15:19.45 |
| | prepress programs almost always use functiontype0 it seems at least | 15:19.57 |
| kens | Gigs PS code you shouldn't see | 15:20.00 |
| chrisl | Gigs-: Eek! Send it back to the "artist" and tell them to make their PDFs better....... | 15:20.04 |
| kens | Other function types are hard to sue | 15:20.10 |
| | use* | 15:20.20 |
| Gigs- | I know chrisl... it's hard, some of our files are sent in and the customer always says "well your competitor doesn't have a problem with our perfect files" | 15:20.41 |
| kens | and sice the tint transform is 'wrong' anyway, it doesn't matter if it doesn't look very good | 15:20.42 |
| Gigs- | so that's what we call "blind exchange" :) | 15:21.10 |
| Robin_Watts | tor7: I think following the gs one is a reasonable model. | 15:21.23 |
| tor7 | Robin_Watts: if I read the git tree correctly, we've been using 2.0+patches for quite some time | 15:21.34 |
| Robin_Watts | And we can't delete the stuff that's in there already without breaking history. | 15:21.52 |
| | tor7: Yeah, maybe it's just shellys fixes that we've pulled in. | 15:22.11 |
| | Let me update the commit message. | 15:22.17 |
| chrisl | Gigs-: my worry would be "fixing" the "wrongly" and getting something not intended by the user | 15:22.26 |
| Gigs- | chrisl: not much worry, since like kens said, separation color spaces on a separated device like a plate maker ignore all the tint anyway | 15:23.00 |
| | so worse case scenario, the preview is a little weird. But even then, I'm mostly just going to be doing Varnish->0000 | 15:23.32 |
| | it'll be rare I actually adjust a tint | 15:23.45 |
| tor7 | Robin_Watts: gitk thirdparty/openjpeg shows a commit "take on zenikos OpenJPEG2 fixes", with a submodule commit at the origin/zeniko_fixes branch in thirdparty/openjpeg.git | 15:24.05 |
| Gigs- | I believe the high end proofers ignore the tint transforms in the PDF too | 15:24.17 |
| tor7 | which sits quite far down the line from "Import openjpeg-2.0.0.tar.gz" | 15:24.22 |
| Gigs- | high end proofer pretends to support separated color space and then performs its own transforms to 8 or 9 primary color space that it supports | 15:24.47 |
| chrisl | Gigs-: I'm a believer in giving the user what they ask for, and not guess what they really wanted. | 15:25.06 |
| Micha` | Talking about pdf_page_write (pdf-device.c:1334)... It creates a new fz_device for a page using pdf_new_pdf_device, based on whatever Contents is in the page. But it seems that pdf_new_pdf_device expects this content to be a stream. It can however be an array (this is well treated in pdf-stream.c:pdf_open_contents_stream). Is the proper fix to always create a new stream if Contents is an array? Or is it better | 15:25.40 |
| | to use the first stream in the array, if one exists? | 15:25.41 |
| Robin_Watts | tor7: Oh, rats. I'll need to fix the android build too. | 15:25.42 |
| henrys | huh emacs gud now has mouse over variable to see values gud-tooltip-mode | 15:25.46 |
| Gigs- | chrisl: their warehouse manager calls you are complains that the preview on the carton label is unreadable then :) | 15:25.48 |
| tor7 | and then your commit use latest openjpeg 2.0 from ghostpdl rewinds a hundred commits (reverting down past openjpeg-2.0.0.tar.gz) | 15:25.55 |
| Gigs- | chrisl: you know how it is I'm sure | 15:26.03 |
| tor7 | and then pulls in a *separate* GS openjpeg2 integration | 15:26.20 |
| Robin_Watts | tor7: yeah. I think the gs stuff has a different directory structure. | 15:26.37 |
| tor7 | Robin_Watts: which is why I suggested you do cherry-pick instead, so we can keep working off of upstream | 15:27.09 |
| Robin_Watts | tor7: oh, no, I think that's a bad idea. | 15:27.23 |
| tor7 | Robin_Watts: so, we want to manually merge with upstream? | 15:27.33 |
| | or fork openjpeg based on the ghostpdl? | 15:27.39 |
| Robin_Watts | I think we REALLY want to be following the same version as ghostpdl. | 15:27.44 |
| tor7 | because the latter is what you're proposing | 15:27.50 |
| Robin_Watts | If ghostpdl moves to tracking the upstream, then we will too. | 15:28.03 |
| | but having 2 different versions of a decoder lib in the same company with all the possibilities for getting fixes out of sync is just madness, IMHO. | 15:28.29 |
| tor7 | then "Update mupdf to use openjpeg 2.0 from the fork maintained in GhostPDL." | 15:28.48 |
| Gigs- | you guys know openjpeg 1 is really slow right. When Second Life went open source we put in a bunch of speed improvements but I think most of that wound up in 2 | 15:28.56 |
| Robin_Watts | see my revised commit message now. | 15:29.01 |
| chrisl | Gigs-: not as slow as Jasper | 15:29.22 |
| kens | Gigs- : its still better than JasPer | 15:29.26 |
| Robin_Watts | Gigs-: We have been using v2 for a while. | 15:29.28 |
| Gigs- | jasper is a reference implementation hacked together just so they could put something in the standard before it was ratified | 15:29.48 |
| tor7 | Robin_Watts: okay. so with this I'm basically going to shut down pulling openjpeg upstream commits from git-svn. | 15:30.03 |
| Robin_Watts | tor7: ok. | 15:30.11 |
| Gigs- | but kakadu is like 50 times faster than openjpeg 1 | 15:30.12 |
| tor7 | and let chrisl handle maintaining the gs openjpeg directory, and pull that out the same as we do for jbig2dec | 15:30.22 |
| Gigs- | openjpeg 2 got a little closer to kakadu performance but still pretty far off | 15:30.31 |
| kens | IIRC kakadu is commercial and C++ | 15:30.32 |
| Gigs- | yeah kakadu is not an option, it's just the gold standard for speed is all | 15:30.44 |
| chrisl | Robin_Watts, tor7: all Shelly's fixes have been passed upstream, so if we get the memory stuff sorted out, we'll be able to track upstream easily | 15:31.07 |
| tor7 | Robin_Watts: right. then I'll turn off that faucet, set a final tag on the commits we've used before so they don't disappear, and move master over to what we have from git-subtree of the ghostpdl. | 15:31.16 |
| Robin_Watts | tor7: Moving master over is what my commit does. | 15:31.37 |
| tor7 | I mean the master in /home/git/thirdparty/openjpeg.git | 15:31.50 |
| Gigs- | from what I've heard kakadu has some highly optimized MMX code to keep it all on the chip and not blow the CPUs caches | 15:31.51 |
| Robin_Watts | tor7: oh, sorry. | 15:32.04 |
| | Gigs-: Awesomely cross platform then :) | 15:32.16 |
| kens | Robin_Watts: beat me to it | 15:32.27 |
| Gigs- | yeah I know | 15:32.31 |
| Robin_Watts | Gigs-: We have a commercial solution using Luratech. | 15:32.38 |
| Gigs- | never heard of them, are they pretty fast? | 15:32.51 |
| chrisl | Gigs-: the inability to have a free encoder really limits interest in JPX | 15:32.52 |
| Robin_Watts | At this point, I don't think anyone sane actually uses JPX, so it's mostly a tickbox item. | 15:33.02 |
| kens | When we needed a JPX decoder for Jaws I wrote one | 15:33.03 |
| Gigs- | chrisl: there's a patent there? | 15:33.04 |
| sebras-hotel | Robin_Watts: how does Luratech compare to openjpeg2? significantly fast? | 15:33.09 |
| kens | Gigs, lots of them | 15:33.11 |
| Gigs- | oh well, at least patents are a temporary problem | 15:33.44 |
| chrisl | Gigs-: for decoding the patents are "waived", but not for encoding | 15:33.52 |
| Robin_Watts | sebras-hotel: I believe Luratech is MUCH better than jasper/openjpeg v1 etc. | 15:33.54 |
| kens | Technically if you write a decoder you are supposed to seek a royalty-free licence from each patent holder, IIRC there are about 20 | 15:33.54 |
| Gigs- | heh well at least standards groups are mostly learning their lesson about allowing RAND terms | 15:34.41 |
| chrisl | kens: I thought you could go through ISO, now, rather than approach each holder individually - maybe I got that wrong | 15:35.16 |
| kens | chrisl that may be true, I'm going back quite a bit there | 15:35.29 |
| | I had to work with teh people in the Hall to get it to happen | 15:35.39 |
| henrys | chrisl: that patch may be wrong for the 32 bit case I don't see how it would use unsigned long if USE_LARGE_COLOR_INDEX == 0. we need an "else" in msvclib.mak. | 15:36.13 |
| chrisl | Gigs-: the patents may be a temporary problem, but by the time they expire, the format will probably not be relevant | 15:36.56 |
| | henrys: It might handled in genarch | 15:37.19 |
| henrys | chrisl: maybe I'll check it sometime today. | 15:37.50 |
| Robin_Watts | Global warming/overpopulation/energy shortages are similarly temporary problems. | 15:38.00 |
| Gigs- | chrisl: Maybe that particular one, but progressive decoding will probably still be relevant. Especially for GIS type data where you want to have a massive massive image and be able to smoothly navigate and zoom | 15:39.07 |
| | or even just render a low res version quickly | 15:39.21 |
| chrisl | henrys: genarch.c line 36-38 | 15:39.24 |
| Robin_Watts | tor7: OK, new version of the commit up there that solves android builds too. | 15:39.44 |
| henrys | and you want me to read a line in ghostscript code and assume it's going to happen without testing -- Hump day humor? | 15:40.07 |
| Gigs- | chrisl: I mean like my prepress preview caching system, I use GS to render at 300 DPI and then I have to use traditional scaling to produce smaller versions for different uses, that's a prime application for something that has the capabilities JPEG 2000 has | 15:40.20 |
| chrisl | henrys: this isn't really ghostscript, it's just genarch | 15:40.55 |
| | Gigs-: the problem is, jpeg2000 is too big, too complicated, and badly patent encumbered - that *really* limits uptake on something like that | 15:41.39 |
| Gigs- | yeah it's sad because there's a lot of "killer apps" that are being held back | 15:41.57 |
| | google maps could be a lot smoother for example | 15:42.08 |
| | instead of the stupid tile system they use | 15:42.32 |
| chrisl | It's always a problem when too many vested interests get involved in a spec like that | 15:43.00 |
| Gigs- | at least companies like Google have the weight to leverage a standard into being free these days | 15:43.53 |
| | I have a feeling Google leaned on Apple regarding HTMl5 canvas for example | 15:44.36 |
| | when apple started disclosing patent claims | 15:44.49 |
| Robin_Watts | google holds no sway with apple. | 15:45.22 |
| | Look at VP8/Theora/WebM. | 15:45.33 |
| | The whole iOS vs Android wars etc. | 15:45.44 |
| Gigs- | it depends on how bad each side wants it I guess | 15:45.56 |
| chrisl | Gigs-: from a PDF point of view, a lot of the nice features in JPG2000 are of limited relevance. | 15:46.20 |
| Gigs- | html5 canvas was critical for google, and Apple wants to kill Flash anyway, so they were probably a little more willing | 15:46.33 |
| | chrisl: yeah, I was just telling Robin yesterday when I was having openjpeg lib problems compiling mupdf, I wouldn't mind not linking it, it's just not that useful these days | 15:47.50 |
| | but eventually something like it will probably be a Big Deal(tm) | 15:48.41 |
| chrisl | Gigs-: but 'cause it's in the spec, we have to handle it, which is a pain. I'm not convinced it will be a big deal. PDF mainly benefits from the better compression, but with disks being huge and cheap, and ubiquitous broadband, that's of lessening importance. | 15:50.06 |
| Robin_Watts | Increases in compression will always be useful as resolutions rise. | 15:51.01 |
| | If H264 wasn't better at compressing than MPEG 2, HD video would be at a big disadvantage. | 15:51.28 |
| Gigs- | yeah and like I said, there's applications out there that may not at first be obvious | 15:52.12 |
| Robin_Watts | If you want to watch HD sport over broadband, you need a 15 Meg connection. | 15:52.23 |
| | And 4K TVs have 5 times the number of pixels. | 15:52.38 |
| chrisl | Robin_Watts: yeh, but there's a huge difference between single images, and motion pictures | 15:52.50 |
| Robin_Watts | chrisl: Indeed. | 15:52.57 |
| | The problem is that each generation of codec (be it video or still image) throws away the last standard and starts again. | 15:53.33 |
| Gigs- | well not entirely, the multi-res and region of interest features would open up new doors in the video world too | 15:53.41 |
| Robin_Watts | So patents being 'temporary' means that by the time the patent runs out, the format is obselete. | 15:53.54 |
| chrisl | Gigs-: none of which is relevant to PDF..... | 15:54.03 |
| Gigs- | think, CSI style zoom-and-enhance that actually looks like it does on the movies :P | 15:54.09 |
| | yeah not directly | 15:54.29 |
| chrisl | I think Adobe rushed into including JPX (and JBIG2) in PDF | 15:55.07 |
| sebras-hotel | chrisl: wouldn't it be possible to use jpx's multiple resolutions when rendered images in documents based on zoom-level in a viewer? | 15:56.00 |
| | chrisl: or something like that. | 15:56.10 |
| Robin_Watts | Adobe did it, I suspect, because they thought they could a) drive adoption, and b) tout how well they compressed stuff. | 15:56.19 |
| | ray_laptop: Hi. | 15:56.21 |
| ray_laptop | Robin_Watts: here now. | 15:56.22 |
| | Robin_Watts: Hi. Got your SMS | 15:56.33 |
| chrisl | And frankly, when a reference implementation is as big a mess, incomplete and buggy as Jasper, that should be a hint that there's a problem with the spec. | 15:56.39 |
| Robin_Watts | So, I have the plumbing in place to do post processing in the clist cases (both with and without threads). | 15:56.57 |
| ray_laptop | Robin_Watts: OK. | 15:57.07 |
| Robin_Watts | There is a commit up on my repo on casper for it. | 15:57.11 |
| | BUT, various things have become clearer to me in doing this. | 15:57.29 |
| ray_laptop | I'll have a look. But what is that about needing a device function ? | 15:57.30 |
| chrisl | sebras-hotel: possibly, but it would kind of break the interpreter/device independence implicit in PDF | 15:57.36 |
| ray_laptop | vs. a printer_procs function that we discussed | 15:57.43 |
| sebras-hotel | chrisl: true. | 15:58.06 |
| Robin_Watts | right. What i have at the moment uses a printer_procs function. And I think it's a poor solution for the reasons I am about to give you. | 15:58.15 |
| | Firstly, I cannot see how to make this work for the non-clist case. | 15:58.41 |
| henrys | kens: I assigned 694704 back to marcosw assuming he'd assign the rest to you, but I haven't heard from marcosw in a bit... | 15:59.27 |
| kens | Hmm, I'm not convinced I have anythign to say on that bug | 15:59.42 |
| | Its not really a PDF/PS interpreter issue, and its not pdfwrite. More graphics library it seems to me | 16:00.15 |
| Robin_Watts | There is no single function that gets called by the non-clist case - we'd want the post processing to happen immediately after the get_bits_rectangle call, and there are just too many get_bits_rectangle implementations in there to know which one is being called at any given time. | 16:00.38 |
| ray_laptop | Robin_Watts: gdev_prn_get_bits and gdev_prn_get_lines don't suffice ? | 16:01.00 |
| henrys | well somebody needs to verify if we put a halftone in Resources it works, which I thought to be language stuff kens | 16:01.10 |
| Robin_Watts | The png devices don't call those functions, for example. | 16:01.23 |
| henrys | kens:question 3 | 16:01.36 |
| ray_laptop | Robin_Watts: OK. | 16:01.41 |
| kens | Hmm, I can certainly put a halftone in Resources, but I'm not certain that proves much | 16:01.43 |
| | Oh proprietary halftone types ? | 16:01.53 |
| Robin_Watts | The png devices (and the tiff devices, and others) all call the downscaler, which calls get_bits itself. | 16:02.08 |
| henrys | kens:yes I thought a customer could put a proprietary halftone in resources and protect it. I guess that is my question. | 16:02.53 |
| Robin_Watts | Which leads me to my next issue... if they use the downscaler, they can't make use of the post processor. | 16:02.56 |
| | unless we can find a way to push the downscaler into the post processor too. | 16:03.08 |
| henrys | kens:maybe ray knows | 16:03.13 |
| ray_laptop | Robin_Watts: actually, the downscaler _is_ a post processor | 16:03.24 |
| kens | henrys I have no idea, I don't know if we support type 9 or 100 dictioanries, and we wouldn't know what to do with them anyway | 16:03.28 |
| Robin_Watts | ray_laptop: Right. | 16:03.31 |
| henrys | kens:I've answered question 1 and 2 | 16:03.33 |
| kens | We don't have to saupport them to be compliant | 16:03.37 |
| ray_laptop | but the downscaler can't cope with running in bands (at least when doing FS). Maybe when doing BNM | 16:04.20 |
| kens | If I try to set a type 9 halftone we get a rangecheck | 16:04.47 |
| Robin_Watts | ray_laptop: BUT our current scheme of having the post process function as a printer function means the downscaler can't easily replace hook itself in. | 16:04.51 |
| kens | SO we don't support them it looks to me | 16:04.57 |
| henrys | kens:I think you have to install one first. | 16:05.01 |
| Robin_Watts | ray_laptop: So I have a plan that I like more... | 16:05.12 |
| ray_laptop | listens | 16:05.20 |
| henrys | and then I think it is no different than a regular halftone except the data can't be read . | 16:05.29 |
| Robin_Watts | I'd like to introduce a new device function: get_processed_bits. | 16:05.34 |
| kens | henrys so how ouwld this help ? | 16:06.02 |
| Robin_Watts | It's essentially get_bits_rectangle, but with an additional parameter of the post_processing details. | 16:06.15 |
| kens | Looks like investigating this will be a lot of effort | 16:06.22 |
| Robin_Watts | We can implement it as a default that calls get_bits_rectangle then does the post processing. | 16:06.49 |
| henrys | kens:I believe the customer wants to install a halftone that can't be read. | 16:06.52 |
| kens | henrys I don't think so, uinless I'm misreading this | 16:07.08 |
| ray_laptop | Robin_Watts: so get_processed_bits gets the callback function ? | 16:07.20 |
| Robin_Watts | get_processed_bits does the get_bits and then post processes it. | 16:07.40 |
| kens | The customer produces contaone and post-processes it to halftone, so they don;t need a hjalftone dictioanry at all | 16:07.45 |
| Robin_Watts | For clist, we implement get_processed_bits directly. | 16:08.03 |
| ray_laptop | Robin_Watts: OK. Fine for post processing that is single threaded | 16:08.17 |
| Robin_Watts | (it's easy - it's just the current code with an extra param pushed through everywhere) | 16:08.42 |
| | For everything else, we just do a fallback that calls 'get_bits' and then calls the post processor. | 16:09.01 |
| | If anyone calls clist_get_bits_rectangle, we can just implement that as a call to clist_get_processed_bits with the new param blank. | 16:09.41 |
| ray_laptop | Robin_Watts: so how does this get us post processing in the rendering threads | 16:10.01 |
| Robin_Watts | That way the multi-threaded version does the work on the threads in the clist case. | 16:10.08 |
| | because the rendering threads have the parameter passed into them. | 16:10.23 |
| ray_laptop | Robin_Watts: OK. So how does the downscaler hook in ? | 16:10.29 |
| Robin_Watts | Just a mo. | 16:10.54 |
| | So this scheme should nicely unify the clist-single threaded/clist-multithreaded/non-clist cases. | 16:11.19 |
| | and it's backwardly compatible etc. | 16:11.32 |
| ray_laptop | Robin_Watts: because some post processors will be thread safe, and some not (the current FS downscaler is the latter) | 16:11.37 |
| Robin_Watts | OK, so the downscaler. | 16:11.50 |
| | currently the way the downscaler works is that the devices call a 'downscaler_get_bits' function. | 16:12.09 |
| | which does get_bits and then downscales. | 16:12.31 |
| | We'd offer a new downscaler_get_processed_bits call. | 16:12.53 |
| ray_laptop | Robin_Watts: right. So that doesn't really change. Since it needs the bits in order anyway | 16:12.55 |
| Robin_Watts | ray_laptop: Right. Ignore the error diffusion case for now, as that's a blocker however we slice it. | 16:13.30 |
| ray_laptop | downscaler_get_bits *are* processed, aren't they ? | 16:13.37 |
| henrys | kens:trust me, he doesn't want anybody to see the halftone⦠but it's fairly clear from PLRM what 9 and 100 are. | 16:13.54 |
| kens | henrys I can define a type 9 halfvtone as a resuorce, but as soon as I try ot use it I get an 'undefined' error | 16:14.06 |
| Robin_Watts | downscaler_get_bits does a get_bits and then downscales them. | 16:14.16 |
| henrys | kens:and it seems like we should support it. | 16:14.18 |
| Robin_Watts | downscaler_get_processed_bits would be a request to get_bits, downscale, then post process. | 16:14.35 |
| ray_laptop | so what is different about downscaler_get_processed_bits ? | 16:14.41 |
| Robin_Watts | so, say we were doing a PNG output device where we wanted to use the post process stage to do the compression. | 16:15.18 |
| kens | henrys I don't understnad the requirement, since the halftoning is post-rendering, it doesn't matter a jot what the PostScript says the halftone is | 16:15.29 |
| ray_laptop | kens: halftoning is not post rendering | 16:15.50 |
| kens | And why should we support type 9 halftones ? What do we expect the to do ? | 16:15.51 |
| ray_laptop | halftone is part of the rendering | 16:15.59 |
| kens | ray_laptop : I thought this customer case was | 16:16.01 |
| | "(Note that we have our own proprietary halftoning engine so we use our contone device instead which outputs an excellent RLE-compressed proprietary display list for further processing.) " | 16:16.17 |
| henrys | kens:a postscript program can print out the values in your halftone which some folks would like to keep private for reasons legitimate and otherwise. | 16:16.23 |
| ray_laptop | kens: I was talking PS spec | 16:16.24 |
| kens | ray_laptop : and I'm talking customer-specific bug report | 16:16.37 |
| ray_laptop | kens: sorry. | 16:16.45 |
| kens | henrys why does it matter what's in the PS halftone ? If they aren't using it anyway | 16:16.58 |
| henrys | kens:I was assuming he would associate type 3 with his halftone and do something else if requested. | 16:17.51 |
| Robin_Watts | ray_laptop: So in order for us to usefully do downscaler_get_processed_bits, we want to push both the downscale and the user requested post process back onto the rendering threads. | 16:17.54 |
| henrys | kens:type 9 | 16:18.04 |
| Robin_Watts | ray_laptop: Are you with me? | 16:18.14 |
| ray_laptop | Robin_Watts: but we can't do downscale in threads, can we ? | 16:18.29 |
| kens | OK so since he isn't using the halftone, let him set it up as something else, and it does not matter if someone reads it, its not relevant to what they do | 16:18.33 |
| | My feeling was they wanted to set type 9 because they hoped that GS would 'do nothing' then and the crash would go away | 16:18.52 |
| Robin_Watts | ray_laptop: Currently the code doesn't do that. But there is no reason why we can't (in the non-error diffused cases anyway). | 16:19.07 |
| ray_laptop | Robin_Watts: we _could_ do idempotent downscale in threads IFF the band contains the correct multiple of the lines, and there is no halftoning or if there is, it is BNM or something | 16:19.57 |
| Robin_Watts | the user would call downscaler_get_processed_bits and would pass in it's post process function A. | 16:20.05 |
| henrys | kens:I read it that he would like to have a type 9 dictionary like there is on most modern printers that is default and proprietary, that will represent his halftone, then the customer may request something else. | 16:20.06 |
| kens | Well, we differ in opinion, maybe someone should ask | 16:20.38 |
| ray_laptop | Robin_Watts: OK. So I we are talking about MT and an idempotent downscale case | 16:20.44 |
| henrys | kens:that is the way my color and mono printer work. | 16:20.47 |
| kens | All that type 9 means on modern prtiners is that its a halftoning technique that 'not PostScript' | 16:20.55 |
| ray_laptop | (if idempotent is the right word) | 16:21.06 |
| Robin_Watts | the downscaler would then make a function B that "did the downscale and then called A", and would pass that into get_processed_bits. | 16:21.10 |
| ray_laptop | Robin_Watts: so the post processing gets 'chained' | 16:21.35 |
| kens | henrys : it doesn't mean anything at all, and the inability to read it just means its 'not PostScript' so it doesn't make sense | 16:21.35 |
| Robin_Watts | For the downscaler to be post processable, we'd need the bandheight to be a multiple of the required downscale size. | 16:21.54 |
| | ray_laptop: Right. | 16:21.59 |
| kens | Naturally all our halftone code is written in PostScript :-( | 16:22.02 |
| henrys | kens:I'm reading 7.4.7 in PLRM is that what you are reading? | 16:22.19 |
| Robin_Watts | Now, such chaining, to me, really says we shouldn't be doing it with a printer proc entry. | 16:22.20 |
| | (not to mention the nasty hernias that produces in casting from clist_device to prn_device). | 16:22.49 |
| ray_laptop | Robin_Watts: so how does it get determined if the post processing can be done out of order ? | 16:22.51 |
| kens | henrys yes | 16:22.51 |
| Robin_Watts | ray_laptop: The downscaler can determine that for itself. | 16:23.05 |
| henrys | It says: If present, they will usually be the deviceâs default halftone dictionary; consequently, any printing that a PostScript program does will automatically take advantage of them (unless the program performs its own sethalftone call). | 16:23.13 |
| kens | henrys yes, that's what I'm saying | 16:23.33 |
| | THey are 'non-PostScript' screenign technuiques | 16:23.45 |
| ray_laptop | Robin_Watts: but, in the thread, how do we know whether or not to do the post processing, and which post processing | 16:23.55 |
| kens | A|s such you *can't* read them because they are not PostScript | 16:23.57 |
| Robin_Watts | ray_laptop: In the thread, if you are given a post processing function, you call it. | 16:24.13 |
| ray_laptop | Robin_Watts: so the downscaler_get_processed_bits decides whether to call get_bits(_rectangle) or get_processed_bits(_rectangle) ??? | 16:25.10 |
| mvrhel_laptop | whew. what a morning. wife was in the front of a 4 car collision. luckily she ended up with just a scratch since the first 3 absorbed the majority of the kinetic energy | 16:25.51 |
| ray_laptop | Robin_Watts: I still don't follow how the thread gets "given the post processing function" ? | 16:25.56 |
| henrys | kens:there is nothing wrong with defining a type 9 threshold array or regular halftone which could be read and should be treated as proprietary. | 16:25.59 |
| Robin_Watts | The downscaler_get_processed_bits will always call get_processed_bits - just it might choose to pass in a null post process function, in which case it will call it single threaded later. | 16:26.06 |
| ray_laptop | mvrhel_laptop: so she's OK ? | 16:26.15 |
| mvrhel_laptop | yes | 16:26.20 |
| kens | henrys you *cannot* define a type 9 halftone in PostScript | 16:26.20 |
| Robin_Watts | mvrhel_laptop: Ouch. Watch for whiplash :( | 16:26.36 |
| ray_laptop | mvrhel_laptop: was it her that ended up with just a scratch, or just her car ? | 16:26.41 |
| kens | All you can do is interrogate a device and discover that its current (or default) halftone is type 9, and therefore 'not PostScript' | 16:26.45 |
| henrys | kens:at compile time by the developer | 16:26.58 |
| kens | The bottom line is we don't support it | 16:27.09 |
| Robin_Watts | ray_laptop: Currently the threads are all called from within clist_get_bits_rectangle | 16:27.09 |
| mvrhel_laptop | the car. she has no injuries. woman who started collison was texting and plowed into stopped cars | 16:27.12 |
| kens | As far as I can tell | 16:27.20 |
| Robin_Watts | We'd be changing that so that all the threads were called from within clist_get_processed_bits | 16:27.42 |
| henrys | kens:I understand that we should support it. | 16:27.44 |
| mvrhel_laptop | looks like I am missing a good conversation. reading logs | 16:27.51 |
| ray_laptop | After I dropped my 7 yr old off, a BIG fire truck pulled up to the school, and as I was driving away, an ambulance came in (lit up and sirens) and another big fire truck. | 16:27.56 |
| kens | Big project. By the way, there's nothing to stop a PostScript program reading a type 9 halftone dictionary | 16:28.09 |
| | "Any such optional entries are strictly private: although they are visible to | 16:28.21 |
| | PostScript programs in the dictionary returned by the currenthalftone operator, | 16:28.21 |
| | there is no way for a program to know what they control or what their permissible | 16:28.21 |
| | values are." | 16:28.21 |
| mvrhel_laptop | ray_laptop: wow | 16:28.48 |
| ray_laptop | I haven't called the school yet to see what was going on. I figure I'll wait until things calm down | 16:29.06 |
| chrisl | How would we "support" proprietary screening? It needs support in the rendering code, or in the device | 16:29.13 |
| kens | chrisl that's the point I'm trying to make | 16:29.26 |
| henrys | kens:yes that is not a problem, the issue is dumpling the actual data that comprises the threshold array, that will be of concern to this customer and printer customers in general. | 16:29.40 |
| chrisl | kens: just rephrasing the point slightly | 16:29.55 |
| ray_laptop | Robin_Watts: the threads are "started" in clist_get_bits_rectangle_mt | 16:30.02 |
| kens | henrys since its 'not PostScript' you can't dump it, its not relevant because its not PostScript | 16:30.09 |
| Robin_Watts | ray_laptop: Yes. Which is called via clist_get_bits or clist_get_bits_rectangle. | 16:30.31 |
| kens | henrys it mattrers not at all how the developer defines their sacreening, since tis not PostScript there is nothgin we *can* return | 16:30.36 |
| | The only use for a type 9 or 100 halftone dictionary is for currenthalftone to be given somethign whihc says ' yeah we're screening' | 16:31.07 |
| | There is no realistic way for sethalftone to 'set' a type 9 or 100 haftone | 16:31.35 |
| ray_laptop | Robin_Watts: OK, if a function calls clist_get_bits_rectangle_mt it does no post processing, but if it calls clist_get_processed_bits then the post processing is done in the threads ? | 16:31.49 |
| kens | So I'm not sure what it is you want to support | 16:31.50 |
| chrisl | If they are that worried about people seeing a threshold array, they could just redefine currenthalftone to return nonsense (as several laser printers seem to do) | 16:32.09 |
| Robin_Watts | ray_laptop: We'd rename clist_get_bits_rectangle_mt to clist_get_processed_bits_mt and add the extra param. | 16:32.31 |
| kens | chrisl since they aren't using PS halftoning, the values returned by currenthalftone will be 'nonsensse' ( ie not what's being used) anyway | 16:32.52 |
| ray_laptop | Robin_Watts: and a post process get_processed_bits function that needs data in order calls clist_get_bit_rectangle | 16:32.54 |
| henrys | chrisl:and why not just do type9? | 16:32.59 |
| kens | henrsy why bother ? | 16:33.06 |
| Robin_Watts | yes. | 16:33.07 |
| kens | henrys^^ | 16:33.11 |
| henrys | kens:because that is what other printer manufacturers do and it is a documented way of presenting a proprietary halftone. | 16:33.55 |
| kens | Implementing a type 9 halftone *return* (we can't set one) is effort, whereas just leaving the default halftone is no effort. Since they are not using the default halftone, nothing is exposed | 16:34.09 |
| chrisl | henrys: the problem is, when we call the device to retrieve the current halftone, what we do with it? It's not going to be something any of our interpreters understand | 16:34.23 |
| | henrys: also, it's not what all printer manufacturers do | 16:35.01 |
| ray_laptop | Robin_Watts: OK, so now in the threaded case, where do the threads put the results? | 16:35.40 |
| Robin_Watts | ray_laptop: OK. Previously, I was suggesting that the post process stuff got to work directly on the buffer device, right? | 16:36.17 |
| ray_laptop | Robin_Watts: yes, and I *really* don't like that | 16:36.44 |
| Robin_Watts | Now, I'm thinking that the post process stuff should get fed the results from the 'get_bits'. | 16:36.53 |
| henrys | chrisl: they get the generic entries of the halftone type and they get the number "9" presumably they can write postscript programs that are conditioned on the type being 9 | 16:37.04 |
| Robin_Watts | That way, the caller has specified the formats they can accept already in the get_bits options fields. | 16:37.21 |
| ray_laptop | Robin_Watts: threads don't have a get_bits | 16:37.25 |
| henrys | I'll just ask him but to me it is fairly clear what he wants. | 16:37.32 |
| kens | You can write a PostScript program conditional on any value you like, but it won't be portable | 16:37.33 |
| Robin_Watts | We can arrange for the options to be passed into the threads. | 16:37.40 |
| chrisl | henrys: that would be very, very bad Postscript. | 16:37.42 |
| henrys | kens:he doesn't care about that in the startup code for his device. | 16:37.57 |
| ray_laptop | Robin_Watts: reading from the buffer device is fine. Writing the results back into the buffer is what I don't like | 16:37.59 |
| kens | henrys if you really want this it will not be any time soon | 16:38.03 |
| | henrys why does he care about the halftone type in the strtup code for his device at all ? He *knows* the halftone is not PostScript | 16:38.39 |
| henrys | I don't want it the paying customer wants it. | 16:38.41 |
| kens | henrys I'm not convinced he does | 16:38.50 |
| mvrhel_laptop | It would seem to me that if they (customer 885) are going to be doing something proprietary with their halftone then they will need to wrap that functionality up in their device. I suppose we should/could have a demo device for this. | 16:38.52 |
| kens | Nor that he neds it | 16:38.55 |
| chrisl | mvrhel_laptop: that's what the "scaled" devices do | 16:39.25 |
| ray_laptop | Robin_Watts: BTW, get_processed_bits needs to return the size of the buffer that it filled (in case it's doing compression) | 16:39.32 |
| Robin_Watts | ray_laptop: get_bits can be called with different options, to say whether the data should be put in a buffer provided by the caller, or whether pointers to the buffer are OK. | 16:39.35 |
| kens | henrys if you are going to ask him whether he needs a type 9 halftone, ask him as well to explain *why* he needs it | 16:40.01 |
| mvrhel_laptop | chrisl: you mean doing the halftone after the rendering to contone | 16:40.02 |
| | I don't know why you would really fool with the type 9 stuff then | 16:40.19 |
| henrys | kens:you are welcome to follow up if you like. | 16:40.22 |
| chrisl | mvrhel_laptop: using a custom halftone algorithm | 16:40.25 |
| mvrhel_laptop | yes | 16:40.29 |
| ray_laptop | Robin_Watts: so how does clist_get_processed_bits_mt know what size buffer each thread needs for its results ? | 16:40.30 |
| Robin_Watts | If the caller asks for the data to be put into a supplied buffer, then the post process phase can work in place. | 16:40.44 |
| kens | henrys probably better not be me, I'm cross with it already | 16:40.45 |
| henrys | kens:I can tell you why I would like one if I were making a product. | 16:40.47 |
| chrisl | mvrhel_laptop: although, it might be nice to have a simpler example - when we've got plenty of spare time! | 16:41.05 |
| ray_laptop | Robin_Watts: because the get_processed_bits call doesn't know what size the band is | 16:41.10 |
| kens | henrsy it looks to me like he just hopes that not setting a halftone will buy him some time | 16:41.49 |
| ray_laptop | Robin_Watts: but we really want a thread to be able to post_process and entire band that it can then return | 16:41.52 |
| kens | reduced processing time. | 16:41.55 |
| chrisl | There's no support in the graphics library for anything other than Type 1 and Type 4 halftones, if I'm reading it right. | 16:42.05 |
| kens | The amoutn of work I'll have to put in to avoid doing that probably costs as much as the one off halftone building | 16:42.16 |
| chrisl | Oops, I mean Type 1 and 2 | 16:42.23 |
| henrys | if somebody dumps out the halftone and they see type 9 they go look in the PS manual and there you go, they understand this is a proprietary thing, not the normal PS mechanism, seems perfectly reasonable thing to do. | 16:42.28 |
| kens | especially since we can't prevent the PostScript calling sethalftone | 16:42.34 |
| | henrys right, and ? | 16:42.44 |
| Robin_Watts | If the caller asks for the data to be given as pointers to the data that the buffer is storing, and we don't want to allow the post process phase to fiddle with that stored data, then the post processor is going to need to allocate it's own buffer and work into that. | 16:42.57 |
| mvrhel_laptop | perhaps when we encounter a type 9, it should be unpickled by the device and then applied in the standard manner or as a after rendering to contone in a sample device | 16:43.06 |
| kens | There are almost no users who can interrogate a PostScript device anyway | 16:43.23 |
| | Most are doing well to be able to post an error message | 16:43.36 |
| chrisl | mvrhel_laptop: a type 9/100 halftone would come from the device, you can't define it in PS | 16:43.42 |
| kens | WE CANNOT SET A TYPE 9 HALFTONE | 16:43.58 |
| Robin_Watts | and the buffers that get allocated can be passed back from the post processor to the device in any device specific way they like. | 16:43.59 |
| kens | The only thing that would be possible would be to pass a name (if on even exists, its optional!) to the device. | 16:44.34 |
| henrys | kens:well than you should write adobe and tell them to deprecate the feature and when they pull it out we can tell people they don't need it anymore ;-) | 16:44.38 |
| mvrhel_laptop | kens: yes. that is what I am saying | 16:44.50 |
| kens | mvrhel_laptop : type 9 halftones don't usually have names even, just a type | 16:45.08 |
| | THey are effectuvely read only | 16:45.14 |
| mvrhel_laptop | but you have a chunck of data | 16:45.20 |
| chrisl | Which raises a fundamental problem: the halftone is part of the graphics state, we don't reference the device for gs_currentscreen() | 16:45.21 |
| kens | henrys plenty of stuff in the PLRM that's useless | 16:45.26 |
| mvrhel_laptop | and the device would know what to do with it | 16:45.29 |
| kens | mvrhel_laptop : Here is a valid type 9 halftone "<</HalftoneType 9>>" sethalftone | 16:45.53 |
| | Not really much you can do with that. | 16:46.08 |
| | In general type 9 halftones are returned by devices which ahve proprietary non-PostScript screening and are not to be altered. | 16:46.38 |
| mvrhel_laptop | oh I see | 16:46.48 |
| Robin_Watts | kens: Suppose I was a device implementer, could I do: "<</HalftoneType 9 /MySpecialSauce/Gumbo>>" sethalftone ? | 16:47.10 |
| henrys | I don't see any requirement they be non-postscript - maybe I just want to hide my postscript screen | 16:47.14 |
| kens | Robin_Watts : no | 16:47.17 |
| mvrhel_laptop | so you would not supply such a type in a PS file | 16:47.23 |
| kens | You could do it with a type 100 | 16:47.24 |
| | henrys it doesn't matter if trhey are not PostScript, though they generally are. | 16:47.42 |
| Robin_Watts | kens: Suppose I was a device implementer, could I do: "<</HalftoneType 100 /MySpecialSauce/Gumbo>>" sethalftone ? :) | 16:47.46 |
| kens | The point is that you cannot set them | 16:47.48 |
| | Robin_Watts : yes | 16:47.54 |
| | Hence why I keep saying type 9 | 16:48.02 |
| henrys | kens:right or read them. You have no way in postscript of installing a postscript screen that cannot be read correct? | 16:48.34 |
| | s/postscript/ghostscript | 16:48.44 |
| kens | But such PostScript is decidedly non-portable, it is totally device-specific, and a PostScript consumer is quite entitled to say 'error' if you do that | 16:48.48 |
| | henrys, not in PostScript, no, but its easy enough to have a device which does screening totally divorced from teh PS setup | 16:49.25 |
| | OK I have to go | 16:49.33 |
| Robin_Watts | will bring popcorn to watch this discussion continue tomorrow :) | 16:49.55 |
| kens | henrys if I set up a GS device which does stochastic screening, that too is not threshold array driven | 16:50.24 |
| | Or any other kind of screening you like which is not threshold arrays | 16:50.38 |
| | In that case its not PostScript screening so you can't read it back | 16:50.51 |
| Robin_Watts | ray_laptop: Sorry, I got distracted by the fireworks. | 16:51.10 |
| kens | THe only real purpose of a type 9 halftone is to say 'I'm screenning and you can't understand how I'm doing it' | 16:51.29 |
| | Which is really pretty pointless | 16:51.38 |
| mvrhel_laptop | I think kens should answer 3 | 16:51.39 |
| henrys | kens:I don't know how that relates to what I said: I am a customer that would like to install a plain postscript halftone and have in unreadable how do I do that? | 16:51.43 |
| kens | mvrhel_laptop : That is what we are yelling about | 16:51.49 |
| mvrhel_laptop | I know | 16:51.59 |
| kens | henrys, you don't and you can't | 16:52.00 |
| | Not even with a type 9 halftone | 16:52.09 |
| Robin_Watts | kens: presumably you can't have it unreadable, but you can have it so that it's hard for anyone else to make any sense out of it? | 16:52.26 |
| kens | You can hjave a device which does threshold screening and doesn't want to tell thbe world, but that's just the same as doing non-threshold screening and not telling the worldx | 16:52.40 |
| | The screening technology is not relevant | 16:52.55 |
| henrys | kens:and I argue I can put that in a type 9 dictionary and have the postscript language protect it. | 16:52.57 |
| kens | henrys that is not the point, it does nont protect it. You cannot set such a screen in PostScript | 16:53.26 |
| chrisl | Robin_Watts: the two printers I've encountered have currenthalftone return, in one case, a null object, and in the other, a "valid" but garbage halftone dict. | 16:53.46 |
| henrys | kens:it's the default screen | 16:53.48 |
| kens | You can have it be a threshold array, but its not relevant. You can still leave the default screen in place, after all, you are going to ignore it anyway | 16:53.51 |
| Robin_Watts | ray_laptop: The problem of what buffers to use/how to communicate those buffers back to the device is the same whether we use a device function or a printer_function. | 16:54.09 |
| kens | henrys if you aren't going to use the PostScript screening, then it does not matter what type of technology you set up. If you are going to use PostScript screening then you cannot protect it | 16:55.09 |
| | ANd with that I really must go and cook | 16:55.17 |
| Robin_Watts | chrisl: If I was a device manufacturer and I wanted to be able to have people read the current halftone setting, and then reset that again later, I could presumably read the halftone setting out as a dictionary with all the values in, and then allow that to be set again later (but not as a type 9). | 16:55.21 |
| chrisl | Robin_Watts: a lot of printer manufacturers lock the screens (even Postscript ones) so they can't be changed anyway | 16:56.02 |
| Robin_Watts | chrisl: Right, but if I wanted to allow the screens to be set. | 16:56.23 |
| chrisl | Then you can't really protect the screens, because they must PS screens | 16:56.48 |
| henrys | chrisl: why can't you protect the screens? They simply can't be accessed. | 16:57.26 |
| chrisl | henrys: if you want to read, and *set* the screen, the screen must be readable in PS | 16:57.56 |
| Robin_Watts | I will not get drawn into this. I will not get drawn into this.... | 16:57.58 |
| | ray_laptop: You still here? | 16:58.05 |
| henrys | chrisl: I think this is exactly what type 9 gets at you can set the screen but you can't see it. | 16:58.31 |
| ray_laptop | Robin_Watts: agreed, but I still want to map it out. Particularly for at least a simple example post_process function e.g. | 16:58.34 |
| Robin_Watts | ray_laptop: Right, sure. | 16:58.43 |
| | but you're not completely offended by what I've described so far ? | 16:59.11 |
| ray_laptop | Robin_Watts: sorry. was on the phone. One kid at school was having trouble breathing. They scrambled everything but jets. | 16:59.17 |
| chrisl | henrys: I've never seen a printer that let you set a Type 9 screen, and have it do anything - I've see a few that completely sethalftone..... | 16:59.23 |
| Robin_Watts | ray_laptop: not your kid though? | 16:59.29 |
| henrys | that's my read of type 9 in the manual: (LanguageLevel 3) Defines a single halftone screen whose data is proprietary. The halftone dictionary may contain only the standard entries defined by Adobe. | 16:59.30 |
| ray_laptop | Robin_Watts: no offense | 16:59.31 |
| | Robin_Watts: no, when I was walking to my car after dropping my son off was when the first fire truck got there. | 17:00.16 |
| henrys | chrisl: anyway I asked the customer. | 17:00.32 |
| ray_laptop | so they had been called some time prior | 17:00.33 |
| chrisl | henrys: if it can only contain standard entries, where do you put your proprietary data? | 17:00.36 |
| Robin_Watts | right. | 17:00.37 |
| | ray_laptop: OK, so one possibility is that we only allow post_process functions to work in the case where the get_bits has been done to a caller supplied buffer. | 17:01.21 |
| chrisl | henrys: FWIW, I think this was poorly thought out in PS - the halftone should be a device param, not a graphics state entry. | 17:01.25 |
| Robin_Watts | The post process functions can safely write updated values back into that buffer. | 17:01.52 |
| ray_laptop | Robin_Watts: but the main thread that calls get_processed_bits starts several threads, but only provides a single buffer | 17:02.24 |
| Robin_Watts | each of which writes into a non-overlapping sub area of that buffer. | 17:02.45 |
| chrisl | henrys: I think we'd take a performance hit to support this stuff, not sure how | 17:02.56 |
| | much though | 17:03.03 |
| Robin_Watts | so each of the post process functions would work within the same non-overlapping sub area of that buffer. | 17:03.05 |
| | Imagine that my post-process function was to apply a gamma or something. | 17:03.23 |
| ray_laptop | Robin_Watts: OK. so how does the main thread caller decide how big a buffer to use ? | 17:03.33 |
| Robin_Watts | ray_laptop: The buffer sized required for a get_bits operation is well defined. | 17:03.52 |
| henrys | chrisl: I assume most devices put the data in the Thresholds entry and if you try and query that and the dictionary is type 9 it won't read it. | 17:04.20 |
| Robin_Watts | When you call get_bits with OPTION_COPY (or whatever it is) you provide a buffer large enough for the required rectangles bits. | 17:04.37 |
| ray_laptop | Robin_Watts: but recall that the main thread caller doesn't know how many threads will be used, and what the band size is (at least without clist invasion) | 17:04.45 |
| henrys | ray_laptop: did you do type 9's halftones at calcomp? | 17:04.49 |
| | we had them at QMS but I never knew the details. | 17:05.17 |
| ray_laptop | henrys: we did default HT with BNM's using a hack, and allowed a PS program to override the HT with sethalftone. | 17:05.59 |
| | henrys: the hack was a ThresholdArray that was of a known funky dimension 1x14 (CalCompDefault) | 17:06.50 |
| Robin_Watts | ray_laptop: The caller says "here is a buffer, get me this rectangle into this buffer, and apply this post process operation on it". | 17:07.10 |
| | The implementation may choose to break that down so that several threads are used to get different parts of that rectangle. | 17:07.39 |
| henrys | chrisl: anyway we'll see what the customer says and hopefully we can drop all this. | 17:07.57 |
| ray_laptop | Robin_Watts: fine. For a single thread. And I assume that the buffer size is passed as well as its address | 17:08.01 |
| ray_laptop | is still not happy with that | 17:08.22 |
| Robin_Watts | No, what have I said that isn't true for multiple threads? | 17:08.25 |
| ray_laptop | Most devices call get_bits line by line. I'd like a mechanism for MT post processing to be able to have automagic optimal sized results buffer per thread | 17:09.50 |
| chrisl | henrys: I think the big problem supporting this would be as I mentioned above: the halftone is part of the graphics state, so there is no generic mechanism for communicating halftone settings to and from the device. And then there could be problems with exactly what needs communicated to/from the device in the general case. | 17:11.04 |
| ray_laptop | so how about a callback into the post processor that will at least tell me what (worst case) size buffer is needed for a particular band size ? | 17:11.09 |
| Robin_Watts | Urgh, hold on. | 17:11.27 |
| henrys | chrisl, ray_laptop:there is some discussion about 532 using our fonts - and I got to thinking - would it be possible to do a compatibility comparison of glyphs like we did with CPSI using their simulator? | 17:11.51 |
| ray_laptop | is "Urgh" the IRC code for throwing up into the trashcan by your desk ? | 17:12.06 |
| Robin_Watts | I've been trying to cast this into a revised 'get_bits' form, whereby the post processing is done at the level of the rectangles requested by get_bits. | 17:12.35 |
| ray_laptop | henrys: They use UFST, so we don't really need to use the simulator do we ? | 17:12.46 |
| henrys | ray_laptop:I think having there exact configuration would be desirable. | 17:13.33 |
| Robin_Watts | You seem to be saying that we should be working purely at the band level. And I can see that that is another level at which we could be working. | 17:13.38 |
| ray_laptop | Robin_Watts: and I am at least as concerned about getting optimal performance out of MT rendering + post processing as simply as possible for the caller | 17:13.42 |
| henrys | configuring the ufst really sucks and getting the exact same thing in gs might not be easy, chrisl? | 17:13.59 |
| Robin_Watts | but I cannot see how to square the idea of working at the band level with the idea of working in non-clist modes. | 17:14.14 |
| chrisl | henrys: we use essentially the same code for "our" gs and customer 532's, the only difference is where we get the FCO data from | 17:14.56 |
| ray_laptop | henrys: their simulator has an option to write PPM's, but it hasn't been worked on and has bit-rotted (crashes). I haven't invsetigated their proprietary format. | 17:15.17 |
| chrisl | henrys: but they have a bunch of non-standard fonts in there, over the 136 PS3 ones, so that might be a problem | 17:15.35 |
| Robin_Watts | Maybe we can't get something that works in non-clist modes. Maybe we need to abandon that idea, and just do this for clist only devices. | 17:15.43 |
| ray_laptop | Robin_Watts: If a post process function provides a function that we can interrogate to give us the buffer size, then the MT thread startup can allocate the buffers (and free them on teardown) | 17:16.41 |
| Robin_Watts | ray_laptop: What sort of buffers are you thinking of? | 17:17.17 |
| chrisl | henrys: in fact, cust 532 use the UFST we supply, unless they've changed things a *lot* | 17:18.01 |
| henrys | chrisl:I was thinking of just seeing which glyphs we are missing using a postscript program which wouldn't print anything - console print type stuff. | 17:18.08 |
| Robin_Watts | Are you back to thinking of (say) a PNG device that compresses each bands as a post-process phase? | 17:18.16 |
| henrys | not on paper | 17:18.19 |
| chrisl | henrys: That wouldn't work because to do that you need access to the Postscript dictionaries, and the MT fonts fonts don't have PS dictionaries | 17:18.55 |
| henrys | chrisl: but I don't know if there PS interpreter will do that like ghostscript | 17:18.55 |
| ray_laptop | Robin_Watts: so a tiffsep type device wants halftoned data with HT done in the threads. If the band is N lines of contone, then the post processed buffer is 1/8th the size of the contone | 17:19.01 |
| Robin_Watts | ray_laptop: OK, that seems like a fair example. | 17:19.30 |
| chrisl | henrys: I believe their PS does similar things to us, and uses a "dummy" font dictionary, with just enough in it to fool inquisitive PS programs | 17:20.03 |
| henrys | chrisl:do they don't have any dictionaries associated with the fonts? | 17:20.08 |
| ray_laptop | so if we can get a function to call to get the size, then the MT startup can allocate a proper sized results buffer per thread | 17:20.12 |
| henrys | chrisl: I see | 17:20.31 |
| | darn | 17:20.38 |
| Robin_Watts | Why does it have to be the MT startup that allocates the buffer? | 17:20.40 |
| ray_laptop | Robin_Watts: and similarly for PNG or JPEG or whatever post processing that we want to tackle | 17:20.44 |
| chrisl | henrys: we also couldn't compare metrics in the same way I did with the URW and Adobe fonts | 17:21.05 |
| ray_laptop | Robin_Watts: who else knows the number of threads and the band size ? | 17:21.09 |
| Robin_Watts | with PNG or JPEG, we have no idea what the size of the buffer might be. | 17:21.14 |
| | and it's likely not a single buffer. | 17:21.25 |
| henrys | chrisl: true the customer was just asking for a coverage comparison though | 17:21.37 |
| ray_laptop | Robin_Watts: that's where we allocate the buffer for the rendered data for the thread (mem device buffer) | 17:21.46 |
| henrys | and I thought that would be a fast way but sigh... | 17:21.52 |
| ray_laptop | Robin_Watts: not a single buffer ? | 17:22.04 |
| Robin_Watts | ray_laptop: Right, *that* makes perfect sense. | 17:22.06 |
| | The rendered buffer is a single, predictable block of data. | 17:22.29 |
| henrys | chrisl: the customer told me they were configured for 80 fonts but that might be incorrect | 17:22.32 |
| ray_laptop | Robin_Watts: and the results for a post process has a predictable *worst case* size | 17:22.52 |
| Robin_Watts | In some cases. But it's not necessarily a single buffer. | 17:23.10 |
| chrisl | henrys: Oh, well, I was told it was the PCL/PS3 font FCO they were using, but again, that may have changed. | 17:23.20 |
| ray_laptop | Robin_Watts: if it's not a single buffer (example, please) then the post process function is required to divvy it up | 17:23.44 |
| Robin_Watts | suppose my post processing involves pulling the data out and compressing the 4 planes separately ? | 17:24.01 |
| chrisl | henrys: they easiest solution would be to see if we could borrow their FCO data, then I could to a little hacking in the FAPI code to gather the stats | 17:24.07 |
| Robin_Watts | ray_laptop: but anyway, I've got sidetracked again. I have larger concerns than "who allocates the buffers". | 17:24.40 |
| henrys | chrisl: isn't that in the simulator? | 17:24.46 |
| ray_laptop | Robin_Watts: so the get_processed_bits only gets passed a single destination buffer. How does it do it in the normal case ? | 17:24.51 |
| chrisl | henrys: the FCO data is obfuscated, and hidden behind custom APIs | 17:25.21 |
| Robin_Watts | Forget get_processed_bits for now, let's follow your one through. | 17:25.42 |
| chrisl | henrys: let me have a look tomorrow, I might be able to fiddle with the simulator code to get at least a first pass | 17:26.21 |
| henrys | chrisl:I'm a little nervous asking for that. | 17:26.25 |
| | chrisl: okay thanks | 17:26.49 |
| Robin_Watts | ray_laptop: So the typical use case, you've said is that someone will call 'get_bits' for a single line. | 17:26.50 |
| | And the clist threads will get kicked off, rendering each band in turn. | 17:27.09 |
| chrisl | henrys: I assume it's just the "base" 35 fonts we're talking about? | 17:27.35 |
| Robin_Watts | and after each band is rendered, you'll do the post processing phase, from the rendered bits into this new buffer of yours. | 17:27.38 |
| ray_laptop | Robin_Watts: right. And if the post process is compressing, then the threads will compress a band. So how do we return a single line ??? oops | 17:27.45 |
| Robin_Watts | right. | 17:28.06 |
| henrys | chrisl: I think that's a start but we really should know where we stand with 80 and 135 configurations, don't you think? | 17:28.51 |
| Robin_Watts | What the customer has done is to 'rewrite' the contents of the buffer device, so that the getbits results they get back can be used to get the munged data out. | 17:29.08 |
| henrys | chrisl: if it is something we are short on URW can fix it. | 17:29.22 |
| chrisl | henrys: the 80 is PCL, no idea how we'd get that done quickly | 17:29.41 |
| ray_laptop | Robin_Watts: right. And that works (I guess) because they are halftoning the data (so it's smaller than the original) ? | 17:30.02 |
| Robin_Watts | ray_laptop: Right. | 17:30.08 |
| chrisl | henrys: for the 135 fonts set we need to get to the bottom of the remaining name mapping issues, first | 17:30.30 |
| ray_laptop | or downscaling by a factor of 2 | 17:30.31 |
| henrys | chrisl: I don't think so I have clj right here and if I print out the postscript fonts I get 80⦠I think the customer is setup the same, ray_laptop might know | 17:30.43 |
| Robin_Watts | Now, either we need to do the same kind of thing (somehow have the results come out via the get_bits call)... | 17:30.58 |
| henrys | clj = Color LaserJet | 17:30.59 |
| Robin_Watts | ...or we're defining a completely new mechanism for getting the results out, and the get_bits call becomes just a way to kick the render threads off. | 17:31.39 |
| ray_laptop | Robin_Watts: plus the data they return is still fixed length per line. So compression in multiple threads is a problem unless we have a call to get_processed_band that tells us how much data comes back, and how many lines per band. | 17:32.00 |
| chrisl | henrys: Postscript generally has 35 for LL2, and 136 for LL3 - of course, the font sets are not actually stipulated in the language definition | 17:32.23 |
| Robin_Watts | My method was to try and use get_processed_bits to give us the updated buffers, but I see now that this will fall down horribly when we're not getting whole bands at once :( | 17:32.44 |
| henrys | chrisl: yeah I was surprised he told me 80. | 17:32.52 |
| ray_laptop | Robin_Watts: a get_processed_band _could_ be given a maximum number of lines it can take so the compression can be "split" at that (even if the threads buffers are bigger) | 17:32.55 |
| Robin_Watts | ray_laptop: For some of the use cases we are talking about, returning "lines" isn't an option. | 17:34.07 |
| henrys | chrisl: I just double checked the PS font list on my HP and I got 80 | 17:34.07 |
| Robin_Watts | If we're compressing whole bands for PNG for example. | 17:34.21 |
| ray_laptop | but post processing (for a lot of the filters) for line by line call may not work | 17:34.24 |
| chrisl | henrys: I suspect what they've got is the LL2 + PCL font set combined, and it's more hassle that it's worth to hide some from each interpreter. | 17:34.49 |
| | Anyway, got to go, my ride just showed up | 17:35.02 |
| ray_laptop | Robin_Watts: right. But the potential benefit from MT compression is so tempting to just toss it out. So we just do it for some common formats (JPEG, PNG) and have them work in bands | 17:35.44 |
| | and maybe TIFF (cust 531) | 17:36.03 |
| Robin_Watts | ray_laptop: Adding hacks in is bad. We need a nice way to expose this. | 17:36.28 |
| ray_laptop | Robin_Watts: I agree. sigh. | 17:36.43 |
| Robin_Watts | Suppose we forget about get_bits etc entirely. | 17:36.48 |
| | and we add a new device function 'process_page'. | 17:37.10 |
| ray_laptop | Robin_Watts: OK. And get_processed_bits. | 17:37.15 |
| Robin_Watts | Yes, forget get_processed_bits. | 17:37.25 |
| ray_laptop | listens again. | 17:37.47 |
| Robin_Watts | All process_page would do is trigger the page (or clist) rendering. | 17:37.50 |
| | and call post_process on the result of each band in turn. | 17:38.05 |
| | (or in the page case, the whole page). | 17:38.10 |
| ray_laptop | Robin_Watts: where does the page go ? | 17:38.37 |
| Robin_Watts | What does a device do with the data it gets? | 17:39.00 |
| ray_laptop | Robin_Watts: Highly variable. | 17:39.10 |
| Robin_Watts | That's my point. | 17:39.19 |
| | Currently the flow goes something like: | 17:39.25 |
| | foreach line { get_bits the line; process the line; } | 17:39.46 |
| | and processing the line might be writing it to a file, or sending it to a print engine, or whatever. | 17:40.12 |
| ray_laptop | Robin_Watts: process_page could get a callback to feed some data in (filter paradigm) the filter *consumes* it (fwrite or whatever) and tells the processing how much it consumed | 17:40.20 |
| Robin_Watts | Exactly! | 17:40.29 |
| | SOrry, I should have given the argument list of process page :) | 17:40.41 |
| ray_laptop | Robin_Watts: s'ok. I read between the lines | 17:41.05 |
| Robin_Watts | process_page(dev, post_process_fn, format options) or something | 17:41.12 |
| | that way, post_process_fn has to cope with being called with the parts of the page, possibly out of order, in whatever size bands gs happens to want. | 17:41.59 |
| ray_laptop | Robin_Watts: so a post_process_page implementation for a clist with MT can be as "smart" as it wants | 17:42.07 |
| Robin_Watts | ray_laptop: A process_page implementation for page mode would just 'get_bits' the whole lot, then call the process function on it. | 17:42.46 |
| ray_laptop | Robin_Watts: I don't agree that to the "possibly out of order". That should be hidden | 17:42.51 |
| Robin_Watts | A process_page implementation for clist mode would call the existing clist_get_bits stuff, but with some voodoo to ensure that we got whole bands at a time. | 17:43.28 |
| ray_laptop | if threads are used to post process, then the buffering of the data per thread, etc. s/b automagic | 17:43.55 |
| Robin_Watts | ray_laptop: I was trying to just use the current rendering threads. | 17:44.35 |
| | by processing in whole bands at a time, we can just call the post_process function on each thread, much as the client code does now. | 17:45.11 |
| | but that leads to the 'out of order' requirement that I mentioned earlier. | 17:45.25 |
| ray_laptop | Robin_Watts: wait. The post_process_fn is the processing. We also need a fn to send the data to that gets it in order. | 17:45.40 |
| Robin_Watts | ray_laptop: We don't *need* that. | 17:46.14 |
| | The processing functions (not really "post processing" now) can be responsible for sorting that out too. | 17:46.44 |
| ray_laptop | Robin_Watts: so how does that get us post processing done in the threads, then ? | 17:46.49 |
| Robin_Watts | is clearly not being clear :( | 17:47.28 |
| | The customer has added code in the clist_render_threads so that after every render, just before the thread closes down, it does some processing, right? | 17:48.15 |
| ray_laptop | needs more coffee (or liquor) :-( | 17:48.29 |
| Robin_Watts | I'm proposing that when we're calling "process_page" the net effect would be that at exactly that same point, we'd call the user supplied process function with that band. | 17:49.06 |
| | So the work is done on the threads. | 17:49.36 |
| ray_laptop | we've now just bubbled it up to the print_page layer, but I don't see any advantage yet | 17:49.36 |
| mvrhel_laptop | Robin_Watts: quick question. so can a fz_page be shared amongst threads? I was just worried a bit about a thumbnail rendering and the full res in a certain case. | 17:49.49 |
| Robin_Watts | mvrhel_laptop: No. | 17:50.52 |
| mvrhel_laptop | ok. that is what I thought | 17:51.01 |
| | just the ctx | 17:51.07 |
| | i need to drill that in my head | 17:51.19 |
| Robin_Watts | ray_laptop: What advantage were you looking for? | 17:51.28 |
| | Driving the thing via get_bits doesn't work really, unless you want to 'get_bits' and then ignore the values you get back and only get the data out of the post_process function. | 17:52.34 |
| | So rather than doing that, I'm suggesting that we use a 'process_page' routine that just renders the bands and then 'post_process'es them. | 17:53.41 |
| | It's explicit that way that the post_process function is responsible for absorbing the data and dealing with it. | 17:54.13 |
| ray_laptop | Robin_Watts: Ok. So we still can't do compression post processing, can we? Because a process_fn that gets called out out order won't know what other threads have run | 17:54.15 |
| Robin_Watts | ray_laptop: We can't do compression post processing where one band depends on the previous one. | 17:54.57 |
| ray_laptop | unless the MT code provides a 'wait for band N' that stalls a thread until it can run | 17:55.11 |
| Robin_Watts | I suggested that the other day, and you were dead set against it, on the grounds that that would destroy the benefits of parallelism. | 17:55.43 |
| ray_laptop | Robin_Watts: writing the data (e.g., to a file) will always need to be in order, even if we can compress in parallel | 17:55.46 |
| Robin_Watts | ray_laptop: Yes. But there is no reason why we can't compress each band and store the compressed version in a queue until it can be written out in order. | 17:56.32 |
| ray_laptop | Robin_Watts: so the 'wait' is done AFTER the CPU intensive processing, unlike yesterday's | 17:56.46 |
| Robin_Watts | ray_laptop: Eh? | 17:57.19 |
| ray_laptop | Robin_Watts: yesterday I thought you proposed delivering the bands to the post process fn *in order* | 17:57.56 |
| | which means single thread post processing | 17:58.22 |
| Robin_Watts | If you want to have bands whose compression depends upon the previous bands compression then we always need to wait until the previous band has finished before we can start the next bands compression | 17:58.23 |
| | which means the post processing will end up being only done on a single thread at a time yes. | 17:58.52 |
| ray_laptop | Robin_Watts: yes, for something like FS, but compression is not necessarily dependent on previous band | 17:59.13 |
| Robin_Watts | If the compression is much slower than the rendering, then that will limit our benefits. | 17:59.19 |
| | If you want to (say) do PNG compression where you flate each band with a reset so bands don't depend on each other, then they can run out of order. | 17:59.52 |
| ray_laptop | The compression (PNG, JPEG) is often much slower than rendering | 17:59.53 |
| henrys | ray_laptop:sorry to bother you but you do have an open question from 801 - I don't know if you saw it, the thread is getting very complicated with interleaving topics. | 18:00.14 |
| Robin_Watts | but you need to get 'in order' before you can write to the file. | 18:00.15 |
| Robin_Watts | pauses to allow henrys to ask ray questions... | 18:00.32 |
| ray_laptop | Robin_Watts: right. And a processing_fn that _does_ depend on previous bands doesn't do the processing in threads | 18:00.33 |
| | henrys: sorry. Missed that. | 18:00.58 |
| | I haven't broken away to finish processing email yet | 18:01.21 |
| Robin_Watts | ray_laptop: How about: process_page(dev, process_fn, process_fn_arg, int gb_options, int in_order) | 18:02.14 |
| ray_laptop | henrys: I see the one from Masuda-san. I'll respond today (before they wake up) | 18:02.15 |
| Robin_Watts | That way, the caller can choose whether the processing needs to be done in order or not. | 18:03.10 |
| | ray_laptop: How long do the rendered buffers last at the end of each thread? | 18:03.48 |
| ray_laptop | Robin_Watts: until they are grabbed by the 'main' thread and that thread restarted. clist_get_band_from_thread | 18:04.45 |
| Robin_Watts | ray_laptop: So we *could* decouple the post processing of the buffers from the thread that renders them. | 18:05.32 |
| ray_laptop | Robin_Watts: so a thread finishes (signalling its sema and status to DONE) and then exits | 18:05.37 |
| Robin_Watts | If we have n threads, do we have a maximum of n buffers? | 18:06.51 |
| ray_laptop | Robin_Watts: so a post_process function that is capable of running "out of order" would be passed to the thread, but if not, then the main thread does it | 18:07.02 |
| | Robin_Watts: yes | 18:07.09 |
| henrys | ray_laptop: yes that's the one | 18:07.45 |
| ray_laptop | each thread (and the main thread) has a memory device buffer. | 18:07.50 |
| | henrys: OK. Will respond to them (and cc support, of course) | 18:08.07 |
| Robin_Watts | ray_laptop: Either that, or we could always pass the post_process function to the thread, and in the 'in_order' cases, have a 'wait my turn' call in there. | 18:08.15 |
| ray_laptop | Robin_Watts: to avoid copying the data, we "swap" buffers with the thread, but otherwise it's basic | 18:08.47 |
| | Robin_Watts: don't really see the advantage to the latter | 18:09.17 |
| Robin_Watts | ray_laptop: Possibly simpler code? (only 1 place where we call post_process?) | 18:09.43 |
| ray_laptop | Robin_Watts: OK, so for compression... We want to do the compression part in the thread, but the writing in_order. How's that work ? | 18:10.40 |
| Robin_Watts | Might it be the case that some post_process things could be split into stuff that can run out of order, and stuff that must be run in_order? | 18:10.53 |
| | ray_laptop: OK, for compression... If I was implementing such a post_process function, I'd compress the data, and then send the buffer pointer/length to the device. | 18:12.01 |
| ray_laptop | Robin_Watts: "send" ? | 18:12.22 |
| Robin_Watts | yeah, conceptually "send". Pass the ownership over to another function in my device. | 18:12.52 |
| ray_laptop | That's what I was proposing. An output filter to send it to | 18:12.59 |
| Robin_Watts | that function would have a queue of completed pieces. | 18:13.06 |
| ray_laptop | the process page gets two fn's the process_fn and the output_fn | 18:13.35 |
| SpNg | Robin_Watts: did you see my comment from last night about compiling the patch for downSampling? | 18:14.15 |
| Robin_Watts | I was thinking that this would be an internal mechanism. We don't *need* to expose that to the device. | 18:14.16 |
| ray_laptop | the output_fn can have 'in_order' requirements that even if the process_fn does not | 18:14.17 |
| Robin_Watts | s/to the device/to the world/. | 18:14.48 |
| | SpNg: I did. | 18:14.56 |
| SpNg | Robin_Watts: I don't know if you responded, my buffer is gone for this chat ;-( | 18:15.16 |
| Robin_Watts | SpNg: I didn't respond as you'd gone. | 18:15.27 |
| ray_laptop | SpNg: it's searchable in the logs on the website | 18:15.35 |
| | (we often respond with "for the logs") | 18:15.54 |
| Robin_Watts | The change has now made it into our repo, and our testing showed no problems. | 18:15.55 |
| | You were complaining that your compilation was filling your harddisc, right? | 18:16.16 |
| SpNg | Robin_Watts: makes sense ;-) Do I need 50 GB+ to compile from source on that repo? | 18:16.19 |
| Robin_Watts | No way. | 18:16.25 |
| SpNg | correct. That's what I thought. Seems strange. I followed the ReadMe.txt ./autoconfig.sh ./configure make | 18:16.59 |
| | CentOS x86_64. I will give it another run today. | 18:17.38 |
| Robin_Watts | SpNg: git clone ... ghostpdl.git && cd ghostpdl.git/gs && ./autogen.sh && make | 18:18.04 |
| | ray_laptop: I'm not hugely keen on the idea of having the output_fn and the process_fn both exposed. | 18:18.56 |
| | I think I'd rather leave it to the device. | 18:19.04 |
| ray_laptop | Robin_Watts: All devices will have one, won't they ? | 18:20.09 |
| Robin_Watts | You're proposing that the process_fn should complete with a buffer pointer/size and that would be queued until the output_fn was ready for it? | 18:20.11 |
| ray_laptop | Robin_Watts: if the output_fn says "in_order", yes it waits (most probably will) | 18:21.02 |
| Robin_Watts | What if my process_fn produces more than one pointer/size ? | 18:21.29 |
| | I guess that can be coped with. | 18:21.51 |
| ray_laptop | or we could just define the output_fn as ALWAYS in_order, main thread. Then if NULL, that particular process_fn has to take care of the data | 18:22.04 |
| Robin_Watts | Right. | 18:22.15 |
| SpNg | Robin_Watts: I was doing it form the root. I will do it form gs/ dir | 18:22.31 |
| Robin_Watts | I'm not against the idea. I just might not have jumped straight in and done it in the first version. | 18:22.34 |
| | ray_laptop: I'm sure I've asked this before and been told no, but.... | 18:23.59 |
| | is there any way a device can influence the bandheight that is chosen? | 18:24.12 |
| | In particular, I could imagine that a device might really want a bandheight that's a multiple of a given size. | 18:24.42 |
| | 8 or 16 for jpeg for example, or 3 if the downscaler is being used with a factor of 3. | 18:25.19 |
| ray_laptop | Robin_Watts: a clst_device (gx_device_printer) has "space_params" where the BandHeight can be specified. If 0, we choose the default given the BufferSpace, otherwise we use the value given | 18:26.41 |
| Robin_Watts | ray_laptop: Right, so it's all or nothing. | 18:27.35 |
| | A lot of the time I can imagine people wanting to say "You pick the size, but make it a multiple of n" | 18:28.01 |
| ray_laptop | Robin_Watts: no, because there is a printer_procs callout to get_space_params | 18:28.11 |
| | in gdev_prn_allocate " give the dev-specific driver a chance to adjust them." | 18:28.58 |
| Robin_Watts | So, you're saying that I could hook that and "adjust" the value. ? | 18:30.04 |
| | or by "adjust" do you mean "set" ? | 18:30.24 |
| ray_laptop | Robin_Watts: I think so. I haven't looked to see if there is enough info | 18:30.35 |
| | Robin_Watts: you are passed a space_params struct (by address) that has been copied from the dev->space_params. Then the fn can modify them. | 18:31.34 |
| Robin_Watts | ray_laptop: OK. so I could just & ~7 and be sorted. | 18:33.03 |
| | ray_laptop: So are you happy about where we've ended up with this process_page stuff? | 18:34.13 |
| | It seems much more sensible this way than trying to force it through get_bits. | 18:34.40 |
| | I'll have a crack at it tomorrow, and I'm sure I'll have more to bother you with by the time you arrive :) | 18:35.22 |
| | Thanks for the discussion. I feel much happier now. | 18:36.24 |
| mvrhel_laptop | bbiaw | 18:40.26 |
| ray_laptop | henrys: reply sent to customer 801 | 20:39.36 |
| henrys | Robin_Watts: at git.ghostscript.com if I select "raw" at commitdiff is that the format compatible with git apply? | 20:56.49 |
| Gigs- | I'm getting that problem again where files segfault at 300dpi but render at any other res | 21:16.34 |
| | I don't see it in buzilla because I think a git pull fixed the particular files in question last time, but I guess what it really did was shift the buffer overflow to a different memory offset or something | 21:17.08 |
| | this is going to be a hard bug to deal with because every snapshot seems to change what files it affects | 21:17.52 |
| | even a slightly different build environment probably changes it | 21:18.13 |
| | I do have high level statistics for the bug though, it happens 0.8% of the time :) | 21:20.55 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=694714 | 21:40.30 |
| | heh you can't render anything at 1dpi, serious bug there :P | 21:43.25 |
| | I guess in theory you should be able to, but I'm not going to file that one | 21:43.46 |
| Micha` | Gigs-: 0.8% of the time... :) Wooh, that's a nice bug you've got there! Good luck with that :) | 21:44.26 |
| Gigs- | yeah it's not going to be fun | 21:44.50 |
| | I doubt it's reproducible by normal means | 21:45.08 |
| Micha` | Depends on the perspective. I surely will have fun looking at the final patch :) | 21:45.24 |
| Gigs- | the final patch will probably be something silly like an off by one fix | 21:45.43 |
| | the thing is even if I make a debug build I'll have to run hundreds of files to find a new broken one | 21:47.22 |
| Micha` | I'd expect that. But the craziness of this 299/300/301 thing is quite promising for the spectator crowd. | 21:47.46 |
| Gigs- | yeah right now I'm running one of them that breaks at 300 from 0 to 300 | 21:48.05 |
| | so far it's been ok | 21:48.15 |
| | It would actually be nice if it broke on more resolutions | 21:48.28 |
| | if it only breaks on 300 then that means it's probably not anything file specific per-se | 21:48.54 |
| Micha` | This. Is. SP... ecial. Quite special. | 21:48.54 |
| Gigs- | it's on 206 now | 21:49.46 |
| Micha` | Well then, the Sparta reference is then out. 206 is the name of a French car though. | 21:53.01 |
| Robin_Watts | henrys: I believe so, yes. | 22:08.39 |
| henrys | Robin_Watts: thanks | 22:08.54 |
| marcosw | Gigs-: I'd like to take a look at http://bugs.ghostscript.com/show_bug.cgi?id=694714 Can you send me the test file and/or attach it to the bug (if you do the latter let me know and I'll mark it as private so it's only visible to Artifex staff). My email is marcos.woehrmann@artifex.com | 22:24.15 |
| | Gigs-: also, have you tried running valgrind? I've had good luck using it to isolate hard to reproduce seg faults. | 22:25.16 |
| Gigs- | marcosw: I will attach a file but I don't have much hope | 22:29.58 |
| | I haven't used valgrind in years but I can try tomorrow | 22:31.56 |
| | marcosw: ok attachment upload please mark private | 22:32.07 |
| marcosw | Gigs-: done. If I get anywhere I'll update the bug report. | 22:33.49 |
| Gigs- | good luck thanks, I'll try to get some more debugging time in tomorrow | 22:34.08 |
| marcosw | Gigs-: the good news is that I'm able to reproduce the seg fault @ 300 dpi (and not at 299 or 301 dpi). | 22:36.49 |
| Micha` | Robin_Watts: I opened a few bug reports based on our discussions here. For http://bugs.ghostscript.com/show_bug.cgi?id=694713 , I have a patch ready but I noticed the warning "A signed Artifex Contributor License Agreement is prerequesite for patch acceptance." For such a small contribution, is it really needed? | 22:52.12 |
| Robin_Watts | Micha`: Probably not. | 23:04.49 |
| ray_laptop | marcosw: I snagged bug 694714 -- pretty clearly clist mis-behavior, but if you (or Robin_Watts) *know* that it's from his code vs. general problems, feel free to take it back. | 23:57.19 |
| | cust 532 is happy (waiting for a minor enhancement that is almost done), so I can look at this while testing their stuff | 23:58.12 |
| | Forward 1 day (to 2013/10/17)>>> | |
IRC Logs