| | <<<Back 1 day (to 2013/07/14) | 2013/07/15 |
| ray_laptop | felipe: Hi, Don't think I've seen you here before. Are you here for gs or mupdf ? | 06:25.53 |
| vtorri | chrisl: hey | 06:30.37 |
| chrisl | vtorri: good morning | 06:30.47 |
| vtorri | chrisl: did you try to add the compilation of the shared lib on windows ? | 06:31.11 |
| chrisl | vtorri: on mingw, yes, we can already build the DLL on Windows | 06:32.14 |
| vtorri | is it in git ? | 06:32.34 |
| chrisl | It's in my private repo, but I need to test I haven't broken other platforms before I push to the central repo | 06:33.12 |
| vtorri | sure | 06:33.20 |
| | perfect | 06:33.25 |
| chrisl | If you want to have a look: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=summary | 06:33.35 |
| | Like I said, I didn't look at the install stuff, just the building of the lib, and the standard exes | 06:34.08 |
| vtorri | -fPIC wil be ignored on Windows | 06:36.11 |
| | it's a unix stuff | 06:36.15 |
| chrisl | I know, but it doesn't do any harm, and I ran out of time | 06:36.40 |
| vtorri | ok | 06:37.58 |
| chrisl | I've removed it here | 06:38.42 |
| vtorri | afaics, it should be good | 06:40.44 |
| chrisl | And I haven't broken it on Linux - only Mac and Sun to try...... | 06:41.21 |
| vtorri | for sun, you use openindiana or solaris ? | 06:41.45 |
| chrisl | Solaris and both gcc and Sun CC, and both gnu make and sun make | 06:42.19 |
| vtorri | ok | 06:42.30 |
| chrisl | This is on SPARC | 06:42.39 |
| sebras | tor5: hello boron-tor! | 08:23.39 |
| Robin_Watts | paulgardiner: Welcome back. Nice hols? | 09:17.05 |
| paulgardiner | Yeah. Great thanks. Luke had a cold so we didn't do as much walking as we'd have liked, but other main activities (drinking, eating) weren't hindered. | 09:19.22 |
| | House had a games room with big telly and 3/4 size snooker table - turned out a good choice. | 09:25.18 |
| Robin_Watts | paulgardiner, tor8: So, paul, while you've been away, I've got progressive loading working fairly nicely. | 10:05.48 |
| paulgardiner | Oh excellent | 10:06.07 |
| Robin_Watts | IF the stream identifies itself as progressive, then we check for linearity and load the linearised object from the top of the file, then read the first page from that. | 10:06.32 |
| | At that point, if we can do byte range fetches from the http stream, we read the hints stream to tell us where objects are. | 10:07.15 |
| | and we can then fetch subsequent pages fast. | 10:07.26 |
| | The current problem I'm facing is that while we find the shared objects by using the hint stream, we still find pages by linearly searching through the file. | 10:08.58 |
| | which means getting pages in non-linear order isn't possible, which is a bit of a git if you want to read page 1000 of a 1300 page file. | 10:09.22 |
| paulgardiner | remind me what shared objects means. | 10:10.23 |
| Robin_Watts | hold on, I've confused myself. | 10:10.54 |
| | Ah, ok. Unconfused. | 10:11.22 |
| | The linearised object contains a pointer to a "hints stream" | 10:11.40 |
| | The hints stream contains (basically) a list of numbers/offsets for each page. | 10:12.07 |
| | and a list of numbers/offsets for each 'shared object'. | 10:12.22 |
| | shared objects are objects (or groups of objects) used by more than one page. (so a font, for example) | 10:12.50 |
| | and then each page has a list of which shared objects it uses. | 10:13.07 |
| paulgardiner | Can the hierarchy of a page refer to other than shared objects? | 10:13.41 |
| Robin_Watts | paulgardiner: In linearised files, all resources are either specific to a page, or are shared objects. | 10:14.15 |
| paulgardiner | Ah. I read "numbers/offsets for each page" as one per page | 10:15.23 |
| | I'm now guessing it's the complete list of objects for the page, other than the shared obects. | 10:15.51 |
| Robin_Watts | It is one per page. | 10:15.52 |
| paulgardiner | Oh damn! Confused myself. Seems to be catching. :-) | 10:16.15 |
| Robin_Watts | But all the objects/numbers for page n will fall between page[n].{number,offset} and page[n+1].{number,offset} | 10:16.29 |
| paulgardiner | ... and I don't seem to be unconfusing | 10:16.30 |
| | Oh ok | 10:17.02 |
| | Hang on. That almost makes sense!! | 10:17.17 |
| Robin_Watts | so when asked to fetch page[n] we can start reading at the given offset, and read enough objects to reach the next one. | 10:17.24 |
| paulgardiner | Plus make sure we have all the shared objects refered to by that page | 10:17.53 |
| Robin_Watts | RIght | 10:18.00 |
| paulgardiner | ... which I think you said were listed | 10:18.07 |
| tor8 | Robin_Watts: can page 1 use the shared objects as well? | 10:18.14 |
| Robin_Watts | tor8: No. Page 1 is always sent entirely self contained. | 10:18.30 |
| tor8 | right. | 10:18.34 |
| Robin_Watts | (Although for various page accountancy reasons the objects in page 1 are all listed as shared objects) | 10:18.51 |
| tor8 | so after page 1, load shared objects, then the rest. is there a way to tell from the hint stream where the shared objects are? | 10:18.56 |
| Robin_Watts | tor8: Yes. | 10:19.03 |
| tor8 | so we could preload shared objects before loading a specific page if we wanted to avoid some of the "popping" | 10:19.35 |
| Robin_Watts | tor8: indeed. | 10:19.54 |
| | But I want to try to solve the page finding issues first. | 10:20.14 |
| | Currently, whenever we do an fz_page_load in progressive mode, I try to 'pdf_progressive_advance' | 10:20.41 |
| | That is, I continue to parse objects forwards from the previous "advance" position I was in. | 10:21.11 |
| | (where the advance position starts at the top of the file and moves forwards until we hit the end) | 10:21.26 |
| | As I go, whenever I find a dictionary with a /Type/Page this gives me the next page. | 10:21.44 |
| | When I hit the hint stream object, I load it, and then use the offset information within that to 'seed' the xref table. | 10:22.27 |
| | That way, when we run the page pdf_cache_object knows where to look for the shared objects. | 10:22.52 |
| paulgardiner | Could we have a stream call that means something like "will reads up to offset x succeed without blocking"? | 10:22.57 |
| | ... hmmm I'm probably trying to solve a non-problem | 10:23.31 |
| Robin_Watts | when it tries to read one of the shared objects, it'll probably fail because we won't be there in the stream fetch yet. | 10:23.33 |
| | paulgardiner: No, you're right. That's what I have in mind, but we'll get to that. | 10:23.46 |
| | so it'll throw a TRYLATER error. | 10:23.56 |
| | but the stream remembers where we tried to fetch, and the next http byte range request it sends is for the block that covers that area. | 10:24.18 |
| | so when we next try to render the page, it'll get a bit further. | 10:24.34 |
| | So the byte range fetches are driven by the page trying to load the shared objects. And the page knows where these shared objects are by the hint tables. | 10:25.30 |
| | But there are various problems with this. | 10:25.45 |
| | 1) I really don't trust the hint tables not to be horribly broken. | 10:25.57 |
| paulgardiner | I'm confused as to why we have to search. Is there not a way to find the hint streams without searching? | 10:26.01 |
| Robin_Watts | paulgardiner: We don't *need* to search to find the hint table. | 10:26.30 |
| | it's just that the way the code fell out was that we naturally 'advance' through the file to read the first pages data. | 10:27.10 |
| | Then the hint stream is the next thing in the file. | 10:27.20 |
| | Then we can use the hint stream to give us offsets for the rest of the file. | 10:27.41 |
| | I have to have normal non-seeking advance implemented as we may be on a connection which doesn't support byte-requests. | 10:28.10 |
| paulgardiner | I have to go. Back in ten or so | 10:29.11 |
| Robin_Watts | hence the "search" for the hint stream costs us nothing. It's just that every time we read an object we check to see if we've passed the point in the file where the hint stream is supposed to be - and if we have, the object we just read is the hint stream. | 10:29.13 |
| | ok. I'll keep burbling. | 10:29.26 |
| | and problem 2) I don't use the hint stream to help find pages. | 10:29.57 |
| | Regarding problem 1. Currently I populate the xref_entries with object types/offsets based on the hint streams. | 10:30.52 |
| | This is great if we trust the hint streams, but it would be possible to confuse everything if we met a broken hint stream. | 10:31.15 |
| | I am tempted to make a separate offset table just to keep the predicted object offsets in. | 10:31.59 |
| | Then when we do a pdf_cache_object, if we haven't got the offset of a given object yet, try to load it from the predicted offset. If it's there, great, it goes into the proper xref_entry. If not, we just throw a TRYLATER. | 10:33.06 |
| | That way we get the benefits of the hint table without opening ourselves up to being broken by them. | 10:33.28 |
| paulgardiner | We are susceptible to brokeness in the file in any case. Is there any reason to think that hint streams are likely to be less well created? I'd can sort of imagine that they might be more reliable because only really serious software would attempt to create them. | 10:42.18 |
| | Of course we mustn't crash, but... | 10:42.49 |
| Robin_Watts | paulgardiner: Even Acrobat produces hint streams that are broken in some regard. | 10:43.16 |
| | Essentially very few people use them, and there are no tools out there for verifying them. | 10:43.49 |
| paulgardiner | Is there anything other than Acrobat that produces them? And does Acrobat break them in a well-defined way? | 10:44.55 |
| Robin_Watts | paulgardiner: Yes other people produce them (they are required by the spec) | 10:45.45 |
| paulgardiner | If they were mostly reliable, we could fall back to downloading the whole file whenever an error was detected | 10:45.51 |
| Robin_Watts | paulgardiner: Right. That's what I'm shotting for. | 10:46.11 |
| | shooting for. | 10:46.15 |
| | brrb. | 10:46.19 |
| | back. | 10:53.56 |
| | If I write the values into the xref_entry's and they then turn out to be wrong, we have no way back from that. | 10:54.21 |
| | If I keep them separate and use them as 'hints' to the loading code, we can fall back to normal loading without me having poisoned our existing structures. | 10:54.54 |
| paulgardiner | So do TRYLATER exceptions and repeated parsing of some objects occur naturally as part of this process, not just in true error conditions? | 11:02.13 |
| Robin_Watts | paulgardiner: Yes/ | 11:09.42 |
| | TRYLATER means "I don't have enough data to fulfill this request yet, try again later" | 11:10.01 |
| paulgardiner | I'm wondering if that could be avoided if streams had a method by which one could ask what data is available. | 11:10.52 |
| chrisl | Grrr, words cannot express my contempt for Microsoft at this moment........ :-( | 11:12.24 |
| paulgardiner | If you come up with any words that do the job, please let me know. That's a common situation. | 11:14.21 |
| sebras | Robin_Watts: maywe we'd want to make a terse example implementation of this as well and stick it into docs...? | 11:14.39 |
| | Robin_Watts: similar to example.c and multi-threaded.c | 11:14.49 |
| | tor8: which I updated yeseterday... | 11:14.59 |
| chrisl | paulgardiner: I really don't think the appropriate words exist | 11:14.59 |
| Robin_Watts | sebras: mupdf-curl :) | 11:15.01 |
| | sebras: i.e. we have a test implementation. | 11:15.09 |
| sebras | Robin_Watts: yes, but is it short? | 11:15.22 |
| Robin_Watts | paulgardiner: curl-stream.c is pretty small, yes. | 11:15.39 |
| | That's got all the client side magic in it. | 11:15.48 |
| | All the rest of it is hidden in normal mupdf operation. | 11:16.04 |
| sebras | Robin_Watts: right. (though my name is not paul...) | 11:16.34 |
| Robin_Watts | details. | 11:17.08 |
| paulgardiner | Oops. Fell off irc | 11:18.52 |
| | When we read from a stream, presumably either something has already cached the data, or there will be a little delay and then we get the data, or the read fails and we throw TRYLATER | 11:20.04 |
| | Maybe the delay case doesn't happen. | 11:20.52 |
| | I wonder if we could implement a stream where we can always assure that data is cached before we attempt to read it, avoiding frequent tripping of error conditions and multiple parsing of the same data. | 11:21.53 |
| | Also might give us a way without polling to know what pages are available to view. | 11:23.53 |
| Robin_Watts | paulgardiner: Either the data is available immediately, in which case we return it, or we don't have it yet, in which case we TRYLATER, and remember the failed read to use to direct our next byte request. | 11:24.53 |
| | Something I have in mind is to have a 'preload' scheme whereby for each page we inform the stream of what data we will require, and it will say "OK, I have that all" or "No, I don't have it all yet" | 11:25.42 |
| paulgardiner | Yeah, that would be nice. | 11:26.00 |
| Robin_Watts | but that's a lower priority than making what I have robust and find pages faster. | 11:26.12 |
| paulgardiner | It might require OS-specific implementation | 11:26.25 |
| sebras | Robin_Watts: do we fetch data while the user is viewing the first page? | 11:26.49 |
| Robin_Watts | No more so than the httpstreaming already does. | 11:26.50 |
| sebras | Robin_Watts: or is it only done on-demand? | 11:26.58 |
| paulgardiner | I wonder if having that available might change how it best seems to implement the page finding. | 11:26.58 |
| Robin_Watts | sebras: Yes, the data fetches in the background on a thread. | 11:27.03 |
| | paulgardiner: I don't believe it will. | 11:27.17 |
| sebras | Robin_Watts: that's not really what I meant. I meant that even if mupdf has not requested anything beyond the first page and its resources, does the background thread continue to request the remainder of the file while the user is reading the first page? | 11:28.06 |
| tor8 | the preload scheme will only work if the file is linearized (with working hint streams), yes? | 11:29.23 |
| kens | Hmm, Robin_Watts I just assigned a bug to you but I dont think its yours, sorry. | 11:29.39 |
| | ANyoen know who owns JPEG decoder bugs ? | 11:30.01 |
| Robin_Watts | tor8: yes. | 11:30.04 |
| | sebras: Yes. The background thread will always be fetching. | 11:30.28 |
| | It will fetch onwards from the last point where data was required. | 11:30.45 |
| tor8 | Robin_Watts: then I'd not give it very high priority :) I think in the presence of Range-capable HTTP even normal pdf files should be good | 11:30.47 |
| paulgardiner | How does the jump to page 1000 case work? | 11:31.36 |
| Robin_Watts | tor8: The benefit of the preload scheme is that we save CPU time rerendering the page multiple times. | 11:31.37 |
| | paulgardiner: At the moment, it doesn't. | 11:31.46 |
| | or rather, we have to wait until it's loaded the non-shared data for pages 1-999 first :) | 11:32.11 |
| | Woo Hoo! Police interview for shotgun license at 1pm tomorrow. | 11:32.36 |
| paulgardiner | Robin_Watts: remember. NO JOKES!! | 11:32.53 |
| Robin_Watts | "I've got to shoot off to a meeting at 4." | 11:33.18 |
| | ec | 11:33.20 |
| | etc | 11:33.22 |
| chrisl | kens: it looks like DCT stuff has defaulted to henrys...... | 11:34.18 |
| kens | chrisl yes I just reassigned the bug to him :-) | 11:34.28 |
| chrisl | Ah, okay then! | 11:34.36 |
| paulgardiner | Robin_Watts: with the preload scheme, it should be possible to have a sort of "request preload page", "is page ready", "read page" type API, without multiple parsing and TRYLATERs | 11:34.39 |
| Robin_Watts | paulgardiner: Yes. although we'd lose out with that. | 11:35.05 |
| | At the moment we get pages rendered quickly (albeit maybe without the correct fonts or images) | 11:35.30 |
| paulgardiner | And no particular preference for page order loading. | 11:35.31 |
| Robin_Watts | and then as those resources arrive the rendering improves (what tor8 calls "popping") | 11:35.50 |
| | solving "no particular preference for page order loading" is a separate issue to the preload one. | 11:36.34 |
| paulgardiner | I imagined the system responsible for preloading would accept requests for particular pages. | 11:37.38 |
| Robin_Watts | paulgardiner: The problem with getting to a particular page is not that we can't drive the http fetcher to get it, but more that the page lookup doesn't use the hints. | 11:39.02 |
| paulgardiner | I thought the use of pdf_progressive_advance suggested page-order loading | 11:39.04 |
| Robin_Watts | Indeed. And by moving to load pages via hints the operation of pdf_progressive_advance would change. | 11:40.40 |
| paulgardiner | I know what it is: when we look at this problem as "what do I need to do to get hold of a page load of info" and "how do we make the current code get hold of a page load of info" we're getting quite different answers. | 11:41.43 |
| | The need to reparse and throw TRYLATER looks to be mostly because of making the current code do it, rather about what the PDF format requires. Is that right? | 11:42.34 |
| Robin_Watts | paulgardiner: That's always true to a degree. | 11:42.51 |
| | TRYLATER is down both to the way the current code works, but also because of the need to degrade gracefully. | 11:43.27 |
| | We need to cope with various different cases. | 11:43.35 |
| | 1) Non-progressive loading. | 11:43.50 |
| | 2) Progressive loading of a non-linearised file. | 11:43.58 |
| | 3) Progressive loading of a linearised file with broken hints | 11:44.17 |
| | 4) Progressive loading of a linearised file with working hints over a non byte-range capable stream. | 11:44.33 |
| | 5) Progressive loading of a linearised file with working hints over a byte range capable stream. | 11:44.47 |
| paulgardiner | Right. So is 2 in particualar hard to do without repeated parsing and TRYLATER? | 11:45.40 |
| Robin_Watts | Devising a scheme that works nicely for 5, but confers no advantages over 1 for 2,3,4 is worse than a scheme where each step up in the list gets better performance. | 11:46.09 |
| | 2 and 3 both require TRYLATER. | 11:46.49 |
| paulgardiner | Yes. I see the point now | 11:47.12 |
| Robin_Watts | and actually, I'm not sure that 3 and 4 can be usefully differentiated. | 11:47.22 |
| | in terms of things we can do. | 11:47.29 |
| paulgardiner | Still not understanding how pdf_progressive_advance fits with the possibility of non-page-order access. | 11:49.35 |
| Robin_Watts | pdf_progressive_advance is the way we discover page objects in the absence of hints. | 11:50.05 |
| | (well, not only page objects, but ALL objects in the file) | 11:50.21 |
| paulgardiner | Oh right. So not called when hints are present and working | 11:50.35 |
| Robin_Watts | When we have hints and byte range requests we can jump to objects much more efficiently. | 11:50.58 |
| | BUT there are still objects within the file that aren't page objects, and aren't shared references (like link annotations etc). | 11:51.24 |
| paulgardiner | Okay. I think I more or less get it now. | 11:51.44 |
| Robin_Watts | So we'll still need to have some form of pdf_progressive_advance running to pull in the other bits of the file. | 11:51.48 |
| | Essentially, I have cases 1,2,3 working now | 11:52.12 |
| | (maybe 1,2,3,4) | 11:52.16 |
| | I'm now figuring out how to add case 5 in a way that gracefully falls back to the other cases if the hints turn out to have been lying. | 11:52.43 |
| paulgardiner | Right. Hence the suggestion of a separate xref | 11:53.55 |
| Robin_Watts | yeah. | 11:54.50 |
| paulgardiner | Is it possible to trust the hints until evidence of their brokeness and then turn off their use? I guess you'd need to blank xrefs filled in by them | 11:55.10 |
| | Hence.... | 11:55.24 |
| Robin_Watts | paulgardiner: My plan is to use the hints to fill in a list of objects (NOT one of the standard xref tables) | 11:55.43 |
| | when we try to fetch an object that isn't in the xref, rather than baling immediately, we consult that table. | 11:56.19 |
| paulgardiner | That sounds good to me. | 11:56.31 |
| Robin_Watts | and we try to fetch an object from that table (using code extracted from pdf_progressive_advance) | 11:56.36 |
| | it that succeeds, we check the number of the object we got back; if it's the right one we populate the xref table and move on. | 11:57.06 |
| paulgardiner | If the hint misleads you, how do you know where to start searching? | 11:57.36 |
| | I suppose between page n offset and page n+1 offset | 11:58.00 |
| Robin_Watts | If it's an earlier one than we expect, we populate the xref table (with the one we just loaded), update the hint table and try again. | 11:58.18 |
| | If it's a later one than we expect, we populate the xref table (with the one we just loaded), blank that entry in the hint table, and try again. | 11:58.42 |
| | If we are asked to fetch object n, and we don't have a hint for object n, we do a linear search backwards in the hint table until we find an object that we DO have an offset for. | 11:59.27 |
| | and we can then load forwards from there. | 11:59.39 |
| paulgardiner | But if the object is not where the hint table says, might it not be anywhere in the file? | 12:01.15 |
| Robin_Watts | paulgardiner: Objects appear in order in linearised files. | 12:01.31 |
| paulgardiner | Oh right. Handy | 12:01.41 |
| Robin_Watts | (Well, in order, with a wrap around thing midway through the file) | 12:02.06 |
| | m..n,1..m-1 | 12:02.37 |
| paulgardiner | Yes. That's all sort of making sense now. Nice. Well when I say "nice", I'm glad I don't have to implement it. :-) | 12:06.17 |
| Robin_Watts | paulgardiner: Well, fortunately I didn't realise the whole horror of it when I started. | 12:06.47 |
| | and each sucessive step has been a modification of the previous one. | 12:07.09 |
| paulgardiner | Thank god for that. Would have sent me running away screaming. | 12:07.40 |
| Robin_Watts | henrys: back from Nebraska? | 13:32.09 |
| henrys | yes back from sabrina's art show, she won an award of a painting of a photo she took in the UK, she wants to come back and take more pictures. | 13:33.06 |
| Robin_Watts | henrys: Cool! We'd love to see you. | 13:33.26 |
| kens2 | LOL | 13:33.27 |
| Robin_Watts | I assume that's an award "for" a painting ? | 13:33.42 |
| henrys | Robin_Watts: yes | 13:34.10 |
| Robin_Watts | What was the picture of? | 13:34.59 |
| paulgardiner | Brilliant! Is anything of hers on line somewhere? | 13:36.32 |
| henrys | http://sabrinastiles.fineartstudioonline.com/dataviewer.asp?keyvalue=17361&subkeyvalue=887389&page=WorksZoom | 13:37.10 |
| Robin_Watts | henrys: But it's not raining in that photo. Are you sure that was taken while you were here? | 13:38.32 |
| henrys | paulgardiner: sabrinastiles.com should get you to everything | 13:38.40 |
| | Robin_Watts: actually artists/photographers like overcast settings light-wise so in that sense it was a good trip | 13:42.58 |
| Robin_Watts | yeah, Helen had a photoshoot last week for some publicity photos for her group. | 13:43.32 |
| henrys | the only problem is we can't remember where that shot is. Well we don't remember the name of the place. | 13:43.49 |
| Robin_Watts | I didn't see much of it, but when I popped over there the photographer was carefully arranging everyone in the shade. | 13:44.01 |
| | My instinct is to get as much light on the subject as possible, which I guess probably explains why I'm not a professional :) | 13:44.39 |
| paulgardiner | henrys: Wow! I like the way you can jump back and forward between seeing the brush work and then clearly seeing the subject and not undestanding how the brush work can create that image. | 13:46.17 |
| | Amazing colours too. | 13:46.27 |
| | ... not that I know anything about art. | 13:46.46 |
| henrys | it's all pastels - chalk like crayons. | 13:50.01 |
| | Robin_Watts: yea the light stuff isn't intuitive. | 13:50.46 |
| Robin_Watts | I think the trick is to have 'enough' light/contrast. having too light probably results in overexposed highlights and underexposed shadows. | 13:52.14 |
| | My photography is of the spray and pray variety. | 13:52.35 |
| henrys | but the uk more suit her than scenes here - she like the dark gloomy stuff and we don't have a lot of that. | 13:52.47 |
| Robin_Watts | Take lots and hope that some are in focus | 13:52.49 |
| henrys | Robin_Watts:I wonder when we'll take to just taking movies all the time in some wearable device and frame pics from it later. | 13:53.59 |
| | s/in/from/ | 13:54.14 |
| Robin_Watts | henrys: It's a nice idea, but real time video compression isn't there yet. | 13:54.36 |
| paulgardiner | Bah! "Gloom of Night" is sold. :-( | 13:54.50 |
| Robin_Watts | video frames are too small res, and the frame -> frame artifacts are too great. | 13:55.14 |
| henrys | yeah gloom of night sold really quickly she'll paint you another if you want. | 13:55.35 |
| paulgardiner | Ooo. Tempting. I wonder if I have a wall the right colour to mount it on anywhere in the house. I guess I could repaint a room. :-) | 13:56.28 |
| Robin_Watts | For short term bursts it's possible (Blackberry do something like that, and I think Sony might have something in their pe cameras). | 13:56.32 |
| henrys | we stayed at a sheep farm b & b and that is the road that led to the pub ;-) | 13:57.16 |
| paulgardiner | Is that the light from the pub in the trees? | 13:58.05 |
| henrys | don't really remember | 13:58.51 |
| martinrame | Since last week I cannot print anymore on an Ricoh Aficio 220 (network print). I'm using 12.04 64bits. The message i get is "/usr/lib/cups/filter/foomatic-rip failed". How can I debug the problem?. | 14:01.16 |
| henrys | Robin_Watts: no it isn't good enough for prime time. I suspect in 5 years it will be viable. | 14:01.18 |
| | Robin_Watts:of course it wouldn't be the first time we traded poor aesthetics for content - look at ebooks. | 14:02.41 |
| | martinrame: distribution? | 14:03.27 |
| martinrame | henrys: sorry, Ubuntu 12.04 | 14:03.36 |
| henrys | you should report it to them and if it is us they report it to us, martinrame | 14:04.13 |
| Robin_Watts | henrys: I think 5 years is hopeful. | 14:04.28 |
| | but as you say... | 14:05.49 |
| martinrame | henrys: ok, thanks. | 14:06.00 |
| henrys | kens:is there a way of punting on images in pdfwrite that will allow decimating to rectangles - if so I have an idea about fixing some of these transparency problems? | 15:45.04 |
| | punt == fallback - american football metaphor | 15:49.00 |
| kens | henrys, there's no swithc for it, but pdfwrite does do thsat sometimes | 15:49.36 |
| | but why ont convert to image instead ? | 15:49.55 |
| | err, forget that. | 15:50.17 |
| | While we do have a means to convert into lots (and ltos and lots) of little rects, its really inefficient | 15:50.43 |
| | And there's no way to enable it from the command line or anything like that. | 15:51.01 |
| | henrys did you see I assigned a JPEG problem to you ? | 15:51.37 |
| henrys | right we would only do it when the rop device is installed in the image code and turn it off at the end image. the library is careful to only use that when needed. | 15:51.47 |
| | I did you did mean decode not encode, yes? | 15:52.05 |
| kens | Well, that's certainly possible. | 15:52.06 |
| | Did I say encode ? I meant decode of course, yes | 15:52.21 |
| | My own JPEG decoder gets the answer right (ie same as Acrobat) | 15:52.36 |
| | But the windows image viewer gets the same result as Ghostscript, so I@m kind of puzzled | 15:52.58 |
| henrys | kens:well something to do with the color space interaction between the library and decoder I suppose. | 15:54.03 |
| kens | I'm not sure its the library. If I use the DCTDecode filter (just decoding the raw data stream, no image operator) its not the same as I get from my own JEPG decoder, or A N Other RIP | 15:55.00 |
| | But, as I say, it does match what I get by opening the DCT stream in the Windows image viewer..... | 15:55.26 |
| | visually that is. | 15:55.32 |
| henrys | how does mupdf open the pdf specimen you created? | 15:55.50 |
| kens | Perfectly, the same as Acrobat | 15:56.01 |
| henrys | we are using the same decoder. | 15:56.19 |
| kens | Yes, but maybe not in the same way :-) | 15:56.29 |
| henrys | I'll have a go at it, I need a break from guillaume and his crazy plots | 15:57.32 |
| kens | :-) I'm not sure JPEG decoding is any better..... | 15:57.49 |
| Robin_Watts | kens: It could be that the jpeg stream has some strange markers in it. | 16:01.01 |
| | which change the interpretation of the color space. | 16:01.17 |
| kens | Robin_Watts : I didn't see anything unusual in it. | 16:01.34 |
| Robin_Watts | and depending on whether the different apps extend the lib in the right way, you'll get completely different results out. | 16:01.51 |
| kens | Like I said, I have my ownimplementationd of a JPEG decoder, and it was fine with the output (sends it to TIFF) | 16:01.53 |
| | But that was what I was alluding to when I said we may not be using hte decoder in the same way in GS and MuPDF | 16:02.57 |
| | My initial thought was that we were not overrding the image colour space with RGB, because you need to *not* do that for JEPG2000, but you do for JPEG (another wonderful kludge in the spec) | 16:03.48 |
| henrys | I just noticed there is a "third party" in openjpeg that contains a bunch of our third party stuff - I wonder how that is resolved. | 16:17.50 |
| vtorri | chrisl: i have strange messages when i compile the DLL (which is compiled btw) | 16:19.59 |
| | chrisl: do you also have them ? | 16:20.09 |
| chrisl | vtorri: define "strange" | 16:20.31 |
| vtorri | strange to me :) | 16:20.40 |
| | node 'iccprofiles/default_cmyk.icc' len=187484 12 blocks, compressed size=138957 | 16:20.42 |
| | including: './lib/../Resource/Init/gs_std_e.ps' | 16:20.53 |
| | or | 16:21.05 |
| | ./soobj/aux_/gscdefs.c:84:41: warning: unknown escape sequence: '\T' [enabled by default] | 16:21.07 |
| chrisl | That's building the romfs file system - that very, very normal | 16:21.07 |
| vtorri | tons of them | 16:21.11 |
| | even the third one ? | 16:21.24 |
| chrisl | Not sure about that one | 16:21.32 |
| vtorri | ./soobj/aux_/echogs.exe -e .dev -w- -l-dev2 -b -s -l-include -l./soobj/page -l-obj ./soobj/png16 ./soobj/gdevpng.o ./soobj/gdevpccm.o | 16:22.00 |
| | normal too ? | 16:22.35 |
| chrisl | Yes | 16:22.40 |
| vtorri | ok | 16:22.44 |
| | it's normal to have 3 dll ? | 16:23.44 |
| | it's the same than on linux and the sym links ? | 16:23.59 |
| chrisl | Yes | 16:24.07 |
| vtorri | the which one is copied ? | 16:24.23 |
| | libgs-9-08.dll ? | 16:24.40 |
| | the others are copies, right ? | 16:24.48 |
| chrisl | No, I think the libgs.dll is the one we build, and then the others are "copies" | 16:25.36 |
| vtorri | ok | 16:26.55 |
| | thank you | 16:26.58 |
| chrisl | vtorri: It is standard practice on UNix systems to have the three names - it would be a fair amount more work to stop that happening just in mingw | 16:27.27 |
| vtorri | no problem | 16:27.45 |
| | usually, the information is in the import lib | 16:28.00 |
| | that's why i ask | 16:28.09 |
| | so when you link with | 16:28.24 |
| | -lgs | 16:28.27 |
| chrisl | I didn't look that closely because the two "loader" applications both worked correctly as soon as I got the DLL building (much to my surprise) | 16:29.16 |
| vtorri | the linker will find the import lib (libgs.dll.a) and will use the dll name which is in libgs.dll.a for runtime | 16:29.18 |
| | i'll try with my lib | 16:29.38 |
| | thank you very much | 16:29.42 |
| chrisl | Okay, so I might need to do something more with the import lib to have it correctly pick up the libgs-9.dll (rather than libgs.dll)? | 16:30.35 |
| vtorri | when you call gcc -shared etc... | 16:31.20 |
| | you pass the name of the dll and of the import lib | 16:31.35 |
| | that's this very name which will be used | 16:31.49 |
| | the others are useless | 16:32.00 |
| | so | 16:33.39 |
| | gcc -shared -o libgs-$(major) --output-implib=libgs.dll.a etc... | 16:34.11 |
| | can't remember if it's --output-implib but you have the idea | 16:34.29 |
| | oups | 16:34.36 |
| | gcc -shared -o libgs-$(major).dll --output-implib=libgs.dll.a etc... | 16:34.41 |
| | usually, only the major version (which characterize the API/ABI version) is necessary | 16:35.20 |
| chrisl | Right, I have a feeling we might be pass libgs.dll - so that might need some work - I'll have to check | 16:35.30 |
| vtorri | but that's a very good start | 16:35.43 |
| chrisl | vtorri: what you've got now is enough to get to started, yes? | 16:36.19 |
| vtorri | it's enough to compile my module, i think | 16:38.13 |
| | about the header, only api.h is needed right ? | 16:38.25 |
| | or gapi.h | 16:38.31 |
| | i can't remember | 16:38.36 |
| | iapi.h :) | 16:40.42 |
| chrisl | Yes, I was just going to say look in dxmainc.c for hints | 16:41.08 |
| vtorri | ierrors.h too i htink | 16:41.24 |
| | thanks | 16:41.25 |
| | time to leave | 16:41.33 |
| | bbl | 16:41.34 |
| kens | Goodnight all | 16:49.28 |
| rayjj | bbiab | 17:08.47 |
| Robin_Watts | Woo Hoo! | 17:17.32 |
| | I can jump to anywhere in a file as it downloads now. | 17:18.26 |
| | Takes a few seconds for the stuff to arrive for that page, but it's pretty bloody good. | 17:18.45 |
| henrys | tor8:did you look into the jpeg stuff with color_transform and saw_Adobe_marker - mupdf and gs have it differently, see gs/base/sdctd.c:197, if you've studied it already we can just use the mupdf answer - I have one example that indicates mupdf right and gs wrong. | 17:19.32 |
| | s/answer/logic | 17:19.48 |
| tor8 | henrys: at one time I did, I think Robin_Watts poked at it fairly recently though | 17:20.34 |
| | and fixed some bugs we had | 17:20.45 |
| Robin_Watts | tor8, henrys: I thought it might have been me too, but blame says tor :) | 17:21.52 |
| henrys | right but you apparently fixed in mupdf filter-dct.c:133 is quite different than the gs code. | 17:23.40 |
| | if you are fairly confident with what mupdf has now (it seems to print my file correctly) we'll use it in gs. | 17:24.47 |
| Robin_Watts | henrys: I stared at some nasty JPEG problems a while ago, and I *think* mupdf gets them right now. | 17:25.16 |
| | hence I'd trust mupdf. | 17:25.32 |
| henrys | thanks | 17:25.41 |
| Robin_Watts | Our logic dates from: http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commit;f=fitz/filt_dctd.c;h=d7d695375b21693688328ee2cdc3085c8e6f2943 | 17:27.02 |
| | which is before my time. | 17:27.19 |
| | so tor gets credit/blame. | 17:27.25 |
| | windowers wanting to play: http://ghostscript.com/~robin/mupdf-curl.exe | 17:27.53 |
| | mupdf-curl.exe http://ghostscript.com/~robin/pdf_reference17.pdf | 17:28.13 |
| | then use (say) 1150g to jump to a late page. | 17:28.28 |
| henrys | Robin_Watts: will that be in the release? | 17:28.49 |
| Robin_Watts | henrys: It's not been pushed yet. | 17:29.01 |
| | but depending on how the next week or so goes, maybe. Why? | 17:29.14 |
| henrys | a good thing for the newsletter | 17:29.20 |
| Robin_Watts | I'll do a write up if it looks like being in danger of making it :) | 17:29.51 |
| henrys | okay | 17:30.01 |
| | we really should find some way that fixes get reflected in mupdf and gs, discovering things 2x is not a good use of time. | 17:31.19 |
| | oh but mupdf is broken with respect to cmyk | 17:51.50 |
| | surely that color transform should not be 0 in gs is num_components == 4 | 17:52.10 |
| | s/is/if | 17:52.48 |
| Robin_Watts | Do you have an example file where we get it wrong? | 17:56.15 |
| henrys | Robin_Watts: no but you don't do cmyk at all so it probably is okay for mupdf but gs does cmyk. | 18:00.37 |
| Robin_Watts | We render CMYK images correctly. | 18:00.56 |
| | just as rgb. | 18:01.04 |
| henrys | oh right yes. | 18:01.25 |
| | why would color transform be 0 if components == 4 strange. | 18:01.43 |
| Robin_Watts | color transform = -1 means "unset" | 18:02.17 |
| | 0 means "default" ? | 18:02.24 |
| henrys | you wold always be setting the color space to JCS_YCCK do you intend that? | 18:02.33 |
| Robin_Watts | and non-zero means "what adobe said" ? | 18:02.34 |
| | henrys: quite probably. | 18:02.53 |
| henrys | well the regression test might have something to add ;-) | 18:05.13 |
| Robin_Watts | Let's see what it says. | 18:06.58 |
| henrys | I logged into Skype with Facebook how do I change the account name or am I stuck with it. | 18:08.01 |
| Robin_Watts | Skype => Edit your profile ? | 18:08.36 |
| henrys | mvrhel_laptop said some weird name was coming up | 18:08.37 |
| Robin_Watts | I still see "Henry Stiles" | 18:09.02 |
| mvrhel_laptop | Now I see that | 18:09.34 |
| | I also saw facebook:henry.stiles.y | 18:09.50 |
| | opps | 18:09.53 |
| | s/.y/.7/ | 18:10.00 |
| | this is pretty funny http://www.cracked.com/article_19155_the-14-most-unintentionally-terrifying-statues-in-world_p2.html | 18:11.11 |
| | I have only seen #4. #1 looks like you can walk inside | 18:11.47 |
| henrys | I see #4 all the time, ungodly | 18:12.18 |
| | and it's cursed the horse apparently fell and crushed the sculptor | 18:12.38 |
| | of I mean #5 | 18:12.52 |
| mvrhel_laptop | really? | 18:13.15 |
| Robin_Watts | mvrhel_laptop: Nice. | 18:13.58 |
| mvrhel_laptop | I thought you might appreciate that Robin_Watts | 18:14.39 |
| henrys | hm we have some machines down | 18:15.17 |
| mvrhel_laptop | anyway back to the windows phone saltmine. I have the file streaming working. just need to figure out what xaml object would be best to use for displaying the pages. | 18:15.43 |
| | missing a lot of stuff in the phone compared to windows 8 | 18:15.53 |
| henrys | marcosw:are you about? | 18:16.18 |
| marcosw | sort of, I'm at Miles' office up to my neck in cluster nodes | 18:20.28 |
| henrys | marcosw:no big deal just was curious when the gcov stuff will update. I've made some changes and I'd like to see the new situation. | 18:43.37 |
| marcosw | I can launch an update later today, assuming I manage to get the cluster put back together :-) | 18:44.04 |
| mvrhel_laptop | bbiaw | 18:55.18 |
| | watch window in visual studio does not work when you are debugging on a real phone only the emulator. worked fine on the surface though | 20:53.04 |
| | Forward 1 day (to 2013/07/16)>>> | |
IRC Logs