| | <<<Back 1 day (to 2011/10/23) | 2011/10/24 |
| borei | ray_laptop: sure will do | 03:16.19 |
| Robin_Watts | Is the dev color type interface considered external ? | 12:58.42 |
| tkamppeter | kens, hi | 12:59.04 |
| kens | no idea | 12:59.13 |
| Robin_Watts | I can't see it documented in the docs. | 12:59.25 |
| kens | hi tkamppeter | 12:59.58 |
| tkamppeter | kens, I have reported two PS writer bugs, http://bugs.ghostscript.com/show_bug.cgi?id=692624, http://bugs.ghostscript.com/show_bug.cgi?id=692626 in the last days. Can it be that they are the same? | 13:02.23 |
| kens | looks likely | 13:02.51 |
| Robin_Watts | strip_copy_rop is though :( | 13:11.10 |
| | I need to add a new param to it :( | 13:11.25 |
| | Do I really need to fork it? Do we really believe that anyone other than us is stupid enough to have implemented it? Everyone else must just call the default one. | 13:12.07 |
| kens | I very much doubt anyone uses it, but if its publicl.... | 13:43.45 |
| Robin_Watts | yeah. I'm forking it at the moment :( | 13:44.46 |
| kens | :-( | 13:44.58 |
| henrys | I thought we were going to just tell hcl to get a support contract. | 15:03.52 |
| kens | henrys I think we already did. | 15:10.35 |
| | I don't see how that one is our problem though. | 15:10.57 |
| | A PDF file from 'Adobe', a PostScript file created by teh Adobe Windows PostScript driver, don't see GS in there anywhere. | 15:11.27 |
| henrys | I would say just close each bug with "get a contract" don't tell them at all. | 15:12.57 |
| | s/tell them/tell them anything/ | 15:13.35 |
| | seems like the support died down maybe just because of the weekend. | 15:14.00 |
| kens | Its been quieter, and I'm grateful. Actually managed to gget another bug fixed (fingers crossed) | 15:14.32 |
| henrys | alexcher around? | 15:18.36 |
| | chrisl (or maybe kens):I am curious if the type 1 parser in freetype doesn't solve the open problems we have, not to say alexcher's parser won't be fine but I wonder why it wasn't considered as a solution. | 15:26.24 |
| chrisl | henrys: it was - we can't build a PS dictionary from the public API in Freetype, and we agreed using non-public calls/data was asking for trouble | 15:27.46 |
| kens | henrys the problem is that the fonts we are seeing are not valid | 15:28.01 |
| | What Acrobat does is use a non-standard (and very loose, just like all of Acrobat) parser | 15:28.34 |
| | What Alex has been doing is writing something similar that will allow us to construct a valid tyep 1 font from invalid data. | 15:29.16 |
| henrys | chrisl I get that kens that seems like the sort of thing the freetype folks would fix so that shouldn't be an issue. | 15:29.25 |
| kens | henrys, no not really. THe fonts are *really* broken. | 15:30.15 |
| chrisl | I'm pretty sure Freetype's parser is more liberal than using a full PS interpreter, but it doesn't solve the problem that the PDF interpreter, in various ways, relies on being able to access a "real" Postscript font. | 15:30.46 |
| henrys | were these bugs pdf or postscript? | 15:31.47 |
| chrisl | PDF | 15:31.52 |
| kens | They are all PDF. | 15:31.54 |
| chrisl | If the same fonts appear in Postscript, there is no salvation by any means | 15:32.42 |
| kens | And no PostScript itnerpreter will handle them, so we don't have to. | 15:33.06 |
| chrisl | No PS interpreter *can* handle them, because in Postscript, we don't know "up front" we're reading a font - in PS, it's just another dictionary until you do definefont | 15:34.17 |
| henrys | it would be interesting to know if they work with xpdf. | 15:35.40 |
| chrisl | I'm pretty sure the FT interpreter handles at least a couple of the problem font streams, I haven't tried all of them. | 15:37.06 |
| kens | Could try the files with MuPDF | 15:37.47 |
| chrisl | It *might* be possible to handle these cases as sort of "faked up" font dictionaries, similar to how the Microtype fonts work - they look to the PS world just like a normal Type 1 font, but are really "fast tracked" through the FAPI code. | 15:39.51 |
| | henrys: another point is: even if FT's interpreter does handle these, UFST and Bitstream might not, and we'd like the option of only using one scaler at a time (if that's possible/viable) | 15:47.21 |
| henrys | good point. | 15:49.27 |
| | but we have copy pasted in freetype code with fairly good success. If we pulled just the C code we need from freetype brought it in and made some changes would we be further along than alexcher's code? | 15:50.39 |
| kens | Have we seen Alex's code yet ? | 15:51.11 |
| henrys | no I've been nagging him to post it in a public branch or send a tarball to chrisl. | 15:52.00 |
| chrisl | I don't think we've pulled code from FT2, and they have their own stream handling which all the interpreters are heavily dependent upon. I'm not saying it would impossible, but...... | 15:52.21 |
| henrys | right we pulled tt parsing code from ft 1 and it hasn't been very difficult to maintain but this could be a whole different deal as you say about the stream handling. | 15:54.25 |
| chrisl | As I say, if we want to try making use of (initially) FT for that, I'd say doing it with the "fake dictionary" approach would be my choice (it would need several changes in FAPI), and then if UFST/Bitstream fails for these cases, we punt it to them as "works with Freetype" | 15:54.43 |
| henrys | well the bridge can support several scalers right? | 15:55.22 |
| | can we identify these fonts somehow and use ft? | 15:55.50 |
| chrisl | Yes, we could do that. | 15:56.04 |
| | I think the best idea would be try to create the font the "normal" way, and if that fails, then we try the custom, fault tolerant way - it's slower, but only for broken fonts. | 15:57.04 |
| henrys | this all sounds much more appealing than adding new code into the system. We link in all the freetype type 1 parsing anyway, yes? | 15:58.13 |
| kens | Yes, we need it | 15:58.26 |
| chrisl | Yes, we have to. | 15:58.26 |
| henrys | certainly alexcher should weigh in on this approach but I think it sounds like a better deal to me all around. | 15:59.03 |
| chrisl | henrys: so do you want me to investigate it? | 15:59.03 |
| henrys | I'd like alexcher to be on board, I know he has spent some time on it. | 16:00.12 |
| chrisl | henrys: I'd really like to finished the current (nightmare!) round of UFST maintenance - once that's done, I'll have a poke at how viable my idea might be (unless alexcher shouts a "nay") | 16:04.17 |
| henrys | sounds good | 16:04.52 |
| chrisl | I was hoping to be shot of the UFST stuff today, but a certain important customer popped up, and....... | 16:05.43 |
| henrys | I don't know if we can plan on being in the ufst business long - if I were monotype I'd start bundling the font solutions with the pdl's. They now have a pcl and a partnership with adobe. | 16:06.20 |
| chrisl | I doubt they'd cut off that revenue stream - UFST is a decent money maker for them, and a lot of big companies rely on it | 16:07.41 |
| henrys | we'll see. | 16:09.08 |
| kens | Time for me to go, Goodnight all | 16:09.21 |
| chrisl | nite kens | 16:09.39 |
| | henrys: Thing is, UFST is money for old rope for them - I doubt they spend much on developing it now | 16:10.11 |
| henrys | support already sigh | 16:12.59 |
| ray_laptop | morning, kens. I saw the additional crash file. Was that from the same customer ? | 16:19.36 |
| henrys | ray_laptop:kens just left | 16:20.01 |
| chrisl | henrys: I don't *think* the issue in Stefan's mail is clist related, I think it's because the higher resolution means the glyph in uncached - we used to (spuriously) image uncached glyphs in Tr 3 | 16:20.40 |
| ray_laptop | I just noticed. I had started typing the message, but had to plow through my email to see if the file had just come in. | 16:20.46 |
| | henrys: do you know where that file came from ? | 16:20.56 |
| | henrys: bug 692618 file RBR1103673.pdf | 16:21.26 |
| henrys | looking... | 16:22.24 |
| | I just searched my mail for the filename and found it. Do you want me to forward the message to you? | 16:23.05 |
| | Oct 21 problem processing at 400DPI... | 16:23.33 |
| | ray_laptop ^^^ | 16:23.50 |
| | chrisl:is there a simple patch that you know about? | 16:26.53 |
| chrisl | henrys: I was just looking it: the fix that I'm thinking of it is commit 32c054eb2eb15425bbd84c390542b9683cb9eb20 | 16:27.46 |
| ray_laptop | henrys: thanks. I had missed that. I wonder why ken hadn't added the file back then. Rather frustrating to have it show up afterwards :-( | 16:29.51 |
| | guess i must have missed yet another dangling pointer | 16:30.13 |
| henrys | chrisl:thanks I'd like to wait for a test file to be sure though. | 16:30.30 |
| chrisl | henrys: yep, I agree, it's just the likelihood is I'll have finished work when (if) you get the test file, so I wanted to mention it now. | 16:31.11 |
| ray_laptop | mvrhel2: on the non encodable colors issue, it looks like that we _can_ handle the colors when painting into the pdf14 buffers, but then when we 'blend' the transparency stack we create even more colors (11 out of 13 components with non-zero, non-100% values) | 16:33.02 |
| mvrhel2 | that makes sense. it is clear looking at the file in acrobat that there are a lot of levels with different colorants after blending | 16:33.40 |
| ray_laptop | mvrhel2: 5 of the components are 257/65535 -- I'm digging into the source of those to make sure that they shouldn't be zero, but not much hope | 16:36.06 |
| mvrhel2 | Robin_Watts: I just heard back from Marti, he was on vacation. The weird rendering on the one file with lcms 2.2 was a bug. He is going to make sure the fix is in lcms 2.3 which is coming out next month | 16:39.00 |
| Robin_Watts | mvrhel2: Cool. | 16:39.10 |
| mvrhel2 | ok. back to xps/transparency/pattern fun. Almost have this one figured out | 16:41.43 |
| ray_laptop | mvrhel2: it is _so_ close. The data is all there in the pdf14 buffers. The problem is that the pdf14_procs put image is 'pdf14_cmykspot_put_image' which doesn't check if the device has a 'put_image' | 16:44.41 |
| mvrhel2 | oh. | 16:45.19 |
| ray_laptop | mvrhel2: do you want me to go ahead and fix it so I can add a tiffsep_put_image proc that gets all the separations directly (without encoding) ? | 16:45.42 |
| mvrhel2 | so the data is just fine in the buffer | 16:45.44 |
| | ray_laptop: that would be great | 16:45.56 |
| ray_laptop | mvrhel2: I think so. The 'non encodable color' doesn't happen until gx_put_blended_image_cmykspot | 16:46.23 |
| mvrhel2 | ah. it is when we do the final blend with the transparency in the put image | 16:46.43 |
| | ok | 16:46.45 |
| | and reencode | 16:46.53 |
| ray_laptop | mvrhel2: right the final 'pop_device' that is trying to encode for the tiffsep device is the problem | 16:47.27 |
| | note that the gx_put_blended_image_cmykspot is pretty bad anyway. It is doing a 'fill_rectangle' on EVERY pixel to get it to the target device !!! | 16:48.24 |
| mvrhel2 | ray_laptop: yes, if you can add in put_image proc to the tiffsep device then that would be great. transparency with separations is where we have the potential to dramatically increase the number of colors. if we can avoid the decode/blend/encode step that would be great | 16:48.25 |
| | ick | 16:48.43 |
| ray_laptop | mvrhel2: that is putting it politely | 16:49.05 |
| mvrhel2 | ok so we can get a performance boost too | 16:49.09 |
| | I never noticed that before | 16:49.33 |
| ray_laptop | I'm going to shift gears to the other problem (crash) that just surfaced, so I'll be doing the put_image work after | 16:50.10 |
| mvrhel2 | ok. | 16:50.25 |
| Robin_Watts | ray_laptop: Before you dive into that, can I run some stuff past you please? | 16:51.53 |
| | mvrhel2 and henrys may want to listen to this too. | 16:52.21 |
| ray_laptop | Robin_Watts: OK | 16:52.47 |
| Robin_Watts | I think I spotted a glaring problem in the planar stuff today. | 16:53.08 |
| | As ever, it's with the rop source device. | 16:53.22 |
| | That's a device used to do ropping of patterns etc. | 16:53.43 |
| | The pattern is rendered into a tile as usual, and then a device is created with that as a source. | 16:53.58 |
| | When that device is asked to do the usual drawing operations, it passes those operations on to the underlying (target) device to perform them, but combining them with a rop and the source with which the device was created. | 16:55.01 |
| | We now create pattern tiles as planar if the underlying device is planar. This makes plotting patterns much faster in the normal case, but causes all sorts of headaches in the rop device case. | 16:55.54 |
| | In particular, we need to be able to pass planar source data into strip_copy_rop. | 16:56.35 |
| | (We also need to be able to pass planar texture data in, but I've solved that already). | 16:56.53 |
| | I had thought that I could signal the presence of planar source data by setting a bit in the lop field. | 16:57.42 |
| ray_laptop | Robin_Watts: how do you pass the texture in ? | 16:57.49 |
| Robin_Watts | textures are passed in as gx_strip_bitmap | 16:58.29 |
| | and I added a new 'num_planes' field to that. | 16:58.37 |
| | If it's <= 1 then it's treated as chunky. If it's > 1 then the planes are sequentially in memory. | 16:59.13 |
| | ray_laptop: OK ? | 16:59.20 |
| ray_laptop | Robin_Watts: OK. But just to educate me a bit more. textures are a mask (1-bit) and source data has n-bits per component ? | 17:00.09 |
| Robin_Watts | No. | 17:00.22 |
| | Both can be either 1 bit or n bit. | 17:00.28 |
| | There is a 'use_tcolors' flag. If set, that means it's 1 bit data. | 17:00.58 |
| ray_laptop | Robin_Watts: OK. not just a mask. If I had a time machine, I might go and get the guy that thought up the ROP crap so drunk that he would forget all about the idea | 17:01.33 |
| Robin_Watts | the key differences between souce and textures is that 1) textures are specified by a pointer to a structure and 2) textures repeat (tile). | 17:02.14 |
| | ray_laptop: I'd split the bar bill with you. | 17:02.23 |
| ray_laptop | Robin_Watts: thanks for the explanation. sorry for the interruption. Please continue | 17:03.15 |
| Robin_Watts | The problem that dawned on me today, is that the source data has no explicit 'size' passed with it. | 17:03.18 |
| | Hence even if the source data is sequential in memory, I have no way of knowing what the distance from a pixels 0th component to it's 1st component in memory in. | 17:04.12 |
| ray_laptop | Robin_Watts: I thought a pattern has a size (independent of the Xstep Ystep) | 17:04.13 |
| Robin_Watts | s/is/ | 17:04.17 |
| | ray_laptop: Yes. | 17:04.25 |
| | But that's not passed into strip_copy_rop. | 17:04.35 |
| ray_laptop | Robin_Watts: Oh, I see. so it's the use of strip_copy_rop that is 'dropping the ball' (the size info) | 17:05.23 |
| Robin_Watts | Yes. | 17:05.29 |
| | So I've made local changes here to give me 'strip_copy_rop2'. | 17:05.49 |
| | That's identical to strip_copy_rop, except it takes an extra 'planar_height' field. | 17:06.10 |
| | planar_height is the number of scanlines of data between components. | 17:06.25 |
| | So 0 means chunky. | 17:06.35 |
| | And for planar we'd pass size.y as planar_height. | 17:07.24 |
| | With me? | 17:07.40 |
| ray_laptop | Robin_Watts: what is calling strip_copy_rop ? | 17:07.50 |
| Robin_Watts | gdevrops.c (spit) | 17:08.00 |
| | That calls gx_device_color_fill_rectangle with a rop source. | 17:08.30 |
| | which is gx_dc_pattern_fill_rectangle in this case. | 17:09.05 |
| | That then calls strip_copy_rop. | 17:09.23 |
| | I've had to extend gx_rop_source with planar_height too. | 17:09.43 |
| | I've had to extend gx_rop_source_t with planar_height too. | 17:09.47 |
| | I believe there are 2 problem areas left to me. | 17:11.49 |
| henrys | sorry I just got back from "support land" why do you not need the size in chunky and do in planar? I must have missed something. | 17:12.04 |
| Robin_Watts | henrys: We pass: char *sdata, int sourcex, int sraster | 17:12.40 |
| | So we can find all the data we need in chunky terms. We can go from line to line, no problem. And the assumption made by the system is that the caller has always passed you enough data. | 17:13.30 |
| | For planar, we need the additional 'how far from one plane to the next' measurement. | 17:13.56 |
| ray_laptop | Robin_Watts: and you need to know how many 'sraster' amounts to get to the next plane | 17:14.26 |
| Robin_Watts | Exactly. | 17:14.31 |
| henrys | hmm but that's implicit in the "color_info" for the device? | 17:15.43 |
| Robin_Watts | henrys: For 'D' yes. | 17:15.44 |
| | dev->height | 17:15.44 |
| | But for 'S' ? | 17:15.44 |
| henrys | the data should already be scaled. | 17:15.44 |
| ray_laptop | henrys: strip_copy_rop doesn't get the pattern 'pdevc' | 17:15.44 |
| | it's only available at the caller 'gx_dc_pattern_fill_rectangle' | 17:16.20 |
| Robin_Watts | henrys: If I am plotting a 50x50 pattern into a banding device that happens to have a band height of 3000, then mdev->height == 3000. | 17:16.27 |
| | but the pattern tiles data is only 50 in height. | 17:16.43 |
| ray_laptop | Robin_Watts: right. and you need the '50' | 17:17.36 |
| henrys | okay I see. | 17:17.50 |
| Robin_Watts | So, problems left to me... | 17:18.18 |
| ray_laptop | thinks it is time to duck | 17:18.36 |
| Robin_Watts | 1) I need to sort out mem_strip_copy_rop so that when it does gx_getbits_copy (or whatever it is) it uses plane_height, not mdev->height | 17:19.08 |
| henrys | well sort of you aren't plotting a 50x50 pattern you are tiling space with a bitmap already in device space? | 17:19.12 |
| | aren't yoiu? | 17:19.16 |
| Robin_Watts | 50x50 was in device space. | 17:19.30 |
| | Sorry, let me rephrase; I was meaning that my pattern tile was 50x50 in device space. | 17:20.18 |
| henrys | thanks | 17:20.28 |
| Robin_Watts | I believe that 1) should work out OK. | 17:20.52 |
| | (but until I actually finish it and test it, who knows...) | 17:21.08 |
| | 2) is more worrying to me; how do I sent this through the clist? | 17:21.27 |
| ray_laptop | didn't have network problems soon enough ;-) | 17:21.56 |
| Robin_Watts | Until now, whenever I've had data to put planar data through the clist, I've always just tweaked the calls to cmd_put_bits to send an (x, y * planar_height) bitmap. | 17:22.30 |
| | Sorry. | 17:23.05 |
| | Make that an (x, y * num_planes) bitmap. | 17:23.13 |
| | Now, I have to send (x, y) * num_planes bitmaps (because we might not be sending the full width/height each time. | 17:24.43 |
| mvrhel2 | bbiaw | 17:26.32 |
| Robin_Watts | actually, maybe that's not as terrifying as I'd feared. | 17:26.47 |
| | I can just do n calls to cmd_put_bits,right? being careful with the RECT_RECOVER stuff. | 17:27.10 |
| ray_laptop | Robin_Watts: wait a minute. The texture bitmap has a size.y doesn't it ? | 17:27.16 |
| Robin_Watts | It does. | 17:27.23 |
| ray_laptop | isn't that enough ? The source and the texture have to be the same size, don't they ? | 17:27.48 |
| Robin_Watts | No. | 17:27.55 |
| | Typically source is much bigger, and the texture 'tiles' into it. | 17:28.18 |
| ray_laptop | Robin_Watts: oh, that's right. You said the texture tiles (repeats) over the source area | 17:28.32 |
| | sorry. | 17:28.39 |
| Robin_Watts | np. | 17:28.58 |
| | As ever, explaining this stuff has helped to clarify it in my mind, I think. | 17:30.03 |
| ray_laptop | Robin_Watts: the RECT_RECOVER stuff is such a mess that I've never "bitten the bullet" and ripped it out | 17:30.08 |
| Robin_Watts | I'll keep bashing for a while; as long as no one can see any obviously stupid decisions I've made so far? | 17:30.34 |
| ray_laptop | but it TOTALLY doesn't work with non-idempotent color rops or with transparency | 17:30.45 |
| Robin_Watts | ray_laptop: I may come crawling back to you for clist help. | 17:30.49 |
| | I have no idea what it does. | 17:30.58 |
| ray_laptop | Robin_Watts: np. The approach seems to make sense (as much as rops ever made any sense) | 17:31.16 |
| Robin_Watts | I thought it was to cope with running out of memory ? and recovering some and then trying again ? | 17:31.19 |
| henrys | so the clist patterns could be used with a non trivial rop and all this goes away or are there also non banding issues? | 17:31.49 |
| Robin_Watts | Non banding too. | 17:32.08 |
| | The basic problem is that strip_copy_rop cannot cope with planar source data. | 17:32.33 |
| ray_laptop | Robin_Watts: what is supposed to do is a allow a partial clist to be rendered, tucked away somewhere in (compressed) raster form, then continue loading the clist with more info. But if the rendering goes from contone to halftoned ... the 'destination' data is lost | 17:32.49 |
| Robin_Watts | So either I need to ensure we never call it with planar source data (which is at odds with our decision to keep patterns in planar form for a planar device), or I need to extend it. | 17:33.05 |
| ray_laptop | It was implemented by a consultant without consultation with anybody (like Peter) for a customer that evaporated | 17:33.58 |
| henrys | I should study the code because I'm probably asking stupid stuff but I don't see how the source size is not known there must be a clipping region right? | 17:33.59 |
| Robin_Watts | ray_laptop: I propose to encode all strip_copy_rop's in the clist as strip_copy_rop2's with a 0 planar_height. | 17:34.01 |
| ray_laptop | Robin_Watts: that would be OK with me. | 17:34.27 |
| Robin_Watts | henrys: http://www.ghostscript.com/doc/current/Drivers.htm#Compositing | 17:35.30 |
| ray_laptop | the extra 32-bit value per strip_copy_rop call won't be a killer, I don't think | 17:35.31 |
| Robin_Watts | see the 'strip_copy_rop' docs there. | 17:35.53 |
| | The parameters to that function, plus the device settings are all I have to work with. | 17:36.21 |
| | Where do you think I can get source size (specifically the source height) from ? | 17:36.45 |
| | There is no guarantee that the source fills the height. | 17:37.06 |
| ray_laptop | Robin_Watts: you have the guarantee that there is ENOUGH source for the height, but the source height may be > than the height, right ? | 17:39.16 |
| Robin_Watts | yes. | 17:39.25 |
| | sorry, yes. I have no guarantee that the source fills the dev->height, but I am guaranteed that the height of this particular strip_copy_rop is <= the height of the source. | 17:40.15 |
| ray_laptop | Robin_Watts: right, and if you have a pattern that is 500x600 and a band that is only 50 lines the source height may even be > than dev->height | 17:41.53 |
| Robin_Watts | yes. | 17:42.05 |
| ray_laptop | basically you need the size.y for the source. I understand | 17:42.19 |
| henrys | I'm back to not understanding why it doesn't work in chunky unless source height is 1 and this always works on a single line | 17:42.22 |
| Robin_Watts | henrys: For chunky, we never need to go from one plane to the next - as there is only one plane. | 17:42.52 |
| ray_laptop | henrys: it works in chunky because each line of sraster has all the components | 17:43.02 |
| henrys | I see that it would work if the height were 1 I don't see how you you would call the routine with height > 1 | 17:44.19 |
| Robin_Watts | henrys: Why not? | 17:44.37 |
| | if sdata[0] gives you the 0th pixel on the 0th line, sdata[sraster] gives you the 0th pixel on the 1st line. | 17:45.05 |
| henrys | yes and when do you stop? | 17:45.34 |
| Robin_Watts | You have all the data you need to navigate a chunky bitmap. | 17:45.34 |
| | strip_copy_rop has a 'width' and a 'height' for the rop you're doing. | 17:45.57 |
| | And it's the callers job to ensure that source is 'big enough' to cope with that. | 17:46.16 |
| ray_laptop | Robin_Watts: ping me if you need me. Off to look at the crash | 17:46.30 |
| Robin_Watts | The problem is that source may be (and indeed often is) bigger than that. | 17:46.49 |
| | ray_laptop: Thanks. | 17:46.53 |
| henrys | so you have more information than the parameter list? | 17:47.20 |
| Robin_Watts | Imagine I have a 50x50 pattern tile, and a call to strip_copy_rop to plot a 3x2 area from the middle of it. | 17:47.22 |
| | No. | 17:47.28 |
| | int (*strip_copy_rop)(gx_device *dev, const byte *sdata, int sourcex, uint sraster, gx_bitmap_id id, const gx_color_index *scolors, const gx_strip_bitmap *texture, const gx_color_index *tcolors, int x, int y, int width, int height, int phase_x, int phase_y, int command) | 17:47.44 |
| | x,y,width,height is the position/dimensions of the rop. | 17:48.07 |
| | phase_x, phase_y apply to the phase of the texture. | 17:48.21 |
| | texture/tcolors give you the texture data. | 17:48.32 |
| henrys | I see I thought width and height were to do with the texture | 17:48.43 |
| Robin_Watts | Ah, no. | 17:48.52 |
| | texture->size.{x,y} are the texture sizes. | 17:49.04 |
| | (what a wonderfully orthogonal interface this isn't.) | 17:49.30 |
| henrys | so now we have sourcex, source width and source height and sraster - everything you need ;-) | 17:49.53 |
| | still lost sigh | 17:50.00 |
| Robin_Watts | The source as it stands has sdata, sourcex, and sraster. | 17:50.35 |
| | sraster is related to the width, but not strongly enough to be useful - but thankfully I don't need the width. | 17:51.03 |
| | I haven't got the source height at all. | 17:51.22 |
| | All I know is that source_height >= height | 17:51.40 |
| henrys | and why do need to access anymore than what is given by the height? | 17:53.16 |
| Robin_Watts | sdata points to the 0th components value in the 0th pixel of the 0th line. | 17:54.07 |
| | sraster lets me get to the 0th components value in the 0th pixel of the 1st line. | 17:54.35 |
| | The color information lets me get to the 0th components value in the 1st pixel of the 0th line. | 17:55.05 |
| | Nothing let's me get to the 1st components value in the 0th pixel of the 0th line. | 17:55.25 |
| | s/let's/lets/ | 17:55.36 |
| | The zeroth planes data is pointed to by sdata. The first planes data is pointed to by &sdata[sraster * planar_height] (but I don't have planar_height currently) | 17:56.49 |
| henrys | that's the piece I don't understand I thought sdata + n * sraster was component color n. | 17:59.03 |
| Robin_Watts | No, that's line n. | 17:59.15 |
| | For ghostscripts *internal* planar data, we always have all the plane 0 data, then all the plane 1 data, then all the plane 2 data... etc. | 18:00.14 |
| henrys | well alright but the plane data is divided up equally in each of of those. | 18:00.16 |
| | each of those lines. | 18:00.31 |
| Robin_Watts | No. | 18:00.37 |
| | For plib (PLanar Interlaced Buffer) the final image ends up in 000...111...222......000...111...222......000...111...222......000...111...222......000...111...222...... form | 18:01.25 |
| | But that's only the very final buffer. | 18:01.37 |
| | For the plan devices (and all the internal planar buffers gs ever holds) we hold the data in 000...000...000......111...111...111......222...222...222...... format | 18:02.22 |
| | (did that make any sense? I'm inventing notation on the fly here :( ) | 18:02.50 |
| henrys | that information needs to be reflected in color info and available to the devices right? | 18:03.16 |
| Robin_Watts | No. | 18:03.29 |
| | Well, as far as everything internal to gs is concerned it always expects data to be plane 0, followed by plane 1, followed by plane 2. | 18:04.27 |
| | The sole exception to that is the plib device which has a special device opening proc that changes the line_ptrs for the final buffer to be planar interleaved by line. | 18:05.11 |
| henrys | and in that particular situation you can calculate where the first component begins right? | 18:05.13 |
| Robin_Watts | In neither case can I calculate where the first component begins. | 18:05.34 |
| | (well, OK, in the planar interleaved case I could probably calculate it, but it'd be hairy) | 18:05.57 |
| | My proposed extension to strip_copy_rop (passing planar_height) will NOT cope with planar interleaved buffers, but that's OK, it never needs to. | 18:06.55 |
| ray_laptop | can git blame give me the blame before a certain commit or date ? | 18:09.19 |
| Robin_Watts | ray_laptop: yes. | 18:09.43 |
| | git blame HASH will give you the blame before and including a given hash | 18:10.03 |
| | git blame HASH~1 will give you what you probably want :) | 18:10.28 |
| ray_laptop | Robin_Watts: thanks. I missed that in all the list of options (rev) | 18:11.03 |
| henrys | Robin_Watts:when is the n'th plane not at base + (sraster / bpc) * n | 18:13.54 |
| Robin_Watts | henrys: a) whenever we're not in planar interlaced format (i.e. all the time :) ) | 18:15.08 |
| | henrys: b) whenever we're not in planar interlaced format (i.e. all the time :) ) | 18:15.53 |
| ray_laptop | now why the heck would lars put a call in 'tiff_open' to: gdev_prn_allocate_memory(pdev, NULL, 0, 0); YUCK. It confuses the logic for pdf14 transparency buffer size | 18:15.57 |
| Robin_Watts | I know that a == b, but it's such a large case I thought it was worth mentioning twice </Red Dwarf> | 18:16.14 |
| | (Sorry, I originally had a different 'b' in mind :) ) | 18:16.47 |
| | I have to walk the dogs to the shop and back. back in 30 mins or so, sorry. | 18:18.22 |
| henrys | okay | 18:19.05 |
| ray_laptop | mvrhel2: the ESTIMATED_PDF14_ROW_SPACE doesn't seem good if we have lots of spot colors (as the files with bug 692618 do) | 18:21.41 |
| henrys | Robin_Watts:I thought the source would always be in ghostscript internal planar format - certainly the destination will not. | 18:24.04 |
| ray_laptop | mvrhel2: would you mind if I changed it to something like: (NUM_PDF14_BUFFERS * ESTIMATED_PDF14_ROW_SIZE(width)) + (width * BITS_PER_CHANNEL * (color_info->num_components + NUM_ALPHA_CHANNELS) ) | 18:27.25 |
| | mvrhel2: possibly with reducing NUM_PDF14_BUFFERS by one, but maybe not since we want to be conservative | 18:28.18 |
| | I'm assuming that getting the actual color spaces and stack depth during our initial 'page_has_transparency' scan would be too difficult | 18:30.06 |
| Robin_Watts | henrys: Ghostscripts internal planar format is plane then plane then plane. not line then line then line. | 18:48.11 |
| | That is: Plane0Line0, Plane0Line1, Plane0Line2... Plane1Line0, Plane1Line1, Plane1Line2,... Plane2Line0,Plane2Line1, Plane2Line2,... | 18:56.19 |
| ray_laptop | Robin_Watts: I suppose in retrospect, line interleaved planar would have avoided this particular issue and probably still would have been as efficient | 18:58.48 |
| Robin_Watts | ray_laptop: Yes and no. | 18:59.09 |
| | line interleaved planar is less condusive to doing differing numbers of bits in each component, I suspect (not that gs can cope with that!) | 18:59.50 |
| | but line interleaved planar or not was Peters choice, not mine. | 19:00.11 |
| | For operations a plane at a time (like drawing etc), line interleaved planar would be worse for the cache. | 19:01.33 |
| | For operations that operate on all planes at once (like rops) line interleaved planar would be better. | 19:01.58 |
| | I *hope* that rops are rarer than non rops. | 19:02.07 |
| ray_laptop | is "that close" to closing 692600 (out of frustration) | 19:08.28 |
| Robin_Watts | henrys: Does your silence indicate that you're in agreement now, or merely that you've been distracted by other more pressing things? | 19:10.04 |
| henrys | sorry I was on the phone but yes I am finally in agreement now. | 19:10.45 |
| Robin_Watts | cool. | 19:10.58 |
| henrys | bbiab lunch | 19:11.54 |
| Robin_Watts | ray_laptop: You here ? | 19:49.41 |
| ray_laptop | Robin_Watts: got your email. I'll have a look at the changes and reply later (assuming that you aren't working anymore until your morning) | 20:48.28 |
| Robin_Watts | ray_laptop: (For the logs) Thanks. | 22:56.55 |
| | Forward 1 day (to 2011/10/25)>>> | |
IRC Logs