| | <<<Back 1 day (to 2011/07/10) | 2011/07/11 |
| chrisl | kens: I finished Accelerando at the weekend - hmmm....... | 09:11.58 |
| kens | Yes, I would say so. | 09:12.13 |
| | Its an early work I would think. | 09:12.20 |
| | There's a sdhort story in 'Toast' (Lobsters) which is the basis for it. THe short story is better. | 09:12.43 |
| chrisl | I liked the idea, but in scope in felt more like a Peter F Hamilton trilogy squeezed into a normal length Stross book | 09:13.02 |
| kens | Probably a fair assessment | 09:13.39 |
| chrisl | So to balance, I started the final Void book :-) | 09:14.08 |
| kens | Oh, I was a bit disappointed with that too. | 09:14.29 |
| chrisl | Well, we'll see - after a couple of pretty difficult to read books, at least Peter Hamilton's writing is easy going! | 09:15.14 |
| kens | Its pretty typical fare, I just thoguth the ending was a bit abrupt and rather 'deus ex machina' | 09:15.49 |
| | Though in some degree, that is fair in this case. | 09:16.09 |
| chrisl | I tend to find that with these meta-physical subject matter stories | 09:17.00 |
| kens | Hmm, I'm goign to have to come up with a way to represent multiple Unicode values from a single glyph name :-( | 09:18.28 |
| chrisl | Eh? how does that work? | 09:19.41 |
| kens | Looks like mutliple table sis the only way to go :-( | 09:19.41 |
| Robin_Watts | kens: postscript array, obviously :) | 09:20.00 |
| kens | Soem (Hebrew and arabic, maybe others) are dfeined with a single glyph name which contains three actual glyphs. | 09:20.10 |
| | Robin_Watts : In C cause I want ti to be quick and effcieitn. | 09:20.19 |
| Robin_Watts | wonders how Firefox can be offering him Firefox 6.0 Beta when firefox 5 isn't out of beta yet. | 09:20.42 |
| kens | hasn't installed FF 4 yet. | 09:51.19 |
| Robin_Watts | FF4 is safe (as they've fixed firebug to work with it) | 10:03.51 |
| kens | not sure all my plug-ins will work | 10:04.06 |
| Robin_Watts | actually, even FF 5 is safe for firebug. | 10:04.19 |
| | I'm holding off FF6 until they get firebug working with that. | 10:04.29 |
| | ooh, they have a beta version that works in firefox 6. | 10:05.21 |
| | Wow. They have firefox 7 in beta too. | 10:05.28 |
| | tor8: sebras: you here? | 10:42.32 |
| sebras | Robin_Watts: I'm here. | 11:22.23 |
| | haven't seen tor8 today... | 11:22.30 |
| Robin_Watts | I just had a crack at supporting 'isolated' groups, and it failed horribly :) | 11:22.43 |
| | or non-isolated ones, rather. | 11:22.56 |
| | You and tor have talked about how to do this before ? | 11:24.26 |
| sebras | briefly, maybe six months ago. | 12:02.28 |
| | tor8 mentioned that there would be some difficulties, but I don't remember them at the moment. | 12:04.40 |
| | he did mention over icq when you mentioned it here the other day that he saw problems with implementing non-isolated knockouts... | 12:05.12 |
| ray_laptop | morning, all | 13:50.34 |
| kens | Morning ray | 13:50.44 |
| ray_laptop | kens:did my question about the multi-level threshold ring any bells ? Have you seen this in the past ? | 13:51.46 |
| kens | Oh sorry Ray, I meant to look at it but got diverted by a customer. | 13:52.07 |
| | I'll read it again now. | 13:52.12 |
| ray_laptop | pesky customers ;-) | 13:52.20 |
| kens | However, Jaws didn't really do multi-level thresholds IIRC | 13:52.22 |
| | It was Raed and his ps2ascii stuff again | 13:52.37 |
| | Quite pesky | 13:52.44 |
| ray_laptop | kens: well, if they didn't do it internally, then they probably didn't have a PS interfaces :-) | 13:52.52 |
| kens | I think the 2/4 bit halftones were internal rather than thresholds, but I oculd be wrong. | 13:53.29 |
| ray_laptop | kens: yeah, I saw that. How's the textwrite device coming :-/ That's probably really the only solution for him | 13:53.34 |
| kens | There was a type 99 I think. | 13:53.36 |
| | ray_laptop : Pretty good. I added teh AdobeGlyphList lookup today. | 13:53.51 |
| | SO now we can use ToUnicode and GlyphNames2Unicode tables. | 13:54.08 |
| ray_laptop | what's AdobeGlyphList -- I haven't heard of that | 13:54.26 |
| kens | If that fails we look for glyph names of the form 'unixxxx' and use the xxxx for a Unicode value. | 13:54.26 |
| | Ray its a list of glyph names and their asscoiated unicode values, published by Adobe. | 13:54.48 |
| | If the name isn't unixxxx then I consult the glyph list and see if I can find it there. | 13:55.05 |
| | THat can result in 1-4 Unicode values. | 13:55.11 |
| ray_laptop | kens: thanks. Didn't know there was such a thing | 13:55.25 |
| kens | If *taht* fails, then currently I give up and dump the raw data. | 13:55.26 |
| | I maintain the text in a y-sorted list of x-sorted fragments. | 13:55.52 |
| | Each fragment has the Unicode value, font name, calculated point size and some other flourishes like writing mode, stroke width for Paint Type 0 and so on. | 13:56.28 |
| | What it doesn do right now (becaus ei removed it in a rework) is actually output anything. | 13:56.47 |
| Robin_Watts | ray_laptop: So, these multilevel thresholds... | 13:56.53 |
| ray_laptop | Robin_Watts: yes ? | 13:57.07 |
| Robin_Watts | Can we not just keep a single threshold array? | 13:57.30 |
| kens | Ah, I mis-filed Ray's email amongst the 'Consultation' on support. That's why I forgot it | 13:57.56 |
| Robin_Watts | Let me try and find a nice way to describe this... | 13:58.09 |
| ray_laptop | kens: are you going to have a mode for the output to be r-2-l or t-2-b (i.e., dump the list for the page differently) ? Do you have any diesign spec ? | 13:58.57 |
| kens | ray_laptop : no design spec. Currently looking at two modes simple (just text more or less in order) and complex, something like the ps2ascii output, where all the info is dumped out. Possibly in fake XML like Robin I think does with MuPDF. | 13:59.50 |
| ray_laptop | Robin_Watts: my option 4 was to keep a single threshold array | 14:00.00 |
| | Robin_Watts: note, that I am not concerned with what is internal (in C) but with the PS representation | 14:00.37 |
| kens | I think we should use our own numbers. | 14:01.05 |
| Robin_Watts | Standard threshold arrays work with each point in the tile (T) having a threshold value, and the colorant value (V) is compared to that; if T > V, we get a pixel set, if not, we get that pixel clear. | 14:01.27 |
| ray_laptop | Robin_Watts: 'set' and 'clear' aren't exactly the case for 2-bit. | 14:02.09 |
| Robin_Watts | Right. When I said "standard" I meant "for 1 bit". | 14:02.30 |
| ray_laptop | Robin_Watts: OK. | 14:02.35 |
| Robin_Watts | OK, so for n bit halftones we have (2^n)-1 threshold levels for each pixel | 14:03.55 |
| ray_laptop | Robin_Watts: multi-level thresholds use N*N-1 levels, so for 2-bit at each pixel we have [ t1, t2, t3 ] | 14:04.01 |
| | Robin_Watts: yeah, it is 2^N I was sleepy last night | 14:04.32 |
| Robin_Watts | np. | 14:04.37 |
| kens | Was about to say :-) | 14:04.39 |
| ray_laptop | also hasn't had coffee yet | 14:05.07 |
| Robin_Watts | OK, so either we have to pack those 2^N-1 values into a single one, or we have to make the threshold arrays bigger. | 14:05.11 |
| | I thought I had an idea for packing, but now I've run through it, I don't. | 14:05.30 |
| kens | I'm not sure it matters, we need a bunch of data, we want to represent it in PostScript. | 14:05.49 |
| | There are several ways to do it | 14:05.55 |
| Robin_Watts | So yes, I reckon having them x*y*(2^n)-1 and detecting based on the size of the array seems perfectly reasonable to me. | 14:06.12 |
| ray_laptop | One example for 'chunky' option 4 is, HalftoneType 3, and the first 2^N-1 elements in the string are the 8-bit thresholds for pixel 0 | 14:07.18 |
| kens | IMO I think we should define these as HalftoneType 100. | 14:07.18 |
| | We cna then add specific keys to the dictionary to hold the data as we wish. | 14:07.41 |
| | I woudl suggest that one of those keys should be /BitsPerSample or soemthing. | 14:08.03 |
| | So we know what output depth the halftone is good for. | 14:08.14 |
| ray_laptop | kens: the only thing about type 100, is that we would also then have optional keys to specify bits per threshold value (8 or 16) as well as the multiple thresholds | 14:08.41 |
| kens | ray_laptop : yes, but is that a problem ? | 14:08.56 |
| Robin_Watts | I liked the idea of Halftone 100+whatever the closest 1 level was. | 14:09.06 |
| kens | 100 is defined, other values aren't | 14:09.17 |
| | There's never likely to be a problem, but..... | 14:09.26 |
| | I'd prefer to stick to the spec. | 14:09.43 |
| Robin_Watts | kens: fair point. | 14:09.51 |
| ray_laptop | kens: no problem -- I just wanted to know if anyone else knew of what Adobe did for type 100 (i.e., use the same key names, maybe) | 14:09.53 |
| kens | I don't know of anyone using proprietary halftones I'm afraid, apart from Jaws which used type 99, because it pre-dated the level 3 spec and the definiton of type 100 :-( | 14:10.41 |
| ray_laptop | kens: I was (only slightly) concerned with having some PS file from the wild that iused 100 (possibly in a beginfeature ... endfeature of setpagedevice) | 14:11.18 |
| kens | ray_laptop : If it does, we can easily ignore it. | 14:11.38 |
| ray_laptop | setpagedevice or other "optional" PPD | 14:11.43 |
| kens | All we need to do is add a mandatory key like /Vendor /Artifex or soemthing | 14:11.54 |
| | We can throw away any halftones which don't match. | 14:12.11 |
| | But I've never actually seen a type 100 halftone in a real job | 14:12.37 |
| ray_laptop | kens: well, most PPD's do 'non standard' stuff in stopped contexts, and fall back to standard. If we do 100 differently to what they expect, but don't 'stop' that might cause confusion | 14:12.41 |
| kens | We can throw an error if the key isn't present :-) | 14:12.58 |
| Robin_Watts | ray_laptop: We check for the /Vendor key and ... what kens said. | 14:13.07 |
| ray_laptop | kens: Robin_Watts: OK. Thanks for the ideas. Using 100 does avoid potential hiccups with CET. I don't know that they enumerate HalftoneTypes, but if anyone did, they (QL) would | 14:14.50 |
| kens | Looks like htere's specific code in the AGMCORE stuff from Adobe to look for type 100 halftones. I htink it leaves it alone if its set. | 14:14.58 |
| ray_laptop | kens: soet of an implied HalftoneMode 1 ? | 14:15.33 |
| kens | I htink so, but I haven't fully deciphered it | 14:15.49 |
| | Google for "/HalftoneType 100" only hits the 3010 supplement | 14:16.19 |
| ray_laptop | kens: I've got the "Adobe PostScript 3 Version 3010 and 3011 Product Supplement" and it doesn't mention HalftoneType | 14:19.09 |
| kens | Hmm, maybe I'm looking at thw rong thing. | 14:19.27 |
| ray_laptop | kens: no, maybe Adobe re-released it with different contents (mine is 1999) | 14:20.00 |
| kens | Possilby, just a mo. | 14:20.09 |
| | Hmm, this is hte 1997 version | 14:20.42 |
| | So it looks like they did, and you have the new one :-) | 14:20.52 |
| | p174 in this one | 14:21.15 |
| | This one is just 3010 | 14:22.13 |
| ray_laptop | kens: does it say anything about the contents ? | 14:23.35 |
| kens | HalftoneType (Required) HalftoneName (Optional) | 14:24.14 |
| | other any type (Optional) Product specific | 14:24.31 |
| ray_laptop | kens: thanks. That's sort of what the PLRM says. | 14:25.52 |
| | I have to run check what they are doing in my street -- construction going on this week. bbiab (with my coffee as well) | 14:26.22 |
| kens | Yes, agreed. You should probably get a copy of the 3010 supplement, there's a lot in there that isn't int the combined 3010 & 3011. | 14:26.26 |
| ray_laptop | kens: I can't seem to find the 1997 3010 only supplement | 14:26.41 |
| kens | I can send you it. Its 406 pages while the combined is only 158 | 14:27.05 |
| ray_laptop | Mr. Google finds the 3010 and 3011 version that I already have | 14:27.09 |
| kens | wait one | 14:27.19 |
| ray_laptop | kens: thanks | 14:27.27 |
| | bbiab | 14:27.42 |
| kens | ray_laptop : : | 14:27.57 |
| | http://ftp.ktug.or.kr/obsolete/info/adobe/devtechnotes/pdffiles/3010SUPP.pdf | 14:27.57 |
| ab5tract | does anyone have any design patterns lying around that allow for generating a random number within a specific range? | 14:51.31 |
| Robin_Watts | ab5tract: http://www.entropykey.co.uk/ ? ;) | 14:52.29 |
| ab5tract | all i have found so far is /smallrand { rand 2147483647 div 2 mul 1 sub } def | 14:52.31 |
| ray_laptop | kens: thanks. It looks like all the extra information was put into the PLRM 3rd edition (which came out in 1999). | 14:53.55 |
| kens | Yes, I would guess that's true ray_laptop | 14:54.12 |
| | I like to keep all the docs :-) | 14:54.20 |
| ab5tract | Robin_Watts, hey, thanks but i was hoping for some way to deal with postscript's cheesy rand feature | 14:54.32 |
| kens | ab5tract : rrand produces a value between 0 and (2^31) -1 | 14:55.03 |
| | So divide the result by 2^31 and you have a result between 0 and 1. | 14:55.24 |
| | multiply by the number you want. | 14:55.32 |
| ab5tract | kens, yes, thanks. im just trying to bend my mind around how to get specific ranges. i realize i just combine the /smallrand and then multiply by the maximum of the range | 14:55.39 |
| kens | Make that 2^31 -1 | 14:55.40 |
| ab5tract | yes, thanks | 14:55.43 |
| Robin_Watts | If the range is small then using rrand and mod will do what you want. | 14:55.46 |
| ab5tract | kens Robin_Watts thanks :) | 14:56.03 |
| Robin_Watts | Can someone sanity check me please? I can't see where the alpha is coming from in this pdf file. | 14:57.04 |
| | http://ghostscript.com/~robin/isolated.pdf | 14:57.25 |
| kens | one minute | 14:58.00 |
| Robin_Watts | We have an XObject with blendmode Multiply that contains 2 overlapping circles. | 14:58.07 |
| | I understand why the stroke of each circle shows through the fill of the other (as the stroke is darker) | 14:58.48 |
| kens | God transparency :-( | 14:59.02 |
| ray_laptop | kens: Robin_Watts: Note it is the 'rand' operator that returns a new random number. rrand is the current 'state' | 14:59.29 |
| kens | Robin_Watts : the two images are blended together, so what's the question ? | 14:59.56 |
| Robin_Watts | kens: The XObject contents are : BlendMode = Multiply. Draw Circle. Draw Circle. | 15:00.48 |
| ray_laptop | Robin_Watts: what alpha setting ? | 15:01.01 |
| | (for each circle) ? | 15:01.13 |
| Robin_Watts | The XObject is invoked in code that looks like: Draw a rectangle. BlendMode = Normal. Invoke the above XObject. | 15:01.31 |
| | ray_laptop: alpha = 1 EVERYWHERE. | 15:01.38 |
| | which is why I don't understand it. | 15:01.46 |
| kens | But multiply says B(cb, cs) = cb * cs | 15:02.05 |
| | So its a simple colour multiply | 15:02.12 |
| Robin_Watts | Right. | 15:02.20 |
| kens | "The result color is always at least as dark as either of the two constituent colors. Multiply-ing any color with black produces black; multiplying with white leaves the original color unchanged. Painting successive overlapping objects with a color other than black or white produces progressively darker colors. " | 15:02.48 |
| Robin_Watts | So I'd expect the net output of the XObject to be something that's either entirely transparent or entirely opaque. | 15:03.01 |
| | i.e. all points within the circles should be solid. | 15:03.24 |
| | all points outside both circles should be entirely opaque. | 15:03.37 |
| kens | 'opaque' and 'solid' are tricky. | 15:03.50 |
| Robin_Watts | why? | 15:04.00 |
| kens | I haven't read the file in detail, but it seems to me that when you draw each image, it is blended with the existing backdrop. | 15:04.08 |
| Robin_Watts | s/opaque/transparent/ | 15:04.13 |
| kens | So when you draw the first circel, it is blended with teh orange stripe. | 15:04.36 |
| | When you draw the second it too blends with the stripe. | 15:04.47 |
| | Whenere it overlies the existing circle it blends with that. | 15:04.56 |
| | Or not ? | 15:05.01 |
| | Maybe I'm missing your point. | 15:05.07 |
| | Actualy, the file says blend mode Normal, not Multiply. | 15:06.02 |
| | brb | 15:06.28 |
| Robin_Watts | D'Oh. Yes. | 15:07.00 |
| | the file uses both Normal and MUltiply. | 15:07.10 |
| kens | There's definitions for all sorts of stuff | 15:07.58 |
| Robin_Watts | yes, it's a cutdown file. | 15:08.11 |
| kens | But the content stream only seems to use normal | 15:08.12 |
| Robin_Watts | The Xobject uses Mult. | 15:08.19 |
| kens | Oh, which one ? | 15:08.30 |
| ab5tract | gar, postscripts rand is painful | 15:08.42 |
| Robin_Watts | The one that's used that isn't Rect :) | 15:08.56 |
| kens | OK object 42 uses multiply | 15:09.01 |
| | G2Y | 15:09.07 |
| | ab5tract : rand isn't generally regarded as useful in printing. | 15:09.20 |
| ab5tract | kens, it is if you are doing generative design | 15:10.03 |
| | i can understand why it is so incapable, its just frustrating | 15:10.20 |
| kens | ab5tract : people usually like theior output to be predictabel | 15:10.25 |
| | Robin_Watts : Still not sure what the problem is. | 15:10.35 |
| Robin_Watts | kens: The problem was with my comprehension. | 15:10.51 |
| | I understand it now, thanks. | 15:10.57 |
| kens | Ah :-) | 15:11.00 |
| ab5tract | kens i'm not arguing that postscript has a strong case for a proper rand function; but on the other hand, if you are going to have one, do it right | 15:11.04 |
| ray_laptop | kens: yes, except for examples/snowflak.ps (one of our customers used that for performance benchmarking -- go figure) | 15:11.20 |
| kens | ab5tract : depends on your definition of 'right', it works, and does what it says on the tin. | 15:11.31 |
| | ray_laptop : I did say 'usually' ;-) | 15:11.42 |
| Robin_Watts | ab5tract: If you want *real* random numbers, use an entropy key. Otherwise you're only ever getting crap pseudo random anyway. | 15:12.13 |
| ab5tract | um, a rand function that produces the same number every time the script is run (and srand is not very helpful here either) absolutely does not do what it says on the tin | 15:12.30 |
| Robin_Watts | In which case you might as well do it using a shift with some taps (which is what Postscript does I believe) | 15:12.38 |
| ray_laptop | ab5tract: since PS is 'extensible' you can just implement your own 'my-rand' proc ;-) | 15:12.40 |
| ab5tract | Robin_Watts, i just need random enough | 15:12.42 |
| Robin_Watts | Then multiply rand by the required range, and you're sorted. | 15:13.00 |
| kens | ab5tract : that's pretty much what the PLRM says it does. | 15:13.03 |
| ray_laptop | ab5tract: you can seed it with 'usertime' and get some variablility, particlularly if you put it after a delay loop like 123456 { 1 pop } repeat | 15:14.21 |
| ab5tract | ray_laptop, thank you very much for the pattern :) | 15:14.53 |
| ray_laptop | ab5tract: or if you can tolerate reading from the 'user', then get the usertime after the user hits the 'enter' key | 15:15.27 |
| ab5tract | ray_laptop, nope its automated. the use case is a generative visual identity | 15:15.50 |
| | with some random and some non-random elements | 15:16.00 |
| ray_laptop | the quality of an automated seed generation is arbitrary, and gs returns the same number for usertime as for realtime, so you may still get some repetition | 15:17.20 |
| | ab5tract: you can get the current system time (for a more unique seed) using the alendar device: e.g., (alendar) currentdevparams dup /Second get exch dup /Minute get exch /Hour get 60 mul add 60 mul add | 15:28.02 |
| | darn, my IRC client ate the C after the % | 15:28.25 |
| kens | alendar ? Not calendar ? Oh right | 15:28.31 |
| ray_laptop | ab5tract: that should be (%Calendar) currentdevparams dup /Second get exch dup /Minute get exch /Hour get 60 mul add 60 mul add | 15:29.07 |
| ab5tract | ray_laptop, thank you very very much! that should be very useful. really appreciate it! | 15:29.32 |
| ray_laptop | ab5tract: you can even extend that to using the /Day /Month and /Year vlaues | 15:29.43 |
| ab5tract | perfect | 15:30.30 |
| ray_laptop | and if you combine that with 'usertime' (millisecond) res values, you can probably get a reasonably random seed | 15:30.33 |
| | Robin_Watts: mvrhel2 is here now, so can help with your transparency questions (at least better than me) | 15:32.43 |
| mvrhel2 | oh. let me go grab something to eat first. brb | 15:33.21 |
| Robin_Watts | mvrhel2: Take your time. | 15:34.36 |
| ab5tract | ray_laptop, intriguingly, i get an undefined in currentdevparams | 15:37.17 |
| | using (Calendar) currentdevparams | 15:37.44 |
| kens | Need a % | 15:37.52 |
| ab5tract | and also (calendar) currentdevparams | 15:37.54 |
| | ah | 15:37.58 |
| ray_laptop | ab5tract: you need % before and after the word Calendar (with upper case C) | 15:38.22 |
| | ab5tract: the trailing % is optional | 15:39.06 |
| | hi, chrisl | 15:39.38 |
| chrisl | hi ray_laptop | 15:39.51 |
| ray_laptop | ab5tract: I don't know how "standard" the %Calendar device is -- I know GS has it, but printers may not have it | 15:40.28 |
| kens | thinks its part of ps3 | 15:40.49 |
| chrisl | It's something like the 3015.x supplement | 15:41.08 |
| ray_laptop | kens: my PLRM 3rd doesn't mention it | 15:41.37 |
| ab5tract | ray_laptop, hmmm. hopefully other interpreters like the microsoft office implementation have it as well (one would hope, 12 years after the standard) | 15:41.50 |
| kens | does not think MS Offcie interprets PostScript | 15:42.13 |
| ab5tract | kens, i know for a fact that it does. at least in 2010 | 15:42.44 |
| kens | I'm surprised. | 15:42.55 |
| ab5tract | it draws randomized eps wonderfully | 15:42.59 |
| kens | But I don't have 2010 | 15:43.02 |
| | Haven't used MS Offcie for years | 15:43.22 |
| ab5tract | me either. its for a client, so we had to make sure the logo would work | 15:43.40 |
| ray_laptop | chrisl: it is mentioned in the 3010 and 3011 supplement I have, so it's been around a while | 15:44.01 |
| kens | Are you sure it works, and doesn't just display the EPS preview ? | 15:44.02 |
| | I suspect MS Office (like most apps) simply draws the preview | 15:44.31 |
| ab5tract | kens, yes. first, we didnt embed a preview. second, they were different every time we embedded them (even in the same document :) | 15:44.31 |
| chrisl | ray_laptop: yes, just found it - I knew it was in a supplement, not in the original LL3 | 15:44.33 |
| kens | ab5tract : Fair enough | 15:44.42 |
| Robin_Watts | ab5tract: So you're producing postscript files that look different everytime they get rendered? | 15:44.51 |
| | So people will see different things when they proof them to when they print them? | 15:45.22 |
| ab5tract | Robin_Watts, that is the idea. since it is branding, some elements remain the same, while others intentionally change | 15:45.23 |
| | yes | 15:45.31 |
| Robin_Watts | And then will get different things everytime they reprint ? | 15:45.42 |
| | fair enough. | 15:45.54 |
| kens | forsees difficulties in trademarks and IP :-) | 15:46.11 |
| ab5tract | for MS Word, supposedly; for Latex, which converts PS to PDF, only if the support files are deleted | 15:46.16 |
| | kens, well if they can patent an algorithm, i suppose we can trademark an approach ;) anyway, its an academic department rather than a company, so hopefully those stresses are less relevant | 15:47.25 |
| kens | can't trademark an algorithm I think | 15:47.41 |
| ab5tract | yeah, only patent :/ (well, at least only in the states for now.. hopefully the EU continues its intelligent approach to software patents) | 15:48.17 |
| kens | Off for a pizza, goodnight all. | 16:01.05 |
| ray_laptop | kens: g'nite | 16:01.25 |
| ab5tract | ray_laptop, thanks again for the help with rand. would love to share the final result with you guys, once its finished :) | 16:09.29 |
| Robin_Watts | mvrhel2: OK, I'm confused again. | 16:19.49 |
| | If you have a few minutes, I'd be grateful. | 16:19.56 |
| mvrhel2 | Robin_Watts: I am back now | 16:24.27 |
| | I have been recruited though to leave in about 15 minutes to help pick strawberries | 16:24.46 |
| | then I will be back in about an hour | 16:24.57 |
| Robin_Watts | ok. http://ghostscript.com/~robin/isolated.pdf | 16:25.03 |
| | That's a simple file that: | 16:25.40 |
| | Draws a rectangle. | 16:25.48 |
| | sets the blend mode toe multiply | 16:25.55 |
| | invokes a non-isolated, non knockout group xobject. | 16:26.13 |
| | That xobject set the blend mode to multiply and draws 2 circles. | 16:26.30 |
| | At the moment mupdf doesn't support non-isolated objects. | 16:26.53 |
| | I thought I had a way to make it do so, but in trying it out, I've got myself horribly confused. | 16:27.09 |
| mvrhel2 | first I would not fool with multiply and knock-out as it can be confusing to see what is going on (at least for me) | 16:27.29 |
| | I would choose normal and knock-out | 16:27.43 |
| Robin_Watts | mvrhel2: Well, what I have works with normal. | 16:27.50 |
| mvrhel2 | ah | 16:27.54 |
| Robin_Watts | We don't support knockout at all. | 16:27.57 |
| | At the moment I'm trying to make non-isolated work. | 16:28.11 |
| | Conceptually, at the beginning of the page, we are drawing into pixmap A. | 16:28.36 |
| mvrhel2 | non-isolated should work as if there is not even a group | 16:28.39 |
| Robin_Watts | There is a group. | 16:29.02 |
| | the Xobject that contains the 2 circles is a group. | 16:29.15 |
| | sorry, "as if", I read that as "as". | 16:29.49 |
| mvrhel2 | hold on . ok so you are just doing non-isolated testing then | 16:29.54 |
| Robin_Watts | Yes. This is a cutdown file that just tests (one of) the cases I don't understand. | 16:30.14 |
| | Can I talk you through what mupdf (and my code) does, and you can tell me when I do something wrong ? | 16:30.33 |
| mvrhel2 | sure | 16:30.45 |
| Robin_Watts | OK. At the beginning of the page we're drawing into pixmap A. | 16:30.57 |
| | (pixmaps = colour + alpha bitmaps) | 16:31.06 |
| | So drawing the rectangle is no problem. | 16:31.15 |
| | When we come to draw the xobject, we create ourselves a new pixmap B. | 16:31.42 |
| | because it's non-isolated, I copy the background from A into B. | 16:32.02 |
| mvrhel2 | that sounds correct | 16:32.39 |
| Robin_Watts | so now I have to draw the first circle into that. | 16:32.44 |
| | we make a new temporary isolated group, which makes us a new pixmap C, that's entirely blank (and transparent). | 16:33.07 |
| | We draw the circle into that. | 16:33.13 |
| | we pop the group, and that blends C back onto B, and we're sorted. | 16:33.33 |
| | That gives the results I expect. | 16:33.49 |
| mvrhel2 | hold on | 16:34.29 |
| Robin_Watts | Then we do the same again for the second circle. We make a new temporary isolated group, which makes us a pixmap D. We draw the circle onto D, pop the group, and that blends D back onto B. | 16:34.34 |
| | holding. | 16:34.43 |
| mvrhel2 | that should work | 16:35.15 |
| Robin_Watts | ok. | 16:35.19 |
| mvrhel2 | well | 16:35.22 |
| | yes that should be ok | 16:35.42 |
| Robin_Watts | Now comes the problem. | 16:35.44 |
| | we close the Xobject group. | 16:35.50 |
| | which means we have blend B back onto A. | 16:36.19 |
| | This gives exactly the results I expect for all the points within the circle. | 16:37.04 |
| | circles | 16:37.09 |
| | but the rectangle is multiplied with itself and so gets darker. | 16:37.25 |
| | http://ghostscript.com/~robin/dump008.png | 16:38.17 |
| mvrhel2 | I see. I believe you may need to maintain a group alpha channel to keep this from happening | 16:39.31 |
| Robin_Watts | Something to embody the idea of "shape" ? | 16:39.55 |
| mvrhel2 | yes | 16:40.09 |
| | Why do you create the temporary isolated groups for every object and not draw directly into B in the above discription? | 16:41.17 |
| | description.. | 16:41.22 |
| | i.e. why the C and D | 16:41.37 |
| Robin_Watts | Because our drawing primitives don't know how to draw and blend. | 16:41.41 |
| mvrhel2 | oh ok | 16:41.57 |
| | you need to make a rect fill that knows how to blend | 16:42.22 |
| Robin_Watts | Our primitives don't all terminate in rect fill. | 16:42.59 |
| mvrhel2 | ok | 16:43.03 |
| Robin_Watts | but yes, I need a way to maintain a parallel alpha channel. | 16:43.27 |
| mvrhel2 | so in gs, we have the possibility of adding a shape plane in the transparency group buffer | 16:45.14 |
| Robin_Watts | Right. | 16:45.25 |
| | I could maybe add a shape plane to the pixmap structure, and only populate it when needed. | 16:45.46 |
| | And get all our drawing primitives to plot to that if it exists first. | 16:46.12 |
| mvrhel2 | in gs during mark_fill_rectangle, the shape and alpha_g and tag plane are checked and accounted for. The values depend upon if the group was isolated/nonisolated knockout/non-knockout and if it was already touched | 16:48.23 |
| ray_laptop | Robin_Watts: gs has a shape plane (optionally) and a group alpha plane (also optional) depending on what is needed | 16:48.25 |
| Robin_Watts | We have the ability to have clip_masks and luminosity masks. I wonder if I can leverage that somehow. | 16:49.27 |
| ray_laptop | Robin_Watts: you can check the logic in gdevp14 to see when gs allocates those | 16:49.58 |
| Robin_Watts | mvrhel2: Thanks for this - it's helped convince me that I'm not miles off base - there is indeed some extra information needed that I don't have. | 16:50.11 |
| mvrhel2 | yes. That is the only way to do this I believe | 16:50.28 |
| | only reasonable way I should say | 16:50.47 |
| chrisl | ray_laptop: from memory(!!) Jaws used the same threshold arrays for 1 bit and 4 bit output (doesn't do 2 bit). I think it then effectively treats each gray value of the 4 bit raster as a separate 1 bit plane each of which gets "halftoned" using that threshold array - you get acceptable results because 4 bit is pretty forgiving (compared to 1 bit). I experimented with 2 bit using the same... | 16:51.49 |
| | ...approach, but never got it working well enough to judge the results. | 16:51.51 |
| ray_laptop | chrisl: this customer (532) has specific requirements for 3 separate threshold arrays for 2 bit. | 16:54.18 |
| | chrisl: and I've looked at extending my 'genpat' stochastic threshold array generator to generate multi-level thresholds as well. Specifically, change some pixels to level 3 before all dots are at level 2, or maybe even level 1, and change some dots to level 2 before all dots are level 1 | 16:56.54 |
| | but in this case the customer has arrays they've used before | 16:57.45 |
| chrisl | ray_laptop: we had a few customers with Jaws that had similar requirements, but they did their own custom stuff, so we didn't have to get involved in it, and they didn't need a "standard" way of defining halftones. | 17:01.34 |
| ray_laptop | chrisl: I want the PS method to define them for testing, and for other customers to be able to use. Doing this has come up before, but just as a query "can you ..." | 17:03.07 |
| chrisl | ray_laptop: personally, I'd be wary about basing it on the length of the data, I've just seen too many cases where apps happily dump loads of extra random data on the end of the "real" on the assumption that the consumer will ignore it. Personally, I'd go for the Type 100 with some suitably cryptic custom entries in the dictionary. | 17:06.42 |
| ray_laptop | chrisl: yes, ken had the same opinion, so that's the way I'll go unless alexcher has some better info (based on knowledge of Adobe, maybe) | 17:07.40 |
| chrisl | ray_laptop: and while I have your attention - a gentle reminder about the info and stuff for the commercial release...... | 17:08.21 |
| ray_laptop | chrisl: the /Vendor /Artifex concept can allow us to pick other key names that aren't too cryptic | 17:08.32 |
| chrisl | ray_laptop: yeh, that looks good - just something other folks won't stumble across too easily by accident. | 17:09.21 |
| ray_laptop | chrisl: OK. I was sort of stalled with making the luratech stuff the default. Have you done the build/configure changes to allow for luratech support ? | 17:09.25 |
| chrisl | ray_laptop: I haven't yet. I wasn't planning on that for this weeks' release (although I was planning to include luratech) - I can probably do it tomorrow if that would be preferred | 17:10.25 |
| ray_laptop | chrisl: since we know it needs to be done, doing it now lets us get the bugs out before the 'real' release | 17:11.10 |
| | chrisl: and the target customer for the oob release uses luratech | 17:11.40 |
| | (but they are only a windows build afaik) | 17:11.53 |
| chrisl | ray_laptop: okay, I'll do it tomorrow. I know what needs done for configure, what about Windows? Do we leave Windows as is? | 17:12.10 |
| ray_laptop | chrisl: I think we need to make luratech the default in both builds. We can just do that as a manual edit as part of the commercial release in the release script. | 17:13.06 |
| | chrisl: similar to what is done for the GPL changes | 17:13.35 |
| chrisl | ray_laptop: I *think* nmake is flexible enough to let us do a conditional setting based on whether the luratech directory exists (as well as force a setting on the command line). I'll look into it. | 17:14.27 |
| gruekeeper | Hi, I'm looking for some help with GS... I'm probably not really in the right place, but anyone know where's good? | 17:14.36 |
| ray_laptop | gruekeeper: actually you probably are in exactly the right place | 17:15.44 |
| gruekeeper | Oh good :) | 17:15.51 |
| ray_laptop | (as long as by "GS" you mean Ghostscript) ;-) | 17:16.17 |
| gruekeeper | (yes, Ghostscript ;) ) | 17:16.24 |
| chrisl | ray_laptop: it seems that Harlequin does do multi-level halftoning, but it seems to be some kind proprietary post process approach. | 17:17.00 |
| gruekeeper | I'm having problems with some PDFs I'm trying to downsample at work - GS seems to want to turn mono tiff images into 8-bit greyscales, and I'm not sure if it's something I'm doing or what... | 17:17.19 |
| ray_laptop | chrisl: yeah, the actual halftoning part is fairly easy as a post process | 17:17.36 |
| | gruekeeper: what -sDEVICE= are you using ? | 17:18.06 |
| gruekeeper | pdfwrite | 17:18.12 |
| ray_laptop | gruekeeper: but GS doesn't read TIFF files directly -- are you using tiff2ps or something ? | 17:18.50 |
| gruekeeper | Ah, no, they're actually page images; old scanned books. | 17:19.23 |
| Robin_Watts | gruekeeper: So you're taking PDFs in, and you want to produce what format out ? | 17:19.23 |
| gruekeeper | Robin_Watts> PDF out too, but smaller. | 17:19.49 |
| Robin_Watts | Ah. And you're upset that gs is taking mono images and turning them into greyscale ones. | 17:20.27 |
| gruekeeper | (I suspect I may be missing some fundamentals somewhere along the way, so forgive me if I seem to talk nonsense at any point :) ) | 17:20.31 |
| ray_laptop | I don't think we can force the output into halftoned CCITT b&w when we downsample | 17:20.35 |
| gruekeeper | Well, I wouldn't say upset. The longer I have to work on this, the less boring work I have to do :) | 17:20.58 |
| | But yes, that's the gist of it. | 17:21.05 |
| Robin_Watts | Essentially, it's the pdfwrite device that you'd like changed then. | 17:21.18 |
| | And our expect for that has gone for the night. | 17:21.37 |
| | s/expect/expert/ | 17:21.49 |
| gruekeeper | So it is actually something hardcoded then? Right. | 17:22.07 |
| | I was puzzled because I've got /MonoImageDepth (or whatever it is) set to -1, which I think ought to leave the bit-depth unchanged. | 17:22.39 |
| | But the output file turns up 8-bit. | 17:22.58 |
| Robin_Watts | Well, if you downsample 1bpp images and try and get 1bpp out you'll lose information. | 17:23.00 |
| ray_laptop | gruekeeper: you can do what you want with a 2-step process. Turn the PDF into a PBM (-sDEVICE=pbmraw) at the desired resolution, then change the PBM back into a PDF using lib/viewpbm.ps | 17:23.26 |
| Robin_Watts | I don't know the pdfwrite switches personally. | 17:23.33 |
| gruekeeper | ray_laptop> That sounds plausible, but these PDFs contain colour images as well, which (according to the spec I'm working to) should come out as jpeg-encoded. | 17:24.30 |
| Robin_Watts | (potentially disastrous loss of information; I'm not sure we have antidropout in the downscalers) | 17:24.36 |
| gruekeeper | Is PBM likely to mess that around? | 17:24.46 |
| Robin_Watts | Yes. | 17:24.51 |
| | Going to PBM will convert the whole page to 1bpp mono. | 17:25.06 |
| gruekeeper | Ah. | 17:25.09 |
| ray_laptop | Robin_Watts: if you force -dDOINTERPOLATE the Special no-droput filter is used | 17:25.31 |
| | it tends to darken halftoned images, but otherwise is reasonable | 17:26.14 |
| gruekeeper | See, the idea is to get the job out of the hands of some outsourced folk who've been wrecking it up left right and centre, but their files have flate-encoded 1-bit tiffs for page images, and 8-bit jpegs for the colour... | 17:26.22 |
| | ...and I can't really believe they're putting that much effort into it :) | 17:26.33 |
| | Maybe I'm going to have to pull the whole file to pieces and reassemble it, then? | 17:27.23 |
| | OK, well thanks for the advice guys :) | 17:36.20 |
| ray_laptop | gruekeeper: you can process the input PDF into different file types (-sDEVICE=pbmraw vs. -sDEVICE=ppmraw) depending on the Image colorspace for each page, writing a list of files to be read into the resulting PDF. | 17:36.57 |
| | oops. I was distracted too long. Hope he knows about the logs. | 17:37.13 |
| chrisl | ray_laptop, Robin_Watts: Given how often this has come up lately (not downsampling image data to 8 bit thru pdfwrite), I wonder if it's something we should consider doing? | 17:37.36 |
| ray_laptop | chrisl: maybe, the loss of image quality could be appalling, so that's one reason we've avoided it, but at least we could make sure Interpolate true was used for the downsampling ;-/ | 17:39.27 |
| chrisl | ray_laptop: I know, but that is the third(?) time the subject has come up this year. I wonder if we could downsample to an 8 bit buffer, and then halftone back to 1 bit. | 17:41.18 |
| ray_laptop | chrisl: downsampling to an 8-bit buffer using the "normal" image center-of-pixel rule would cause dropout. Using grayscale downsampling would turn into 'light gray' pixels which might well disappear as well when halftoned | 17:44.13 |
| | chrisl: if you know the end result is to be 1-bit, then downsampling using the 'Special' rule would be better to avoid dropout (better for scanned text doc) | 17:45.35 |
| | at least vertical and horizontal stems won't drop out | 17:46.13 |
| chrisl | ray_laptop: Sure. What I was thinking was that the cases where this has come up, they are not really halftoned images, they're bilevel scanned images, so for those cases it *might* be possible to get workable results - but I don't know how practical it would be inside GS. | 17:46.50 |
| gruekeeper | ray_laptop> yes I do know about the logs! Thanks for the pointer, I'll look into that :) | 17:48.10 |
| | Cheers! | 17:48.14 |
| ray_laptop | chrisl: exactly -- scanned bi-level documents (or engineering drawings) is where the dropout prevention is needed | 17:48.25 |
| | chrisl: it doesn't do as well as center of pixel rule on halftoned photos since it tends to darken those areas of the image | 17:49.33 |
| | for photos, downsampling to 8-bit using interpolation then re-halftoning is better | 17:50.36 |
| | but it's ugly no matter what (IMHO) | 17:50.57 |
| chrisl | ray_laptop: it would always be one of those "if it works for you, great! If not, see the disclaimers". I just thought it was worth thinking about given how often it seems to be coming up. | 17:50.58 |
| | Anyway, I have to go a try not to lose a squash match..... g'nite! | 17:51.21 |
| ray_laptop | chrisl: this was the first time I saw it. | 17:51.23 |
| | were any of the other queries customers ? | 17:51.35 |
| | chrisl: g-nite | 17:51.43 |
| chrisl | ray_laptop: no customers that I know of, just queries on here - so at best, a low priority. | 17:52.04 |
| ray_laptop | darn. Just spent 1.5 hours doing git bisect (mostly building each time) only to find that the "fix" was making FT_BRIDGE=1 the default. Now have to do it over to see what the "real" fix was :-( | 18:05.02 |
| | well, at least HEAD is OK with FT_BRIDGE=0 -- and 9.00 is BAD. | 18:38.03 |
| ray_laptop | wonders if Marcos does a fuzzy run of FT_BRIDGE=0 vs. =1 ??? | 18:41.01 |
| | it would have to be a fuzzy compare because the edges will be different (most likely) | 18:41.32 |
| Robin_Watts | Bingo. | 19:39.06 |
| | I have problems in the blending routines (edge pixels go all colorful), but the broad strokes are right. | 19:39.34 |
| mvrhel2 | whew. just sat my son down with a copy of K&R and visual studio. that should keep him busy for a bit... | 20:28.26 |
| Robin_Watts | tor8: http://ghostscript.com/~robin/out.png | 23:02.24 |
| | The blending isn't right yet, but it's in the ballpark. | 23:03.07 |
| tor8 | Robin_Watts: ohh... you solved the problems you had earlier today? | 23:03.10 |
| Robin_Watts | Yeah, mvrhel2 put me right. | 23:03.22 |
| tor8 | well, it's certainly an improvement. how many ugly hacks did you have to make? | 23:03.30 |
| Robin_Watts | tor8: The rendering stack now carries a 'shape' pixmap around with it. | 23:03.55 |
| | (created when we enter the first non isolated group) | 23:04.11 |
| | (which I fear means the top page group - need to fix that) | 23:04.27 |
| | Every rendering op now renders to the shape pixmap as well as the destination pixmap. | 23:05.06 |
| | (still need to fix a couple of things, like the image stuff) | 23:05.23 |
| tor8 | sounds expensive, rendering to two targets | 23:18.57 |
| | talk more tomorrow, I'm dead tired now | 23:20.24 |
| ray_droid | robin_watts; you shouldn't need a shape plane at the page level | 23:40.30 |
| ray_droid | is on the cell phone, waiting for the first of 8 harry potter films. | 23:41.58 |
| | 2 per night. newest one Thursday after midnight. | 23:43.08 |
| | Forward 1 day (to 2011/07/12)>>> | |
IRC Logs
