| | <<<Back 1 day (to 2013/12/15) | 2013/12/16 |
| kens | chrisl just discovered that, in order to get the width of a type 1 glyph, pdfwrite always runs a type 1 interpreter. However there is no information on the glyph BBox in a type 1 glyph, just the width. The setcachedevice values come from the computed outline (or bitmap if the glyph is rendered) | 09:09.13 |
| chrisl | kens: oh, well, if you're already running the charstring..... | 09:10.36 |
| kens | Not really, only until hsbw | 09:10.50 |
| | We only run the whole charstring if there is no (h)sbw | 09:11.07 |
| | Its actually done by the graphics library | 09:11.37 |
| | gs_default_font_info | 09:11.53 |
| | That calls font->procs.glyph_info which runs a t1 interpreter (for t1 fonts) | 09:12.31 |
| | Out of curiosity, what kinds of information can we have FreeType return ? | 09:13.03 |
| chrisl | Freetype would execute the entire charstring, so we can any information we might want | 09:13.54 |
| kens | Hmm, I wonder if we could replace the glyph_info proc with something that called FreeType | 09:14.25 |
| | Good grief, it seems we do the whole font up front when we copy it | 09:15.06 |
| chrisl | It would still be a bit nasty taking into account an CDevProc | 09:15.33 |
| kens | z1_glyph_info_generic deals with that | 09:15.50 |
| | it returns a rangecheck error | 09:16.11 |
| chrisl | Another problem is that going through FAPI needs an enumerator | 09:16.32 |
| kens | Hmm OK too much effort then | 09:16.44 |
| chrisl | I do it for the PCL stuff, so I could look at making it more generic | 09:17.56 |
| kens | No don't worry I'mstill hacking through a maxe here | 09:18.10 |
| | maze* | 09:18.14 |
| | I was trying to sort out the type 3 font and wondered if there was a useful way to cover type 1 at the same time | 09:18.36 |
| chrisl | FWIW, given that it already runs the charstring interpreter, wouldn't it be fairly straight forward to just make it run the entire string? | 09:19.05 |
| kens | Yes, sure, but its ahrd to calculate the BBox from that | 09:19.21 |
| | lines are OK but curves are more complex | 09:19.35 |
| | I could probably figure something out, since I'm only interested in a BBox | 09:19.59 |
| chrisl | Hmm, well, we must do something to work it out since we need a fairly accurate bbox to allocate the raster to render the path into | 09:20.28 |
| kens | Not sure where we do that | 09:21.00 |
| | Or where FreeType does it either | 09:21.11 |
| chrisl | I have been through it before.... | 09:22.03 |
| kens | Not to worry just now, I'm concentrating on the type 3 stuff. I have it assembling a BBox for me, but I need to figure out somewhere to store it. | 09:22.44 |
| Robin_Watts | kens: So, one of the JIBG2 commits I made from shelly last week, broke a load of stuff. | 10:27.22 |
| | he's produced a new patch that solves all the problems, except for with: | 10:27.36 |
| | tests_private/comparefiles/Bug691785.pdf.ps.ppmraw.300.0 gs ps2write | 10:27.48 |
| | tests_private/comparefiles/Bug691785.pdf.ps.ppmraw.72.0 gs ps2write | 10:27.50 |
| | But he can't reproduce those problems locally. | 10:28.02 |
| kens | Hmmm | 10:28.14 |
| Robin_Watts | Does that file have a known problem with ps2write by any chance ? | 10:28.16 |
| kens | errors, not diffs ? | 10:28.19 |
| Robin_Watts | Looking at his bmpcmp those look like progressions. | 10:29.39 |
| | I'll run some tests locally. | 10:29.44 |
| | Thanks, | 10:32.12 |
| kens | I'm not aware of a problemwith that file | 10:32.49 |
| | Robin_Watts : they sure look like progressions | 10:50.36 |
| Robin_Watts | Hmm. I just applied his patch and clusterpushed, and I see very few changes. | 10:51.09 |
| kens | odd | 10:52.00 |
| Robin_Watts | Morning paulgardiner | 11:40.02 |
| paulgardiner | Hi Robin_Watts | 11:40.12 |
| Robin_Watts | How's the jetlag? | 11:40.53 |
| paulgardiner | Pretty horrendous. Didn't manage to get out of bed until 2pm yesterday. Managed 10am this morning so maybe on the mend. | 11:41.48 |
| | You still afflicted? | 11:43.09 |
| Robin_Watts | almost back to normal, I think. | 11:44.40 |
| | heating in the house is playing up (seems to stick on), so we're having disturbed nights which isn't helping. | 11:45.08 |
| paulgardiner | I'm having much more disturbed sleep than when I arrived in Maui. I was expecting both directions to be about the same, what with its being 10h | 11:45.49 |
| Robin_Watts | I think the body copes OK with 1 change. | 11:46.25 |
| | 2 changes in quick succession is what kills me. | 11:46.46 |
| paulgardiner | Like the 2 day meetings? | 11:47.37 |
| Robin_Watts | yes, but they aren't as bad as this - possibly because I get up 4 hours earlier than usual there, so it's only a 4 hour adjustment. | 11:48.54 |
| | This is much worse than the 2 day meetings. | 11:49.40 |
| paulgardiner | I seem to do okay on two quick changes if back to the start location. | 11:49.49 |
| | Last two-day meeting, I worked a bit during the nights in the US when I had trouble sleeping. Felt terrible in the later parts of the meetings, but had almost no jetlag when returning to the UK. | 11:52.27 |
| | Need a chorus of coqui frogs to help me sleep, like in Hilo | 11:56.51 |
| Robin_Watts | tor8: 5 patches on robin/master for you. Not the last 3. | 12:43.28 |
| | marcosw1: Morning. | 14:42.40 |
| | I had problems with the cluster this morning. | 14:43.00 |
| paulgardiner | hi marcosw1 | 14:43.37 |
| Robin_Watts | Bug 694845 is about a regression caused by a commit. When I cluster test that regression removed, it doesn't show me any differences. Presumably because they've matched in the last 50 runs. | 14:44.12 |
| | Morning mvrhel_laptop | 14:52.53 |
| | Could I trouble you to read bug 694842 to see if my explanation makes sense to you? | 14:53.16 |
| kens | Robin_Watts your explanation looks sensible to me | 15:08.05 |
| | Wihtout actually looking at the dithering going on | 15:08.17 |
| Robin_Watts | actually... it's an 8x8 dither and we set 2 pixels in it. | 15:09.37 |
| | So I am confused by that. | 15:09.43 |
| kens | seems like the same principle though | 15:12.26 |
| | the3 background of the image is not white | 15:12.42 |
| Robin_Watts_ | kens: Oh, indeed. | 15:13.27 |
| | Fundamentally, the background of the image is not white, so if we draw it not white, you ain't got that much to complain about. | 15:13.46 |
| | BUT... I'd like to convince myself that we don't have a rounding thing in there going the wrong way. | 15:14.14 |
| kens | fair enough | 15:14.31 |
| | I understand the itch ;-) | 15:14.40 |
| Robin_Watts | d_order->{width,height} = 8. d_order->num_bits = 64 | 15:15.12 |
| | d_order->num_levels = 32. Eh? | 15:15.24 |
| kens | ?? That sounds wrong | 15:15.33 |
| Robin_Watts | which bit sounds wrong? | 15:15.43 |
| kens | Surely num_;eve;s = num_bits | 15:15.46 |
| Robin_Watts | I would have thought so. | 15:15.54 |
| kens | what happens if you change it ? :-) | 15:16.42 |
| Robin_Watts | Aw, hell. I'm going to need to try to understand the params fields :( | 15:18.04 |
| kens | runs away screaming | 15:18.13 |
| | Hmm, no sign of Michael | 15:25.05 |
| | That fix I pointed out in gdevp14.c is causing another problem | 15:25.24 |
| | Because its not yet been applied | 15:25.36 |
| nl | hi | 15:29.28 |
| ghostbot | hey | 15:29.28 |
| Guest22193 | does somebody know if ghostscript is utf8 compatible regarding file names? | 15:29.54 |
| Robin_Watts | Guest22193: Yes. | 15:30.20 |
| Guest22193 | I have a file with a euro symbol in it's name and when i try to proces that one with ghostscript I get an File IO read error | 15:30.28 |
| Robin_Watts | Guest22193: What OS? | 15:30.35 |
| Guest22193 | Windows | 15:30.39 |
| Robin_Watts | and what version of gs ? | 15:30.43 |
| Guest22193 | I took the latest version from git a week ago | 15:30.56 |
| Robin_Watts | How are you invoking it? | 15:31.04 |
| Guest22193 | and compiled it myself | 15:31.04 |
| | I generate a postscript file and put that into ghostscript | 15:31.20 |
| | using command line parameters | 15:31.35 |
| | from a batch file | 15:31.41 |
| Robin_Watts | So the PS file contains the filename with the Euro symbol in it? | 15:32.01 |
| Guest22193 | yes | 15:32.15 |
| Robin_Watts | Or the PS file has the Euro symbol in its name ? | 15:32.32 |
| Guest22193 | no the name is in the postscript file | 15:32.42 |
| | I use the run command to process the file | 15:32.50 |
| | I use postscript because I also generate some bookmarks | 15:33.07 |
| | I used the ghostscript.vcproj file to compile gs | 15:33.52 |
| Robin_Watts | OK, so your PS file contains a string that is the name of the file. | 15:33.56 |
| | That string should be UTF8 encoded. | 15:34.02 |
| Guest22193 | If I open the gs file in e.g. notepad everything looks fine | 15:34.25 |
| | but when I put the file into gs i get the error | 15:34.35 |
| | I generate the gs file from C# .NET | 15:35.11 |
| | With a stringbuilder | 15:35.18 |
| | so it should be utf8 | 15:35.25 |
| tor8 | Robin_Watts: what is the source/fitz/deflate file doing in the pdf_crypt commit? | 15:35.50 |
| Guest22193 | does gs read text (ps) files as ansi or does it it read as utf8? | 15:36.33 |
| kens | Neither | 15:36.45 |
| | strings are sequences of 8-bit binary data | 15:36.58 |
| Guest22193 | what is the difference between the ghostscript-ufst.vcproj and ghostscript.vcproj file? | 15:38.01 |
| Robin_Watts | One is for if you want to build with UFST. | 15:38.30 |
| kens | One caters for the inclusion of the (commercial) font interpreter 'UFST' from Monotype | 15:38.32 |
| Robin_Watts | You don't want to build with UFST> | 15:38.37 |
| | tor8: looking. | 15:39.53 |
| tor8 | and the 'fix typo in deflater code' commit later on ... have you been coding while jetlagged? ;) | 15:40.20 |
| Robin_Watts | tor8: OK, I must have added that by mistake. I will remove it. | 15:40.47 |
| | That does at least make more sense. | 15:40.58 |
| tor8 | did I not review a commit to make ctx in streams explicit before the weekend? | 15:41.07 |
| Robin_Watts | tor8: I put a commit up for reference that made ctx in streams explicit. | 15:41.41 |
| | I said I was going to do a rebind version for comparison. | 15:42.07 |
| tor8 | I sort of liked that commit, but I thake it you prefer rebinding? | 15:42.10 |
| Robin_Watts | and I have now done that. | 15:42.15 |
| | I do prefer rebinding. | 15:42.19 |
| tor8 | anyway, this rebinding stuff goes deeply | 15:42.20 |
| | I've got a bad feeling about how far it reaches | 15:42.42 |
| Robin_Watts | I think it's reasonable to say that in mupdf, some structures 'bind' the contexts. | 15:42.47 |
| | In such cases, we provide 'rebind' functions to change that binding. | 15:42.59 |
| tor8 | yeah, but keeping track of all those is going to end up being rather fragile code that can easily be broken or forgotten when adding new features | 15:43.12 |
| Robin_Watts | It's the users responsibility to ensure that no one rebinds a context while someone else is using it. | 15:43.37 |
| tor8 | so while I agree that we should bind certain structures, I would like to limit it to documents and devices | 15:44.10 |
| | and yes, it's up to the user to not mess up with multi-threading and rebinding | 15:44.50 |
| Robin_Watts_ | If people are concerned, then they can build their own lock/unlock functions. (rebind is exactly what is required to allow that to be done) | 15:44.56 |
| | damn. I fell off then. Dunno if I missed anything. | 15:45.13 |
| tor8 | until such a time as we decide to integrate a threading library properly (should we ever do so) | 15:45.14 |
| | Robin_Watts: (repeat) yeah, but keeping track of all those is going to end up being rather fragile code that can easily be broken or forgotten when adding new features | 15:45.40 |
| | Robin_Watts: (repeat) so while I agree that we should bind certain structures, I would like to limit it to documents and devices | 15:46.05 |
| Robin_Watts_ | tor8: OK. So you'd still rather make the fz_stream contexts explicit. | 15:46.32 |
| tor8 | streams tend to be passed around a lot, I fear it'll be too easy to forget to rebind | 15:46.33 |
| Robin_Watts_ | streams are not passed around a lot. | 15:46.47 |
| | They are passed around within the code, but almost never in a way that survives calls to the user. | 15:47.21 |
| tor8 | maybe not anymore, now that we read more things into buffers ahead of time | 15:47.24 |
| | I'm thinking about our own code, not the public API | 15:47.39 |
| | I don't trust myself to not slip up with this | 15:47.49 |
| Robin_Watts_ | The sole case where a user visible stream survives calls from the user is the document stream. | 15:48.03 |
| | and ownership of that is passed into the document, so the document rebind takes care of that. | 15:48.19 |
| tor8 | Robin_Watts: yes, from a pure user perspective, the choice of explicit or rebinding makes no difference | 15:48.51 |
| Robin_Watts_ | Can you give me an example of a stream (user visible or not) other than the document stream, that survives over separate calls from the user? | 15:49.06 |
| | i.e. give me an example of a stream that would need rebinding (other than the document one, which is easy) | 15:49.39 |
| tor8 | considering we only use streams with documents now, no, not off the cuff | 15:49.51 |
| | but fz_outputs I could probably do, but then you'll say they're tied to the fz_device :) | 15:50.13 |
| Robin_Watts_ | This is why I could not stay in hawaii any longer: http://www.thepoke.co.uk/2013/05/26/snaps-of-the-summer-vol-1/gallery/image/image-323/ | 15:50.44 |
| tor8 | Robin_Watts: I mentioned fz_output, but that's tied to fz_device. | 15:51.04 |
| | any new stream, document or device types we create, we now have the extra checklist of making sure to rebind all stream, document and device pointers when we use them. | 15:51.40 |
| Robin_Watts_ | and one of my commits introduces rebind for fz_output too, which is called by fz_rebind_device | 15:51.42 |
| | tor8: Indeed. | 15:51.58 |
| tor8 | and I don't like that. | 15:52.05 |
| Robin_Watts_ | But that's not a large cost. | 15:52.12 |
| tor8 | lots of small decisions like that, and soon we'll look like ghostscript's code ;) | 15:52.39 |
| Robin_Watts_ | You can't forget to add a rebind to a stream, because it's a required param to fz_new_stream. | 15:52.52 |
| Robin_Watts | For single threading it's no work at all. | 15:52.55 |
| Robin_Watts_ | eh, what? That's me in the past talking. It's like Dr Who! | 15:53.19 |
| | It's gone all Timey Wimey! | 15:53.31 |
| tor8 | you've spent too much time with GS! repent! | 15:53.42 |
| kens | Oh I'm sure he does | 15:53.59 |
| Robin_Watts_ | tor8: So, presumably, you'd advocate not rebinding fz_output's either. | 15:56.07 |
| | i.e. making contexts explicit there too. | 15:56.18 |
| tor8 | Robin_Watts: correct. | 15:56.29 |
| Robin_Watts_ | I *really* dislike that. | 15:56.44 |
| | Having to take 2 bottles into the shower just feels wrong. | 15:56.58 |
| tor8 | and I'm not 100% convinced we should bind anything other than documents, but I'm willing to let the devices remain bindable | 15:57.08 |
| kens | Ding ding! seconds out.... | 15:57.09 |
| Robin_Watts_ | (Actually, that's a reference that you probably won't get...) | 15:57.19 |
| tor8 | it's the short lifetime of a device, and the create/use/destroy cycle, that makes me doubt the usefulness | 15:57.52 |
| Robin_Watts_ | tor8: I outlined a case the other day (serialised callbacks from another process (perhaps via RPC)) where devices might be called from different threads. | 15:58.53 |
| tor8 | Robin_Watts_: wash & go? head & shoulders? or whatever it's called. | 15:59.14 |
| Robin_Watts_ | tor8: wash and go. Didn't know if that advert had made it abroad. | 15:59.32 |
| tor8 | Robin_Watts_: yes. was that an argument in favor of binding or explicit contexts for devices? | 15:59.43 |
| Robin_Watts_ | It was an argument that I'd be using in favour of binding. I guess it would also work with explicit contexts for devices, but I'd be really against that. | 16:00.33 |
| | How about, we go with rebinding for now (minimum change to the code), and when we run into problems, you get to say "I told you so" and we can take the upheaval of changing all our APIs then ? | 16:03.06 |
| tor8 | but one of us gets to say that regardless of what we decide! ;) | 16:04.30 |
| | maybe we should let sebras and paul (and zeniko) weigh in? | 16:05.01 |
| | like I said I'm not 100% convinced either way but I am leaning towards explicit contexts in preference over binding for streams and outputs | 16:05.36 |
| Robin_Watts_ | tor8: That seems reasonable. | 16:05.41 |
| paulgardiner | Haven't been keeping up. How far back should I read? | 16:06.14 |
| tor8 | paulgardiner: the short version: explicit contexts for streams, or "rebind" calls at strategic places to swap the baked in context | 16:06.49 |
| | the rebind version is minimally intrusive, and doesn't affect a lot of current code (since our use of streams is very simple and localised to document reading) | 16:07.45 |
| | the explicit context version adds more arguments, changes the api, but makes for fewer exceptions to remember (both in which arguments are passed, and also to remember that contexts need to be rebound) | 16:08.25 |
| 23LAAPK74 | wonders why "You are now known as 23LAAPK74" | 16:23.03 |
| paulgardiner | Okay I'm up to date on the rebind stuff, I think. My feeling is that the whole use of rebind is a bit nasty, but it is preferable to adding contexts all over the place in the API. I feel, if we are going to add rebind calls at all, then it's best to use that approach for all objects that have the problem. | 16:33.43 |
| Robin_Watts_ | (I think this failed to make it to irc before) This is why I could not stay in hawaii any longer: http://www.thepoke.co.uk/2013/05/26/snaps-of-the-summer-vol-1/gallery/image/image-323/ | 16:34.27 |
| paulgardiner | My main problem with the whole thing is accepting the use of rebind at all. It's a pity to have to add that really just because of our exception handling, but at least it's something that developers can ignore other than when using multiple threads. | 16:35.40 |
| tor8 | paulgardiner: Robin_Watts_: the radical solution to this is to mandate TLS for the context and get rid of the ctx argument everywhere. | 16:37.12 |
| | but that's not really an acceptable solution, for many reasons :( | 16:37.25 |
| paulgardiner | Actually, given that multiple threads introduces a whole lot of potential problems, requiring deeper understanding of how we use contexts, perhaps rebind calls which are required only when using multiple threads isn't so bad. | 16:37.42 |
| | tor8: Oh yes, that is a lovely solution... other than probably not being possible on some platforms. | 16:38.45 |
| Robin_Watts_ | TLS would be nice if a) it was available everywhere, and b) cheap. | 16:39.15 |
| | We use the context a lot. | 16:39.25 |
| paulgardiner | oh yeah, and potentially inefficient. Still it's nice conceptionally. | 16:40.35 |
| Robin_Watts_ | Ignore "We use the context a lot" | 16:40.36 |
| | We want the exception handling to be cheap, and thus we'd need TLS to be similarly cheap. And it's often not, AIUI. | 16:41.21 |
| | So other than it not being available where we need it, and it not being fast when it is, it's ideal :) | 16:41.35 |
| henrys | This bug is certainly reason to place finger on nose ⦠but if anybody wants to weigh in ⦠http://bugs.ghostscript.com/show_bug.cgi?id=694528 | 16:44.23 |
| Robin_Watts_ | tor8: Fixed commits on robin/master | 16:47.20 |
| | (Though we should wait til sebras can weigh in) | 16:47.33 |
| henrys | Robin_Watts_: yea I don't know how folks can live there and stay in shape but it is home to a lot of athletes. | 16:55.41 |
| Robin_Watts_ | kens: OK, so it's an 8x4 dither that we hold expanded (and shifted) to give an 8x8 one. That's why it's a 32 level thing. | 17:01.18 |
| kens | Weird | 17:01.30 |
| Robin_Watts_ | But a 32 level thing shouldn't be showing up with 2 bits grey. | 17:01.37 |
| kens | Hmmm, I guess not. | 17:01.53 |
| Robin_Watts_ | mvrhel_laptop: ping | 17:28.39 |
| mvrhel_laptop | Robin_Watts_: pont | 17:31.36 |
| | pong | 17:31.38 |
| Robin_Watts_ | mvrhel_laptop: I have a threshold array question. | 17:31.52 |
| mvrhel_laptop | ok | 17:31.56 |
| Robin_Watts_ | bug 694842 has a file where an image background is showing up as dithered. | 17:32.32 |
| | The image background is not full white, but even so, I think we're wrong. | 17:32.44 |
| | The dither in question is a 32 level one, generating into an 8x8 matrix. | 17:33.09 |
| | My reasoning says that there should actually be 33 levels. | 17:33.51 |
| | i.e. for the sake of simplicity, consider it as being an 8x4 matrix, with 32 pixels. | 17:34.29 |
| | level n = n pixels set | 17:34.46 |
| | hence we have levels 0 to 32 inclusive, hence 33 levels. | 17:34.59 |
| mvrhel_laptop | Iyes | 17:36.28 |
| | yes | 17:36.29 |
| Robin_Watts_ | I could therefore understand us setting up the thresholds in 1 of 2 ways. | 17:36.35 |
| mvrhel_laptop | Robin_Watts_: it is possible that the TRC of the gray ICC profile is going to effect this also | 17:37.34 |
| Robin_Watts_ | Either the thresholds should be set every 7.72 (on average), or they should be set every 8 on average (with the top and bottom regions only having 4) | 17:37.48 |
| mvrhel_laptop | it has a 2.2 gamma like the sRGB color space | 17:37.56 |
| Robin_Watts_ | mvrhel_laptop: I don't think this is actually related to anything like that. I think the threshold table is just offset wrong. | 17:38.25 |
| mvrhel_laptop | I wonder if the result is different though with fast color enabled. | 17:38.43 |
| paulgardiner | Robin_Watts_, tor8: three commits on paul/master - adding a JavaScriptCore implementation of our pdf_jsimp API. | 17:38.57 |
| mvrhel_laptop | I guess if the output device is gray though then it will have no effect | 17:39.04 |
| | so never mind | 17:39.09 |
| Robin_Watts_ | I would have expected: level 0 = 0-3, level 1= 4-11, level 2 = 12-19, ..., level 31 = 244-251, level 32 = 252-255 | 17:39.29 |
| | Does that seem like a reasonable expectation to you? | 17:39.42 |
| mvrhel_laptop | I agree the number of levels is always n+1 where n is the size of the matrix | 17:39.44 |
| kens | Robin_Watts_ tor8 is there a way to force a commit with tabs ? I need to chane a .mak file | 17:40.10 |
| Robin_Watts_ | git commit -n | 17:40.22 |
| kens | thanks | 17:40.26 |
| Robin_Watts_ | kens: IIRC, YMMV, IANAL, etc. | 17:40.40 |
| kens | -n = no_verify | 17:41.19 |
| mvrhel_laptop | Robin_Watts_: I dont follow your reasoning of having 4 at the top and bottom | 17:41.27 |
| Robin_Watts_ | mvrhel_laptop: What values would you prefer? | 17:41.41 |
| mvrhel_laptop | this is set anyway by the screen | 17:41.44 |
| Robin_Watts_ | My point is that the top and bottom regions should be of the same size. | 17:42.17 |
| mvrhel_laptop | Robin_Watts_: I do agree that in the distribution I would expect that for a linear TRC | 17:42.48 |
| | i.e. top and bottom have the same number of levels | 17:43.05 |
| Robin_Watts_ | Right. | 17:43.22 |
| | The table we get from the file is actually: | 17:43.31 |
| | threshold array row 0= 88 120 152 184 176 144 112 80 | 17:43.43 |
| | threshold array row 1= 192 224 208 168 72 40 56 96 | 17:43.45 |
| | threshold array row 2= 232 255 240 136 32 8 24 128 | 17:43.47 |
| | threshold array row 3= 216 248 200 104 48 16 64 160 | 17:43.49 |
| mvrhel_laptop | ok well that seems ok 248 to 255 and 0 to 8 | 17:44.46 |
| | depending upon you <= >= > < use of the screen | 17:45.05 |
| Robin_Watts_ | AIUI, the pixel will be set if the value(x,y) < threshold(x,y) | 17:45.32 |
| | so the top region is a single value, 255 when all pixels are unset. | 17:45.51 |
| | hence the bottom region comprises 0-7 and the top region comprises just 255. | 17:46.42 |
| | so we do not have an 'equitable' distribution. | 17:47.01 |
| mvrhel_laptop | Robin_Watts_: if that is the way this is used, then I agree that is wrong | 17:47.39 |
| Robin_Watts_ | Well,the alternatives are: | 17:47.52 |
| | 1) that we are using > (in which case it's still mismatching) | 17:48.06 |
| | 2) that we are using <= (in which case we'll always have at least 1 pixel set) | 17:48.19 |
| | 3) that we are using >= (in which case we'll always have at least 1 pixel set) (or clear. or something) | 17:49.13 |
| mvrhel_laptop | let me see what we do hold on | 17:52.02 |
| Robin_Watts_ | (The code in gsht.c in gx_ht_construct_threshold is where it's building the table) | 17:52.49 |
| mvrhel_laptop | ok so < is what we do | 17:53.42 |
| Robin_Watts_ | And the place we use the threshold in the C version is: | 17:53.44 |
| | if (contone_ptr[k] < thresh_ptr[k]) { | 17:53.47 |
| | halftone_ptr[k] = 0; | 17:53.49 |
| | } else { | 17:53.51 |
| | halftone_ptr[k] = 255; | 17:53.52 |
| | } | 17:53.53 |
| mvrhel_laptop | so that 255 value is not going to work so well | 17:54.34 |
| Robin_Watts_ | mvrhel_laptop: The simplest fix is to 'offset' the thresholds a bit, so that top and bottom are even. | 17:55.03 |
| mvrhel_laptop | so this table is in the file? | 17:55.16 |
| Robin_Watts_ | but that will leave the top and bottom region being 4 each rather than 256/33 | 17:55.25 |
| mvrhel_laptop | and we used to render it different? | 17:55.36 |
| | I am confused by the bug report | 17:55.43 |
| Robin_Watts_ | mvrhel_laptop: No. This table is generated by gx_ht_construct_threshold | 17:55.44 |
| mvrhel_laptop | oh | 17:55.49 |
| Robin_Watts_ | When we enabled the fast thresholding code, it changed the dithering of these files slightly. | 17:56.26 |
| | when I fixed the rounding of encode/decode color, it changed it a bit more. | 17:56.43 |
| | The encode/decode change was correct, I believe. It's just the previous error there was masking this problem. | 17:57.18 |
| | and if we were using a larger dither (8x8 say), then we'd see a shadow anyway as the file is not using pure white. | 17:57.48 |
| mvrhel_laptop | ok. I see. Robin_Watts_ I am fine with you fixing this in the manner that you said. But can you leave me a open enhancement/bug to go back and check over gx_ht_construct_threshold. I would prefer to have the levels as close to the same across the range. | 17:58.53 |
| Robin_Watts_ | mvrhel_laptop: That sounds like an excellent solution. | 17:59.08 |
| mvrhel_laptop | and I will go back over this stuff. This was actually lifted from Ray's work in gdevtsep | 17:59.37 |
| Robin_Watts_ | as I a) would prefer the levels to be the same across the range, and b) would prefer not have to code it myself :) | 17:59.44 |
| mvrhel_laptop | ok great. thanks Robin_Watts_ | 18:00.01 |
| Robin_Watts_ | thank you. | 18:00.08 |
| ray_laptop | Hi, everyone. | 18:29.02 |
| Robin_Watts_ | Morning ray_laptop | 18:29.18 |
| ray_laptop | sort of here today, but may not be for all that much. | 18:29.27 |
| Robin_Watts_ | I will probably have daft questions for you in a mo. | 18:29.38 |
| ray_laptop | I'll send an email with the upshot of the earache I had Sat AM in Maui. | 18:29.54 |
| | Robin_Watts_: OK, np | 18:30.03 |
| Robin_Watts_ | ah, if you're not here, I'll email them. | 18:30.05 |
| | ray_laptop: literal earache? or metaphorical? | 18:30.31 |
| ray_laptop | paulgardiner: I noticed your responses to Righini. Is he with a supported customer ? | 18:31.04 |
| | (even among mupdf customers, there are many that are unsupported) | 18:31.32 |
| mvrhel_laptop | Robin_Watts_: so you know the windows phone GPL violators | 18:31.38 |
| Robin_Watts_ | I do. | 18:31.47 |
| mvrhel_laptop | they had put up their pro version for a bit. | 18:31.57 |
| Robin_Watts_ | I see that they released an updated version of the 'lite' version. | 18:32.06 |
| | oh, ok, I hadn't seen that. | 18:32.11 |
| mvrhel_laptop | well it was only there for a short time. | 18:32.19 |
| | I grabbed it right away | 18:32.23 |
| paulgardiner | ray_laptop: I don't know. Was I maybe being too helpful then? :-) | 18:32.32 |
| mvrhel_laptop | they pulled it, I suspect after Miles told them we would be putting up a free version of it | 18:32.43 |
| | they have since pulled their applications from the windows phone store | 18:32.55 |
| Robin_Watts_ | mvrhel_laptop: Pulled? Or Miles' takedowns took effect ? | 18:33.11 |
| mvrhel_laptop | Good question. In an email that I saw from Miles, they said they (the violators) had pulled them, but who knows what microsoft told them | 18:34.02 |
| | anyway, it is no longer on the store and I also have their code in case it goes back up | 18:34.53 |
| ray_laptop | paulgardiner: not as long as he works through the bug tracker. Also I don't know how the original stated up -- just the cc's to support | 18:35.16 |
| Robin_Watts_ | mvrhel_laptop: Cool. So I guess the next step is for someone to mail them asking about commercial licensing from a non artifex address :) | 18:35.16 |
| mvrhel_laptop | excellent idea! | 18:35.29 |
| Robin_Watts_ | ray_laptop: ISTR that the person paulgardiner was replying to was Micha on here. | 18:36.14 |
| ray_laptop | just use a gmail address | 18:36.26 |
| | Micha is M. Righini ??? | 18:36.54 |
| mvrhel_laptop | need to do expense report then tackle P1 customer bug | 18:37.14 |
| ray_laptop | not according to /whois | 18:37.23 |
| Robin_Watts_ | Micha`, not micha :) | 18:37.58 |
| ray_laptop | Robin_Watts_: I get no such nickname for that. I assumed that Micha` was just an auto extension for Micha if that was taken (like ray_laptop_) | 18:39.19 |
| Robin_Watts_ | I might be misremembering, but I thought micha`s questions matched up with the questions that came via email. | 18:39.25 |
| paulgardiner | ray_laptop: lost me there. I think the first contact was to support, but then some of his replies may have been just to me. | 18:39.37 |
| ray_laptop | paulgardiner: according to the email on 12/10, the *might* be a potential customer | 18:40.44 |
| paulgardiner | marcosw copied that to Scott, but I don't know the outcome. | 18:42.53 |
| Robin_Watts_ | oh, wait, no. It was Guest13093. Who might be marco. | 18:43.17 |
| ray_laptop | the first one I see from him is 12/9 (that cc'ed support), but your reply to him dates back to 12/3 and Robin apparently wrote to him on 12/2. IMHO, we should, at the earliest chance, send them to post bugs on the bug tracker. | 18:43.30 |
| paulgardiner | ray_laptop: ah okay. | 18:44.18 |
| ray_laptop | I think Scott is a bit frustrated with how much time and effort it takes to find out they will never be a customer | 18:44.48 |
| paulgardiner | How do we check for someone being a supported customer? | 18:45.01 |
| ray_laptop | for the majority of the mupdf "I am writing a little application that uses mupdf"... folks | 18:45.25 |
| | paulgardiner: you should get joann's customer list, but if they don't use a company email address we have to ask who they are until we get to recognize them. | 18:46.29 |
| paulgardiner | Okay | 18:46.48 |
| Robin_Watts_ | Often, we get people who 'might become customers, but are just having this problem...' | 18:47.18 |
| | I always mention the licensing to them up front, so they have been warned, and don't waste huge amounts of time working on something that can't go anywhere (and stop bothering us). | 18:48.15 |
| | If they aren't scared off by that, then I point them at Scott, but continue to help them (at low priority) in the background. | 18:48.44 |
| | Often their issues point to things we might genuinely want to fix anyway. | 18:49.06 |
| | Hi zeniko. | 18:49.28 |
| paulgardiner | I'm never quite sure how helpful to be. The replies took only 10min ish and one of the problems he pointed out we definitely need to address (the one I then forwarded more info to henrys ) | 18:49.41 |
| Robin_Watts_ | brb. just got to apply some percussive maintenance to boiler. | 18:49.51 |
| zeniko | Hi Robin_Watts, tor8 and paulgardiner | 18:49.53 |
| | I've looked through Robin's rebind changesets and am not convinced yet | 18:50.22 |
| | Having functions for rebinding implies to me that the context is relevant for keeping state in between function calls, | 18:51.12 |
| | but that doesn't seem to be the case neither for streams nor devices (nor documents?). | 18:51.38 |
| ray_laptop | paulgardiner: np. I had no idea how long it was taking, but I just saw quite a bit of traffic | 18:51.41 |
| Robin_Watts_ | zeniko: Currently, we bind the context into the document and into devices. | 18:52.00 |
| | That is held between calls. | 18:52.11 |
| henrys | woohoo! house officially sold! | 18:52.27 |
| zeniko | Would it be possible to pass in a different context for each call which takes a stream, document or device? | 18:52.29 |
| Robin_Watts_ | Yes, it would absolutely be possible to do that. | 18:52.51 |
| | That is one end of the "solution spectrum". | 18:53.00 |
| | Pass contexts explicitly everywhere. | 18:53.08 |
| ray_laptop | Robin_Watts_: I know. We get the same thing from gs prospects. So quick and dirty things get handled (and we usually point them to SO for usage issue or "this might be a bug") | 18:53.18 |
| | henrys: congrats!! | 18:53.34 |
| Robin_Watts_ | That would mean that everywhere in the code that we do a pdf_ operation (such as pdf_dict_get(...)) we'd need to pass a context as well as the doc. | 18:53.42 |
| zeniko | That would be my preference, as it makes the API contract clearer and requires less lateral thinking on the API consumer's part. | 18:53.51 |
| Robin_Watts_ | That's a MASSIVE upheaval to the code. | 18:54.02 |
| | IMHO it makes the API much worse. | 18:54.12 |
| zeniko | (I'd be fine with making the one exception for the documents for convenience and tradition) | 18:54.22 |
| Robin_Watts_ | For single threaded users, they never need to worry about the contexts. | 18:54.27 |
| | There is no issue with rebinding in single threaded use. | 18:54.42 |
| | OR... you can choose to follow the 3 laws of MuPDF, and you never need to worry about rebinding. | 18:55.12 |
| | BUT... if you want to code a multithreaded app, and you don't want to follow the 3 laws of MuPDF, then you need to rebind. | 18:55.49 |
| zeniko | BTW: Why would you not want to follow the three laws of MuPDF? | 18:56.14 |
| Robin_Watts_ | zeniko: I'm implementing JNI bindings for MuPDF at the moment. | 18:56.36 |
| | which will mean that java programmers can call the MuPDF api. | 18:56.51 |
| | As part of that, the JNI bindings will take care of the context use for you. | 18:57.10 |
| | But it means that I have to make the jni bindings cope with java programmers calling from different threads. | 18:57.41 |
| | (suppose they have something being called by RPC on worker threads, from which they make device calls). | 18:58.12 |
| zeniko | We currently use the API with a single context from multiple threads - and appropriate locking in place wherever required | 18:58.18 |
| | Isn't that possible for the JNI implementation as well? | 18:58.29 |
| henrys | ray_laptop:unfortunately the funds for furniture purchase are available to Sabrina now, maybe I should have kept that house ;-) | 18:58.31 |
| Robin_Watts_ | zeniko: Then for you, you have no issue and rebind is not an issue. | 18:58.33 |
| | zeniko: I *could* put a lock in the jni, yes. | 18:58.45 |
| | but that would stop valid multithreading use. | 18:58.58 |
| zeniko | Aren't e.g. streams inherently thread-unsafe? | 18:59.30 |
| paulgardiner | henrys: You've told Sabrina the house has sold? Big mistake. | 18:59.34 |
| Robin_Watts_ | For instance in our (mvrhel's) windows app, we draw to the screen on one thread, while drawing thumbnails from a displaylist on another. | 18:59.44 |
| | zeniko: Streams are indeed inherently thread-unsafe. | 19:00.00 |
| | But streams never get used from 2 threads at once. | 19:00.15 |
| | And suppose I have 2 documents open; I don't want working on one of them to block working on the other one. | 19:00.40 |
| zeniko | Then documents are thread-unsafe as well (as are devices?) | 19:00.40 |
| Robin_Watts_ | Indeed, documents are thread unsafe. This is what the 3 laws of mupdf are about. | 19:01.05 |
| zeniko | So you'd need one context per document (as we handle things)? | 19:01.07 |
| henrys | paulgardiner: what I've learned is that furniture is not portable. Apparently the old furniture won't run in the new house. | 19:01.22 |
| Robin_Watts_ | zeniko: You need to make one 'base' context which inits the locks and the caches etc. | 19:01.55 |
| | Currently you then 'clone' that context for each new thread. | 19:02.17 |
| zeniko | And then you clone that context for every display list you want to run? | 19:02.29 |
| paulgardiner | henrys: :-) Designed by Apple? | 19:02.35 |
| Robin_Watts_ | Yes. | 19:02.37 |
| zeniko | Are we still talking about the JNI design? If so, when would you need to rebind a document (or anything for that matter)? | 19:03.16 |
| Robin_Watts_ | The current rules say that when you create a document (or a device) the context becomes permanently associated with that device. You can only ever call that document or device from under that given context. | 19:03.19 |
| | This is the current design. | 19:03.34 |
| | The addition of rebind just allows us to change that rule a little bit. | 19:03.51 |
| | It will now be: "When you create a document (or a device) it is bound to the context with which it is created. You can use rebind to change the context to which a document is bound." | 19:05.03 |
| | i.e. we're not fundamentally changing anything, we're just giving ourselves a bit more wiggle room. | 19:05.45 |
| zeniko | Wouldn't a caller still have to ensure that a document isn't rebound while being used, effectively forcing it to remain single-threaded? | 19:06.11 |
| | (I seem not to know enough about JNI to appreciate the advantage context rebinding would have.) | 19:06.34 |
| Robin_Watts_ | Yes, the caller still has to ensure that we only call a given document once at a time. | 19:06.52 |
| | OK, so the 3 rules of MuPDF are: | 19:07.38 |
| | 1) No simultaneous calls to MuPDF in different threads are allowed to use the same context. | 19:07.54 |
| | 2) The document is bound to the context with which it is created. | 19:08.07 |
| | 3) Any device is bound to the context with which is is created. | 19:08.19 |
| zeniko | Is the idea for the JNI bindings to use a single base-context for creating documents and then rebinding all documents to use one context each so that multi-threading between documents gets possible? | 19:08.22 |
| | So that you don't have to create an entirely new context for each document which should be somewhat more memory efficient? | 19:09.15 |
| Robin_Watts_ | Rule 1 coupled with 2 and 3 implies that documents and devices cannot be called into simultaneously on 2 different threads. | 19:09.35 |
| | All we are doing with rebind is to allow documents to change the context with which they are created. | 19:10.06 |
| | So, why do we need this for JNI? | 19:10.12 |
| | With the Java bindings, all the context cloning etc is hidden inside the JNI level. | 19:10.49 |
| | The JNI level automatically clones a new context for every new thread under which it is called (using the magic ThreadLocalStorage java stuff) | 19:11.17 |
| | As such a java user is freed from worrying about which thread he is in. | 19:11.50 |
| | I still intend to use java synchronisation to ensure that no one calls twice into the same document. | 19:12.16 |
| | but it would be perfectly possible (and reasonable) for a java programmer to make calls to a document from several different threads. | 19:12.45 |
| | The syncronisation means that only one call at a time will take place. | 19:13.00 |
| zeniko | short break, bbiaw | 19:13.32 |
| Robin_Watts_ | but the JNI needs to 'rebind' the context each time to ensure that we aren't inadvertantly calling in with a context that is in use elsewhere. | 19:13.34 |
| ray_laptop | Robin_Watts_: BTW, given the examples that cust 801 sent, I think I have the padding correct now. I'm throwing together an applet to convert it to see if I can get it to work with both theirs (that works) and my fixed result | 19:22.14 |
| Robin_Watts_ | ray_laptop: Cool. | 19:23.51 |
| | ray_laptop: Dunno if you read the logs earlier with my discussion with mvrhel_laptop | 19:24.09 |
| | Bug 694842 is about dithering problems. | 19:24.39 |
| | I've tracked it down to the way we generate threshold tables. | 19:24.50 |
| | Specifically, gx_ht_construct_threshold | 19:25.08 |
| | which is lifted from code you wrote (I believe) threshold_from_order in gdevtsep.c | 19:25.29 |
| henrys | ray_laptop:feel free to reassign stuff and get some rest. | 19:26.03 |
| Robin_Watts_ | The problem with it is that it doesn't generate the levels 'evenly'. | 19:26.35 |
| zeniko | Robin_Watts_: Right, so you want to allow changing from "one context per document/device" to the "one context per thread". | 19:26.52 |
| Robin_Watts_ | ray_laptop: Ouch. Just read your email. If you want to throw anything my way, feel free. | 19:26.57 |
| | zeniko: exactly. | 19:27.09 |
| zeniko | Even though you then still have to lock for each document/device call | 19:27.24 |
| Robin_Watts_ | The point about this change is that it doesn't have to affect anyone. | 19:27.29 |
| | If they had code that worked before, it will still work in the future. | 19:27.45 |
| | If they don't care about multithreading, it won't even cross their radar. | 19:28.02 |
| zeniko | Things start to make more sense now, | 19:28.28 |
| Robin_Watts_ | but if they do care about multithreading, it might just give them the scope to do what they need in a more natural way. | 19:28.31 |
| | Now there is a "solution spectrum" here. | 19:28.45 |
| | At one end there is "make the context explicit everywhere". | 19:28.59 |
| zeniko | guess I'm just slightly wary about "one context per thread" because it feels more fragile (since the context is no longer guaranteed for a document/device) | 19:29.15 |
| Robin_Watts_ | At the other end there is "use rebind everywhere". | 19:29.15 |
| | and in the middle there is "use rebind in some places, but move some things to explicit contexts" | 19:30.04 |
| | zeniko: There is no code that would have been valid before that would not be valid now. | 19:31.06 |
| zeniko | Is that middle ground around the line of "use context where calls are thread-safe and rebind where they're not"? | 19:31.25 |
| Robin_Watts_ | You might argue that rebind gives people a bit more rope to hang themselves with. | 19:31.26 |
| | zeniko: No, the middle ground is "make contexts explicit on every fz_stream and fz_output call, but use rebind for documents and devices" | 19:32.00 |
| | or something like that. | 19:32.04 |
| | In practise, everyone I know that has implemented a multithreaded app for MuPDF has taken the 'one context per thread' route. | 19:33.21 |
| zeniko | Everyone but us? | 19:34.13 |
| Robin_Watts_ | (by which I mean 'an app that calls MuPDF from multiple threads without having added locks to ensure that MuPDF is effectively being called single threaded") | 19:34.34 |
| | I count you as a single threaded app, due to your use of locks. Would you say that's fair? | 19:35.09 |
| zeniko | Given the pains we've had where locks were missing, I wouldn't quite agree ;-) | 19:36.01 |
| Robin_Watts_ | zeniko: I'm not seeking to minimise the quality of your app here. | 19:36.58 |
| | I'm just saying that (AIUI) your app works by adding explicit locks around MuPDF calls, so all calls are serialised, and MuPDF can safely be called with a single context. | 19:37.48 |
| zeniko | No worries, I've looked into using different context for rendering on separate threads, but that didn't fit well with our overlying API (which abstracts MuPDF's details away) | 19:37.58 |
| Robin_Watts_ | So it's a 'single context' application. | 19:38.04 |
| | Everyone who has written a MuPDF application that makes multiple concurrent calls to MuPDF has gone down the 'one context per thread' route. | 19:38.52 |
| | And that means that they have had to be careful to create documents and then only to use them within the same thread. | 19:39.24 |
| | So rebind would give them a little more rope, but I don't see it as something that will make the system particularly more fragile. | 19:39.56 |
| zeniko | Nitpicking: We use a single context per document, still allowing multiple concurrent calls into MuPDF for different documents. | 19:40.20 |
| Robin_Watts_ | zeniko: OK. | 19:40.38 |
| zeniko | But yeah, I see that this is quite different usage from what I'm used to. | 19:40.47 |
| Robin_Watts_ | So rebind wouldn't affect you at all. | 19:41.05 |
| zeniko | Well, it affects me to the point where I have to wrap my head around it to make sure it's nothing we have to use ;-) | 19:41.58 |
| Robin_Watts_ | :) | 19:42.20 |
| | I have to step out for 20 minutes. | 19:42.29 |
| zeniko | Sure, thanks for the lengthy walkthrough, | 19:42.43 |
| Robin_Watts_ | No worries. | 19:42.49 |
| | ray_laptop: Could I trouble you to look at: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=6ad80bf15855cf2ea52a80a1997ed51420642f4c if you get a mo/feel up to it etc? | 19:43.20 |
| zeniko | I guess I'd then be fine with rebind instead of having to pass a context even in places where concurrent calls with different contexts aren't supported (for document, device and even streams) | 19:43.25 |
| Robin_Watts_ | Great, thanks. | 19:44.07 |
| | bbiab. | 19:44.40 |
| ray_laptop | Robin_Watts_: Is this in response to a bug ? (the log message doesn't say). I'm guessing 694842 ? BTW, we should get PacificLife to sign up for a support contract :-) | 20:05.30 |
| | Robin_Watts_: nm. I see the bug number in the header. I'm not used to looking at git commitdiffs on the browser | 20:08.57 |
| | Robin_Watts_: the change looks fine to me. If mvrhel_laptop has an issue I assume he will weigh in. | 20:09.36 |
| Robin_Watts_ | ray_laptop: The worry I have is that I have taken no account of nshades in my calculations. | 20:13.22 |
| | And I have no idea what all the t_level_adjust/delta/delta_dum fraccery is all about. | 20:14.02 |
| Robin_Watts_ | was bought "The British Medical Association Complete Family Health Encyclopedia" as a wedding present. | 20:16.25 |
| | Or as we now refer to it, "The Bumper Book of Diseases" | 20:16.52 |
| | I recommend it as an excellent gift that will turn people into hypochondriacs. | 20:17.21 |
| ray_laptop | Robin_Watts_: OK, I'll have a look at nshades and see if I can make any sense of it | 20:18.02 |
| mvrhel_laptop | ray_laptop: good grief | 20:18.42 |
| ray_laptop | Robin_Watts_: I tend to ignore most things. Some things are hard to ignore. My wife is the one that goes on the internet to try and dig out diseases. | 20:18.47 |
| mvrhel_laptop | just read your email | 20:18.49 |
| | that one must have been a little scary | 20:19.00 |
| ray_laptop | I got tired of being called "dengue-ray" :-) | 20:19.10 |
| mvrhel_laptop | almost stroke like symptons | 20:19.14 |
| Robin_Watts_ | ray_laptop: According to the book of doom here, corticalsteroids or ACTH, analgesics for any pain, and it should resolve without anything else. | 20:19.52 |
| ray_laptop | mvrhel_laptop: no kidding. The only thing that relaxed me a bit (I took a shower before heading to the ER) was I had no weakness on the left side | 20:19.59 |
| Robin_Watts_ | So it sounds like your Doctor was right :) | 20:20.04 |
| ray_laptop | still, the recovery time can be substantial | 20:20.12 |
| mvrhel_laptop | well I wish you a speedy recovery. luckily things should be slow work wise this time of year | 20:20.38 |
| Robin_Watts_ | Some people will do anything so they can get in the "first group to board the plane" :) | 20:20.47 |
| ray_laptop | It may be from Ramsey-Hunt syndrome. I _thought_ I had gotten the "shingles shot", but either I hadn't or it didn't take | 20:21.08 |
| | mvrhel_laptop: I hope so. At least, now that the fever's gone I feel more or less human. Or at lease, feel more human than I look | 20:22.10 |
| mvrhel_laptop | ray_laptop: it must be something about hawaii. I think the last time we went, my wife had shingles. | 20:22.44 |
| | right after we got there | 20:22.50 |
| ray_laptop | Robin_Watts_: hopefully it'll be while before I need boarding assistance again. The last time was when I had to fly back from STL -- a 4 hour filight-- just 4 days after achilles tendon repair surgery | 20:23.37 |
| Robin_Watts_ | ray_laptop: I'm amazed they let you fly. | 20:23.58 |
| | leg problems == risk of DVT. | 20:24.33 |
| | Helens Grandfather died of a PE caused by a DVT after flying back from holiday. | 20:25.14 |
| ray_laptop | why not ? It's not like I was moaning in pain or anything. I took a pain pill, and slept the whole way. I did have a bulkhead seat and once we took off, I had my leg propped up on a carry on. | 20:25.28 |
| Robin_Watts_ | And my uncle died of a DVT caused by poor aftercare after (I think) knee surgery. | 20:26.24 |
| ray_laptop | Robin_Watts_: well, this was when I was quite a bit younger, back in about '96 | 20:26.31 |
| Robin_Watts_ | I suspect the whole DVT thing wasn't so well known back then. | 20:26.48 |
| ray_laptop | yeah, way back in 96 | 20:27.02 |
| | my cousin (about 6 years younger) had shoulder surgery about 8 yrs ago and got a PE. He recovered and is fine now. | 20:28.06 |
| | I was quite good about keeping my ankle elevated above my heart (throbbed less that way), and after about a week I started pushing down with my toe to stretch it (which pumps the calf muscle). I found out that every 2 weeks they take the cast off and put a new one on that is nearer to 90 degrees. I didn't want it to be excrutiating in the office | 20:31.57 |
| Robin_Watts_ | A friend went through the snapped achilles tendon thing last year. | 20:34.28 |
| | Fortunately it didn't completely break (tiny strands were left connected) so she avoided needing surgery. | 20:34.56 |
| | But it was a long slow recovery. | 20:35.04 |
| | Do you routinely break mirrors, walk under ladders, curse strange gods etc? | 20:35.41 |
| | ray_laptop: Helen sends her wishes for your speedy recovery too. | 20:36.55 |
| ray_laptop | Robin_Watts_: Thanks | 20:41.21 |
| | Robin_Watts_: from what I was told, a partial rupture the the achilles is *MUCH* more painful. Mine didn't really hurt (until after the surgery) | 20:42.16 |
| | Robin_Watts_: I don't think you have to worry about nshades -- that's for max_gray (for example) being greater than 1, but the threshold array is the same. EG. if max_gray = 16 then it uses th threshold array to dither between the two closest gray levels, maybe level 0 and level 1 if contone value is < 255/16 | 20:46.09 |
| Robin_Watts_ | I was thinking that maybe the offset would be less in the nshades case? | 20:48.34 |
| ray_laptop | Robin_Watts_: Oh, I see. Well, for the 0..1 (out of 15) having 4 at the start is OK, but you are right that it will be a little 'compressed' near the top of the 0..1 range and at the bottom of the 1..2 range | 21:03.01 |
| | Robin_Watts_: so, for nshades > 1, off == 0 ? | 21:03.34 |
| | Robin_Watts_: part of the problem is having a value of 255 on and additive device makes it very hard to get all white. | 21:05.28 |
| | but on a subtractive device (CMYK) having 8 as the lowest value makes it easy to get white. | 21:07.05 |
| | no, wait. That doesn't make sense. If we set a pixel when contone < threshold value that's not white. It must invert for SUBTRACTIVE | 21:09.39 |
| | my brain is fading. I think I need to take a break and get some lunch. bbiab | 21:10.35 |
| | mvrhel_laptop: do you want to have a look at Robin's patch w.r.t max_levels > 1 ? | 21:11.33 |
| kens | henrys ping | 21:42.01 |
| | OK for the logs; henrys can you take a look at this please ? I don't recall a -C switch: | 21:42.48 |
| | http://stackoverflow.com/questions/20620341/count-pages-in-pcl-with-ghostpdl-9-x | 21:42.48 |
| henrys | kens:for the logs I got rid of it sometime back - I thought folks could just use -sDEVICE=bbox and count the number of output lines - the bbox output is the same as ghostscript. | 22:23.53 |
| ray_laptop | Robin_Watts_: just how much less than 255 is the value they want rendered with no dots ? | 22:43.49 |
| | Robin_Watts_: IMHO, relying on a limited number of levels in a halftone to map near white to white is wrong. If they were to use 'stocht.ps' (the ht_ccsto.ps stochastic dither pattern, it has a full num_levels = 256 | 22:45.40 |
| | Robin_Watts_: I think we need to look into having them use a transfer function. Let me have a look at the PDF they supplied | 22:48.11 |
| | Robin_Watts_: BTW, the PDF ref 6.4.1says: A gray value g in the range 0.0 to 1.0 is produced by making i pixels white, where i = floor (g à n). Not all that clear to my currently fuzzy head. | 22:49.49 |
| | Robin_Watts_: and for halftones defined in the PDF as threshold arrays (6.4.3) it says:If the requested gray level is less than the threshold value, paint the device pixel black; otherwise, paint it white. Gray levels in the range 0.0 to 1.0 correspond to threshold values from 0 to the maximum available (255 or 65,535). | 22:52.19 |
| | with the note that value 0 in is always black | 22:52.40 |
| | In PDF halftone dictionaries have an optional TransferFunction that is what should be used to map values near white to white | 22:54.24 |
| | Robin_Watts_: I found that with the stocht.ps we produce better quality (smoother) screens and the white problem isn't there. Maybe OK since we don't have to construct the threshold ? but the image had 0xFE and 0xFD in the background, so I am surprised | 23:46.01 |
| | Forward 1 day (to 2013/12/17)>>> | |
IRC Logs