| | <<<Back 1 day (to 2012/02/07) | 2012/02/08 |
| sebras | tor8 henrys: the mupdf.apk installed fine on my HTC Sensation and works ok. There are however bugs | 01:19.42 |
| | When I search for a word which is in the page by writing the word on the onscreen keyboard and pressing enter nothing happens. | 01:20.16 |
| | I have to press the next/back buttons for it to actually search. | 01:21.17 |
| | When a search hit is found, the page is not scrolled to the correct region if I have zoomed in. | 01:21.57 |
| | Also after having located the highlighted area, I attempted to search for a word which was not in the pdf at which point the previous search hit was still highlighted and a dialog box appeared to tell me that no hits could be found. | 01:23.45 |
| | Finally, on such a small screen fullscreen mode seems important to me, but I can not find any way to toggle this. | 01:25.18 |
| henrys | mvrhel,Robin_Watts:is one generation long edge and the other short edge. | 01:44.17 |
| | ? | 01:44.45 |
| sebras | tor8 Robin_Watts: Some more documentation done on sebras/doc. All basic functions are document except fz_run_page (mostly because I'm too tired to write something sensible about cookie, but I will get back to it soon). | 02:01.38 |
| | zzz. | 02:02.33 |
| | it's, oh, so quiet... it's, oh, so still... I'm all alone... | 11:06.30 |
| Robin_Watts | sebras: Watch out for that tumbleweed! | 11:06.53 |
| sebras | Robin_Watts: *whistling* wah-wah-waahhhh... | 11:07.23 |
| | Robin_Watts: I moved your exception explanation to doc/overview.txt, I'm not sure you noticed. | 11:07.55 |
| Robin_Watts | sebras: I haven't looked yet. Been in lock hell for the past couple of days. | 11:08.26 |
| sebras | Robin_Watts: np. | 11:09.42 |
| t4nk741 | a | 11:14.12 |
| Robin_Watts | Did someone collapse onto their keyboard? :) | 11:21.55 |
| tor8 | Robin_Watts: ugh, raed's questions drive me crazy. | 13:09.22 |
| | anyway, he's sent a file asking where is the link border color and dash pattern in the fz_link struct, when we don't even draw the borders for said annotations because they don't have an appearance stream. | 13:10.02 |
| chrisl | tor8: you ain't seen nothin' yet - wait until he's asked he same thing four times, then you can start complaining! | 13:17.41 |
| tor8 | chrisl: oh, I'm only on the third time so far ;) | 13:18.04 |
| chrisl | he's definitely someone I would rather leave to Marcos..... | 13:18.30 |
| tor8 | I'll ping Marcos next time he asks me a question then... | 13:21.09 |
| chrisl | The trouble is, when it starts getting very detailed, Marcos may not be best equipped to deal with him :-9 | 13:22.36 |
| | :-( is what I meant.... | 13:22.47 |
| chrisl | needs to go out for a while | 13:23.43 |
| Robin_Watts | tor8: Yeah, he does seem incapable of accepting certain statements. | 14:02.58 |
| kens | reboot, brb | 14:21.27 |
| henrys | kens:the hpgl->pdfwrite I was thinking of turns out to be a general performance issue... as/if this project progresses raster ops are going to become the issue. We just can't pass the genoa tests without that and I think they are going to require it eventually. | 14:42.28 |
| | and I have no idea how to do it other than rasterizing relevant parts of the file. | 14:43.58 |
| kens | henrys some raster ops may be reproducible using PDF transparency and other trickery, but in the general case we will *not* be able to produce a PDF file with raster ops in it. We will have to render an image and include that. | 14:44.58 |
| | There are a number of problems with that, not least that there is no way to 'anticipate' transparency. So how do we know when to start/stop rendering the image ? | 14:45.51 |
| | I suppose we coul always render a band of the entire page, and use some kind of bbox accumulation to decide how big an image to cut out of it. | 14:46.27 |
| henrys | sort of curious what swiftview does. | 14:48.01 |
| kens | Well if you ask for a copy of its PDF outptu I could investgate teh PDF file. | 14:48.24 |
| henrys | I should go ahead and buy it I had a trial but it expired. | 14:51.32 |
| kens | I think it would be useful to have a copy available, to answer these questions and for comparison of our own output. | 14:51.58 |
| henrys | anyway this isn't definitely needed just though I'd give you time to mull it over in case it is. | 14:52.13 |
| kens | Well I do know that some uses of raster ops can be handled as masks, and some can 'probably' be done with transparency. But the general case is simply impossible to do without rendering. THough I would be intrigued to see how other developers have chosen to handle it. | 14:53.17 |
| henrys | I'm pretty confident they punt to image or get it wrong but let's check. | 14:54.13 |
| kens | I'm inclined to agree, but its definitely worth checking. | 14:54.28 |
| henrys | off to buy swiftview | 14:54.28 |
| kens | henrys is there anything you want me to do about this in the next couple of days ? | 14:55.01 |
| henrys | no it is something to think about while you ski ;-) | 14:55.21 |
| kens | I'll probably be too busy not hitting anything :-) | 14:55.36 |
| Robin_Watts | Presumably swiftview must parse to an internal format, then write that out. | 15:04.26 |
| kens | Why ? | 15:04.42 |
| Robin_Watts | While you have it in the internal format, you can run through looking for transparency. | 15:04.56 |
| | taking the bbox of the area that needs it etc. | 15:05.13 |
| kens | That's a possible solution, and it did occur to me that a 2-pass solution would work for us too. | 15:05.19 |
| | I need to dash out and buy a Valentine's card to take on holiday with me, or I'll be in trouble next week, back shortly. | 15:08.58 |
| henrys | we'll see if they'll sell it to me, I have to fill out forms and they review them. | 15:09.47 |
| | Robin_Watts:I was asking wondering night if the there was a difference in paper feed direction for 5th gen vs. 5th gen that would explain a dramatic slowdown in the sort of image you describe. | 15:24.14 |
| | 5th gen vs. 6th gen | 15:24.34 |
| Robin_Watts | henrys: I haven't got a clue. I have never seen a 5th gen. | 15:24.39 |
| | I suspect that they probably just don't break images down into scanlines in the way we do. | 15:25.06 |
| henrys | I guess they aren't very eager to sell swiftview - I had to call in to give them my credit card and they weren't there, I left a message. | 15:37.12 |
| | caffeine and sudafed are needed. | 15:37.26 |
| malc_ | tor8: the only way to get mupdf for ios is to promise apple ones firstborn, right? | 15:41.28 |
| sebras | malc_: http://itunes.apple.com/us/app/mupdf/id482941798?mt=8 | 15:42.49 |
| Robin_Watts | malc_: It's a free download from itunes (as sebras is pointing out). | 15:44.39 |
| malc_ | Robin_Watts: needs an AppleID which requires aforementioned firstborn, no? | 15:45.00 |
| | sebras: thanks btw | 15:45.07 |
| Robin_Watts | This does mean that all Tor8's offspring unto the 4th generation are promised to the cult of jobs though. | 15:45.12 |
| | malc_: You need to have signed up for an itunes account. | 15:45.37 |
| | but then there ain't much point in owning an iOS device if you haven't done that... | 15:45.53 |
| malc_ | i don't own an iOS device, my mom does though :) | 15:46.46 |
| henrys | somebody reported xps problems ??? wow that's a surprise | 15:47.11 |
| | I guess it is the only xps viewer for the iphone so that's where we are going to get feedback | 15:49.29 |
| tor8 | malc_: if you have a jailbreaked ios device and have the know-how to build unsigned apps with Xcode you can probably get around it | 16:25.25 |
| | but it's a lot more hassle than it's worth | 16:25.30 |
| Robin_Watts | tor8: sanity check please. | 16:39.13 |
| | pdf_load_shading_dict; for a type4 shade, we open the stream, then call pdf_load_type4_stream | 16:39.48 |
| | pdf_load_type4_shade, sorry. | 16:39.58 |
| | That then calls pdf_load_mesh_params, that can move the file pointer anywhere else it feels like. | 16:40.22 |
| | Then it starts to read from the stream. | 16:40.34 |
| | Surely that's unsafe ? | 16:40.43 |
| tor8 | Robin_Watts: sebras last touched that code, but I'll double check | 16:41.34 |
| | Robin_Watts: in general it should be safe, but there's no guarantee | 16:42.08 |
| | since the dict that load_mesh_params reads from is the same as the stream dictionary | 16:42.23 |
| | so it should already be loaded. but if any of the fields are indirect references it'll bomb as you say | 16:42.38 |
| Robin_Watts | Well, I have a case here (tests_private/pdf/sumatra/2.7.1colorpatch-devn_x1a.pdf) where the pdf_load_mesh_params is resolving an indirect reference. | 16:42.43 |
| tor8 | so it should be fixed | 16:43.04 |
| Robin_Watts | I'm going to move the stream open into those functions., | 16:43.19 |
| ray_laptop | Robin_Watts: I haven't made any progress on the image rotation stuff since they yanked my chain back to a 'critical' bug on the currently shipping product | 16:45.34 |
| Robin_Watts | ray_laptop: Well, if I get out of locking hell, I can try to have a look. They are multiplying in my skype contacts list... | 16:46.23 |
| ray_laptop | Robin_Watts: so FT needs locking around glyph rendering ? | 16:47.23 |
| Robin_Watts | Yes, but that's the least of it :) | 16:47.37 |
| ray_laptop | Robin_Watts: that'll affect GS if we ever enable multiple parsing threads | 16:47.52 |
| chrisl | No it doesn't, but you need to create a Freetype instance per thread | 16:48.18 |
| Robin_Watts | s/Yes/The way we use it, Yes/ | 16:48.52 |
| ray_laptop | chrisl: I was just skimming the IRC logs and thought that was the issue -- so mupdf doesn't create an instance per thread ? | 16:49.10 |
| | Robin_Watts: what does mupdf do for ICC color conversion ? | 16:49.37 |
| Robin_Watts | Uses the alternate. | 16:49.49 |
| chrisl | I guess not - Robin_Watts: is there a reason why mupdf doesn't create an ft instance per mupdf context? | 16:49.55 |
| Robin_Watts | chrisl: I have no idea. | 16:50.28 |
| chrisl | Can't argue with that! | 16:50.43 |
| Robin_Watts | I've never touched the freetype handling code. | 16:50.45 |
| | But wouldn't that mean having to open the fonts once per thread? | 16:50.58 |
| | which sounds like a bad thing to me. | 16:51.13 |
| chrisl | I wouldn't expect multiple threads to be accessing the same fonts *too* often | 16:52.19 |
| henrys | chrisl:are you handling cygwin port issues? | 16:52.49 |
| Robin_Watts | chrisl: Eh? I'd expect it all the time. | 16:53.05 |
| | Suppose I'm using 2 different threads to render 2 halves of a page... | 16:53.23 |
| chrisl | henrys: do we have cygwin port issues? | 16:53.29 |
| ray_laptop | Robin_Watts: does mupdf use lcms ? (that's why I was asking about the ICCBased). BTW, the Alternate is optional. And what about Lab ? | 16:54.00 |
| henrys | I was reviewing shellys stuff and this falls under jbig2dec - 691555 | 16:54.15 |
| Robin_Watts | mupdf does not use lcms. | 16:54.36 |
| henrys | seems like I should assign it to you. | 16:54.42 |
| chrisl | Robin_Watts: I'd expect the front end to push glyphs into the cache, and multiple threads to execute a display list which would access the cache | 16:54.44 |
| | henrys: is that the one about the DLL? | 16:54.58 |
| henrys | you're probably thinking of 691784 | 16:55.22 |
| ray_laptop | chrisl: so you'd need to lock the cache for every access | 16:55.32 |
| | chrisl: or (yuck) have a lock on each cache slot | 16:56.07 |
| chrisl | ray_laptop: only writing, you should be able to read without locking | 16:56.14 |
| Robin_Watts | chrisl: We lock/unlock on every char lookup. | 16:56.34 |
| ray_laptop | chrisl: not if the writing decides to use the slot someone else is reading | 16:56.35 |
| chrisl | ray_laptop: true, so it depends on how the cache works | 16:57.02 |
| hypnocat | what's a good postscript viewer for windows? | 16:57.06 |
| ray_laptop | hypnocat: GSView uses Ghostscript. | 16:57.23 |
| chrisl | henrys: I need to do some work on the jbig2dec builds anyway, so just assign 691555 to me, yes | 16:57.49 |
| hypnocat | was that a recommendation? :) | 16:57.51 |
| ray_laptop | hypnocat: and I think the later XnView will use ghostscript for PS (if it finds gs installed) | 16:57.57 |
| | hypnocat: I just use gswin32c from the command prompt :-) | 16:58.22 |
| | hypnocat: but the GSView is a GUI based front end that many that don't understand ghostscript find easier | 16:59.06 |
| hypnocat | thanks | 16:59.48 |
| ray_laptop | hypnocat: at least until Artifex does a better GUI front end, I think GSView is the best | 16:59.51 |
| | well, back to working on cust 532 "regressions" | 17:00.37 |
| henrys | ray_laptop:do you have a link to a "5th generation product" as a customer would see it? | 17:02.22 |
| | I guess you should send that privately. | 17:02.37 |
| | nvm google works | 17:03.29 |
| ray_laptop | henrys: I don't know exactly which model they are using -- they mentioned that it is a 5thgen+ so it is not the most basic model | 17:05.14 |
| henrys | just concerned they are making some stupid comparison like resolution, page feed orientation or something and not making a proper comparison but I suppose you've dismissed that. | 17:06.48 |
| | all shelly is nearing the end of the jbig2 job - if you can think of other suitable stuff for him to work on please speak up. | 17:08.07 |
| ray_laptop | henrys: I know the 6thgen is short edge feed, and the low end monochrome machines are also, but I haven't asked about feed direction. | 17:09.36 |
| henrys | I sort of thought about that with your rotated image issue, been hit with that in a previous life. | 17:10.29 |
| ray_laptop | henrys: it is interesting that we "blow them out of the water" for the 50_blank_pages file. We still don't understand that. Also we were slower on blank pages than they were on the WW files (that have text). | 17:12.17 |
| | henrys: that bit of confusion was in Eric's email from 1/23 4:59pm | 17:13.31 |
| | henrys: they were taking 85 seconds to do blank pages, and only 74 for pages with text | 17:14.14 |
| henrys | is the paper black to start with ;-) | 17:14.44 |
| ray_laptop | henrys: that's cust 661's technology (white writing) ;-) | 17:15.54 |
| | they charge the entire drum and discharge with the laser where they want white | 17:16.59 |
| henrys | that does sound quite peculiar and calls into question how good there measurements actually are. | 17:17.26 |
| ray_laptop | henrys: yes, I agree -- we've gotten strange things on occassion, but when they send us profiles, that's really the best. | 17:18.23 |
| henrys | chrisl:release today? I wanted to get back to the lawyer with a pointer to the docs. | 17:20.24 |
| chrisl | henrys: it's done, I just haven't sent an announcement yet | 17:22.35 |
| henrys | great thanks | 17:23.29 |
| mvrhel | ray_laptop: I think at the last meeting I was tasked with getting ICC stuff in place in mupdf. Have not made much progress on that though :( | 17:32.42 |
| kens | Tim to go, night all | 17:37.56 |
| mvrhel | bye kens | 17:38.04 |
| Robin_Watts | Night tim :) | 17:38.17 |
| ray_laptop | mvrhel: now you'll have to make sure it's thread safe as well. :-( If you had done it earlier, Robin_Watts would have gotten stuck with fixing that ;-) | 17:44.45 |
| mvrhel | good point | 17:44.58 |
| | he might still get stuck doing it though... :) | 17:45.20 |
| Robin_Watts | ray_laptop: He still has time :( | 17:45.23 |
| chrisl | Just lock on every lcms call - that'll work...... | 17:45.52 |
| ray_laptop | Robin_Watts: probably not enough to put ICC conversion into mupdf before March | 17:45.54 |
| mvrhel | no I am not quite that fast | 17:46.12 |
| ray_laptop | chrisl: that's pretty much what gs does | 17:46.20 |
| chrisl | ray_laptop: we ought to be able to change that, once we shift fully to lcms2, shouldn't we? | 17:47.02 |
| mvrhel | I have not looked to see if lcms2 is thread safe in profile and link access. My guess is that it is not | 17:47.41 |
| ray_laptop | chrisl: I don't recall if lcms2 is thread safe -- lcms1 sure wasn't | 17:47.42 |
| Robin_Watts | lcms2 is supposedly thread safe, yes. | 17:48.11 |
| mvrhel | hmm. I will check into that | 17:48.39 |
| ray_laptop | mvrhel: well, we have time to beat on it before 9.06 in August :-) -- Does Marcos use NumRenderingThreads > 1 on any testing ? | 17:49.57 |
| mvrhel | good question | 17:50.09 |
| sebras | Robin_Watts tor8: I'm a bit baffled that it is that pdf that triggers the file position problem... I'm sure we've used that one in testing for the shadings! | 17:59.00 |
| | when developing the shading code... | 17:59.14 |
| Robin_Watts | sebras: It's odd, but undeniable. | 17:59.36 |
| sebras | Robin_Watts: has it been filtered through some tool perhaps..? | 17:59.58 |
| Robin_Watts | no, it's exactly as checked into our repo. | 18:00.18 |
| ray_laptop | oh, darn -- the fixed annots.pdf didn't make 9.05 :-( | 18:01.36 |
| | mvrhel: but thanks for fixing it :-) | 18:01.46 |
| mvrhel | sorry about that | 18:01.56 |
| ray_laptop | mvrhel: not a big deal -- it's been broken since day 1 | 18:02.21 |
| mvrhel | so right now the warnings from lcms get displayed when we are in debug mode. I like that but I do understand how it could be noisy for files that have a lot of ICC issues. Would you prefer it only displayed them if we have the icc debug flag set? | 18:03.25 |
| | ray_laptop: ^^ this is about bug 692827 | 18:03.47 |
| Robin_Watts | isn't offended by them, unless they are spurious warnings. | 18:03.59 |
| mvrhel | define spurious for me | 18:04.12 |
| | they do mean that the profile is not going to be used | 18:04.33 |
| Robin_Watts | A warning that occurs when it shouldn't. | 18:04.37 |
| ray_laptop | mvrhel: no, I just thought I had broken something when testing the %d output from annots.pdf | 18:04.46 |
| mvrhel | they are real warning. the profiles are invalid | 18:04.50 |
| Robin_Watts | That sounds absolutely non-spurious! | 18:04.54 |
| mvrhel | ok | 18:04.59 |
| ray_laptop | mvrhel: but as long as I know to ignore them its OK | 18:05.04 |
| Robin_Watts | are the profiles broken in a known way? | 18:05.15 |
| sebras | Robin_Watts: it may be the case that sumatra folks changed the file. I'll have look when I get home. | 18:05.19 |
| mvrhel | they are missing stuff in the headers. in this particular case, the signature number | 18:05.42 |
| Robin_Watts | i.e. is it that they are broken because lcms is insisting on following the letter of the spec and other things cope OK ? | 18:05.50 |
| mvrhel | not sure who would make a profile without that | 18:05.53 |
| | well, we cope in that we fall back to the default space. | 18:06.08 |
| | AR does this too | 18:06.11 |
| Robin_Watts | 'Well, it worked with out profile reading code' :) | 18:06.15 |
| | Ah, we do the same as AR? Perfect. | 18:06.20 |
| | s/out/our/ | 18:10.55 |
| mvrhel | I understood. And yes, this was probably the case | 18:11.27 |
| Robin_Watts | OK, all the pdf files from sumatras test suite are passing my locking tests. | 18:14.22 |
| | Now to figure out why the xps ones are whinging. | 18:14.34 |
| mvrhel | blue screen on my desktop machine.. :( | 18:53.42 |
| Robin_Watts | tor8, sebras: ping | 18:55.40 |
| | I've just pushed a commit to my local repo that changes the locking in MuPDF. | 18:56.09 |
| | I'd appreciate it if you could cast your eyes over it to see how much it offends you. | 18:56.32 |
| | The commit message should explain most of it. | 18:56.51 |
| mvrhel | another blue screen upon launching the profiler. Apparently I need some hot fixes. http://social.msdn.microsoft.com/Forums/hu-HU/vstsprofiler/thread/03a058af-3832-4940-b00b-56ac911507dd | 19:01.03 |
| Robin_Watts | Nehalem - what's that in real money? | 19:01.54 |
| | i7, right, so not me. | 19:02.25 |
| mvrhel | I hope this fixes the issue | 19:05.32 |
| | yeah! no blue screen | 19:08.54 |
| | sheesh | 19:08.56 |
| tor8 | Robin_Watts: the pdf_open_stream lock, it probably won't work with nested streams. fortunately we don't actually read nested streams that way. | 19:13.17 |
| | Robin_Watts: I'm talking about content streams that contain inline image data | 19:13.38 |
| Robin_Watts | Inline image data is done another way, and we do cope OK with that way of working. | 19:16.21 |
| | If you can see a nicer way of achieving what I'm doing, then please say! | 19:17.25 |
| tor8 | pdf_load_inline_image calls pdf_open_stream, so it wouldn't work | 19:18.05 |
| | it works now because we preload content streams into a buffer | 19:18.14 |
| | and no, I'm not seeing a nicer way :) | 19:18.28 |
| Robin_Watts | tor8: The general locking scheme seems sane to me (and it's nicely extensible if we need more locks in future) | 19:20.22 |
| | I would have preferred that the lock/unlocks for the file lock were a bit less invasive, but they aren't *that* bad. | 19:21.06 |
| | tor8: So... no objections from you to me pushing that to the main repo ? | 19:32.29 |
| tor8 | haven't studied all the details, but in general, nothing objectionable, no | 19:33.38 |
| Robin_Watts | Cool. | 19:33.45 |
| tor8 | Robin_Watts: pdf_load_embedded_cmap ... pdf_open_stream is followed by close then unlock if I read the code correctly | 19:39.23 |
| | that looks a bit... difficult to remember to do | 19:39.33 |
| | shouldn't the fz_close remember to do the unlock for that case? | 19:40.01 |
| Robin_Watts | tor8: Possibly. | 19:40.08 |
| | I tried to achieve that, but failed. | 19:40.17 |
| tor8 | a flag in the fz_stream to say if it should unlock on close doesn't work? | 19:41.17 |
| Robin_Watts | tor8: I tried to do it by nobbling fz_open_null to lock, and fz_close_null to unlock. | 19:43.32 |
| | but I backed that out because of problems elsewhere. | 19:44.08 |
| | It may be worth me trying that again. | 19:44.17 |
| | Ah, that won't work because of pdf_open_inline_stream | 19:45.08 |
| | So a simple int unlock_on_close; in the fz_stream might work. | 19:48.53 |
| | That would indeed be much nicer. | 19:49.04 |
| mvrhel | bbiab | 19:54.15 |
| ray_laptop | Ok, critical problem fixed for cust 532 (I hope) -- now back to the performance on 6thgen for that same customer | 20:05.22 |
| Robin_Watts | ray_laptop: Nice. | 20:09.15 |
| | tor8: OK, updated commit. That is much nicer. | 20:14.18 |
| tor8 | Robin_Watts: if the locks are per context, I don't see how that protects the FT_Library from multiple threads rendering at the same time | 20:52.28 |
| Robin_Watts | The locks are not per context. | 20:57.53 |
| | There is one set of locks for all contexts. | 20:58.25 |
| tor8 | so *all* file accesses are serialised | 20:58.40 |
| Robin_Watts | The debugging functions keep track of what contexts (threads) hold what locks to check for locking order violations. | 20:59.17 |
| | Yes. That's turned out really nicely. | 20:59.30 |
| | It means we can implement 'load image data from file on decode' if we want to. | 20:59.51 |
| tor8 | hmm, I guess it's not a problem in practice | 20:59.54 |
| Robin_Watts | tor8: On the contrary, it WOULD have been a problem without the locks. | 21:00.10 |
| | If we have 2 threads both trying to fseek and read at the same time, we'll get very bad results. | 21:00.34 |
| tor8 | oh, don't misunderstand me, it's better than no locks at all | 21:00.34 |
| Robin_Watts | The locking cures that. | 21:00.37 |
| tor8 | but ideally the lock would be on the file object instead of a global 'all files lock here' | 21:01.14 |
| | but that gets us deep into what threading library is used territory | 21:01.27 |
| Robin_Watts | tor8: True. | 21:01.28 |
| | but our two use cases are pdf and xps, both of which have just one base file (.pdf or .zip) | 21:02.03 |
| tor8 | exactly, and parsing two documents at the same time is probably never going to happen | 21:02.31 |
| | so in practice, who cares | 21:02.39 |
| Robin_Watts | Hmm. | 21:03.03 |
| | That can be done now by having 2 completely separate contexts and passing in a different set of locks to each. | 21:03.31 |
| | I was thinking of the '1 context for interpretation, n for rendering' case. | 21:04.07 |
| tor8 | right. but they'll have to be careful with the font lock due to freetype | 21:04.13 |
| Robin_Watts | The font lock takes care of all that for them. | 21:04.38 |
| tor8 | as long as they have only one font lock for all contexts | 21:04.53 |
| Robin_Watts | Yes. | 21:05.02 |
| tor8 | which is what I meant to say | 21:05.08 |
| | even if they have separate file locks, the font locks MUST be the same | 21:05.21 |
| Robin_Watts | Think of the 1 context, plus the n contexts cloned from it as being 1 context 'family'. | 21:05.21 |
| | All the locks within a family are the same. | 21:05.37 |
| tor8 | ah, right. that's why you clone, to share the store and freetype and cache | 21:05.50 |
| Robin_Watts | If they wanted to open 2 documents at once, they could create 2 context families. | 21:06.11 |
| | And each context family could have a completely different set of locks. | 21:06.26 |
| tor8 | so one new context per document, and cloned contexts for multithreaded access to said document | 21:06.29 |
| Robin_Watts | But that would mean those context families couldn't share the store. | 21:06.44 |
| | but I'll worry about that when it happens :) | 21:07.00 |
| | yes. | 21:07.09 |
| | Being called for food. ttyl. | 21:07.40 |
| endomafrendo | hi there, does someone know, whether there is any way to convert a grayscale pdf to only black and white with no shades of grey in between? | 21:19.54 |
| mvrhel | bbiaw | 23:06.47 |
| marcosw_ | alexcher: any update on Bug 692832? The customer said last week it was a critical issue for them and needed it fixed quickly. Even if you don't have a fix I'd like to assure them we are making progress. | 23:45.19 |
| | Forward 1 day (to 2012/02/09)>>> | |
IRC Logs