| | <<<Back 1 day (to 2013/10/13) | 2013/10/14 |
| sebras2 | good morning! | 01:17.50 |
| | Robin_Watts: Amr_ seemed to be eager to get someone to look at his bug, but I'm not sure I get your comment. :) | 01:19.39 |
| kens | henrys (for the logs) conditional breakpoints are not terribly slow in VS. However I have found that on an Intel chip if you exceed some number of hardware breakpoints supported by the processor *all* breakpoints cause VS to execute incredibly slowly. | 07:05.06 |
| paulgardiner | kens: Interesting. I didn't know there was on-chip support. I thought debuggers had to overwrite at each point with a software interrupt instruction. | 07:08.38 |
| kens | sebras2, Robin's comment in the bug report was because Amr had altered the severity field to 'critical' which Robin reverted to 'Normal' and posted teh comment. It would be nice if could stop people meddling with those fields..... | 07:10.50 |
| | paulgardiner : there's hardware breakpoitn support, AIUI for conditional breakpoints VS issues a hardware breakpoint, and tehn evaluates the condition on each break | 07:11.32 |
| sebras2 | kens: oh. that wasn't very obvious. :) | 07:12.15 |
| kens | But this is going back a few years, it might have changed. I no oonger try to keep up with Intel's ever more baroque chippery | 07:12.19 |
| sebras2 | kens: but yeah, only some users ought to be able to alter certain fields after the bug has been field. | 07:12.50 |
| paulgardiner | kens: my knowledge of it is nonexistant. I just always assumed it worked the other way. | 07:13.37 |
| kens | sebras2 : it happens a lot, people change the severity to match *their* perception of the problem. or change the prioiryt (always to P1) because they think it'll affect how we address it. | 07:13.50 |
| | paulgardiner : the 'int 11' (I think it was 11) software breakpoint is how it always used to work, and I belive that when you have too many breakpoints set, so you have exhausted the hardware breakpoints, that's what the debugger falls back to | 07:15.04 |
| | Which is why it gets a lot slower | 07:15.18 |
| paulgardiner | Ah right. Makes sense. | 07:15.31 |
| kens | Ah apparently intel x86 CPUs support up to 4 hardware breakpoints | 07:16.34 |
| sebras2 | kens: annoying. :-P | 07:27.07 |
| | brb | 07:27.10 |
| kens | Robin_Watts : ping | 08:46.15 |
| kens | coffees | 08:52.58 |
| Robin_Watts | kens: pong. | 08:54.46 |
| | but I'm about to head out to take Helen to the station. Will ping you back as soon as I return. | 08:55.05 |
| kens | OK | 08:59.41 |
| Robin_Watts | kens: I have 2 mins before I have to go... | 09:05.37 |
| kens | Robin_Watts : I'll wait til you get back | 09:05.49 |
| Robin_Watts | ok | 09:05.54 |
| kens | no rush | 09:05.56 |
| sebras2 | tor7: morning. | 09:35.48 |
| tor7 | hi sebras2 | 09:35.57 |
| | recovered from your bout of food poisoning? | 09:36.17 |
| Robin_Watts | kens: back. | 10:06.03 |
| kens | Hi Robin_Watts | 10:06.16 |
| | THe bug is number 691178 | 10:06.24 |
| | There are 2 files attached to that (by me) | 10:06.34 |
| | Its probably worthwhile grabbing them | 10:06.45 |
| Robin_Watts | fill_adjust problem? | 10:07.03 |
| kens | The problem is not what Alex described it as at all, no its a clipping problem I think bt it might be related. | 10:07.18 |
| | THe problem occurs (I believe) in gxidata.c, gx_image1_plane_data, around line 613 | 10:08.04 |
| | sorry 163 | 10:08.10 |
| | The image data is being clipped out. | 10:08.22 |
| | However, this is code I don't understand, not even slightly | 10:08.44 |
| | If I hack penum->hci to be non-zero, then the failing case works. | 10:09.11 |
| Robin_Watts | kens: Let me have a look. | 10:09.19 |
| kens | Yep, thought you woudl want to try running it | 10:09.29 |
| Robin_Watts | This will take a while. Need to rebuild. | 10:10.14 |
| kens | POK let me know | 10:10.23 |
| Robin_Watts | Still building... I clicked Build SOlution rather than Build Ghostscript. | 10:23.39 |
| kens | :-) | 10:23.44 |
| Robin_Watts | ok, built. | 10:27.53 |
| kens | righto | 10:28.03 |
| | probably best if you run through with the 'failing' file | 10:28.28 |
| | break around line 147 in gxidata.c | 10:28.51 |
| Robin_Watts | both fails and works give the same output as far as I can see. | 10:29.14 |
| | 300dpi tiff ,right? | 10:29.22 |
| kens | What are you using for a device ? | 10:29.25 |
| Robin_Watts | tiff24nc | 10:29.31 |
| kens | 300 dpi tiff fails for me | 10:29.35 |
| | you get a cyan fill, no image | 10:29.43 |
| Robin_Watts | ok, sorry, yes. | 10:29.49 |
| kens | You may need to zoom in to see the image | 10:29.52 |
| Robin_Watts | dunno what happened there. | 10:29.54 |
| kens | is relieved | 10:30.09 |
| | the problem is that in the fialing case the image is clipped out | 10:30.23 |
| | the files differ only in the pattern Matrix | 10:30.37 |
| Robin_Watts | OK, png device works too. | 10:30.52 |
| kens | display device works also | 10:30.59 |
| | I don't know why | 10:31.04 |
| Robin_Watts | Let me just shrink the pagesize a bit so I don't always have to zoom and scale. | 10:31.05 |
| kens | You can remove the blakc rectangle too | 10:31.23 |
| | It was just tehre so I knew I didn't have a totally blank page | 10:31.36 |
| Robin_Watts | Oh, there is a rotation too. | 10:32.33 |
| kens | THat's part of the problem | 10:32.41 |
| | I believe anyway. I suspect if you remove it the problem will go away | 10:33.01 |
| | The original file was 3 pages, first two portrait, third landscape | 10:33.27 |
| Robin_Watts | ok, so I'm at the breakpoint you said. | 10:36.56 |
| kens | right | 10:37.01 |
| | If this is the tiff device then yn becomes 128 from dda_current | 10:37.28 |
| Robin_Watts | png, but I get yn=128 too. | 10:37.52 |
| kens | pngdoes hte same, for diaply device its 1024 | 10:38.02 |
| | lower down thre is penum->hci = fixed2intpixround_perfect(yn) and that comes out as 0 | 10:38.29 |
| | Amd that's the problem | 10:38.34 |
| | I don't believe it should be 0 | 10:38.51 |
| | But its a hideous collection of macros and special numebrs with no explanations | 10:39.07 |
| Robin_Watts | ok. I'll have to dig through the code for a bit to figure out what hci/yci are :) | 10:39.43 |
| kens | Yeah I thought that, I can't offere any illumination, its not code I know, and I'm puzzled by the whiole lot | 10:40.03 |
| | But its the fact the we jump out to 'mt' that causes the problem, it seems like we are clipping the image | 10:40.35 |
| | Given that the image is, I htink, a single row, clipping it makes the image disappear | 10:40.55 |
| | I know its a ridiculous way to do a fpattern fill, but that's MS Office for you | 10:41.16 |
| | FWIW in hte case with the modified matrix, yn comes out as 133 and penum->hci becomes 1, so the row is rendered | 10:42.12 |
| Robin_Watts | yci = Integer y of row, hci = Integer height of row. | 10:44.39 |
| kens | OK | 10:44.50 |
| | So the scaling reduces the height to something greater than 0 but less than something | 10:45.17 |
| Robin_Watts | so, the calculation is figuring out if the image of the row in destination space covers the centre of a pixel. | 10:45.44 |
| kens | After clipping I assume | 10:45.58 |
| | Since this is a clip calculation | 10:46.10 |
| Robin_Watts | We're working in 8 bit accuracy here, so pixels run from 0 to 255. | 10:46.17 |
| kens | so where is the centre ? | 10:46.41 |
| | 128 ? | 10:46.46 |
| Robin_Watts | and the row here should fill from [0..128) | 10:46.58 |
| | hence 128, the centre, is not covered by the image. | 10:47.17 |
| | so stuff doesn't get filled. | 10:47.23 |
| kens | Well,I think its incorrect | 10:47.30 |
| | Acrobat renders it at all resolutions, and changing the Matrix so that teh pattern fill is ever so slightly larger makes it work too | 10:48.06 |
| Robin_Watts | I think it's valid that this repeat of the row doesn't get displayed. but the next one should. | 10:48.31 |
| | clearly there is something wrong. | 10:48.42 |
| kens | Well it does draw the next row, or at least it goes off to the rendering routines. | 10:49.06 |
| Robin_Watts | kens: But the problem is that the image only contains content in the top row or something? | 10:50.34 |
| kens | Robin_Watts : its possible but I don't think so | 10:50.47 |
| | Let me look at the image data in the PDF | 10:51.01 |
| paulgardiner | tor7: ping | 10:51.36 |
| kens | Hmm, its an imagemask, so 1bpp | 10:51.40 |
| | and its defined as 8x8, so that's 8 bytes of data | 10:51.55 |
| Robin_Watts | second line is 8 lots of 255. | 10:52.14 |
| kens | COuld be its all 0 | 10:52.25 |
| tor7 | paulgardiner: pong. | 10:53.00 |
| Robin_Watts | tor7: Did the lappy arrive? | 10:53.13 |
| kens | 3rd line is 0xF3 so that's not all emopty | 10:53.27 |
| tor7 | Robin_Watts: not yet :( | 10:53.29 |
| kens | Looks like alternate lines are not empty, even ones are | 10:53.47 |
| tor7 | Robin_Watts: should be here this afternoon or tomorrow, it arrived in malmo friday night | 10:53.58 |
| Robin_Watts | tor7:Ah, you've been tracking it. I was about to try. | 10:54.13 |
| tor7 | oct 11th, forwarded to delivery depot is the last item on the tracker | 10:54.41 |
| kens | first line is 2 bits one, 6 off, then 8 off, then 6 on 2 off, then 8 off, repeat for next 4 lines | 10:54.42 |
| paulgardiner | tor7: In MuPageViewNormal.loadTile, before recreating tileView, there is an assignment "tileFrame = CGRectZero". Can you recall/reconstruct the purpose of that? | 10:55.17 |
| kens | ah on line 3 yci is 1, but hci is 0 | 10:55.34 |
| Robin_Watts | kens: So, I think we're rendering alternate lines from the pattern. | 10:55.46 |
| kens | Robin_Watts : yes, exactly | 10:55.54 |
| Robin_Watts | i.e. we happen to be at the stage where the pattern fits exactly 2 lines of pattern to 1 line of screen raster. | 10:56.11 |
| kens | Yes, seems to be the case. | 10:56.22 |
| Robin_Watts | According to postscript plotting rules we have to pick a line to use. | 10:56.22 |
| kens | WHich is more or less what Alex said | 10:56.30 |
| Robin_Watts | And we happen to be picking the empty one. | 10:56.32 |
| | tor7: When are you off on holiday? | 10:57.25 |
| kens | OK I can get exactly the same effect in Acrobat by turing off smoothing and zooming to 138% | 10:57.39 |
| tor7 | Robin_Watts: next week | 10:57.42 |
| kens | So I'mgoing to close this bug | 10:57.44 |
| Robin_Watts | ok, so should be there beforehand. | 10:57.49 |
| | kens: cool. | 10:57.51 |
| | tor7: Have you ordered a 128Gig SD card to go with it yet? :) | 10:58.15 |
| tor7 | Robin_Watts: I'm about to :) | 10:58.35 |
| Robin_Watts | The SD slot will take either SD or... what's the other one? | 10:58.57 |
| | You may want to pick the one that sticks out least :) | 10:59.08 |
| tor7 | will be easier to dual boot from an sd-card I reckon, and not risk wiping the laptop if someone boots it and hits "Yes" to the "Do you want to exit developer mode" warning. | 10:59.15 |
| Robin_Watts | MMC card = shorter sd card. I wonder how big MMC cards come. | 11:00.25 |
| tor7 | MMC is obsoleted by SD-cards | 11:02.30 |
| | IIRC | 11:02.34 |
| | same form factor. but there may be some shorter variant of SD-cards | 11:02.52 |
| Robin_Watts | I thought an MMC card was the shorter version. | 11:03.08 |
| tor7 | you can hardly buy MMC anymore. | 11:03.28 |
| | the biggest MMC I can find is 2G | 11:03.51 |
| Robin_Watts | yeah, you're right. MMC are thinner, but that's it. | 11:04.29 |
| | 128Gig SDs seem to be the best bet at the moment. You can get 256Gig, but they are stupid prices. | 11:04.55 |
| tor7 | paulgardiner: I'm sorry, I have no idea. I'm looking at it and nothing is coming back to me... | 11:05.48 |
| Robin_Watts | What you need is: | 11:05.51 |
| | http://www.kickstarter.com/projects/1342319572/the-nifty-minidrive | 11:05.57 |
| paulgardiner | tor7: Okay. I guess after removing it I'll find out. :-) | 11:06.36 |
| Robin_Watts | tor7: http://www.amazon.com/MiniDrive-microSD-Adaptor-MacBook-Retina/dp/B00AL1385C | 11:09.31 |
| tor7 | Robin_Watts: http://www.jdhodges.com/wp-content/uploads/2013/07/P7120644-google-pixel-sd-card-inserts-fully.jpg looks like it may not even be necessary | 11:10.55 |
| Robin_Watts | tor7: Ah, perfect! | 11:11.13 |
| | I am really looking forward to seeing it in Hawaii. | 11:11.47 |
| | Someone must put that screen in a properly powered laptop at some point, right? | 11:12.26 |
| | tor7: So, I'm gradually running through the FTS files, doing my best to make the svg output of mupdf work with them. | 11:17.02 |
| | and I've reached 09_0924 which deals with TK. | 11:17.24 |
| | Is that what the 'accumulate' thing is about with text objects ? | 11:17.55 |
| tor7 | Robin_Watts: I hope so. you can get similar screens, but not 3:2 aspect ratio, on the zenbook UX301 | 11:18.59 |
| | the 'accumulate' is for clipped text that is one text object in pdf but uses multiple fonts | 11:19.34 |
| | which need to be split to separate fz_text objects | 11:19.51 |
| | (or even multiple font sizes, since the matrix abcd coefficients are also fixed in the fz_text) | 11:20.16 |
| Robin_Watts | tor7: Right, but by "properly powered" I mean a machine with a bit more heft than that. | 11:20.46 |
| tor7 | it may be easier to rip out the 'accumulate' flag and enhance the fz_text object to be a list of text chunks | 11:20.50 |
| Robin_Watts | Thin and light is lovely etc, but I want at least 8 hours battery life. | 11:21.05 |
| | OK, so how do we handle TK? | 11:21.20 |
| tor7 | Robin_Watts: oh, right. yeah. well, the UX301 is Haswell, so it's probably better than the current gen. | 11:21.36 |
| | Robin_Watts: I don't know if we handle TK... | 11:23.06 |
| | I suspect we don't because I've never implemented anything with knockouts myself :) | 11:23.24 |
| Robin_Watts | Render fts_09_0924.pdf to png and we give the right results :) | 11:23.39 |
| | Ok, we definitely look at TK. | 11:37.57 |
| | but I can't see how :( | 11:39.36 |
| | ok, wait... we don't. | 11:40.29 |
| | The test file is broken. | 11:41.21 |
| sebras2 | Robin_Watts: were you thinking of RS-MMC? what about uSD? they are pretty tiny..? | 11:57.14 |
| | not sure what you'd be using it for, but anyway... | 11:57.23 |
| Robin_Watts | sebras2: This is for tor7's shiny new chromebook. | 11:57.41 |
| | It looks lovely, but it only has 32Gig of storage on board. | 11:57.53 |
| sebras2 | Robin_Watts: oh. I managed to confuse your nicks at the beginning of the conversation. :) | 11:58.06 |
| Robin_Watts | but it has an SD card slot, so you'd probably want to put as much storage in there as you can. | 11:58.19 |
| | but having an SD card sticking out of the side is a pain, so I was suggesting a solution to that. | 11:58.40 |
| | BUT, it seems the chromebook takes the SD entirely into itself. | 11:58.50 |
| sebras2 | Robin_Watts: I'm sure some crazy chinese site has a SD-card to SATA adapter. ;) | 11:58.52 |
| | Robin_Watts: most SD-based devices do. | 11:59.12 |
| paulgardiner | tor7: three commits up for review on paulg/master when you have a moment | 11:59.15 |
| sebras2 | Robin_Watts: contrary to SIM-based devices (I just had to cut my regular sizes SIM down to a micro-SIM, with a scissor, eeep!) | 11:59.47 |
| | or is it nano-SIM? I forget... | 12:00.08 |
| Robin_Watts | sebras2: eek. | 12:00.59 |
| sebras2 | tor7: word of advice though, your SD-card is not crashsafe, but your eMMC on the PCB probably is. have you heard me say this before? ;) | 12:01.03 |
| | Robin_Watts: indeed. apparently most of it is plastic. it is really only the part where you have the contacts that have electronics. | 12:01.57 |
| kens | OK, so who knows where Marcos keeps the fuzzing files ? | 12:51.39 |
| tor7 | Robin_Watts: eek. I've run into trouble, swapping the bits in the stencil buffer around so that I can keep the nvidia path rendering stencil bits in the lowest bits... | 12:57.17 |
| | Robin_Watts: I'm trying to count the clip depth in the top 4 bits (so bump the stencil value by 16 when I push/pop a clip) | 12:57.43 |
| | and use the low 4 bits to count the winding with the nvidia extension | 12:57.54 |
| | so now I have the stencil buffer filled at clip depth N (so values N*16) and also the low bits set for the current path I'm drawing as a clip path or'ed in (so N*16+nonzero value) | 12:59.16 |
| | and trying to get a StencilFunc + StencilOp combination that will set the stencil buffer to (N+1)*16 if value in buffer is > (N*16) | 13:00.09 |
| | the stencilop can be one of KEEP (don't change), INVERT (flip the bits), ZERO, and REPLACE (with the comparison value used in StencilFunc) | 13:00.45 |
| | previously I used the high bits for the nvidia extension, but that only works with Even-Odd fill rule | 13:01.55 |
| | and doing if stencil-value (clip depth + 0xF0) > (clip depth + 1), write (clip depth + 1) | 13:03.26 |
| Robin_Watts | tor7: back from lunch. reading now. | 13:22.54 |
| | kens: tests_private/pdf/fuzzing/ | 13:23.07 |
| kens2 | Robin_Watts : thanks!I'll get the file in a moment | 13:23.22 |
| Micha` | Howdy people. | 13:24.26 |
| Robin_Watts | tor7: Are you not looking for: if ((N+15)&~15) > N&~15) N = (N+15)&~15 | 13:26.31 |
| | Micha`: Hi. (In general on irc, don't wait for a reply before asking questions, as lag times can be high :) ) | 13:27.01 |
| | Also, the content of your question may determine whether people want to break cover or not :) | 13:27.30 |
| Micha` | To get used to MuPDF objects, I tried the (obviously overkill) steps to copy a PDF page to a new pdf: 1. create a new PDF document, 2. create a new page, 3. run the source page in the new page. So, just to be sure everything is how it is supposed to be: 2. fails because MuPDF does not know how to create a new page tree, and 3. fails because running a page on a pdf_page_write device has a font issue. Is that right? | 13:27.38 |
| | Haha, thanks :-) I usually ask questions in large paragraphs, hence the lag on my side ;-) | 13:28.13 |
| Robin_Watts | Micha`: Yeah. pdfwrite is imcomplete at the moment. | 13:28.56 |
| | or incomplete, even. | 13:29.23 |
| Micha` | This certainly explains the failure of 2. :-) But what is the reason for the "pdf device supports only base 14 fonts currently" error when running a PDF page on a pdf_page_write? | 13:31.21 |
| | I mean, i{n,m}completeness is probably the reason why, but... | 13:31.45 |
| Robin_Watts | Micha`: Currently we can't embed new fonts using pdfwrite. | 13:32.13 |
| Micha` | Ah, thanks! So no way to copy a page, right? | 13:32.57 |
| Robin_Watts | Micha`: Not trivially, currently. | 13:33.18 |
| Micha` | --- not that I need it, though, I'm just fooling around with the library. | 13:33.18 |
| Robin_Watts | You can do it by copying pdf objects directly, but... | 13:33.36 |
| Micha` | Well then, thanks for your help. Oh, and as a plain user: nice seeing overview.txt being extended! It's fun and stuff to reverse engineer the code, but a doc would be lovely :-) | 13:35.49 |
| Robin_Watts | Micha`: Contributions, suggestions etc welcome. | 13:36.23 |
| Micha` | I'd expect that :-) | 13:36.49 |
| Robin_Watts | Micha`: The last set of changes to overview.txt came about because Michael hit stuff that wasn't explained clearly enough. | 13:41.39 |
| henrys | kens:then it must be the vm - they aren't useable for me. | 13:46.19 |
| kens2 | henrys, that is likely. I imagine you cannot use hardware Breakpoints in a vm | 13:46.44 |
| Robin_Watts | henrys: You use virtualbox, right? | 13:48.05 |
| henrys | yes | 13:48.14 |
| Robin_Watts | http://www.jwandrews.co.uk/2011/12/hardware-breakpoints-virtualbox-vs-vmware/ | 13:48.25 |
| henrys | Robin_Watts: I have thought of switching - I guess I could do a complete backup and restore it in vmware. | 13:50.38 |
| Robin_Watts | VMware can import machines from various places. | 13:51.01 |
| | I went to parallels instead of VMware on the mac, cos VMware wanted a silly amount for me to upgrade versions. | 13:51.27 |
| henrys | I've also thought of going dual boot on a mac I have. | 13:51.44 |
| Robin_Watts | and parallels imported the vmware image. | 13:51.52 |
| | dual boot seems like too much pain to me. | 13:52.00 |
| | but then I only have the 1 mac. | 13:52.16 |
| henrys | even with the hardware support you don't get access to all the machines ram. | 13:59.32 |
| Robin_Watts | henrys: right. For me the purpose of the VM is so I can get to visual studio while using my laptop (i.e. when on a plane). | 14:00.16 |
| | but if you don't have any other PC, then it's a different use case, and dual boot may make more sense. | 14:00.40 |
| | on the other hand, PCs are cheap. Potentially screwing up a mac is expensive :) | 14:01.05 |
| tor7 | Robin_Watts: yeah, that might work! let me test it out. | 14:20.33 |
| Robin_Watts | tor7: Or even... | 14:29.05 |
| | N = (N+15)&~15 | 14:29.11 |
| | which will leave the bottom 4 bits 0, which is what you need for the next round, right? | 14:29.28 |
| tor7 | Robin_Watts: yeah. | 14:29.45 |
| | the problem I want to solve (in hopefully a clearer expression): the buffer contains X+Y, the comparison value is constant N+16. if Y==0 then leave unchanged else set buffer to N+16. | 14:32.51 |
| | X is any value, but Y==0 if X != N (since there is a test if buffer == N when doing glStencilFillPath) | 14:33.48 |
| | so you could say if X == N && Y != 0 then write N+16 else do nothing | 14:34.34 |
| | the problem is that I want to compare with N and set N+16 | 14:34.47 |
| | (and also ... monday) | 14:34.54 |
| Robin_Watts | tor7: Right, so that sounds like: N = (N+15)&~15 | 14:35.35 |
| | Suppose N = X + Y, then we have 4 cases to worry about. | 14:36.20 |
| | X = n or non-n, Y = 0 or non-0 | 14:36.51 |
| | In the X=n, Y=0 case, we want to leave the buffer unchanged. | 14:37.13 |
| | In the X=non-n, Y=0 case, we want to leave the buffer unchanged. | 14:37.32 |
| | In the X =n, Y = non-0 case, we want to set X = n+1, Y=0 | 14:37.52 |
| tor7 | In the X=non-n, Y=1 case, what we do is irrelevant (impossible case) | 14:38.12 |
| Robin_Watts | And the X = non-n, Y=non-0 case never occurs. | 14:38.22 |
| tor7 | yeah. | 14:38.29 |
| Robin_Watts | So N = (N+15)&~15 | 14:38.39 |
| tor7 | the problem is, the GL_REPLACE mode writes a constant value. | 14:39.09 |
| | basically the stencil operation goes like: | 14:39.18 |
| | if (buffer OP reference) then PASS() else FAIL() | 14:39.37 |
| | PASS() { if (mode == KEEP) pass; if (mode == REPLACE) buffer = reference; if (mode == INCR) buffer++; } | 14:40.09 |
| | and the same for FAIL() | 14:40.18 |
| Robin_Watts | if (N != (N+15)&~15) then N= magic | 14:40.39 |
| tor7 | if (mode == INVERT) buffer = ~buffer; | 14:40.40 |
| Robin_Watts | where magic is n+16 for the n you are testing for. | 14:41.17 |
| tor7 | if (buffer OP reference) is actually: if (buffer & MASK OP reference & MASK) | 14:41.37 |
| | yeah. the problem is that the only value I can write is the same value I test | 14:42.06 |
| Robin_Watts | tor7: OK, essentially what you need to test for is "the bottom 4 bits being non zero", right? | 14:42.08 |
| | because the only time they can ever be non zero is when X=n | 14:42.41 |
| | so: if (buffer & 15) buffer = magic | 14:43.19 |
| tor7 | if (buffer & 15) != (N+16) then buffer = N+16 | 14:44.14 |
| | should do the trick, I think | 14:44.19 |
| Robin_Watts | tor7: eh? | 14:44.30 |
| tor7 | if (buffer & 15) != (N+16) & 15 then buffer = N+16 | 14:44.43 |
| | I missed the second &15 | 14:44.48 |
| Robin_Watts | (N+16)&15 == 0 :) | 14:45.03 |
| | hence: if (buffer & 15) buffer = N+16 | 14:45.19 |
| tor7 | exactly, and then I get to put my magic N+16 in the reference that gets written :) | 14:45.21 |
| | OpenGL is perverted. | 14:45.24 |
| Robin_Watts | ok. | 14:45.40 |
| | oh, now I understand what you put earlier. | 14:46.16 |
| tor7 | yup! that works! | 14:46.48 |
| Robin_Watts | excellent. | 14:46.52 |
| tor7 | thanks for listening to my incoherent ramblings :) | 14:47.11 |
| | (and prodding me in the right direction) | 14:47.17 |
| Robin_Watts | no worries. | 14:49.31 |
| henrys | chrisl:I seem to be finding many problems in the msvc makefiles for the "other" languages. Is this something that is going to completely change with your configuration restructure or should I try and fix stuff now. | 14:50.01 |
| chrisl | henrys: I'm not really reusing the platform specific makefiles at all, so probably ignore them - at least for now | 14:51.32 |
| henrys | chrisl: good | 14:52.16 |
| | what a mess that is. | 14:56.19 |
| Robin_Watts | tor7: We get stroking+filling wrong when done with transparency. | 15:10.34 |
| | stroke is Ok. fill is OK. stroke + fill is broken. | 15:10.49 |
| | We need to push an isolated knockout group or something like that. | 15:11.19 |
| tor7 | yeah. the stroke+fill should be done as a separate knockout group | 15:11.22 |
| | but that'll kill performance, though I guess we could check to see whether we need it or not first | 15:11.38 |
| | I guess we don't do it because at the time I wasn't caring about knockouts :) | 15:11.59 |
| Robin_Watts | tor7: yeah, we'd only do it the case of alpha != 1. | 15:12.02 |
| henrys | chrisl: but it really is in bad shape I worry leaving it. Look at msvc_top.mak folks have set CFLAGS there but it is never passed into the recursive make invocation. So for one example I make GX_COLOR_INDEX "large" and only PCL is compiled with the large index, all the other settings too. How did this get so broken? | 15:45.52 |
| sicos | Hi | 15:47.24 |
| | Does somebody know if it is possible to search for specific words in a pdf with ghostscript and turn those word to "hyperlinks (pdfmark)" ? | 15:48.07 |
| kens2 | No its not possible | 15:48.19 |
| sicos | ok | 15:48.27 |
| Robin_Watts | henrys: Which recursive make invocation? Can you give me a line? | 15:48.29 |
| henrys | msvc_top.mak search for MAKE | 15:49.19 |
| Robin_Watts | CFLAGS is never passed into the recursive make. | 15:49.25 |
| | So each recursive make call resets the CFLAGS for itself. | 15:49.40 |
| | The only recursive make call I can see is the one for FORCE: | 15:50.06 |
| henrys | yes that is the only now there is | 15:50.33 |
| chrisl | henrys: GX_COLOR_INDEX_TYPE is set explicitly in msvc_top.mak | 15:50.34 |
| Robin_Watts | And that's only used in the /DPSI_INCLUDED case, which is language switch. | 15:50.37 |
| henrys | Robin_Watts: no the re is an ELSE part | 15:51.12 |
| | chrisl: how is it propagated through the recursive make? | 15:51.36 |
| Robin_Watts | CFLAGS is influenced by: MEMENTO, PSICFLAGS, GX_COLOR_INDEX_TYPE and that's all | 15:51.47 |
| | recursive make calls always pass on any values they were called with initially, right? | 15:52.15 |
| chrisl | Robin_Watts: no, nmake you have to pass all the definitions on explicitly | 15:52.48 |
| Robin_Watts | so if someone does: make blah CFLAGS="something" and that does a recursive call, the CFLAGS="something" will be passed automatically. | 15:52.49 |
| | chrisl: Really? Oh well... | 15:53.03 |
| | but that probably doesn't matter. | 15:53.16 |
| | as people should be setting XCFLAGS not CFLAGS, right? | 15:53.28 |
| henrys | I tripped over this setting the color index and having pcl get a 64 and gs get a 32... | 15:54.07 |
| Robin_Watts | ah, but the recursive make should pass on GX_COLOR_INDEX_TYPE. | 15:54.21 |
| chrisl | XCFLAGS should be used for "user" CFLAGS settings, CFLAGS should be used for internal settings | 15:54.21 |
| Robin_Watts | and PSICFLAGS | 15:54.46 |
| henrys | chrisl: it does look as though most things are passéd in as I look more carefully. | 15:54.52 |
| | Robin_Watts: it should yes. | 15:55.04 |
| Robin_Watts | but just those 2 things, not CFLAGS. | 15:55.18 |
| chrisl | henrys: it looks to me like this was explicitly done (or attempted) so that only language_switch gets the 64 bit GX_COLOR_INDEX_TYPE | 15:55.18 |
| henrys | Robin_Watts: agreed but I also thing this mess is a recipe for future breakage. | 15:55.58 |
| chrisl | henrys: so why was it done that way in the first place? | 15:56.20 |
| Robin_Watts | henrys: Recursive make is always a recipie for future breakage. | 15:56.24 |
| paulgardiner | tor7: one more additional commit needing review on paulg/master | 15:57.00 |
| henrys | chrisl: because it was done 20 years ago ? | 15:57.15 |
| chrisl | henrys: I don't understand why it was done "outside" the GS build system like that | 15:57.53 |
| henrys | chrisl:you mean why use recursive make? namespace issues. | 15:58.44 |
| | the idea was to be able to say make debug for both pcl and gs. You can't have the same named targets without the recursive make. | 16:00.13 |
| | later we learned this created more trouble than it was worth. | 16:00.41 |
| Robin_Watts | Can I get a sanity check please? In my homedir is a file 1508-2.pdf | 16:01.36 |
| | Acrobat renders this differently to gs and mupdf. | 16:01.47 |
| | Can anyone tell me why? | 16:01.55 |
| kens2 | not without seing it | 16:02.02 |
| henrys | chrisl: we fixed gcc to not do that terrible library gs make call but not msvc. | 16:02.12 |
| kens2 | I#'ll need a minute | 16:02.14 |
| chrisl | Robin_Watts: overprinting? | 16:02.25 |
| Robin_Watts | nope. | 16:02.35 |
| | It's a fill + stroke file. | 16:02.46 |
| | but the whole shape seems to be cropped left/right by half the linewidth to me. | 16:03.00 |
| chrisl | henrys: The thing is, the build rejig isn't going to get rid of recursive make calls - I can't see any way to get there without recursive calls | 16:03.25 |
| Robin_Watts | I have a fix here for mupdf getting the stroke+filling wrong. | 16:03.29 |
| | Having recursive calls right at the topmost level isn't such a bad thing, right? | 16:04.09 |
| henrys | chrisl: we did it in gcc I don't remember what the problem was in VS | 16:04.52 |
| | Robin_Watts: right there is a topmost which is okay. | 16:05.24 |
| Robin_Watts | chrisl: Are you forseeing having recursive calls anywhere except at the top ? | 16:06.13 |
| chrisl | henrys: the way it was done for "gcc" was by assuming GNU make, which we can't do in general | 16:06.13 |
| | Robin_Watts: no | 16:06.27 |
| Robin_Watts | Then I don't think we're too worried, are we? | 16:06.38 |
| kens2 | Robin_Watts : in what way different ? | 16:06.39 |
| henrys | Robin_Watts: frequent problems occur when we have a make for the graphics library separate from PCL/XL etc. of course that is only a problem because we have to many dependencies. | 16:06.49 |
| Robin_Watts | kens: In gs, look at the left/right sides. | 16:06.56 |
| kens2 | Hmm, yes hte strokes look clipped in acrobat | 16:07.26 |
| | But not in GS | 16:07.33 |
| Robin_Watts | kens2: Can you see any justification for that in the file? I can't. | 16:07.44 |
| kens2 | Not sure, I needed to see the difference first | 16:07.56 |
| henrys | chrisl: it is actually a deeper level problem for the color index. It should be opaque to the language and not even in the makefile. | 16:08.27 |
| | chrisl: only the graphics library need know about it right? | 16:08.48 |
| kens2 | Robin_Watts : at the moment, no, the Acrobat rendering looks wrong | 16:08.49 |
| chrisl | henrys: it's platform dependent, thus it has to be set by a "high level" makefile | 16:09.13 |
| Robin_Watts | kens2: If I change the file from "B*" to " S" then the sides change. | 16:10.07 |
| chrisl | henrys: unless you want to "hide" it in genconf/genarch? | 16:10.15 |
| Robin_Watts | So it's acrobat screwing up the fill+stroke case. | 16:10.16 |
| kens2 | Yes, I have to agree | 16:10.23 |
| sebras3 | kens2: Robin_Watts: what about other viewers... foxit... poppler..? do they side with acrobat or gs? | 16:10.46 |
| Robin_Watts | I bet acrobat is pushing a knockout group like us, and is screwing up the calculation for the bbox of that knockout group. | 16:10.52 |
| kens2 | I was about to try another viewer sebras2 | 16:10.57 |
| Robin_Watts | sebras3: I have not tried. | 16:11.08 |
| | firefox screws it up. | 16:12.07 |
| kens2 | Another viewer of my acquaintance renders it the same as GS | 16:12.21 |
| | One that I have confidence in | 16:12.44 |
| Robin_Watts | chrome agrees with gs. | 16:12.51 |
| chrisl | firefox effectively ignores transparency - doesn't it give the message about possibly rendering incorrectly? | 16:12.51 |
| kens2 | Odd man out is Adobe all round | 16:13.05 |
| Robin_Watts | chrisl: no message, but yes, that would be consistent to what I am seeing. | 16:13.09 |
| | OK. I don't propose to worry about it any more then. | 16:13.17 |
| | Thanks guys. | 16:13.19 |
| henrys | chrisl:Without seeing what you have in place now hard to opine. I just would like the language not to know anything about color indices. | 16:13.24 |
| chrisl | henrys: I don't really understand what you mean. Platform specific settings are usually in the top level makefile, which until now have been effectively specific to each language. | 16:15.16 |
| Robin_Watts | henrys: The color index size is something that needs to be set as part of the build. | 16:15.43 |
| | And we invoke the build "at the top level". i.e. we don't build a graphics lib, and then a language and then link the language with the graphics lib. | 16:16.26 |
| henrys | I thought we were separating things so the library could be built separately. That is the only build that needs to know about the indices why does a language client care? | 16:16.45 |
| Robin_Watts | and even if we did, the language calls into the graphics lib, so would need to agree on the types it uses, right? | 16:16.50 |
| chrisl | henrys: this first rejig is not pulling the builds into separate libraries, there are compatibility issues with doing that | 16:18.16 |
| Robin_Watts | henrys: Presumably we will have a top level makefile with targets for "a pcl release binary", "a pcl debug binary", "a graphics release lib" etc. And the "pcl release binary" will build "a graphics release lib" along the way. | 16:18.16 |
| kens2 | Right, goodnight everyone | 16:18.28 |
| Robin_Watts | henrys: but either way, the top level makefile is going to need to know what type to use for the graphics index. | 16:18.59 |
| | because regardless of whether you are building the graphics lib directly (as the target you specify), or indirectly (as a dependency of the target you specify) that knowledge has got to get down to the graphics lib build process somehow, right? | 16:20.09 |
| henrys | chrisl: oh okay I had assumed we would separate build. | 16:20.27 |
| chrisl | henrys: but even if we get to that stage, as Robin said, the various parts of the build still to know agree on data types | 16:20.59 |
| henrys | chrisl: why I have no idea what the graphics state data type is in PCL, it is properly opaque. | 16:21.40 |
| | ? | 16:21.54 |
| | well at least in places where we don't cheat. | 16:23.21 |
| Robin_Watts | Does the library make gs device calls ? | 16:23.37 |
| henrys | Robin_Watts: pcl and the language should not make gs device calls - is that what you mean? | 16:24.27 |
| chrisl | henrys: AIUI, the graphics state is visible from the interpreter, and the graphics state contains device color values. | 16:25.47 |
| mvrhel_laptop | good morning | 16:26.26 |
| Robin_Watts | Morning mvrhel_laptop. Good weekend? | 16:26.56 |
| mvrhel_laptop | more or less. stupid cold is still with me | 16:27.14 |
| henrys | chrisl: it ought to be completely opaque. The design intent is clear from how the structures are set up in the include files. | 16:27.47 |
| Micha` | Hey there! So, not sure whether `fz_free_device` is supposed to be segfault-free when every modification of `dev` was made by the library, but it does segv if dev is a pdf_page_write on a page with no contents. | 16:28.52 |
| | (which is arguably not often.) | 16:29.46 |
| Robin_Watts | Micha`: Can you give me a sequence of code to trigger than please? | 16:30.40 |
| | pseudo-code is fine - I just can't visualise what you mean. | 16:30.55 |
| Micha` | Yup. Just a second. | 16:30.57 |
| | Ah, easier then. | 16:31.04 |
| chrisl | henrys: well, nevertheless, it's parameter we to control for ports, and platform specific settings not set by genarch are set in the top level makefile. I don't plan to change that | 16:32.05 |
| | s/we to/we need to | 16:32.23 |
| henrys | chrisl: I suspect this is broken in many places but as you can see at the top of gsstate.h - /* Opaque type ⦠*/ and the idea is the idea was client would access a pointer to an incomplete type to implement opacity in C. | 16:34.22 |
| chrisl | I could rejig the cflags propagation so that we only set things like GX_COLOR_INDEX_TYPE for the graphics lib part of the build, but that seems like a) a needless complication, and b) a recipe for a PITA in debugging. | 16:34.39 |
| | henrys: but as I said, whatever we do with it, we need to set the value in the top level makefile - now we're just arguing about the reason for setting it there | 16:36.11 |
| henrys | there really is not argument until we do separate libraries for everything I'm just carrying on, ignore me. | 16:37.00 |
| chrisl | henrys: but even with the separate builds, we still need to set the value in the top level makefile | 16:37.53 |
| Micha` | I use a PDF with one empty page: 1 0 obj<</Type/Catalog/Pages 2 0 R>>endobj 2 0 obj<</Type/Pages/Kids[3 0 R]/Count 1>>endobj 3 0 obj<</Type/Page/MediaBox[0 0 3 3]>>endobj. It seems that, at pdf-page.c:455 (pdf_load_page), the page->contents is set to NULL, as no Contents appears in the file. Hence when a (pdf_page_write (doc, page)) is fz_free_device()'d, pdf_dev_free_user calls pdf_dict_puts_drop on a NULL pdev- | 16:38.06 |
| | >contents, and segv's. | 16:38.06 |
| | I gather that you speak PDF fluently :-) | 16:38.51 |
| Robin_Watts | What line is the drop that crashes please? | 16:39.22 |
| Micha` | http://pastebin.com/gWyhTTCR | 16:40.36 |
| Robin_Watts | I see the problem. We attempt to write into a contents dictionary and there isn't one. | 16:41.00 |
| | We ought to create one in that case. | 16:41.09 |
| Micha` | I see that pdf_create_page creates an empty Contents, maybe pdf_load_page should do the same. | 16:41.13 |
| Robin_Watts | Micha`: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c0e3e859f2dca28a0d7375dc004315a10a61543e | 16:43.31 |
| | That should solve it. | 16:43.35 |
| chrisl | henrys: do you ever see us shipping the gs graphics library as a "product", rather than a component in larger products? | 16:43.56 |
| henrys | chrisl: that was the original design yes - see gslib.c for a sample broken client. | 16:45.12 |
| chrisl | henrys: That's not what I asked - are we likely to do that in the future? | 16:45.35 |
| henrys | chrisl: highly unlikely that we would get a customer for that. But I think we'd have a better overall architecture if that were the assumption. | 16:47.10 |
| Micha` | Robin_Watts: You're right it should. Any reason why fix it here rather than pdf_load_page? Oh, and is page->contents automagically updated to `contents`? | 16:49.34 |
| henrys | henrys: if we had completely separate graphics gs library there would be no need for a pcl client to know about the color index. What I mean here is we link PCL to the gs library just as we use the c library. | 16:49.52 |
| | chrisl: ^^^ | 16:50.43 |
| chrisl | henrys: so, where does the PCL client actually use the colour index? | 16:50.44 |
| | henrys: looking (quickly) through the PCL/PXL/PL code, I don't see a color index referenced anywhere | 16:52.12 |
| henrys | places where we break opacity cause size differences... | 16:52.18 |
| | in structure which use a color index. | 16:52.53 |
| chrisl | henrys: but that's a code problem, not a makefile problem | 16:53.01 |
| henrys | chrisl: yes if we fix all that I can take the color index out of PCL's make that's what I'm saying should be fixed. | 16:53.50 |
| chrisl | No you can't take the color index out of the PCL make, because it must be set along with the other platform specific values | 16:54.28 |
| Robin_Watts | Micha`: Hmm. | 16:54.51 |
| | Micha`: I don't want loading a page to change any of the structures. | 16:56.00 |
| | writing a page can though. | 16:56.10 |
| chrisl | henrys: Even if the value is only used by the graphics lib, it must be set | 16:56.11 |
| Micha` | Robin_Watts: Honestly, I'm still wandering in the library, so if I take up your time for nothing relevant, just say it! :) | 16:56.51 |
| | Aah, I get the gist. | 16:56.56 |
| Robin_Watts | Micha`: So I have a new version. Just a tick. | 16:57.26 |
| henrys | chrisl: I'm assuming it would be set by the makefile that builds the graphics library or genarch or whatever. PCL doesn't really care about it, no? | 16:57.50 |
| Robin_Watts | Micha`: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=440ddabc384802328852f2da4032c0ad64ed34fa | 16:59.27 |
| Micha` | Robin_Watts: Yes, I understand this one better. | 16:59.57 |
| chrisl | henrys: but we'd still have a "top" makefile where settings like BAND_LIST_STORAGE and FILE_IMPLEMENTATION, and the font scaler get set | 17:00.14 |
| | henrys: we don't really want to be rooting through 4+ makefiles to change values for a given port/build, we want them centralised | 17:01.15 |
| Micha` | Any reason why this is written "obj = pdf_new_dict(doc, 4); | 17:01.54 |
| | page->contents = pdf_new_ref(doc, obj); | 17:01.54 |
| | pdf_drop_obj(obj);" in create_page? (And isn't it more consistent to leave contents NULL here?) | 17:01.54 |
| | Oh boy, sorry for the flood. | 17:02.05 |
| henrys | chrisl: Ideally no, they wouldn't be set at compile time if we were architecting an independent library, I thought that was the direction. | 17:02.07 |
| Robin_Watts | Micha`: Well, without that bit of code, we'd have SEGVd as soon as we made a new page and wrote it up until now. | 17:03.47 |
| | With the new fix, I could arguably leave it out. | 17:04.02 |
| chrisl | henrys: I don't follow - you want to compile a platform independent graphics library? | 17:04.09 |
| Robin_Watts | chrisl: I believe henrys is suggesting that in an ideal world, we'd build the graphics lib and the language completely separately. | 17:06.03 |
| | and then we could mix and match which graphics lib and which language we linked together. | 17:06.18 |
| henrys | chrisl: no I would expect things like size of long to compiled in but not BAND_LIST_STORAGE | 17:06.21 |
| Micha` | Sorry, I meant to ask about the use of an intermediate `obj` in create_page: is there any reason it is created, referenced, then dropped, rather than, as you did, just created? | 17:06.56 |
| Robin_Watts | Micha`: Sometimes, yes. | 17:07.28 |
| | It's to do with what happens if an allocation fails. | 17:07.37 |
| | and also to do with keeping reference counts correct. | 17:08.03 |
| | If we did: page->contents = pdf_new_ref(doc, pdf_new_dict(doc, 4)); | 17:08.20 |
| | pdf_new_dict returns something with the ref count set to 1. | 17:08.45 |
| chrisl | henrys: okay, but the point is, there will always be platform/port specific settings, and I think those should be in one place - the top makefile | 17:08.52 |
| Robin_Watts | pdf_new_ref makes a new reference to it. This pushes the ref count to 2. | 17:09.01 |
| Micha` | I got the reference part, but I was wondering why not page->contents = pdf_new_dict() directly. | 17:09.02 |
| Robin_Watts | because pdf_new_ref make a new 'reference' pdf object, not a new reference to a pdf object :) | 17:09.39 |
| | sorry, language is failing here. | 17:09.47 |
| henrys | chrisl:agreed. | 17:09.56 |
| Robin_Watts | pdf_obj's are reference counted things. | 17:10.01 |
| chrisl | henrys: and GX_COLOR_INDEX_TYPE is one of those platform/port specific values | 17:10.25 |
| henrys | chrisl: well no long term I think there should be a top level makefile for gs/base that nobody else even knows about. | 17:10.54 |
| Robin_Watts | hence if you have a pdf_obj that is an int, or a dictionary, or a stream or whatever, we can have lots of things holding pointers to it. Each of them bumps the reference count by 1 when it takes a copy of the pointer. When they release the pointer, they decrement the reference count. That way we only destroy the actual object when the ref count reaches 0. | 17:11.37 |
| henrys | that create s a library and client -l to that just they'd link to any other library. | 17:11.48 |
| Robin_Watts | This is done by calling pdf_keep_obj() and pdf_drop_obj() respectively | 17:12.05 |
| | But, PDF allows objects to reference one another within the file. | 17:12.17 |
| | For this, we have a type of pdf_obj that is a "reference". | 17:12.33 |
| chrisl | henrys: so we'd potentially have two places where platform specific settings are required? Ugh..... | 17:12.39 |
| henrys | chrisl: I don't need libpng's COLOR_INDEX_TYPE to use the library . | 17:12.40 |
| Robin_Watts | This is distinct from our reference counting. | 17:12.44 |
| | pdf_new_ref(obj) makes a new pdf_obj of type "reference" that refers to obj. | 17:13.18 |
| Micha` | Oh boy! I finally got it, thanks! | 17:14.11 |
| | BUT it does not explain why you want a reference object in create_page and not in write_page, does it ? :-) | 17:14.40 |
| henrys | chrisl: might be to much sharing between the libraries and languages for that to be possible. But I think it would make ghostscript much easier to deal with and perhaps it could get used as general purpose graphics library. | 17:14.54 |
| Robin_Watts | Micha`: Oh, hell. No, you're probably right. | 17:15.08 |
| chrisl | henrys: I don't like the idea of having to invoke make multiple times just to build gs, or pcl or xps. I thought part of the point of this was to be able to build all the products from a single make invocation | 17:16.40 |
| Micha` | Hell it is :-) But I'm getting the hang of it. My masochistic side is very pleased, it seems. | 17:17.13 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=bafae4ca0b31a0de40c254da696f6dc2185a34b4 | 17:18.27 |
| | Ha, now you get to see the error system at work too :) | 17:18.43 |
| henrys | chrisl:no I was more of a mind build gs/base stuff once make a library then clients can be quickly developed and simply -lgs ... | 17:18.44 |
| | chrisl: but that will be complete disaster with the current interdependencies. Interaction needs to be minimized first. | 17:19.44 |
| Micha` | Robin_Watts: That I do! Shouldn't obj be defined? (And fz_var'd, but I'm still unsure about this fz_var'ing thing.) | 17:20.05 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=9245913e84e87dde3c2a2aca92723165bb9c4003 | 17:21.13 |
| | Micha`: I should build before publishing :) | 17:21.22 |
| | fz_var(x) is needed if x is changed within the fz_try block. | 17:21.43 |
| | obj is not changed within the fz_try block, so we don't need it. | 17:21.54 |
| chrisl | henrys: I agree it would be nice to have a "core" graphics lib library. The problem I encountered is that it seems we can't rely on always having "ar" available. Also, some ar implementation need the resulting object archive to be post processed to build the symbol index. | 17:22.07 |
| Robin_Watts | specifically the reason is that fz_try calls 'setjmp'. And the C standard says that any local automatic variables can be blown away if longjmp is called if their value has changed since the setjmp was performed. | 17:22.58 |
| chrisl | henrys: however my plan had been to have the graphics library just be a makefile target, rather than being it's own independent makefile infrastructure | 17:23.45 |
| henrys | chrisl: oh that would be a problem. | 17:23.55 |
| Robin_Watts | fz_var passes the address of the given value out of scope, hence it can no longer be considered 'local' by the compiler. i.e. the compiler must ensure that its value is written back to memory before every function call. | 17:23.58 |
| mvrhel_laptop | finally got this dumb xps transparency bug figured out | 17:24.13 |
| | the softmask from an image was getting the opacity for the fill applied to it | 17:24.29 |
| Robin_Watts | mvrhel_laptop: We have some of those in mupdf if you want? :) | 17:24.33 |
| mvrhel_laptop | we were essentially applying the opacity 3 times | 17:24.43 |
| | Robin_Watts: you could assign them to me, and I can look them over in my spare time | 17:25.10 |
| Robin_Watts | so you solved it by taking the cube root of the opacity ? | 17:25.11 |
| henrys | chrisl: that seems reasonable given the state of things. | 17:25.11 |
| mvrhel_laptop | Robin_Watts: exactly! | 17:25.22 |
| | great minds think alike | 17:25.33 |
| Micha` | Robin_Watts: Ah, I get it now, thanks! The patch looks fine to me, if it compiles :-) Any reason why initialcap is set to 4 in create_page? | 17:25.53 |
| Robin_Watts | Cos at that point I'm fairly sure I'm going to put stuff into it :) | 17:26.16 |
| | I suspect that the underlying code sets the cap to at least 4 anyway. | 17:26.36 |
| chrisl | henrys: So, with my tentative plan to have the graphics library be a makefile target, I've been vaguely kicking around ways we might be table to build a graphics lib ".a" where ar is available, and use the current style ".o" file list where ar is not available. But I'm trying to focus on the current stage, rather get bogged down in future stages. | 17:27.20 |
| Robin_Watts | tor7: 2 commits for your consideration on robin/master | 17:27.23 |
| henrys | chrisl: what platforms do we have problem's on. Maybe sane ar should be required . | 17:28.23 |
| Micha` | It does indeed: 10. Well then, I have everything sorted out in my current mupdf doodling. Thanks a bunch! | 17:28.41 |
| chrisl | henrys: at least some solaris versions are missing. | 17:30.35 |
| | are missing "ar", I mean | 17:30.51 |
| henrys | the big issue is how does it affect 832 and folks like that. | 17:32.21 |
| | ? | 17:32.28 |
| Robin_Watts | Micha`: No worries. Thanks for spotting the problem. | 17:33.08 |
| chrisl | henrys: I've no idea what 832 do? | 17:33.30 |
| henrys | chrisl: you mean solaris with the gcc toolchain installed or native? | 17:33.31 |
| | chrisl: well I think the simulator would be okay but don't know about the products. | 17:34.20 |
| chrisl | henrys: gcc does not depend on ar | 17:34.36 |
| henrys | chrisl: I'm asking if solaris folks can use gar | 17:35.15 |
| | ? | 17:35.15 |
| | gnu ar | 17:35.22 |
| chrisl | henrys: if you use gcc, you can use gnu ar, I don't know about the Sun tools. It would be an additional dependency for us | 17:35.54 |
| | henrys: oh, 532? Well, it would mean them redoing their customisations to the build | 17:36.20 |
| henrys | chrisl: oh 801 and 532 were running together ;-) | 17:36.47 |
| | chrisl: probably much pain. | 17:37.34 |
| chrisl | henrys: well, we can't expect to make wholesale changes to the build, and have them not affect those doing custom builds! | 17:38.22 |
| | henrys: I'm not averse to having ar as an additional dependency, it's just it's not vital to *this* part of the rejig, so I'm not worrying about it right now | 17:38.52 |
| henrys | chrisl: okay let's finish this milestone first. In itself it will be a vast improvement from where we are now. | 17:39.38 |
| chrisl | henrys: once this stage is done, changing to build a graphics lib static library won't be a huge task. The biggest impediment just now is that the romfs is part of the graphics library build, but is actually a language setting | 17:41.22 |
| henrys | chrisl: even adding GX_COLOR_INDEX_TYPE to the giant nmake parameter list it still doesn't seem to be getting through. Digging... | 17:41.26 |
| chrisl | henrys: if you want me to look into it, I'll do so tomorrow - I'm getting too tired now...... | 17:42.10 |
| henrys | chrisl: no I'll have it by then, I can actually get around this mess okay. | 17:42.31 |
| chrisl | henrys: it's possible that the value isn't being correctly added to the AUXCFLAGS, so isn't being communicated to genarch (I think) | 17:43.33 |
| henrys | chrisl: looks like it wants USE_LARGE_COLOR_INDEX not GX_COLOR_INDEX_TYPE | 17:43.38 |
| | I'm no msvc | 17:43.54 |
| | s/no/on | 17:43.59 |
| chrisl | henrys: I think you do need it added to CFLAGS, looking in gs/psi/msvc.mak | 17:45.50 |
| | CFLAGS=$(CFLAGS) /DGX_COLOR_INDEX_TYPE="$(GX_COLOR_INDEX_TYPE)" | 17:46.00 |
| henrys | chrisl: as Robin_Watts was saying we don't want to pass in CFLAGS, that'll break other stuff. | 17:47.34 |
| | chrisl: that is in a condition USE_LARGE_COLOR_INDEX so that needs to be passed in too. | 17:48.12 |
| | or rather instead. | 17:48.38 |
| | ugly | 17:49.00 |
| chrisl | henrys: where are you seeing the condition on USE_LARGE_COLOR_INDEX? | 17:50.03 |
| henrys | oh wait it already is set to 1 in msvc.mak | 17:51.25 |
| chrisl | You're not using msvc.mak are you? | 17:52.00 |
| | henrys: shouldn't the PCL only build be using msvclib.mak? | 17:52.42 |
| henrys | chrisl: no we switched it to use the upper level makefiles a while back. | 17:53.08 |
| chrisl | cd ../main | 17:53.53 |
| henrys | cd ../common ;-) | 17:54.12 |
| mvrhel_laptop | and yet another transparency issue with 694707 | 17:54.25 |
| | sigh | 17:54.28 |
| chrisl | henrys: I'm looking in msvc_top.mak, and I'm seeing: "$(MAKE) /F $(GLSRCDIR)\msvclib.mak....." if we're not including PSI | 17:54.58 |
| sebras3 | time to sleep. see you guys tomorrow evening! | 17:55.42 |
| henrys | chrisl: that's right stupid me. | 17:55.51 |
| | now it makes sense | 17:55.56 |
| chrisl | So we probably need to copy the settings from psi/msvc.mak over to winlib.mak | 17:56.31 |
| | I mean msvclib.mak | 17:56.52 |
| henrys | chrisl: right | 17:57.23 |
| | I guess I should leave this one to you for tomorrow. | 17:57.41 |
| chrisl | henrys: well, now you know what makefile is being used, you can stick in a hack to keep you moving. I'll look at doing it properly tomorrow | 17:58.30 |
| henrys | chrisl: it can't be uncondition in msvclib.mak | 17:59.23 |
| | unconditional | 17:59.31 |
| chrisl | henrys: no, I realise that | 17:59.52 |
| henrys | chrisl: I'll probably patch it correctly and send it to you for review if I don't trip over something ... | 18:00.32 |
| chrisl | henrys: okay, I'm happy with that | 18:00.47 |
| henrys | so don't expect anything ;-) | 18:00.52 |
| chrisl | henrys: Well, it's Visual Studio, so I usually just close my eyes and hope for the best........ | 18:01.37 |
| Robin_Watts | henrys, mvrhel_laptop: So, it seems Marti is happy with the idea of us funding him fixing lcms2. | 18:15.56 |
| | The original lcms2 API had no thoughts about thread safety. | 18:16.39 |
| | Then he added an API that was 'mostly' thread safe. | 18:16.53 |
| | What he's proposing now is that he fix the newer API to be 'actually' thread safe. | 18:17.08 |
| | That will be backwardly incompatible, but most people are using the original API anyway. | 18:17.35 |
| | I think we may be one of the few people that tried to use the newer API :) | 18:17.50 |
| henrys | Robin_Watts: would you like me ask him for a schedule and an estimate - I'd prefer not to have an open ended arrangement. | 18:17.54 |
| Robin_Watts | henrys: I think the purpose of writing this document was so that we'd agree technically what needed to be done. Then he'd come back with timescales/tasks etc for you and Miles to agree to. | 18:18.38 |
| | At least, that's how I read his latest email (just arrived) | 18:18.54 |
| | henrys, mvrhel_laptop: If either of you are unhappy with what he'd proposing technically, we should probably say sooner rather than later. | 18:20.05 |
| | mvrhel_laptop isn't here of course - hopefully he'll read the logs, or someone can prod him later. | 18:20.24 |
| henrys | Robin_Watts: oh right he was just here a few minutes ago. | 18:20.48 |
| | Robin_Watts: I'm good with the proposal, let's see what michael says. | 18:33.02 |
| | Robin_Watts: is there something I should know about nmake quoting I noticed you quoted "($MEMENTO)"="1" is that necessary for a simple integer value? | 19:15.06 |
| Robin_Watts | henrys: I copied it from elsewhere :) | 19:20.39 |
| henrys | thanks | 19:21.05 |
| ray_laptop | henrys: if $(MEMENTO) is an empty string then the if will have bad sytax: if = 1 | 19:45.23 |
| | henrys: so it's always safer for macros that may be undefined. If MEMENTO is ALWAYS 0 or 1, then you are OK without it | 19:46.09 |
| | btw, that probably should be == (not =) | 19:47.10 |
| | not = | 19:47.17 |
| Robin_Watts | ray_laptop: It's == in the file. | 19:49.12 |
| henrys | ray_laptop:right he didn't !ifndef MEMENTO as we do for all other variables. | 19:49.30 |
| ray_laptop | henrys: right | 19:49.50 |
| | Robin_Watts: yes, I looked (at one of the makefiles) | 19:50.03 |
| | henrys: so if you have the ifndef AND the "$(MEMENTO)" then you have belt and braces :-) | 19:50.42 |
| Micha` | pdf-page.c:573 ; shouldn't "pdf_dict_puts(page->me, "Parent", page_ref)" read "..., parent)" ? | 21:05.22 |
| | This creates cycles in the page tree. | 21:05.35 |
| | Robin_Watts: As for the empty contents thing, simply inserting a page newly created (with pdf_create_page, hence with an empty but non-NULL contents) results in a PDF which triggers a "PDF object stream missing" warning. In the PDF, the Contents ressource is <<>> ; it is not missing, but it is indeed empty. | 21:51.17 |
| tophyr | hi, i'm interested in commercially licensing the mupdf library for use in a closed-source android application. i've sent a couple emails to sales@artifex.com but haven't received any replies. is there a better contact I should use? | 22:10.58 |
| Micha` | tophyr: I do believe that you are at the right place, but maybe not at the right moment. It seems that some of the main staff lurking around here are located in Europe. | 22:14.41 |
| mvrhel_laptop | Robin_Watts: I read through Marti's notes and your comments. I am glad to hear that approach b) is the choice. This will be better for lcms in the long run | 22:19.56 |
| Robin_Watts | tophyr: Resend your mail to sales@artifex.com and copy it to robin.watts@artifex.com and I will ensure that it gets through. | 22:44.11 |
| tophyr | Robin_Watts: thanks | 22:55.29 |
| | Robin_Watts: looped you in | 22:56.10 |
| Robin_Watts | tophyr: Typically what happens next is that Scott will contact you, and send you a huge list of questions. Answer it as best you can (some of them won't be relevant). | 22:58.09 |
| | The more Scott can understand your situation the more he can tailor a license solution to your needs. | 22:58.30 |
| tophyr | perfect :) | 22:58.43 |
| Robin_Watts | tophyr: Is your nick a Dollshouse reference? | 23:00.45 |
| tophyr | no, never heard of Dollshouse :) i gave it to myself when i was a little kid and my dad gave me my first email address | 23:06.06 |
| | my name's christopher and he always called me topher, and i wanted the y for some reason | 23:06.31 |
| Robin_Watts | fair enough. :) | 23:08.00 |
| tophyr | it's served me fairly well as a handle.. in 20 years, haven't ever run into another tophyr | 23:09.39 |
| Robin_Watts | tophyr: No, it was unusual hence I asked. | 23:16.10 |
| | tophyr: Scott didn't see your original mail for some reason. he's dealing with it now though. If you don't hear back within 24 hours hassle me again. | 23:28.28 |
| tophyr | awesome! thanks :) | 23:29.25 |
| Robin_Watts | np. | 23:32.50 |
| | Forward 1 day (to 2013/10/15)>>> | |
IRC Logs
